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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2185
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
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]
Asylum - Törzstag | 5440 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 | 94 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 | 528 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 | 1336 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 | 2185 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 | 528 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 | 528 hsz       Online status #147272   2011.02.03 13:08 GMT+1 óra  
proof88 - Törzstag | 528 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 | 528 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 | 528 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 | 528 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 | 5440 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 | 2185 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 | 2185 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 | 528 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 | 528 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 | 528 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 | 528 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 | 528 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 | 491 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 | 5440 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 | 528 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 | 528 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!
   
Pretender - Törzstag | 2498 hsz       Online status #146705   2011.01.20 18:05 GMT+1 óra  
áhá, tegnapira: Annál lehet jobban megcsinálni, h bezáratom az ablakot, majd újra megnyitom az új paraméterekkel?

   
Pretender - Törzstag | 2498 hsz       Online status #146675   2011.01.19 22:52 GMT+1 óra  
Gondoltam belenézek már én is ebbe az Ogl-be, de ahogy látom már az elején gondjaim vannak Eddig is Gerit nyüsztöltem msnen
Elérhetővé szeretném majd tenni, hogy játék közben lehessen fullscreen / windowed között, illetve felbontások között váltogatni. Amit találtam fullscreenre az ez:
Kód:
if (m_Fullscreen)
{
    DEVMODE displayMode;
    memset(&displayMode, 0, sizeof(displayMode));
    displayMode.dmSize       = sizeof(displayMode);
    displayMode.dmPelsWidth  = m_Width;
    displayMode.dmPelsHeight = m_Height;
    displayMode.dmBitsPerPel = 32;
    displayMode.dmFields     = DM_BITSPERPEL | DM_PELSWIDTH | DM_PELSHEIGHT;
    ChangeDisplaySettings(&displayMode, CDS_FULLSCREEN);
}

Ennek a "RegisterClassExA(&m_Wnd);" előtt kell lennie, különben szar az egész. Foglalkozott-e már valaki a fentebb említett váltásokkal?

szerk.:
Másik dolog, hogy érdemes-e ugyan úgy saját shadereket használni, vagy jó a "beépített"?

Ezt a hozzászólást Pretender módosította (2011.01.20 06:06 GMT+1 óra, ---)

   
Asylum - Törzstag | 5440 hsz       Online status #146563   2011.01.18 10:55 GMT+1 óra  
Ööö mért kéne átméretezni?

FBO: és akkor ugyanott lyukad ki mint az eredeti probléma...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Eldor - Tag | 162 hsz       Online status #146558   2011.01.18 06:25 GMT+1 óra  
Szerintem a textúrába rajzoláshoz használj FBO-t ( FrameBuffer Object ). Ezzel be tudod állítani, hogy a depth buffer is textúra legyen. Ezzel szokás mélységtérképet csinálni árnyékokhoz.

   
bit.0x8000 - Törzstag | 574 hsz       Online status #146556   2011.01.18 02:50 GMT+1 óra  
Egyébként rájöttem a megoldásra, ami végig az orrom előtt volt: mivel az OpenGL textúrákat amúgy is SDL_Surface-ekből olvasom be, ezért nem nagy tudomány, hogy az SDL_Surface-ben rakom össze a tile-okat, és csak azután csinálok belőlük textúrát...
Viszont egy kérdés: ha a grafika natív felbontása és az aktuális (desktop-ról átvett) felbontás különbözik, akkor érdemes a textúrát már a beolvasásnál átméretezni (az aktuális/natív arányban)?
   
bit.0x8000 - Törzstag | 574 hsz       Online status #146553   2011.01.17 23:54 GMT+1 óra  
Én valami ilyesmire gondoltam, csak nem ismerem különösebben az OpenGL belső működését...
   
bit.0x8000 - Törzstag | 574 hsz       Online status #146538   2011.01.17 22:03 GMT+1 óra  
És betöltött OpenGL textúrába hogyan lehet rajzolni?

szerk: Ahogy látom, ez a mostani megoldás nem is annyira rárajzolás, mint inkább "ráírás"...

Ezt a hozzászólást bit.0x8000 módosította (2011.01.17 23:56 GMT+1 óra, ---)
   
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]