Zobrazit předchozí téma :: Zobrazit následující téma |
Autor |
Zpráva |
jjub
Založen: 21. 08. 2009 Příspěvky: 6
|
Zaslal: 22. srpen 2009, 12:31:38 Předmět: Neostrý pohyb spritu v SDL |
|
|
Zdravím,
mám takový problémek v knihovně SDL. Snažím se udělat nějakou jednoduchou vesmírnou střílečku, mám již tak nějak udělaný pohyb hráčovy raketky, ale její pohyb je značně "neostrý" (vypadá to jako pohyb zdvojeného spritu). Nevím, jestli je chyba v mém kódu nebo že je to problém typu "takhle to má být, ten pohyb bude vždycky rozmazaný, s tím nic neuděláš", proto bych poprosil o radu. Ještě dodám, že používám softwarový surface (hardwarový mě to nepovolí a když jsem změnil v SDL vykreslovací driver na directx, tak i poté byl na hardwarovém surface s doublebufferingem pohyb neostrý - navíc se rychlost vykreslování scény snížila). Zde je zdrojový kód hlavní herní smyčky (bude-li to třeba, není problém dodat kompletní zdrojový kód):
http://nopaste.ceske-hry.cz/222737
Naposledy upravil jjub dne 22. srpen 2009, 14:05:22, celkově upraveno 1 krát |
|
Návrat nahoru |
|
 |
nou

Založen: 28. 07. 2007 Příspěvky: 1050
|
Zaslal: 22. srpen 2009, 13:01:41 Předmět: |
|
|
1. taketo dlhe kody patria na http://nopaste.ceske-hry.cz/. edituj ten prispevok a presun ten kod tam. sem daj len okdaz.
2. co myslim tym neostry. vidis za lodou ducha alebo to ze je pohyb nepravidelny. ak to ze nejde plynulo tak je to tym ze casovac ktory pouzivas nie je moc presny. roby sa to asi takto
kód: |
while(1)
{
spracujEvent();
if(ubehlo uz 10ms)DrawScene();
} |
_________________ Najjednoduchšie chyby sa najtažšie hľadajú. |
|
Návrat nahoru |
|
 |
jjub
Založen: 21. 08. 2009 Příspěvky: 6
|
Zaslal: 22. srpen 2009, 14:11:12 Předmět: |
|
|
Omlouvám se, již jsem to editoval a budu si to do budoucna pamatovat...
Jinak neostrý vskutku myslím to, že vidím za raketkou ducha (myslel jsem si, že je to kvůli tomu, že nepoužívám doublebuffering, ale jak jsem psal v prvním příspěvku, i v hardwarovém surfacem s DB to ty duchy dělalo), samotný pohyb je docela i pravidelný. |
|
Návrat nahoru |
|
 |
JohnyDog

Založen: 17. 08. 2007 Příspěvky: 66
|
Zaslal: 22. srpen 2009, 14:46:43 Předmět: |
|
|
jjub napsal: |
Jinak neostrý vskutku myslím to, že vidím za raketkou ducha |
Screenshot ? _________________
 |
|
Návrat nahoru |
|
 |
jjub
Založen: 21. 08. 2009 Příspěvky: 6
|
Zaslal: 22. srpen 2009, 15:26:47 Předmět: |
|
|
Screenshot jsem si zkoušel udělat již dříve, na výsledném obrázku žádný duch nebyl, raketka byla ostrá, proto se spíše kloním k názoru, že ten duch je prostě chyba lidského oka...Každopádně uploadoval jsem již zkompilovanou hru, zajímal by mě tedy Váš názor, jestli je to tedy normální či nikoliv:
http://uloz.to/2337955/dvs.zip |
|
Návrat nahoru |
|
 |
JohnyDog

Založen: 17. 08. 2007 Příspěvky: 66
|
Zaslal: 22. srpen 2009, 15:39:41 Předmět: |
|
|
jjub napsal: |
Screenshot jsem si zkoušel udělat již dříve, na výsledném obrázku žádný duch nebyl, raketka byla ostrá, proto se spíše kloním k názoru, že ten duch je prostě chyba lidského oka...Každopádně uploadoval jsem již zkompilovanou hru, zajímal by mě tedy Váš názor, jestli je to tedy normální či nikoliv:
http://uloz.to/2337955/dvs.zip |
Ja tam zadneho ducha nevidim takze bych se klonil k nazoru ze je to zpusobeno odezvou toho LCD monitoru na kterem to zkousis
Edit: na druhou stranu kdyz se divam na ten kod tak posouvas tu lod skokove jen jednou za X framu, coz na plynulosti neprida, mel by si posouvat o kousek pri kazdem prekresleni (a idealne tedy nepouzivat timer vubec ale nekonecnou smycku a pocitat pozici v zavislosti na case) _________________
 |
|
Návrat nahoru |
|
 |
