játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5462
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2523

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2192
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] > 35 < [40] [45] [50] [55] [60] [65] [70] [75] [80] [82]
HomeGnome - Szerkesztő | 2919 hsz       Online status #147322   2011.02.04 18:46 GMT+1 óra  
proof88: Elnézést, csak naivan érdeklődve kérdezem, hogy komolyan van ahol nincs VSync?? Integrálton letiltották vagy miért? Szerintem már a 20 évvel ezelőtti kártyákon is volt VSync, hiszen ez nem 3D specifikus dolog... Tényleg csak érdeklődésképpen kérdezem!

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
proof88 - Törzstag | 530 hsz       Online status #147319   2011.02.04 16:53 GMT+1 óra  
Asylum: miért ne lenne?

Viszont látom senki sem hallgat rám és hülyének néz, amikor azt mondom, hogy VSYNC NEM ÉRHETŐ EL MINDENHOL!!!

Épp ma említette valaki hogy a vsync szépen tartja a képet. Na igen, de ha épp egy olyan gépen nézed a progit, amiben az integrált kártya nem tudja a vsyncet, akkor ugyanúgy több 100 fps lesz. Ezért kell valami plusz dolog. Arról nem is beszélve, mint azt már elmondtam, hogy a vsync negatív hatással is lehet az fps-re. Sokan kitalálják, hogy pl az nfs-ek 30 fps-re vannak belőve. Na persze. Hát nem. Csak a vsync miatt annyival megy.

Amit Joga írt először, a while ciklusban várakozás, az nem jó, mert ugyanúgy maxon pörög a proci és úgy lesz x fps. Az már jobb, amikor úgy írta, hogy while-on belül sleep-el, mert akkor ténylegesen arra a rövid időtartamra nem pörgeti a proci a progit.

Gaborlabor meglátása helyénvaló, tényleg nem pontos a sleep(). Ahogy írták többen is, QueryPerformance....

De még mielőtt lebaszna mindenki, elmondanám, hogy abba a 2D-s játékba én elégségesnek találtam volna berakni kezdésnek egy sleep(20)-at, gondolom a régebbi integrált kártyákat sem fekteti meg folyamatosan rajzolgatni a 2D-s alakzatokat. Ezért említettem a sleep()-et. És igenis kell valami. Ha van vsync, akkor érdemes bekapcsolni, de nem biztos hogy van. És ha van, akkor is opcionálissá kell tenni. A játékokban, pl fps-ekben is be lehet állítani egy max fps értéket, attól hogy nem használtok vsyncet.
   
syam - Törzstag | 1491 hsz       Online status #147318   2011.02.04 16:06 GMT+1 óra  
alias aalberik
   
Asylum - Törzstag | 5462 hsz       Online status #147317   2011.02.04 16:04 GMT+1 óra  
Mért nem jó nektek a vsync?...

ui.: ja mert hogy nincs opengl-ben hohó
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #147315   2011.02.04 15:50 GMT+1 óra  
A Sleep() viszont nagyon kis időtartamokra pontatlan, kb 10 ms-nél kevesebbet nem nagyon tud várakoztatni. Queryperformance, az a jóság.

   
Joga - Törzstag | 1791 hsz       Online status #147312   2011.02.04 15:01 GMT+1 óra  
No igen, érdemesebb akkor ciklus helyett egy sleep:

Kód:
void syncronize( int milisec )
{
static Uint32 time = 0;
if( time + milisec > SDL_GetTicks() )
    Sleep( time + milisec - SDL_GetTicks() );

time = SDL_GetTicks();
}
(ಠ ›ಠ) Stewie!

   
Matzi - Szerkesztő | 2523 hsz       Online status #147311   2011.02.04 14:43 GMT+1 óra  
Asylum:
Azért nem, mert a sleep nem a legutóbbi idő óta eltelt minimális távolságot korlátozza, hanem annyi ideig nem csinál semmit, amit átadsz neki. Joga kódja viszont azt csinálja, hogy ha két lefutás között az átadott intervallumnál több idő telt el, akkor nem várakoztat semennyit sem.
Annyi hibája van, hogy az üres ciklus 100%os processzor kihasználtságot eredményez, ami nem szerencsés, oda esetleg kellene egy minimális sleep, vagy valami ahhoz hasonló.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5462 hsz       Online status #147310   2011.02.04 14:31 GMT+1 óra  
A Sleep() szerintem pont ugyanezt csinálja.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Joga - Törzstag | 1791 hsz       Online status #147309   2011.02.04 14:19 GMT+1 óra  
Kétlem, hogy nagy dolog lenne összedobni egy függvényt, ami biztosítja az egyenletes FPS-t
pl SDL-ben .:
Kód:
void syncronize( int milisec )
{
static Uint32 time = 0;
while( time + milisec > SDL_GetTicks() )
    ;
time = SDL_GetTicks();
}

de queryperformance, vagy clock() esetén is hamar lehet írni egyet
(ಠ ›ಠ) Stewie!

   
barack1 - Tag | 95 hsz       Online status #147305   2011.02.04 10:33 GMT+1 óra  
Egy 2D -s játékban feltétlenül célszerü bekapcsolni a VSYNC -et. A sleep -es megoldás brutálisan csúnya a VSYNC -hez képest. Miután a 2D játékok több száz FPS -el mennének vsync nélkül, a vsync bekapcslolása azt eredményezi, hogy a játék pont olyan gyorsan rajzol, amin a monitor megy ( álltalában 60 fps ). Ilyenkor a játékokban a mozgás álomszép és lágy lesz. Ha a sleep utasítással probálom a sebességet tartani, akkor nem lesz teljesen egyenletes ( rezeg a mozgás ), és összetört lesz a kép.
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #147279   2011.02.03 13:57 GMT+1 óra  
Idézet
Wolfee :
Idézet
MaNiAc :
[...] simán elkurvulunk [...]
[...] és a magamfajta vakon hisz benne, hogy a fejlesztők elég intelligensek hozzá, hogy kikapcsolják, ha nem kell


ezt a két félmondatot gondold végig együtt

LOL
Dare to imagine!
http://www.insaneidea.hu
   
proof88 - Törzstag | 530 hsz       Online status #147277   2011.02.03 13:34 GMT+1 óra  
normális esetben már nem veszi észre az ember - hát én pedig sokszor észreveszem tft-n, pl Mafia 2-ben is nagyon idegesített de pl multis játékokban általában minél nagyobb fps érdemes.
   
Wolfee - Törzstag | 1337 hsz       Online status #147276   2011.02.03 13:23 GMT+1 óra  
Idézet
MaNiAc :
[...] simán elkurvulunk [...]
[...] és a magamfajta vakon hisz benne, hogy a fejlesztők elég intelligensek hozzá, hogy kikapcsolják, ha nem kell


ezt a két félmondatot gondold végig együtt
FZoli jóváhagyásával XD

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #147275   2011.02.03 13:21 GMT+1 óra  
Lehet, hogy nem tűnt el, de normális esetben már nem veszi észre az ember... CRT-n még éreztem a tearinget. Dehát ez van, a nagy hardver-bőség miatt simán elkurvulunk Egy ideje nem írtam semmi olyat, ami 60 FPS alá menne (nem azért mert májer vagyok, hanem mert már nincs annyi időm kódolni, hogy olyat írjak, ami a mostani kártyákat értelmes keretek között padlóra küldi ), a játékoknál meg app controlled és a magamfajta vakon hisz benne, hogy a fejlesztők elég intelligensek hozzá, hogy kikapcsolják, ha nem kell
Dare to imagine!
http://www.insaneidea.hu
   
Geri - Törzstag | 2192 hsz       Online status #147274   2011.02.03 13:19 GMT+1 óra  
Én szeretem ha be van kapcsolva a vsync, mert nem szeretem a félframeket, ennek ellenére mégis mindig kikapcsolom, mert valahogy kurvára nem szokta bírni a gépem a frissítési frekvencia utolérését, úgy viszont értelmetlen.

   
proof88 - Törzstag | 530 hsz       Online status #147273   2011.02.03 13:12 GMT+1 óra  
vsyncnek tft-nél is van értelme egyébként, a probléma nem tűnt el a crt-kkel együtt
   
