Hát úgy fest, hogy a láncolt listám bejárásakor keletkezik valami kivétel, de megfogni nem tudom. .

Nézegetem a java alap konténereit, nem tudom melyik lenne e legjobb nekem, kérhetek ebben egy kis segítséget?

Szóval eddig úgy üzemelt a dolog, hogy láncolt lista elemei oda vissza látták egymást, volt szülő és gyermek struktúra is.

pl a rajzolás úgy üzemelt, hogy egy elemnek meg lett hívva a Draw() fügvénye, ami elöbb kirajzolta magát, majd átadta a "next" elemnek a rajzolást, onnantól kezdve ment midnen a maga útján. ezt melyik konténerrel tudom megcsinálni javaban?

Vagy van-e jobb módszer az elemek hierachikus tárolására bejárására?

Érdekelne, ki hogy csinálja.


EDIT: LinkedList-re átreszeltem a részecske rendszert gyorsba, azal megy limit nélkül, persze 20000 részecske már nem fér bele a Blade gyomrába, de elszállni nem száll el a progi. Kicsit átgondolom, hogy jó-e ez nekem, és áthurcolkodom rá, azért érdekelne a ti módszeretek is.

Már csak azt kéne tudnom, hogy én csesztem el valamit, vagy hardver limitbe szalad bele jogosan a láncolt lista.

én is voltam már pipa a Javára emiatt de igazából tök jó

baszki, nem is a DrawElements() Bug felelős azért, hogy elhal a progi.

Kiiktattam a kirajzolást, és 253 db részecske felett, akkor is elhasal ha nem rajzolok ki semmit. Valami a láncolt listával lehet, most kereshetem meg a hibát.

Ez a javaban csak referencia van dolgo most másodszór szivat meg úgy érzem.

HáHá...

Vissza az elejére.

Android OpenGLES2.0 alatt nem lehet VBO-t használni, mert a glVertexAttribPointer nincs rá felkészítve. Királyság. Találtam rá egy kerülő megoldást, valami csóka lekódolta NDK-ban le is szedtem az .so libet, de használati utasítás az lemaradt.

Mindegy, mert amúgy sem szeretek mások által házibarkácsolt kerülőmegoldásokat hazsnálni, szóval várom az új SDK-t amiben javítják, mert ígérve van. Addig a VBO-t elfelejtem, marad az eredeti probléma, amit meg akkor kezdek is nyomozni.

De velem akkor sem fog kicseszni.

Mert a GIF Isten büntetése.


Syam, kösz a tippet, egyelőre a VBOt próbálom kicsikarni a cuccból, mert úgy is kell, aztán meglátom, hogy azzal mit művel, most szét van kapva teljesen a kód ezen része, szóval ezt a tippet már nem próbáltam ki, talán estére kiderül, mire jutok, hajnali egyre megyek melózni addig ráérek.

Nagyon erős a gyanúm, hogy valami Hardver Limitbe sikerült beleszaladnom, csak nem tudom, hog yjogos, vagy kiküszöbölhető.

hally ...
nem tudjátok véletlenül hogy a leg töb engine mért nem támogatja a GIF-kiterjesztést ?
XNA-ba van egy hasonló- funkció bár az egy diavetítő-szerű cod-részlet és számolni kel a pixeleket .

DMG- enél azért több információt szeretem volna meg tudni !

Látatlanban próbáld ki azt, hogy amikor eléred azt a primitív-mennyiséget aminél fagy, akkor vertex arrayból foglalj le 3-4x annyit, mint amit szükségesnek tartasz.

A java oldallal viszont nem sokat foglalkoztam szóval nem tudom mennyire stabilak a driverek:]

VBO-t még mindig nem raktam bele, tudom, tudom, most dolgozok rajta, mert hátha az kiküszöböli ezt.

Amúgy, most így fest egy draw-m, de a régi 1.x-es is produkálta, csak drawtexture-el ment, akkor akár 20.000 elemet is ki tudtam rajzolni egyszerre:

Ilyen jellegű buggal még nem találkoztam pedig már 3 éve dolgozom "extrém" körülmények között mobilokkal :3

Kódot... pointer beállítással / vbo inittel / drawhívással ^^