jjub
Založen: 21. 08. 2009 Příspěvky: 6
|
Zaslal: 27. srpen 2009, 11:25:22 Předmět: |
|
|
No vyzkoušel jsem to i na rychlejším LCDčku a duchy vidím pořád, ale jestli říkáte, že je to v pořádku, tak slevuji ze svých nároků
Co se týče kódu, tak tu loď opravdu posouvám každý frame, resp. funguje to tak, že každých 10ms se aktualizují souřadnice raketky (ale netiskne se na obrazovku) a každých 30ms se vytiskne celá scéna...Nejsem si také jist, jestli rozumím té závislosti pozici na čase, to se potom využívá SDL_GetTicks() a když chci aktualizovat pozici raketky, tak se spočítá dle diference času mezi jednotlivými aktualizacemi souřadnic (co mají vlastně všichni proti timeru? Já sice vím, že jeho přesnost není zázračná, ale někde jsem četl, že GetTicks na tom také není moc slavně)?
BTW: také se omlouvám za své lamácké dotazy, co se týče programování her jsem začátečník  |
|
Návrat nahoru |
|
 |
quas4
Založen: 18. 10. 2007 Příspěvky: 199
|
Zaslal: 27. srpen 2009, 12:25:36 Předmět: |
|
|
jjub napsal: |
No vyzkoušel jsem to i na rychlejším LCDčku a duchy vidím pořád, ale jestli říkáte, že je to v pořádku, tak slevuji ze svých nároků
Co se týče kódu, tak tu loď opravdu posouvám každý frame, resp. funguje to tak, že každých 10ms se aktualizují souřadnice raketky (ale netiskne se na obrazovku) a každých 30ms se vytiskne celá scéna...Nejsem si také jist, jestli rozumím té závislosti pozici na čase, to se potom využívá SDL_GetTicks() a když chci aktualizovat pozici raketky, tak se spočítá dle diference času mezi jednotlivými aktualizacemi souřadnic (co mají vlastně všichni proti timeru? Já sice vím, že jeho přesnost není zázračná, ale někde jsem četl, že GetTicks na tom také není moc slavně)?
BTW: také se omlouvám za své lamácké dotazy, co se týče programování her jsem začátečník  |
naopak, me tento problem pripada dulezity. Vetsina lidi zde zna a pouziva jen variabilni timestep ("delta timer") nebo nejaky jeho hybrid. Doporucuju (uz jsem to na tomto foru nekolikrat linkoval) fixni timestep a vizualni interpolaci: http://gafferongames.com/game-physics/fix-your-timestep/ coz ti vyresi tve "duchy" (a s odezvou LCD to nema moc spolecneho ). Vysledek skutecne stoji za to. |
|
Návrat nahoru |
|
 |
jjub
Založen: 21. 08. 2009 Příspěvky: 6
|
Zaslal: 27. srpen 2009, 16:51:15 Předmět: |
|
|
Děkuju za odkaz, prostuduju, pokusím se implementovat a podám zprávu  |
|
Návrat nahoru |
|
 |
pavolzetor
Založen: 06. 09. 2008 Příspěvky: 12
|
Zaslal: 27. srpen 2009, 19:28:20 Předmět: |
|
|
ja som mal kedysi takého ducha v hre keď som mal CRT a bolo biele na čiernom pozadí |
|
Návrat nahoru |
|
 |
pcmaster

Založen: 28. 07. 2007 Příspěvky: 1827
|
Zaslal: 28. srpen 2009, 13:51:11 Předmět: |
|
|
quas4 napsal: |
...
naopak, me tento problem pripada dulezity. Vetsina lidi zde zna a pouziva jen variabilni timestep ("delta timer") nebo nejaky jeho hybrid. Doporucuju (uz jsem to na tomto foru nekolikrat linkoval) fixni timestep a vizualni interpolaci: http://gafferongames.com/game-physics/fix-your-timestep/ coz ti vyresi tve "duchy" (a s odezvou LCD to nema moc spolecneho ). Vysledek skutecne stoji za to. |
Musim povedat, ze som uz na tuto temu cital kopec clankov, ale tento typek to opisal fakt dobre. Dik za link. _________________ Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est. |
|
Návrat nahoru |
|
 |
Al
Založen: 23. 10. 2007 Příspěvky: 196
|
Zaslal: 3. září 2009, 20:14:30 Předmět: |
|
|
Aby clovek videl souvislost s puvodnim dotazem zde a tim clankem "fix your timestep", to uz chce fakt velkou predstavivost. Nezpochybnuji ten clanek, ale tady se zacatecnik pta na pohyb raketky, ne raketovy vedec na chybu v numericke integraci zpusobenou variabilnim frame ratem. Tazatel proste nesmyslne pocita cas po 10 ms a kresli po 30 ms, to jde opravit i bez nastudovani spickovych algoritmu ze slozitych fyzikalnich simulaci a navic to dokonce i po aplikaci veci z toho clanku nemusi byt dobre, protoze tazatel tam celkem pravdepodobne ma jine ci dalsi nedostatky, ktere se na tom podileji.
Ja bych proto dal tazateli jednodussi a srozumitelnejsi radu: Nebudou tam duchove, kdyz budes kreslit obraz pro kazdy snimek obrazovky a nakreslis tu raketku na spravne misto. Pri pohybu to v jednotlivych snimcich nesmi byt treba 0,1,1,2,3,3,4,5,5,6,7,7,8... nebo dokonce 0,0,2,2,4,4,6,6... Tohle jsme resili jako vizualni problem uz na 8bitovych pocitacich pripojenych na televizi a tam vubec neslo o zadne fyzikalni simulace. Ty ciselne rady pozic pro tyto dva pripady proste museji byt 0,0.7,1.3,2,2.7,3.3... a 0,1,2,3,4,5,6... |
|
Návrat nahoru |
|
 |
