|
|
Spravuje: Mr.Spock
Počet příspěvků: 3834
|
Bývalá veřejná diskuse členů vývojářského týmu WDK Games, do které se mohl zapojit opravdu ka?dý, dnes "jen" nejnav?těvovaněj?í fórum s řadou hybridních bytostí bez mozku...
|
|
| Anonym: Unimatrix325 - 30. červen 2002 11:34 |  |
| ZAMĚŘIT
|
|
| | | BTW napi?tě mi sem prosím v?ichni svůj mail, abych zase něco nemusel posílat přes Koviho :-) něčí u? znám, ale něčí je?tě ne, tak aby v tom nebyl bordel...
BTW muj mail je Unimatrix325@seznam.cz |
|
|
| Anonym: Unimatrix325 - 30. červen 2002 11:32 | |
| ZAMĚŘIT
|
|
| | | Happz : dostals od Koviho ty data ? (tři jpg,dvě doc) co tomu říká? ? |
|
|
|
| | | No co fora, spis cvsko - ale to uz se brzy zmeni, zanedlouho prijde upload GUI a hotoveho galscreenu. |
|
|
|
| | | BTW. Nase SourceForge fora dost zejou prazdnotou :( |
|
|
|
| | No... blendery se snad ani nesnaz pochopit :) Kdyz sem poprve cetl manual k Allegru uplne sem se zdesil :) Je jich tam tak 30.
V podstate ukolem blenderu je interpolovat barvy bitmapy a cilovou barvu.... |
|
|
|
| | | mam, necekane se to jmenuje fblend :) |
|
|
|
| | Aha, ja uz se zdesil...
Na blendery jsem koukal, ale moc jsem to nepochopil :( Obcas netusim, co ktera ta fce ma delat, a na allegro.cc jsem ennasel tu knihovnu, o ktere jsi mluvil - mozna jsem spatne koukal, radsi to udelam jeste jednou. |
|
|
|
| | No, to si pochopil spravne :))) ale nepochopil's me :))).
Ja to myslel obecne. Bitmapa se zamyka pri kazde operaci (pokud nebyla zamcena predem) - pixel je v tomhle pripade extremni pripad. Stejne sem moh napsat treba blit...
BTW. Koukal ses na ty blendery ? |
|
|
|
| | | No, ja to pochopil tak, ze se zamyka cela bitmapa - ne jednotlive pixely, to by bylo IMHO dost silene. |
|
|
|
| | Ja sem to z manualu pochopil nasledovne:
Pokud bitmapa nejni zamknuta, tak se pri jakekoli operaci provede maraton zamkni-"operuj"-odemkni. V tomto pripade (zamykani pro kazdej pix :) to bezesporu pomale bude :)).
Pokud ale je bmp zamkla, uz se jen "operuje"....
(to je pouze muj vyklad manualu, ale...) |
|
|
|
| | naku: ani tak moc nejde o zamykani v poradi, jako spis o to, ze je pry 'velmi' pomale pod DirectX. Uvidime.
PVH: jo, to by se casem hodilo |
|
|
|
| | | při označení flotily ( pozor planet se na galmapu označit nedá, je jen vypsaná) v podstatě nic nestane, jen se zpřístupní mo?nost poslání lodi kamkoliv na mapu, jediným kliknutím. Myslim, ?e to ti zabere dost času...mimochodem asi ti dodám něaký bitmapy který bude? vykreslovat jako cestu lodi...popřemej?lim o tom... |
|
|
|
| | Zamykani ? To je detail...
zamknes - vse vykreslis - odemknes
Pri dobre strukturovanem programu (a nepochybuju, ze ten tvuj je zatracene dobre strukturovanej :) to nejni problém... |
|
|
|
| | Hm, prave na to jsem taky koukal - nekdy to nemusi vyjit, a zase pro DirectX poznamenavaji, ze ma potize se zamykanim a odemykanim - tam bysme asi neusetrili vubec nic. Uvidime, zatim to necham takhle, ozivime klienta a pak muzeme testovat rychlost. Rozhrani je pripravene, ale pere to zatim primo na screen.
No, mel bych par dotazku, uz skoro koncim s galscreenem :-) a potrebuju poradit:
co se bude dit po kliknuti na ikonu flotily v sektoru na galmap, co po kliknuti na ikonku planety, stanice atd. Potom, co a jak se ma vypisovat do listboxu - pri vybranem systemu, pri nezvolenem systemu (tam predpokladam, ze nic :)
Tak, tohle si rozmyslete, a poslete odpoved. Tohle je asi to posledni, co mi chybi na galscreenu. |
|
|
|
| | | Nemusi to byt nutne pravda. Pokud bude d-buffer video bitmapa tak to bude akcelerovany a ten blit bude fakt rychlej, ale inicializovat prvky GUI jako video mapy je sazka do loterie... kdo vi, kdo a jak ji ma velkou ? |
|
|
|
| | To se neopovazuj! Nemuze to byt ruchlejsi, kdyz se vykresli jen maly obdlnicek, nebo vykresleni celeho d-bufferu. Tam je to jednoducha matematika, maly obdelnik, nebo velky obdelnik? Vsechno ostatni je totiz stejne. ALE: uz konecne vim, proc sme ho chteli udelat - to scrollovani :) Ja si furt nemoh vzpomenout :(
No, a i kdybych si nevzpomnel, stejne jsem napsal rozhrani, pres ktere se vykresluje, a pod ktere pak muzeme primo soupnout ten d-buffer. Zatim to jde primo na screen, pozdeji s tim scrollovanim bude d-buffer. |
|
|
|
| | | BTW. Buffer se mazat nemusi. Nikdo nas nenuti prekreslovat to vsechno. Opovazuji se tvrdit, ze to mozna bude rychlejsi krz d-buf i s jen decentnima zmenama... |
|
|
|
| | | Na druhou stranu - paklize D-buffer zavedeme, zbavime se te agendy, kod moc nezpomalime a (to predevsim) jestli budem zavadet nekdy v budoucnu plynulej scrolling tak se bez d-bufferu neobejdeme... |
|
|
|
| | Naku: vysledna agenda - ta stejne bude, ptze by pak i to vykreslovani do bufferu stalo hodne casu a hodne pripisu, ktere vubec byt nemusely. A na screen se vykresluji pouze zmenene oblasti - nikdy se nemaze! Pokud se prekresluje map area, tak ta se vykresli do bufferu a ten se cely soupne na screen - tady si trochu ulehcuju praci, dalo by se to napsat rychleji, ale musel bych se hodne hlidat - verze 2 :)
COz o to, ten system chapu, ale nevidim duvod, proc ho pouzit. Vzdycky - zatim - dochazi k tomu, ze je treba zmenit jen malou cast screenu, a proto IMHO neni potreba prekreslovat ho celej. Staci blitnout jen zmenenou oblast. |
|
|
|
| | Modelova situace:
Na obrazovce se pohybuje n ctvercu (sprajtu...) a
obazovka ma na pozadi bitmapu.
Postup bez d-bufferingu:
-smaz screen - pomale az hruuuza !
-vykresli ctverce - pomale...
Postup s d-bufferingem:
-smaz buffer - rychle, jen pametova operace
-vykresli ctverce do bufferu - rychle
-blit buffer - nejpomalejsi cast celeho procesu, ale relativne rychle...
Co se tyce dalsich moznosti (ctverce si pmatuji co je pod nima etc.) vysledna agenda bude nakladna (pametove, kodove) a ne o moc efektivnejsi... |
|
|
|
|
HLAVNÍ STRÁNKA
UŽIVATELÉ
DISKUZNÍ FÓRA
VYHLEDÁVÁNÍ
STATISTIKY
AKCE
NASTAVENÍ
FAQ
[ ARCHÍV ]
|