Áhh feladom, eddig úgy tudtam, hogy a glDrawElements() bugos ES alatt, de a DrawArrays is produkálja, hogy 200 elem felett elhasal, és nem tudom, hogy miért. Valakinek van esetleg ötlete, hogy mitől lehet? Monitorozok kicsit, de hátha valaki csípőből tudja.

o, D3DCREATE_MULTITHREADED tudtommal nem volt Az miért fontos neki? Az oké, hogy elvileg safe lesz, de attól ki szabad fagynia az ablaknak, ha nincs belőve?

Idézet

---

Indicates that the application requests Direct3D to be multithread safe. This makes a Direct3D thread take ownership of its global critical section more frequently, which can degrade performance. If an application processes window messages in one thread while making Direct3D API calls in another, the application must use this flag when creating the device. This window must also be destroyed before unloading d3d9.dll.

---

szerk.:
Ja látom, írja, hogy ha az ablaküzik (ami nekem a fő szálon van) és a d3d api hívások (ami pl. create texture) külön szálon vannak, akkor kötelező.

D3DCREATE_MULTITHREADED flag megvan kreáláskor?
A threadet bezárod rendesen?
DX debug runtime mit mond?

Furcsa dolog, de amióta beraktam a többszálúsítást, és indítom a programot, akkor hol így, hol úgy, de néha kifagy az ablak. A VS szerint sehol nem áll meg a progi, és az output window szerint lezárja az általam nyitott threadet, de mégse jó. De ez így random. Ötlet?

Az OpenMP-ről nem árt tudni, hogy a microsoft nem tervezi az újabb szabványok implementálását (jelenleg 2.0-nál tartanak), helyette a Concurrency Runtime, a Parallel Pattern Library és az Asynchronous Agents Library a hivatalosan támogatott megoldások.

Idézet

---

Thank you for your suggestion. Microsoft currently supports OpenMP 2.0 in Visual Studio 2008 and 2010. We are evaluating the demand for OpenMP 3.0 but we cannot commit to a specific implementation at this time. We value your opinion and truly appreciate that you have taken the time to request this feature. Rest assured that we read all suggestions, and they do influence our decisions when making product plans.

With Visual Studio 2010, Microsoft released Concurrency Runtime, Parallel Pattern Library (PPL), and Asynchronous Agents Library, which we believe provide a lot of flexibility for C++ developers building parallel applications. The Concurrency Runtime in Visual Studio 2010 provides a common runtime that allows multiple parallel programming models from Microsoft and partners to compose well together. PPL represents a multi-vendor, cross-platform approach in providing task-based parallel programming templates.

---

Kösz, használhatónak tűnik, kipróbálom.

EDIT: Még M4-nek ment, de köszi mindenkinek.

void glVertexAttribPointer( GLuint index,
GLint size,
GLenum type,
GLboolean normalized,
GLsizei stride,
const GLvoid * pointer);


Lényeg hogy jól állítsd be ebben az egyes paramétereket, aztán meg drawarrays vagy drawelements-el kirajzolod.

Elvileg asztali gpuk is jobban szeretik ha interleave az adat.
Másrészről számodra is jobb (lehet), mert csak egy pointered / tömböd van.

ezt találtam:
http://stackoverflow.com/questions/3794644/offsets-for-per-vertex-data-interleaved-in-opengl-es-on-android

Kéne egy kis help.

Már egy ideje szemezgetek az IOS-re íródott Best Practices-ben leírt dolgokkal. Most konkrétan a "struct of arrays" megvalósítása az ami kérdés, szóval van erre vonatkozóan valakinek tudása? Mivel jelenítek meg egy ilyen összeömlesztett adatstruktúrát openglES-ben?

Köszi az infókat, megnézem majd őket

TY!

Most a windows-ost néztem, van rá bőven találat. Megnézem még jobban, azt kiderül h be tudom-e építeni értelmes helyre.

Még a glfw t is nézem. De vsz maradok a korábbi rendszeremnél, ha nem lesz jobb eredmény a csóri gépemen.
--
uez ujjabra.

