Pozicování objektů v SDL

[dadajax]

Mám takový menší problém. Chtěl bych udělat nějakou menší hru, něco ve stylu 2D střílečka viděna z vrchu. Něco fakt jednoduchého, abych na tom pochytil nejen základy tvorby her, ale taky si pořádně procvičil programování. Přece jen když člověk programuje něco co ho baví, tak jsou výsledky lepší. Rozhodl jsem se pro C++ v kombinaci s knihovnou SDL. Napadlo mě použít i OpenGL, ale přišlo mi to jako zbytečná komplikace do začátku, myslím že na jednoduché věci si vystačím pouze s SDL.

Co mě ale zajímá je pozicování objektů. Pokud budu mít neměnné rozlišení, je to jasné, nastavím napevno souřadnice. Co ale když chci nabídnout uživateli změnu rozlišení, potom bych musel pro každé rozlišení psát jiné souřadnice. To mi nepřijde moc dobré. Napadlo mě místo absolutního pozicování to udávat v procentech, např tento objekt bude na pozici x = 50%. Pak si zjistím že rozlišení je např. 800x600, takže objekt se umístí na x = 400.

Jen nevím jestli to není blbost, přece jen při vypočítavání pozice z těch procent se může vyskytnout nějaká odchylka, která bude dost viditelná. Máte někdo lepší nápad?

[igor]

Podivej se na specifikace typu float (popr. double, ale je to zbytecnost) a pak si spocitej, jak "giganticke odchylky" ti tam muzou vzniknout

[rezna]

pouzij OpenGL - tutorial za chvilu znovu vyjde na CH - pripadne je tu NeHe nahore v odkazech

vubec nemysli na rozliseni - celou hru pocitej ve floatech (odchylky budou ale do zacatku je vubec neres) a nakonec vyresis tzv. viewport - tedy do jak velkeho prostoru kreslis a udelas si jenom prepocet

[dadajax]

A sakra, toho použití OpenGL jsem se chtěl vyhnout, ale vypadá to že mi nic jiného nezbývá. Něco málo v OpenGL jsem zkoušel, ale měl jsem s tím problémy, tak jsem si říkal že si zatím vystačím jen s SDL

[Quiark]

Gigantické odchylky můžou vzniknout, když se ty drobné odchylky budou hromadit. Například když následujícím způsobem počítáte pozici objektu pohybujícího se po přímé trajektorii a občas na něj působí zrychlení, jde to do kytek poměrně snadno.

[Quiark]

OpenGL není nutné, to, co dělá OGL si můžeš naprogramovat sám.

EDIT: Jsou dva přístupy. Buď s větším rozlišením bude vidět víc herní plochy, nebo se s větším rozlišením všechny obrázky roztáhnou a bude vidět v podstatě to samé. To co radil rezna s OpenGL by byl ten druhý případ.
_________________
Mám strach

[igor]

Kdyz vsechno bude pocitano v urcitych jednotkach a pak jen vynasobeno nejakou hodnotou aby sedelo na obrazovku v jinem rozliseni (v kazdem framu, takze zadna zavislost presnosti na case ani jine hromadeni), tak to bude urcite ok. Fyzikalni vypocty trvajici urcity cas atd je uz neco jineho (a ani nepredpokladam ze bys je provadel v teto hre, ale samozrejme nevim o co pujde).

[dadajax]

Nakonec bude použití OpenGL asi nejlepší řešení. Vidím to tak, že různé jiné způsoby vykreslování bez OpenGL by mě možná ze začátku ušetřili čas, který jinak strávím učením OpenGL, ale zase na druhou stranu je možné, že časem zjistím že nemůžu přidat nějakou funkci právě kvůli způsobu vykreslování.

[OndraSej]

dadajax> Hlavne si rozmysli, jakym zpusobem budes mit resenou grafiku. Pokud bude vektorova, pak ok, zmena rozliseni ma smysl (s lepsim rozlisenim bude jemnejsi grafika), ale pak stejne budes pouzivat OpenGL, kde nastaveni kamery jde obslouzit tak, ze pouzivas vlastni souradnice a ne pixely na obrazovce (o vetsinu tehle prace se vlastne nebudes muset moc starat).
Pokud ale budes mit grafiku bitmapovou, pak pri zmene rozliseni nastanou dve moznosti:
1) s vyssim rozlisenim bude videt vetsi cast herniho sveta - pak ok, akorat podle rozliseni posunes souradnice tak, aby vse bylo vycentrovane (napr. v 1024x768 mas proti 800x600 o 224 pixelu vic vodorovne a o 168 pixelu vic svisle, takze vse posunes o 112 pixelu doprava a o 84 pixelu dolu, aby to, co je uprostred obrazovky v 800x600 bylo uprostred i v novem rozliseni). Z programatorskeho hlediska jasne, na druhou stranu z herniho neni uplne koser, ze lidi s vetsim rozlisenim vidi vic a jsou tim zvyhodneni.
2) zaridis to tak, aby bylo stejnou cast herniho sveta v puvodnim rozliseni. Problem v tomhle pripade je, ze budto musis nakreslit tu grafiku vickrat pro ruzna rozliseni (=> vic prace a stejne musis rucne predelat souradnice), nebo ji budes pri zobrazovani zvetsovat/zmensovat, coz ale nemusi (a nejspis nebude) vypadat moc dobre. Rozhodne tim neziskas zlepseni obrazu proti rozliseni, ve kterem ta grafika je nakreslena. Takze si myslim, ze zmena rozliseni timhle zpusobem neni moc ucelna a roztahovani klidne muzes nechat na monitoru... pokud pouzijes pristup 1), je zas situace s prepocitavanim o dost jednodussi (nejsou potreba procenta, jenom to spravne vystredit). Neni to uplne fer vuci hracum, ale pro ucely vyuky to snad vadit nebude