Ladis

Založen: 18. 09. 2007 Příspěvky: 1537 Bydliště: u Prahy
|
Zaslal: 3. září 2009, 21:40:19 Předmět: |
|
|
Al napsal: |
Pri pohybu to v jednotlivych snimcich nesmi byt treba 0,1,1,2,3,3,4,5,5,6,7,7,8... nebo dokonce 0,0,2,2,4,4,6,6... Ty ciselne rady pozic pro tyto dva pripady proste museji byt 0,0.7,1.3,2,2.7,3.3... a 0,1,2,3,4,5,6... |
Podle mě je správně je zarovnat na celé pixely, tj. ta první těch 0,1,1,2,3,3,... Protože co znamená ta desetinná část u 2D hry? Že pixely spritu se nebudou mapovat 1:1 na pixely obrazovky. (U vykreslování 2D spritů přes 3D API to jde mít "mezi pixely", ale je to z toho důvodu neostré/máznuté - aspoň já ve svých 2D hrách vyrkeslovaných přes OpenGL zajistil to zarovnání na celé pixely, monitory maj dnes dostatečně jemné rozlišení.) _________________ Award-winning game developer |
|
Návrat nahoru |
|
 |
Al
Založen: 23. 10. 2007 Příspěvky: 196
|
Zaslal: 3. září 2009, 23:35:03 Předmět: |
|
|
Podle vysvetleni puvodniho tazatele to vypada, ze tam treba taky ma mozna neco uplne atypickeho jako 0,0,3,3,6,6,6,9,9,12,12... (tri sestky tam jsou schvalne).
Ty desetinky je treba resit pri pomalych pohybech. Ty jsou bez nich hnusne. Rychle pohyby to tolik nepokazi, kdyz to bude celociselne. No a k tomu sporu: 2D grafiku muzes delat 3D enginem, ne? Ta graficka karta stejne ma jen jeden engine a jen lidi tomu rikaji "3D" nebo "2D". Viz stara dobra 3Dfx sveho casu jednicka na trhu - ta ma jen 2D engine, vubec nic 3D krome nazvu v ni neni.  |
|
Návrat nahoru |
|
 |
quas4
Založen: 18. 10. 2007 Příspěvky: 199
|
Zaslal: 4. září 2009, 09:17:24 Předmět: |
|
|
Al napsal: |
Aby clovek videl souvislost s puvodnim dotazem zde a tim clankem "fix your timestep", to uz chce fakt velkou predstavivost. Nezpochybnuji ten clanek, ale tady se zacatecnik pta na pohyb raketky, ne raketovy vedec na chybu v numericke integraci zpusobenou variabilnim frame ratem. Tazatel proste nesmyslne pocita cas po 10 ms a kresli po 30 ms, to jde opravit i bez nastudovani spickovych algoritmu ze slozitych fyzikalnich simulaci |
O slozitych fyzikalnich simulacich nebyla rec a clanek fyziku pouziva jen jako 'prostredi' ve kterem osvetluje problem.
Al napsal: |
a navic to dokonce i po aplikaci veci z toho clanku nemusi byt dobre, protoze tazatel tam celkem pravdepodobne ma jine ci dalsi nedostatky, ktere se na tom podileji. |
Jake jine nedostatny? Nebo jen hadas?
Al napsal: |
Ja bych proto dal tazateli jednodussi a srozumitelnejsi radu: Nebudou tam duchove, kdyz budes kreslit obraz pro kazdy snimek obrazovky a nakreslis tu raketku na spravne misto. |
A o to presne jde - "na spravne misto" - clanek proste jen vysvetluje ze toto spravne misto (pozice) pri posouvani objektu neni prave jeho aktualni pozice ale interpolace mezi jeho predchozi pozici a soucasnou. To je vse - zadna slozita fyzikalni simulace.
Al napsal: |
Pri pohybu to v jednotlivych snimcich nesmi byt treba 0,1,1,2,3,3,4,5,5,6,7,7,8... nebo dokonce 0,0,2,2,4,4,6,6... Tohle jsme resili jako vizualni problem uz na 8bitovych pocitacich pripojenych na televizi a tam vubec neslo o zadne fyzikalni simulace. Ty ciselne rady pozic pro tyto dva pripady proste museji byt 0,0.7,1.3,2,2.7,3.3... a 0,1,2,3,4,5,6... |
ty ciselne rady znamenaji dejme tomu napr. x-ove hodnoty objektu tak jak jdou snimky za sebou? Pokud ano tak 1. proc by se objekt nemohl pohybovat nelinearne?? 2. algoritmus o kterem tady mluvim je zalozen na oddeleni posouvani objektu od jeho vykreslovani. |
|
Návrat nahoru |
|
 |
|