Hát igen, glfw-t esetleg ablakozáshoz, png betöltéshez, ilyesmikhez (A nem ehhez kapcsolódó részeket idővel ki akarják belőle gyomlálni, ha jól tudom)
Multithreadinghez OpenMP. Egyszerű, platformfüggetlen (fordítófüggő ).

Idézet

---

borsi :
vagy használj egy platformfüggetlen könyvtárat

mint pl a glfw

---

vagy használj egy platformfüggetlen könyvtárat

mint pl a glfw

ddbwo: unix alatt a pthreadsnak és a forknak nézz utána, windows alatt pedig createthread - waitforsingleobject.

Idézet

---

Pretender :
Nem igazán foglalkoztam még MultiThreadinggel, szóval egy amatőr kérdés:
Ha azt szeretném, hogy van egy bool változóm, pl. m_Loading, meg egy Load metódusom. A fgv hívásakor elindítok egy szálat (amin betöltök), meg a bool értékét true-ra állítom, akkor kell-e valamivel trükközni, hogy azt a fő szál is rendesen kezelje (pl. static, vagy ilyesmi...)?

Arra kellene, hogy ha a változó true, akkor a betöltés cuccot rajzolom (miközben természetesen a másik szálon megy a betöltés), ha meg false, akkor már a rendeset.

---

Winfos alatt használhatod a critical section metódusokat mutexeléshez (amig tölt addig senki nem irhatja a loading változót).

Én ezt a töltögetést ugy csináltam, hogy a szál mindig létezik, de ha nincs dolga akkor alszik.

Ezt a nem írhatja rész én sem értem egészen. Szerintem írhatja, csak arra kell vigyázni, hogy ne próbálkozzanak egyszerre többen hozzá férni ugyan ahoz. Ezt meg meg lehet oldani mutexekkel.

Ez így érthető.

De a struktúr ágak áttudnak nyúlni egymásba. Legalábbis a kiinduló struktúr ha módosul, nem tűnik el, amíg a fő program fut.

Osztályokkal ez máshogy van?

Azt a részt nem értem, hogy nem írhatja, csak olvashatja.
---
Amúgy a hivatalos megnevezései, meg magyarázata hol található meg?
Hátha van benne valami hasznos is.
Most komolyan érdekelne hogy oldják meg ezeket általában. Ha kaphatnék egy linket v kulcsszót, kevesebb stresz is érne mindenkit.

több szál = a struktúrfüggönyöd több processzormagot tud kihasználni, mert mindegyik processzormagon mást csináltatsz vele egyidőben

Ezeket nem nagyon értem h mik akarnak lenni.

Ez a több szálazás létező dolog, vagy csak valamilyen módszer megnevezése?
Van valami tutorial rá? Ahol nem azt mondják hogy csinálj több szálat, hanem valami példát levezetnek az olvasó elött?

Idézet

---

Pretender :
És akkor pl. ugyan azt az adatot hogy ér el több szál? Tuti lehet ilyet csinálni

---

olvashatja, de nem írhatja.

Nekem egy gyerek osztályon belül kellene.

Az én megoldásom nem tudom mennyire valid, de egyenlőre működik. Van egy "Game" singleton objektumom, aminek publikus metódusaiban vannak a render, ai, fizika stb loopok. Így elérik ugyan annak az objektumnak a memberjeit és mivel publikusak, el lehet őket indítani különböző szálakból.

Én OpenMP-t használok multithreadinghez, azzal elég egyszerű. shared(...)

Nyelv függő a dolog, hogy mi kell hozzá, de meg lehet csinálni. Nem a legelegánsabb dolog, és lehet az is, hogy a program rosszul viseli, ha egyszerre próbálja valami lockolás nélkül írni és olvasni is. Tipikusan kicsit jobban szokták definiálni az adat átadás menetét, meg például ha jól tudom (lehet, hogy nem) c++ban külön stack van a két szálnak, de a heapben foglalható közös elérésű terület, szóval ennek megfelelően kell kezelni. Szerintem egy utánaolvasást mindenképp megér a téma, én magam is szívesen foglalkoznék vele, de most a melóban az erlang kell.

És akkor pl. ugyan azt az adatot hogy ér el több szál? Tuti lehet ilyet csinálni