proof88 - Törzstag | 530 hsz       Online status #147272   2011.02.03 13:08 GMT+1 óra  
proof88 - Törzstag | 530 hsz       Online status #147271   2011.02.03 13:07 GMT+1 óra  
igen a triple buffering kényszerítése driverből az oké, de valszeg a userek kis része kapcsolja ezt be és mint mondtam, vsync nem mindenhol elérhető.
   
proof88 - Törzstag | 530 hsz       Online status #147270   2011.02.03 13:06 GMT+1 óra  
pedig a vsync eléggé negatívan tudja befolyásolni a játékélményt, ha utánaolvasol akkor el van magyarázva hogy miért. nincs is jobb mint amikor 30 és 60 fps váltakozik és azt érzed a játékon, hogy ugrál. De bármilyen játékot megnézel, javasolják hogy vsyncet csak akkor használj ha bírja a gép. én nem magyarázom el, mert ahhoz rajzolgatni is kéne a szemléltetéshez, de anno olvastam róla cikket, hogy miért is 30 fps meg ilyesmik jönnek ki amikor nem bírja a gép tartani a 60-at.

akkora hülyeséget nem mondtál, de amikor cicergő hangot hallat a gép, mert valszeg több száz fps van egy 2D-s játékban, akkor simán a legjobb tanács szerintem, hogy "kúrj bele egy sleep-et és jó lesz"
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #147269   2011.02.03 12:52 GMT+1 óra  
Nem értem a rengeteg kérdőjelet, szerintem nem mondtam akkora hülyeséget, de ahogy érzed :-)

A main render loop annál sokkal komplikáltabb dolog, mint hogy "kúrj bele egy sleep-et és jó lesz"...

"másrészt pedig, a vsync miben jobb? Véletlenül nem sikerül tartani a 60 fps-t, és nem 58-at kapsz amennyit kaphatnál vsync nélkül, hanem sokkal kevesebbet, pl 30-at."

A fenti mondatot részt nem értem. Miért felezné le a VSync az FPS-t?


SZERK: Előkotortam pár régi vackot, amik a mostani cuccokon kikapcsolt VSync-el több ezer FPS-el mennek... CRT monitoron (1024x768x85) mindig 85 FPS volt VSync-el, TFT-n meg mindig 60. Komolyan nem értem a felezés honnan jön, sose tapasztaltam.

SZERK2: Nvm, rájöttem. Rég szoptam már ilyenekkel, hogy VSync (TFT ftw!), így elfelejtettem, hogy a triple buffering gyakorlatilag kiiktatja ezt a problémát - ez meg nálam szerintem mindig ON volt

Ezt a hozzászólást MaNiAc módosította (2011.02.03 13:03 GMT+1 óra, ---)
Dare to imagine!
http://www.insaneidea.hu
   
Pretender - Törzstag | 2498 hsz       Online status #147268   2011.02.03 12:40 GMT+1 óra  
Igen, 30at. Vsync esetén feleződik, ha jól tudom Esetleg ez? http://gafferongames.com/game-physics/fix-your-timestep/ Bár ez updatere vonatkozik...

   
proof88 - Törzstag | 530 hsz       Online status #147267   2011.02.03 12:31 GMT+1 óra  
MaNiAc: proci limites ????????????
egyrészt a vsync mint azt írtam nem minden helyen érhető el, másrészt pedig, a vsync miben jobb? Véletlenül nem sikerül tartani a 60 fps-t, és nem 58-at kapsz amennyit kaphatnál vsync nélkül, hanem sokkal kevesebbet, pl 30-at. Ezzel a sleep()-pel nem procilimites lesz a program, csak tisztességesebb. Egyébként sem fix értékkel kell sleep()-eltetni, hanem változóval. Egy komplex jelenetnél, amit mondjuk 30 ms tart kirajzolni, ott nyilván nem is kell sleepeltetni.
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #147266   2011.02.03 12:24 GMT+1 óra  
Hat mondjuk en nem tudom, render ciklusban nem sleep-elnek, mert ettol kvazi-procilimitesse valik a program... VSync ON es csok a csaladnak.
Dare to imagine!
http://www.insaneidea.hu
   
