OpenGL ES 2 - update a draw

[Poky]

Zdravím všechny,

mám takový dotaz. Pro projekt do školy mám vytvořit aplikaci pro Android v Jave, a protože jsem kdysi dávno dělal Pong3D pro klasické PC (také v Jave), napadlo mě překodit to do mobilní verze, jenže jsem se zasekl na jedné (asi) kravině.

Na mobilních zařízeních není nekonečný while cyklus, kde se provádí update a draw, ale onDrawFrame event a zde nastává má otázka. Jak řešíte update objektů (myslím obecně)? Děláte to vše v této metodě nebo v onDrawFrame jen vykreslujete a o update se stárá "něco jiného" nezávisle. Pokud je to druhá možnost, jak dosahujete oné nezávislosti (PS: Do vláken se mi moc nechce ...), když není možné použít nekonečný cyklus... (Nebo je )

Díky moc za odpověď.

[VODA]

A co si takhle vnitřek toho nekonečného cyklu představit jako volání metody onDrawFrame?

[Poky]

Jj to samozřejmě vím, toto řešení mě také napadlo, jen se mi právě trochu nelíbí, že by se Renderer (onDrawFrame je jeho metoda) staral i o update... Z hlediska jednoduché aplikace to asi je jedno, ale z hlediska nějaké řádné struktury enginu mi to vadí. Proto se ptám... má mi to opravdu vadit nebo mám sklopit zrak a napsat to jak uvedl VODA?

[VODA]

http://www.edu4java.com/en/androidgame/androidgame3.html
http://obviam.net/index.php/a-very-basic-the-game-loop-for-android/
http://www.codeproject.com/Articles/827608/Android-Basic-Game-Loop
http://www.javacodegeeks.com/2011/07/android-game-development-game-loop.html
http://blorb.tumblr.com/post/236799414/simple-java-android-game-loop
http://stackoverflow.com/questions/14077403/android-game-loop-vs-updating-in-the-rendering-thread
https://www.youtube.com/watch?v=ztFzofX66Vo

Ve všech těchto odkazech používají speciální vlákno...
Stejně bych ale pro malou hru jako je Pong nechal logiku hry v onDrawFrame... je tu nějaký expert na Android?
_________________
Opravdovost se pojí s trýzní...

[Mem]

While v samostatném threadu... já když dělal před lety první hru pro Android (tower defense) tak jsem vyšel ze samplu Lunar Lander od Googlu. Akorát v současném SDK už asi není nebo je obsolete (a ta prapůvodní verze byla taky zabugovaná co se týče pauzování main activity, ale to jsou malé věci )
https://gitorious.org/replicant/development/source/3eda8fc3859c243df4a1f892a11e2da84b49cb94:samples/LunarLander/src/com/example/android/lunarlander/LunarView.java

[Vilem Otte]

Nevím jestli jsi posílal "fixed" verzi Lunar Lander - je třeba tady - https://gist.github.com/mikehibm/1623649

Update dej do samostatného threadu, v Javě to je na pár řádků navíc.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[mar]

No pro Android jsem nic nedělal,
ale asi bych to vyřešil jak píše VODA, ne? To mi přijde nejjednodušší.

Pokud budeš mít zvlášť vlákno, musíš to tak jako tak řešit zamykáním (aspoň na kratičkou dobu).
Co mě napadá je buď:
- zamknout objekty, renderovací vlákno je projde a vyrenderuje (toto se mi vůbec nelíbí, i když je to nejjednodušší možnost,
protože update by mohl zabrat relativně dlouhou dobu a tím pádem tím úplně zabiješ smysl dalšího vlákna)
- vytvořit jejich kopii (resp. část stavu, která důležitá pro renderování), pak zamknout (na velmi krátkou dobu, stačilo by předání pointeru) a předat renderovacímu vláknu - tím minimalizuješ contention
- bufferovat rendering commands, pak zamknout a předat renderovacímu vláknu (nevýhoda je, že bys musel wrapnout gl příkazy a logika, která řeší update, by řešila i renderování)
- možná by šel místo toho použít lock-free ring buffer, kde commands sypeš renderovacímu vláknu, akorát bys musel nějak řešit synchronizaci se začátkem framu (v podstatě obdoba předchozí možnosti)
Doufám, že mi neuniklo nějaké elegantní řešení, osobně jsem renderer nikdy ve speciálním vlákně neřešil (nebylo potřeba pro mé jednoduché projekty).
Nicméně úplně oddělit logiku renderování snad vlastně ani nejde, vždycky musíš aspoň vědět, co je pro renderování důležité a co ne.
Nemluvě o tom, když to pojede na zařízení s jedním core (i když dnes je toto už u mobilních zařízení spíš vzácnost), tak si dalším vláknem vůbec nepomůžeš (právě naopak).
Poslední věc, co mě napadá je, že je sice fajn mít nezávislý update, nicméně zase tím permanentně vytěžuješ CPU (1 core), což není u mob. zařízení moc dobré na životnost baterie.
Hmm tak ta poslední poznámka tak úplně neplatí, můžeš čekat na condition variable (event), až renderovací vlákno dokončí práci.

[Radis]

Poky: Dalsi vlakno je ve tvem pripade uplne zbytecne, delej to normalne v jednom. Dela se to tak standardne i v libGDX, na kterem jsou postavene stovky her pro Android. Chapu, ze ti muze byt proti srsti volat update logiky z metody s nazvem render() nebo neco podobneho... Ale to prezijes

Vilem otte: Ano, odstartovat vlakno je opravdu "par radku navic", ale ono je taky potreba ta vlakna synchronizovat. A to je pomerne netrivialni zalezitost, kdyz to chces delat efektivne. U zacatecniku to vetsinou dopada tak, ze render a update na sebe navzajem cekaji a volaji se pekne sekvencne. Uplne jako by byly v jednom vlakne, ale s overheadem navic

[perry]

Plus vlákna v Javě jsou celkově dost divně řešený, takže bych se do nich raději nepouštěl tak jako tak.
_________________
Perry.cz

[Poky]

Díky za reakce... opravdu se asi vykašlu na další vlákno a vše nasypu do té metody onDrawFrame

[]semo[]