ez nem így működik. így adtot átadni kb esélytelen, ha mégis akarsz ilyesmit, akkor használj szemaforokat.
inkább írj monolitikus párhuzamosítást (pár páros idjű ojjekteket az egyik, páratlanokat a másik bözgeti), vagy procedurálist (egyiken megy az ai, a másikon meg a fizika)

Nem igazán foglalkoztam még MultiThreadinggel, szóval egy amatőr kérdés:
Ha azt szeretném, hogy van egy bool változóm, pl. m_Loading, meg egy Load metódusom. A fgv hívásakor elindítok egy szálat (amin betöltök), meg a bool értékét true-ra állítom, akkor kell-e valamivel trükközni, hogy azt a fő szál is rendesen kezelje (pl. static, vagy ilyesmi...)?

Arra kellene, hogy ha a változó true, akkor a betöltés cuccot rajzolom (miközben természetesen a másik szálon megy a betöltés), ha meg false, akkor már a rendeset.

Hát, végülis maradt az, hogy 2 értéket adok át a shadernek, sor/oszlop, viszon nem kalkulálgatok, csináltam két 16 elemű tömböt, és odt beírtam fixen a koordinátákat, kösz az tanácsot.

VBO egyelőre elnapolva, egyellőre egy működő, játékra alkalmas motort akarok összedobni, VBO meg marad az optimalizálási fázisra.

Lassan kipiálom az össze elemet a ToDo listán. :banán

Most részecske rendszeren dolgozom. Túlbonyolítani azt sem akarom, túl nagy részecske számmal úgy sem akarok dolgozni.

Köszi!

Ha tudod vbozni a billboardot akkor nem, ha nem akkor igen

Köszi! Frappáns megoldás.

De nem pazarlás ez? Csak mert ez minden rendernél átadódik, meg kiszámolásra kerül. Vagy elhanyagolható?

Azt is figyelembe véve, hogy itt most mobil telefonGPU-járól beszélünk tehát az alsó kategória ilyen 200 Mhz.

Na azt hiszem alszok rá egyet.

- vertex texcoordba rakod:
0,0
0, 1 / 4
1/4, 0
1/4 1, /4
a sorrend a topológiádtól függ

- uniformként átadsz 16 uv koordinátát + időt

- az időből kiszámolsz indexet -> az index alapján kiveszel a tömbből egy uvt

- végleges texcoord = uv + vertex texcoord

BillBoard.

Most elmentem fürödni, aztán rájöttem (hol máshol), hogy az mindenképen pazarlás, ha a shaderrel számoltatom ki, mert animáció sebességétől függően változik a sorszám, és felesleges minden frame render alatt kiszámolni, ha nem változik frameenként. Szóval az én paraszti eszemmel marad az hogy a képkozka változásakor kiszámolom,és két értéket adok át a shadernek., hacsak nem montok valami okosat.

Nincs ilyen, hogy sourceRectangle és destinationRectangle?

Billboard v point sprite?

Ezt mos tnem tudom, melyik témába kéne.

Szóval Animált Sprite-al szórakozom.

Van egy 4x4 kckából álló textúra, amit rárakok shaderrel, az animálás fázisai meg 1-16-ig menének, kérdés, hogy hol optimálisabb kiszámolni, hogy a textúra hanyadik sorának hanyadik oszlopát kell megjeleníteni? Ádjam a shadernek a sorszámot, és számoljam ott, vagy számoljam ki előbb és adjam át a sor és oszlop számait?

Vagy teljesen rossz a koncepcióm, és van valami jobb megoldás erre?

De jobban belegondolva lehet hogy nem is konkrétan az A*t használom, de kb hasonlót hoztam össze, csak a waypointok kész listája terelik az ai-t és nem ledobálja a négyzeteket. De pl csináltam "eltévedtem" scriptet, amikor megjegyzi hogy merről jött, hol nézett már körbe, és ahogy talál egy waypointot, arra csapódik rá.

Nagyon imádtam nézni hogy mit csinálnak a botok. Tök buli! Kajak még a WITK pongos AI-t is vicces volt összerakás után nézni ahogy játszik.

Az, hogy mihez választod ki a legrövidebb utat azt az AI dönti el - akár még "tippelhet" is.