proof88 - Törzstag | 530 hsz       Online status #147265   2011.02.03 12:14 GMT+1 óra  
Mystro: teljesen normális dolog ez, és valszeg több száz fps-ed van, és az fps nagyságának arányában hallod a ciripelést. Limitáld le az fps-t, mondjuk 100-ra vagy 60-ra, vagy 30-ra ha az is elég. Mindig érdemes limitálni az fps-t. Egyszerűen annyit teszel, hogy sleep()-elsz néhány ms-et a főciklus végén. pl ugye ha 10 ms-t sleepelsz, akkor 100 lesz a max fps-ed, akkor már valszeg nem fogod hallani ezt a hangot. Ezen felül, VSync-et is érdemes lehet bekapcsolni, hogy ne törjön meg a kép. A VSync-et általában nem tudják az integrált vga-k (a régiek), de érdemes használni, extension kell hozzá. De a vsync előtt, a kódbeli fps limit legyen az első, amit írtam.

ezt a jelenséget bitzajnak is nevezik, egyébként a tekercsek rezgése esik hallható tartományba, azért hallani. Zenél a videjókártya egyébként alaplap, táp, stb is tud ilyen hangot produkálni a terhelés függvényében.
   
Mystro - Tag | 60 hsz       Online status #147261   2011.02.03 10:20 GMT+1 óra  
Hali

Nem tudom mennyire kapcsolódik ez ide, de SDL-ben opengl-t használok 2D alakzatok rajzolására, és észrevettem, hogy renderelés közben a gépből (talán videokártyából) furcsa, halk ciripelő/sípoló hang jön, szerintetek mi lehet ez?
   
metaxa - Tag | 73 hsz       Online status #146981   2011.01.28 14:40 GMT+1 óra  
Sajnálom, hogy zavaros volt amit írtam. Ilyen témában hozzáértés kell, hogy jól fogalmazzon az ember, én viszont csak pár napja foglalkozok a 3d-s programozással. Mindenesetre sikerült segítenetek, amit köszönök. Legközelebb már ahogy egyre jobban megértem a rendszerét úgy fogok egyre otthonosabban fogalmazni is
   
Asylum - Törzstag | 5462 hsz       Online status #146980   2011.01.28 14:27 GMT+1 óra  
Fps függetlenség: http://gafferongames.com/game-physics/fix-your-timestep/

Erre a "szakdogámban" is kitértem, javaslom nézd meg a prezentáciom slidejait (vagy akár magát a kódot). http://people.inf.elte.hu/asylum/releases/
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Geri - Törzstag | 2192 hsz       Online status #146978   2011.01.28 14:20 GMT+1 óra  
Metaxa, zavaros amit írsz, és senki se érti, de érdekes amit csinálsz, úgyhogy segítek neked. Szóval felvettelek msnen, és kitaláljuk hogy mit akarsz, és hogy hogyan kell megcsinálni.

   
metaxa - Tag | 73 hsz       Online status #146977   2011.01.28 14:14 GMT+1 óra  
igen srácok ez volt a probléma. Nem akadozott ez egyáltalán a Call List-et, csak sokkal gyorsabb, mikor háttal állok a labirintusomnak. Viszont amit írtam, hogy
Idézet
Azthiszem erről van egy cikk a lighthouse3D oldalán, hogy lehet az fps-t konstanssá tenni, hogy ne gyorsuljon meg lassuljon állandóan,
Ez mégsem a lighthouse oldalán van, ráadásul nem is a frame per secondot teszi állandóvá, sokkal inkább a fordulás sebességét. Nemtudom pontosan mi miatt változik ez a dolog de nem tudnátok adni egy cikket, ami szépen leírja ennek kiküszöbölésének a módját? Ezután a többit már tényleg megoldanám
   
