Hra / engine - obecně

[costa]

Zdravím, jelikož jsem zde "nový", rád bych nejdřív objasnil, na čem bych rád zapracoval v budoucnu a zároveň vás zkušenější požádal o pár rad, návodů, triků apod.
Takže, rád bych si zkusil napsat vlastní hru (vím, že "psát herní engine" tady není moc v oblibě ), a to pomocí SDL/OpenGL.. V tomto vlákně bych se chtěl dozvědět některé věci, které jsem nevyčetl zatím ani tady na fóru, ani jsem nenašel v různých bakalářkách, semestrálkách apod (nebo nepochopil), popřípadě alespoň slyšet váš náhled na věc, nejelegantnější řešení (v rámci možností vašeho know-how ) apod.

- rád bych ještě zdůraznil, že mně půjde především o obecnější věci co se týče fungování hry, tzn. pokusím se vás neotravovat věcmi jako binární strom ( které jdou velmi snadno dohledat ) ..


za A) Jak řešit správu paměti pro menší hru (řádově 1 menší mapa, 2 hlavní objekty, pár vedlejších, nic velkého) ? Naalokovat si hned ze začátku veškerou potřebnou paměť + nějakou rezervu, načíst všechny modely, textury, scénu, .. a pak k nim jenom přistupovat, nebo alokovat/uvolňovat paměť, nahrávat data, až podle potřeby?

za B) V jakém pořadí inicializujete / uvolňujete jednotlivé části hry? Handle okna, správce zdrojů (modely, obrázky, popisy scén, konfigurační soubory ..), ev. síťovou hru, grafickou část (rendering, 2D f-ce), fyzikální engine, správce scény, .... ? Něco tu už psal ]semo[ , jenom v pořadí mám ještě zmatky .-)


P.S. Píšu v C-čku, vím, že objekty bych si ušetřil hodně práce, ale jelikož rozhodně umím víc čisté C, než C++ apod., tak bych rád zůstal u něho..

.. prozatím asi vše, předem vám děkuji za odpovědi, i do budoucna

[frca]

A) Něco mezi. Rozhodně vše naalokovat na začátku, za běhu už nic nealokovat. Nahrávat buď na začátku, nebo podle potřeby za běhu. "Na začátku" nemusí znamenat přímo jenom na začátku programu, ale třeba na začátku levelu, při loadingu uložené pozice apod. "Za běhu" znamená během výkonové části.
_________________
www.FRANTICWARE.com

[OndraSej]

A) Pokud jde o malou hru, cekal bych, ze se cela vejde to 100-200 MB RAM. Pokud ano, nema nahravani behem hry moc velky smysl. Pokud jde o alokovani pameti, tak to zalezi na tom, k cemu ji potrebujes. malloc/free jsou vcelku drahe operace, ale pokud jich udelas jenom par za frame (napriklad pro smazani mrtvych nepratel a pridani novych, trochu prace s retezci pro zobrazeni score...), tak se to nikde neprojevi a vlastni/specialni alokator nestoji za tu namahu. Pokud by jich ale mely byt tisice nebo desetitisice, pak by asi bylo lepsi pouzit nejakou chytrejsi metodu pro spravu pameti.

B) Nevim o tom, ze by existovalo jedine spravne poradi, v jakem to delat. Obecne doporuceni je "co nejdriv ukazat uzivateli, ze se neco deje" (co nejdriv vytvorit okno a napsat do nej "Loading"), ale dal uz je to asi jedno. Poradi nekterych veci vyplyne ze zavislosti (nema cenu inicializovat grafiku, dokud nenactes vychozi rozliseni z konfigurace, bez inicializovaneho spravce sceny moc nejde nacitat levely, ...), ale na to prijdes az to budes programovat.
_________________
http://trionteam.net

[costa]

Ahoj, předem bych vám chtěl poděkovat za rady, načtu teda vše hned ze začátku.. Řeším další problémy, a sice s hlavní smyčkou, takže přidávám další otázku..

za C) Mám funkci app_run(), která se stará o herní smyčku. Ve smyčce volám 2 funkce, app_run_update() a app_run_render() ... update() by měla zachytávat události (klávesnice, TIMER, zprávu o ukončení programu, ...) a dále obnovovat (pozice objektů ve hře, scénu atd); a render() vše vykreslí.. Vás bych se rád zeptal, jestli je toto řešení v pohodě, pořád mně to nepřijde úplně "čisté" a funkční...

Opět budu rád za váš názor/připomínku, radu, cokoliv.. zdravím, costa

[perry]