Jinak odchylky, ktere z tech nepresnosti plynou jsou opravdu, ale opravdu hodne male. Pokud behem hry nedochazi k jejich akumulaci jak psal Quiark, tak nemaji prakticky sanci se projevit.
_________________
http://trionteam.net

[Weny Sky]

Vykresluj vse v maximalnim rozliseni, ktere chces uzivateli nabidnout a pro mensi rozliseni jen zmenis velikost ciloveho pohledu a mas to bez komplikaci.

Jinak 2D hry to ale vetsinou resi jak uz rikal Quiark, ze pri vetsim rozliseni vidis vetsi plochu, cili zase nemas zadne komplikace pri vykreslovani.

[Mem]

Přesně jak píšou kluci, u 2D hry si buď připravíš obrázky ve všech podporovaných rozlišeních (viz moje CatchFish, kde je 240x320 i 480x640), anebo zobrazuješ víc, a tady jsou taky 2 přístupy:
- vzpomínám si na některé DOSové hry, které typicky nabízeli VGA resp. SVGA rozlišení (640x480, resp. 800x600), a v tom druhém byl navíc třeba jen okrasný okraj kolem celé herní plochy, takže skutečná herní plocha (a tím i gameplay) byla zachována
- anebo zobrazíš i skutečně víc z plochy a tím pozměníš gameplay (typicky třeba RTS)

[dadajax]

Hmm, tak nakonec je to složitější než jsem si původně myslel. Po delším zamyšlení jsem vybral dvě řešení z těch co jste tu psali:
1)rozlišení měnit nepůjde vůbec, bude jen možnost přepnout na fullscreen nebo se to bude zobrazovat v okně. To okno kvůli lidem co mají LCD a jiné rozlišení než podporované monitorem vypadají hůř. Otázka je potom jaké zvolit to rozlišení. 800x600 nebo 1024x768? Menší nebo větší bych raději nedával.
2)rozlišení půjde měnit libovolně, a podle toho rozlišení hráč uvidí různě velkou plochu s tím, že budu muset ošetřit okraje a další maličkosti, aby se to zobrazovalo správně.

Více bych se přikláněl k tomu prvnímu řešení, ještě to ale budu muset promyslet.

[Weny Sky]

No ono existuje i vylepseni tveho prvniho reseni. Rikal mi o tom kdysi Ladis, za coz mu dekuji, protoze jsem ten napad pouzivam v The Farmers.

Jde o to, ze hru muzes prepinat do fullscreenu jakehokoliv rozliseni s tim, ze hra samotna bude vycentrovana do stredu obrazovky v nativnim rozliseni treba 1024x768 a kolem ni budou napiklad cerne okraje, neaktivni rozsireni interfacu, proste uz jen nejaka neaktivni okrasa.

[dadajax]

Tak je zase čas na hloupé otázky. Rozhodl jsem se pro tu variantu, že zobrazovací plocha bude závislá na rozlišení. Potom jsem přemýšlel nad samotnou strukturou mapy. Udělal jsem to tak, že mapa je 2-rozměrné pole, a každé políčko mapy představuje reálně texturu o velikosti 16x16px. Pokud je hodnota v poli 1, políčko bude zeď, a pokud 0, políčko bude normálni podlaha.

Představuju si to tak, že si zjistím rozlišení, a podle rozlišení a pozice hráče vykreslím do pomocného SDL_Surfacu jen potřebné okolní políčka.Takže první dotaz je jasný, je to dobrý způsob?

No a dále, aby toho nebylo málo, zkoušel jsem to udělat tak jak bych chtěl, ale z nějakého záhadného důvodu mi to nefunguje.(kód je jen provizorní, vykreslí první řádek od začátku mapy)

[Weny Sky]

a pouzivas debuger, aby si zjistil, jestli se ti vubec dostalo rizeni programu do te tve podminky? Jinak nevim, jak pracuje funkce SDL_BlitSurface() takze nemuzu rict, jestli to mas spravne, jestli neni chyba nekde tam.

Ten cyklus mas zbytecne slozite, staci