gaborlabor - Moderátor | 4449 hsz       Online status #146975   2011.01.28 14:02 GMT+1 óra  
Back face culling van ogl-ben "gyárilag" is. 3 sor kóddal be lehet kapcsolni.

   
metaxa - Tag | 73 hsz       Online status #146973   2011.01.28 13:53 GMT+1 óra  
Leírom hogy van a programban, első hozzászólásomban tényleg nagyon septibe fogalmaztam meg. Van egy utasítás amit mutattam a kockám kirajzolására, ami már textúrázoptt kockát rajzol az aktuális pozícióra ez a kocka(meret). Aztán van a display list függvényem amiben a két for-ciklussal legenerálom a txt szerint a pályát, ennek csak a forciklusos részletét mutattam. Aztán a renderscene-ben már csak a CalListet nyomom. Igazából nem is nagyon vészes az akadás, csupán mikor a hátam mögött van a labirintus akkor nagyon szépen szalad a fordulat, mikor ránézek akkor meg tisztára lelassul. Azthiszem erről van egy cikk a lighthouse3D oldalán, hogy lehet az fps-t konstanssá tenni, hogy ne gyorsuljon meg lassuljon állandóan, csak mikor régen olvastam nem találtam még hasznosnak. A suliban eszembejutott, neme ez lehet a gond.

Továbbá tervbe van még véve, hogy mikor a kockákat legenerálja, mindíg csak annyi oldalát készítse el, meg textúrázza, amennyit látok. Már kidolgoztam rá egy algoritmust remélem az a pár trigonometrikus számítás nem vágja majd hanyatt a programom, hátha később szükség lesz rá egy ilyesmi kiegészítésre.
   
Geri - Törzstag | 2192 hsz       Online status #146970   2011.01.28 13:31 GMT+1 óra  
A kézzel lekódolt frustum culling sokkal gyorsabb mint amire a driver képes, mivel a driver kénytelen polygononként megcsinálni, kézzel meg le lehet kódolni mondjuk egy befoglalógömbre/kockára amit elég egyszer kiszámolni, aztán onnantól lehet vizsgálgatva hogy hova projektálódik. Éppen ezért a kézzel lekódolt cull akár több százszor is gyorsabb lehet - és lesz is.

   
proof88 - Törzstag | 530 hsz       Online status #146969   2011.01.28 13:17 GMT+1 óra  
az utóbbi időben úgy tűnt nekem, hogy a frustum cullingot magától csinálja a driver és már jó ideje nem foglalkozik a GPU azokkal az objektumokkal, amik nincsenek benne a "látótérben" - így van de ahogy Pretender is írta: valszeg a programozó egyszerűbben meg tudja oldani a VFC-t, mintha a driver "légből kapott infók" alapján csinálná. Persze valamilyen szinten csinálja a driver, hiszen azzal is csak jobb sebességet nyújt a kártya.
   
Pretender - Törzstag | 2498 hsz       Online status #146967   2011.01.28 12:53 GMT+1 óra  
VFC nem bonyolult, ráadásul itt van leírás is: http://www.lighthouse3d.com/opengl/viewfrustum/
Belegondolva OC neked tényleg nem érdemes, valszin csak lassítana, de amúgy: http://www.gamasutra.com/view/feature/3394/occlusion_culling_algorithms.php
A lassúságot meg az okozhatja, ha tényleg a renderkörben hozod létre a display listet

szerk.:
Igen, írták valahol, hogy csinálja magától a vfc-t, de azt is írták mellé, hogy ha mi egyszerűbb módon meg tudjuk állapítani, hogy el kell-e dobni (pl. bounding sphere/box), akkor csináljuk

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #146965   2011.01.28 12:44 GMT+1 óra  
OpenGL 3.3-tól van ilyen is:

GL_ARB_occlusion_query2 – egyszerűbb és gyorsabb occlusion query, ami csak egy booleant ad vissza – jó, ha csak azt akarjuk látni, hogy takarásban van-e az objektumunk, etc.

Ha csak objektum láthatóságát akarod csekkolni, akkor ez jobb, mint a sima occlusion query.