Mělo by to stačit... maximálně bych render třeba pozdržel podle FPS... tzn. že update se bude provádět pořád a jednou za nějaký čas se provede render
_________________
Perry.cz

[Ladis]

Zas ale proč provádět update, když nebude volat render, což bude asi jediný výstup té hry.
_________________
Award-winning game developer

[Houp]

[OndraSej]

Ladis> obecně se hodí mít update s pevným časovým krokem kvůli numerické stabilitě. A proč dělat víc update bez renderů - update je obvykle rychlejší než render, takže takhle jde snížit framerate rendereru, ale přitom mít simulaci herního světa přesně stejnou jako na počítačích s vyšší framerate.
_________________
http://trionteam.net

[Marek]

Volat render víckrát než update nemá smysl, pokud neděláš benchmark.

Jinak:

A) Tam těch možností je trochu víc než jen 2. Buď nahrát vše při spuštění aplikace (podle mě je to blbost, plýtvá se paměť), nebo nahrát vše při načítání levelu (obvykle používaný způsob, snadný na implementaci), nebo nahrávat data podle potřeby během hraní, tj. zatímco hráč kuchá příšery, jejichž mozky tečou po podlaze, tak ty paralelně nahráváš další úsek levelu, ke kterému se hráč blíží, umísťuješ příšery apod., zároveň uvolňuješ úseky levelu, od kterých se hráč vzdaluje a zároveň je třeba zachovat naprostou plynulost hry (časté u online her, netriviální na implementaci, ale umožňuje více detailní scény kvůli tomu, že se tak neplýtvá pamětí).

Ze začátku je lepší načítat jen po levelech.

B) Uvolni si to, v jakém pořadí chceš, ale hlavně abys tam neměl memory leaky a jiné leaky. Samozřejmě je potřeba vědět, jestli ti zrušení handlu okna samo nezruší í všechny objekty, které jsou s ním asociované. To se obvykle dočteš v dokumentaci. Co se týče grafiky, okno doporučuju uvolnit až na konec, před ním je třeba uvolnit grafický kontext a před tím je celkem jedno, jak to uvolníš. Co se týče ostatních věcí, tak je asi úplně jedno, kdy to uvolníš. Zvuky je asi lepší uvolnit přes zrušením zvukovýho kontextu a fyzikální objekty je třeba uvolnit přes zrušením fyzikálního kontextu (enginu atd). Ale typicky je to tak, že herní objekt (třeba panák) si sám drží svoje modely, zvuky, fyzikální reprezentaci atd. a při jeho uvolnění se uvolní všechny objekty, co k němu patří.
_________________
AMD Open Source Graphics Driver Developer

[Vilem Otte]

[costa]

ještě bych měl upřesnit, o co se vlastně snažím... chci si napsat leteckou arkádu - samozřejmě zjednodušenou v co největší míře - takže jak jsem už psal, 1 mapa, 2 letadla, + nějaké věci okolo (skybox, pár domů, stromy, voda) každopádně nic megalomanského. Většina objektů půjde víceméně vidět po celou hru, žádné levely neplánuju .... takže jsem si vlastně odpověděl sám

- k TIMERu - ještě by tu byla jedna možnost..... v hlavní smyčce hry bych ošetřoval události s tím, že jeden event by byl timer.... někde bokem by mě běžel timer s nastaveným MAXFPS s tím, že by v každém intervalu poslal zprávu do hlavní smyčky.... ve smyčce by vedle zpráv z klávesnice, myši, ... by byla událost s timerem, která by volala f-ce update() a render() .... co vy na to?

[Marek]

Vilem> Jenomže update interpolační proměnné je v update (haluz, co). Teď se nebavím o updatu fyzikálního enginu, ale o updatu kompletní hry. Co se ale týče té fyziky, není mi jasný, k čemu je tam interpolace dobrá. Ať nad tím přemýšlím jak chci, vždycky mi vyplyne, že tam ta interpolace spíš věcí kazí než že by něco vylepšovala.

costa> Kašli na timer, podle mě to nepotřebuješ, prostě udělej:

[costa]

Eosie: to by bylo nejjednodušší, ale jak by se pak hra chovala na různě rychlých kompech? Pokud bych třeba rychlost počítal jako přírůstek pozice za snímek, a hra někomu běžela 1500 FPS a druhému 150...

[OndraSej]

costa> ta zakladni smycka klidne muze byt takhle a v updateGameState bys mel mit neco typu:

[costa]

o té nepřesnosti WM_TIMERu vím, já naštěstí používám SDL timer asi to udělám jak píšete vy, vykašlu se na celý timer, maximálně přidám do smyčky SDL_Delay(), což by svůj účel taky mělo splnit...