SZERK: Lehet, hogy én vagyok hülye, de az utóbbi időben úgy tűnt nekem, hogy a frustum cullingot magától csinálja a driver és már jó ideje nem foglalkozik a GPU azokkal az objektumokkal, amik nincsenek benne a "látótérben".
Dare to imagine!
http://www.insaneidea.hu
   
proof88 - Törzstag | 530 hsz       Online status #146964   2011.01.28 11:35 GMT+1 óra  
Opengl-ben nincs előre definiált vfc vagy oc.

Ellenben pl oc-t könnyű használni úgy, hogy van rá extension. GL_ARB_occlusion_query a neve, ezt kell használni. De sztem ilyen kevés rajzolnivaló mellett nem hozna sokat, sőt lehet hogy lassítana. Komplex jelenet esetén sokat hozna. Kb úgy működik, hogy először az objektumodat befogó téglatestet rajzolsz anélkül, hogy a color bufferbe vagy a zbufferbe írnál. Ezután megkapod, hogy történt-e volna változás a zbufferben. Ha nem, az azt jelenti, hogy nem látszana a képernyőn az objektumod, ezért felesleges kirajzolni a komplex változatát. Sokat lehet nyerni vele, hiszen egy egyszerű téglatesttel teszteltél, de megspóroltad egy akár sok ezer vertexből álló objektum kirajzolását. A te esetedben sajnos a teszt objektum ugyanolyan bonyolult, mint amit kirajzolnál, hiszen kockákat rajzolsz. Bár az is igaz, hogy legalább a color bufferbe nem kell írni sokszor. Egy labirintusban eleve a kockák 80-90%-ának a kirajzolását meg tudnád spórolni vele, kérdés hogy ez gyorsít-e vagy sem, mert lehet hogy maga az extension használata annyival lassít hogy nem éri meg. De tesztelni kell, próbáld ki.

VFC-re nincs extension sem, azt le kell programozni, egyébként nem olyan bonyolult. Az is igaz, hogy újabb driverek már eleve csinálják maguktól is, bár mindenképp jó, ha van.

Egyébként rajzolni úgy is lehet, hogy a kamerától való távolság alapján rendezed a kockákat, és abban a sorrendben rajzolsz. Tehát a legközelebbi kockát rajzolod ki először, a legtávolabbit legkésőbb. Ennek az az előnye, hogy mivel az első kockákkal kb ki is rajzolod azt, ami ténylegesen látni lehet a képernyőn, a többi kocka renderelése meg a z-test miatt el fog maradni. Ugyebár a legrosszabb dolog az lenne, ha a legtávolabbi kockával kezdenéd a rajzolást, gyakorlatilag minden kockát ki kéne renderelni a color bufferbe is, hiszen nincs ami takarná őket.
   
proof88 - Törzstag | 530 hsz       Online status #146963   2011.01.28 11:24 GMT+1 óra  
Hát ott valami nem okés, mert 100 kocka az semmi. Biztos jól használod a display listet? Ugye a rajzolásnál már nem kompilálsz semmilyen display listet, csak glCallList() van?
Mert először még azt írtad, hogy a renderscene-n belül hívod meg a ujkocka(meret)-et is... na most az a függvény mit csinál? Utólag azt írtad hogy display listet használsz, ezek szerint azon belül hívod a display listet, ha igen hogy?

Illetve ez milyen gép? Nagyon ősréginek kell lennie, hogy 100 kockánál lassú legyen a display list. Vagy a kódodban van valami.

Illetve, hány fps-ed van, ami már lassú?
   
metaxa - Tag | 73 hsz       Online status #146959   2011.01.28 08:26 GMT+1 óra  
hááát mindíg másmennyiből, a pályától függően de akár 100 kockából is állhat. Utánanézek az Occlusion cullingnak meg a view frustum culling-nak. Ezeknek vannak előre definiált függvényeik? remélem nem kell nekem megírnom, mert lenne vagy 100 sor a matek része biztos
   
proof88 - Törzstag | 530 hsz       Online status #146958   2011.01.28 07:02 GMT+1 óra  
azért azt tisztázzuk, hogy hány darab kockából is áll a pálya?
   
Pretender - Törzstag | 2498 hsz       Online status #146957   2011.01.28 06:32 GMT+1 óra  
Occlusion culling a neve Meg nem ártana view frustum culling, az is eldob sokat.

   
metaxa - Tag | 73 hsz       Online status #146956   2011.01.28 06:25 GMT+1 óra  
Srácok elfelejtettem írni, hogy az egész már alapból Display listben van úgy ahogy írtátok. Nem sokkal lett tőle gyorsabb. Majd megmutatom a teljes forráskódot, hátha elrontottam valamit a DisplayListnél. Amugy arra gondoltam kéne egy függvény ami nem rajzolja ki azokat a kockákat, amik takarásban vannak
   
proof88 - Törzstag | 530 hsz       Online status #146948   2011.01.27 22:56 GMT+1 óra  
ősrégi dolog, én nem várnék tőle nagy gyorsulást - igazából a driverek eleve vertex buffer csinálnak a display listekből, a régiek nem, de egyébként is jó gyorsulás érhető el vele; itt egyébként is kockákról van szó, az nem nagy dolog
   
gopher - Törzstag | 496 hsz       Online status #146946   2011.01.27 22:01 GMT+1 óra  
Üdv!

Van egy olyan problémám, amit úgy hívnak, hogy widescreen fix felbontás esetén (1024x768, tilemap). Most FBO-t használok, és a végén egy textúrát rajzolok ki (össze lehet nyomni). Jó megoldásnak tűnik, csak kíváncsi vagyok, hogy ez jó megoldás e, ti másképp csinálnátok e, ill. ezt melyik videókártyák támogatják? Vagy ez már nagyon nem elvárás a videótól? (Mármint az FBO.)

Szerk: ja igen, a glScale a tile-ok szélénél "csíkozódást" eredményezett, ezért is az FBO.

Ezt a hozzászólást gopher módosította (2011.01.27 22:57 GMT+1 óra, ---)
   
gaborlabor - Moderátor | 4449 hsz       Online status #146945   2011.01.27 21:28 GMT+1 óra  
a display list az ilyen bohóckodás, ősrégi dolog, én nem várnék tőle nagy gyorsulást. inkább vertex array, vagy még inkább vbo, mint már írták mások is.

   
Asylum - Törzstag | 5462 hsz       Online status #146942   2011.01.27 20:48 GMT+1 óra  
OpenGL-ben is létezik vertex buffer, ugy hivják, hogy vertex buffer object. A GL_ARB_vertex_buffer_object -nek nézz utána.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #146940   2011.01.27 20:26 GMT+1 óra  
Ha nincs semmiféle optimalizálás, akkor az egész 1 display listbe gyorsabb lesz. Ha jól tudom az annyit csinál, hogy feltölti a cumót a videókártya memóriájába, és a glCallList-nél egy erre való hivatkozással állítja be a megjeleníteni kívánt listet. Ez azért gyorsabb, mert nem kell minden egyes frameben átküldeni a vga-nak a cumót. (valami olyasmi, mint DirectX-ben a vertexbuffer)
Ha van valami szűrés (pláne ha vfc és oc is van), akkor viszont az utóbbi, proof88 által írt megoldás jobb lesz, hiszen a legrosszabb esetben is csak a pálya csekély részét kellene kirajzolni.

   
proof88 - Törzstag | 530 hsz       Online status #146939   2011.01.27 20:02 GMT+1 óra  
ja bocs, én most olyat írtam hogy 1 kocka 1 display list ... igen Pretender rögtön arra gondolt amit a végén írtál, hogy a pályát 1 menetben. Na igen, akkor tényleg az egész pálya 1 display list. Bocsi.
   
proof88 - Törzstag | 530 hsz       Online status #146937   2011.01.27 19:58 GMT+1 óra  
Pretender-t kiegészítve: szerintem csináld úgy, hogy :

még amikor tölt a játék, szóval még a fő játékciklus előtt csinálj egy display listet:
Kód:
m_Handle = glGenLists(1);
glNewList(m_Handle, GL_COMPILE);
ujkocka(1.0f);
glEndList();


Így lesz egy display listed, ami egység oldalú kockát rajzol. A rajzoló kódodban pedig csak ezt a display listet kell meghívni úgy, hogy előtte glScalef()-et használsz a kocka átméretezésére, tehát hogy ne csak egység oldalú kockát tudj rajzolni:

Kód:
void labirintusrajzolas(){
  for(sor=0;sor!=maxsor+1;sor++){
    oszlop=0;
    for(oszlop=0;oszlop!=maxoszlop+1;oszlop++){
      if (lab[sor][oszlop] == '*'){
        glPushMatrix();
        glTranslatef(oszlop*meret,meret,sor*meret);
        glScalef(meret, meret, meret);
        glCallList(m_Handle);
        glPopMatrix();
      }
    }
  }
}
   
Pretender - Törzstag | 2498 hsz       Online status #146934   2011.01.27 18:13 GMT+1 óra  
Az én csekély opengl-es pályafutásomból (néhány nap ) rémlik egy olyan, hogy display list:
Kód:
m_Handle = glGenLists(1);
glNewList(m_Handle, GL_COMPILE);
//rajzolás kód ide
glEndList();

Rajzoláskor pedig csak annyi, h:
Kód:
glCallList(m_Handle);

Felszabadítás pedig:
Kód:
glDeleteLists(m_Handle, 1);

Emellett, ha sok objectet rajzolsz egyszerre és nincsen optimalizálás (legalább vfc, view frustum culling) akkor bizony tud akadni..

De majd az ogl-es arcok megmondják a tutit

   
metaxa - Tag | 73 hsz       Online status #146933   2011.01.27 17:31 GMT+1 óra  
Sziasztok!
Elkezdtem foglalkozni az OpenGL-el pár napja és problémám akadt az optimalizálással. Egy régi programom szeretném megírni 3d-ben. Fut is, csak borzasztóan akad. A program lényege, hogy beolvas egy txt-t amiben *-csillagokból van rajzolva egy labirintus. benne egy S betű és egy F betű. Az s betűn kezdünk, ha megnyitjuk a játékot és el kell a labirintusban jutni az F ig. Graphics.h-val úgy oldottam meg hogy ne akadjon, (mivel már ott is szaggatott, ha minden ciklusban kirajzoltam egy algoritmussal a labirintust), hogy elösször kirajzoltam, aztán a kirajzolt labirintust elmentettem a memóriába és már legközelebb csak azt kellett bevillantani.

Az opengl programom gluttal készült
glutDisplayFunc(renderScene);
glutIdleFunc(renderScene);

a render scenen belül van a függvény ami kirajzolja a labirintust.

Kód:
void labirintusrajzolas(){
for(sor=0;sor!=maxsor+1;sor++){
oszlop=0;
for(oszlop=0;oszlop!=maxoszlop+1;oszlop++){
if (lab[sor][oszlop] == '*'){
glPushMatrix();
glTranslatef(oszlop*meret,meret,sor*meret);
ujkocka(meret);
glPopMatrix();
}
}
}
}


Nem egy szép kód, nagyjából érthető. Alab[][] tömbben vannak a fájból beolvasott csillagok. bevittem ilyeneket hogy maxsor, maxoszlop hogy mindíg csak addig pörögjön ameddig kell, de nemnagyon gyorsult tőle.
Mi ilyen esetben a megoldás? nem akarok ilyen labirintusos célra .bsp pályát használni, szeretnék maradni a könnyen szerkeszthető txts módszernél.
Olyanra gondoltam, hogy egyszer kirajzolom a "pályát" aztán azt valahogy úgy ahogy van lementem a memóriába és legközelebb ciklusok nélkül csak simán azt rajzolom ki. Gondolom ez jó ötlet csak segítsetek légyszi megvalósítani mert erre még rá sem tudok keresni
Köszi minden segítséget!
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] > 35 < [40] [45] [50] [55] [60] [65] [70] [75] [80] [82]