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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2195
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]
Kristf - Törzstag | 125 hsz       Online status #84950   2008.04.11 07:21 GMT+1 óra  
Hello!

Opengl-ben hogyan tudom beállítani a kép (vagy monitor) frissítési frekvenciáját? És még azt is lekéne ellenőrizni, hogy a monitor milyen frekvenciát támogat, mert pl sima crt-re 85 Hz-et, de egy LCD -re csak 75 Hz-et szeretnék beállítani. Ja és nem GLUT-ot használok, hanem simán hozom létre a windows ablakot.

   
proof88 - Törzstag | 530 hsz       Online status #84916   2008.04.11 02:17 GMT+1 óra  
Hello!

A hajam égnek áll már!
Továbbra is a rendering contextes problémával szenvedek.
Előzmény: szerettem volna, ha futás köben bármikor lehetett volna új ablakot csinálni. Persze több ablakhoz is lehet ugyanazt az RC-t használni, de én külön RC-t szeretnék minden ablakhoz, hogy pl. ha más beállítást adok a másik ablakhoz, pl. ott már legyen élsimítás, akkor tényleg különbözzenek.
Na most, ha utólag csinálok RC-t, akkor azzal az a baj, hogy úgy lenne szép, ha megosztanám a textúrákat. Itt eleve bukik a dolog, mert a wglShareLists csak akkor működik jól, ha az elején hívod meg, tehét még 1 textúrád sincs. Ja és persze további kritérium, hogy a 2 rendering contextnek ugyanaz a pixel formatja legyen, pedig én pont azt akarom, hogy különböző is lehessen.
Gondoltam jó, egye-fene, mikor csinálok új RC-t, akkor fájlokból újra megcsinálom oda is a textúrákat. Otthon ment is, de itt suliban egyszerűen egy alap dolognál bukik el a dolog. Itt egy Geforce 6150 IGP van, és a wglCreateContext()-re másodszorra se NULL-t ad, tehát elvileg létrehozza a másik kontextet, DE amikor a wglCopyContext()-tel átmásolnám az első RC beállításait a 2.RC-be, akkor sok0000011-es memóriacím-hivatkozással elszáll az nvoglnt.dll. Tehát valami NULL hivatkozás van, valami osztálypéldány vagy strukt lehet, ami gondolom 0, a 11 meg a taghivatkozásból adódó offszetcím. Na mindegy, nálam nem NULL semmi,mert külön ellenőrzőm is. Ma megnézem, hogy mi történik Voodoo3-mal.

Valami ötlet, hogy lehetne még ezt jól megcsinálni?
Vagy valakinek ha van egy 2 RC-s progija, ami 2 ablakba rajzol, megdobhatna vele, hogy kipróbáljam a suliban... talán a driver defektes, de mivel nem vagyok rendszergazda, meg sem próbálhatom a drivercserét.
   
DMG - Szerkesztő | 3172 hsz       Online status #83723   2008.03.22 11:57 GMT+1 óra  
Elvilag ez nem jelenthet neki gondot, mert hát maga a parancs pont normalokra van kitalálva.

Mindegy, egyenlőre félre tettem, és maradtam sima Vertex Array-nél.




EDIT:
Na átalakítottam az egész extenson rendszert, egyszerűbb lett, és ennek hozományaként az ARB_vertex_buffer_object is átalakult, most működik.

Csak át kellett nézni az alapokat, mindig megfogadom, hogy nem dolgozom előre megírt kóddal, na tessék, csak át kellett írni.

Ez a sor eddig nem is szúrt szemet, és fogalmam sincs így utólag, hogy miért van belerakva.
Kód:
#define GL_ARRAY_BUFFER_ARB 0x8892
#define GL_STATIC_DRAW_ARB 0x88E4
typedef void (APIENTRY * PFNGLBINDBUFFERARBPROC) (GLenum target, GLuint buffer);
typedef void (APIENTRY * PFNGLDELETEBUFFERSARBPROC) (GLsizei n, const GLuint *buffers);
typedef void (APIENTRY * PFNGLGENBUFFERSARBPROC) (GLsizei n, GLuint *buffers);
typedef void (APIENTRY * PFNGLBUFFERDATAARBPROC) (GLenum target, int size, const GLvoid *data, GLenum usage);


Na gondoltam megosztom ha esetleg valaki találkozik hasonlóval a Nehe VBO tutor kapcsán, mert az tökéletesen működik, amig nem dolgozod bele a normalokat.

Ezt a hozzászólást DMG módosította (2008.03.22 15:18 GMT+1 óra, ---)
-----------------------------------------
Dont Listen to the Naysayers
   
syam - Törzstag | 1491 hsz       Online status #83698   2008.03.21 17:12 GMT+1 óra  
én még nem láttam ilyet bár én már csak vertex attributumokkal dolgozok;
talán az lehet a gond, h a normal csak 3 komponensű lehet (de ha vertex attribként adom meg akkor ilyen probléma nincs) és a stride bekavarhat...
alias aalberik
   
DMG - Szerkesztő | 3172 hsz       Online status #83693   2008.03.21 16:34 GMT+1 óra  
Tud esetleg valaki olyanról, hogy a GL_ARB_vertex_buffer_object-nek valami problémája lenne a Normálisok leképezésével?

Ugyanis 1.3-as OpenGL-ben csak ezt tdom használni tudomásom szerint VBO-ra, és amint engedélyezem a Normal leképezést a progam elszáll egy futásidejű hibával.

Leellenőritem többszőr is, telejsen ugyan azt a sémát követi a normálisaok tárolása, mint a textúra pontoké, vagy a vertexeké,és mégsem, VBO nélkül tökéletesen leképezi VBO-val lerohad.

Valaki esetleg találkozott már ezzel?

-----------------------------------------
Dont Listen to the Naysayers
   
DMG - Szerkesztő | 3172 hsz       Online status #83531   2008.03.20 05:32 GMT+1 óra  
Hát akkor első körben marad a redundancia, mert 2.x-re azért nem szeretném lekorlátozni a fejlesztést.

Aztán idő közben hátha megvilágosulok.

Kösz az infókat.

H aez most a prog.hu lenne, menne a pont
-----------------------------------------
Dont Listen to the Naysayers
   
syam - Törzstag | 1491 hsz       Online status #83526   2008.03.20 04:29 GMT+1 óra  
amit írtam módszer tényleg nem hatékony

a vertex array az kliens oldalon van, tehát rendszermemóriában, a vertex buffer van szerver oldalon, tehát a video memoriában;

a redundancia abban az esetben jelent hátrányt, ha cpuval akarsz vmit számoltatni (pl. animálás), mert akkor uazt a vertex poziciot többször kell kiszámolni;

a 64/128 mega vram pedig bőveeeen elég:]
alias aalberik
   
DMG - Szerkesztő | 3172 hsz       Online status #83524   2008.03.20 04:21 GMT+1 óra  
Viszont a nagy könyv szerint a glBegin glEnd párosítás a lehető legrosszabb a sebesség szempontjából.

Viszont ha tényleg ezt választanám, akkor sem nagyon értem ennek a módját.


Viszont halottam, hogy mivel a Vertex Array úgyis memóriába töltődik, így nem kell foglalkozni a redundanciával, mert hát van elég memória, ez esetben nem is lene gond, csak a VBO meg a videó memóriából vesz el ha jól tudom, az meg azért végesebb mint a RAM.

Szóval, mit javasolsz, érdemes a redundancia kiküszöbölésével szórakozni, vagy törődjek bele?
-----------------------------------------
Dont Listen to the Naysayers
   
syam - Törzstag | 1491 hsz       Online status #83520   2008.03.20 03:33 GMT+1 óra  
hmm,

hát van 1 nyakatekert megoldás:
az opengl egy indexellel címzi meg az összes arrayt (vertex,texcoord etc), ha ha gldraw... parancsot használsz;
ha azonban glbegin és glend között rajzolsz, akkor a glvertexpointered (és minden más ami együtt indexelődik vele) lehet array és glarrayelementtel hivatkozol rá viszont minden mást manuálisan kell átadnod
alias aalberik
   
DMG - Szerkesztő | 3172 hsz       Online status #83512   2008.03.20 00:07 GMT+1 óra  
WOW


Amúgy meg már megörültem kora reggel, hogy érkezett válasz a problémámra.

EDIT: Tyű és ezzel a posttal most meg is bontottam az egyenletet.
-----------------------------------------
Dont Listen to the Naysayers
   
fpeti - Törzstag | 1295 hsz       Online status #83510   2008.03.19 17:22 GMT+1 óra  
off:
WOW: syam hsz == DMG hsz (387-387 hozzászólás )
   
DMG - Szerkesztő | 3172 hsz       Online status #83509   2008.03.19 17:04 GMT+1 óra  
Kéne egy kis help.

Most kezdtem el tüzetesebben foglalkozni, a VBO-val, meg a hasonló vertex buffer területtel, és most döbbentem rá, hogy ahhoz, hogy az objektumot rendesen ki tudjam rajzolni glDrawElements-el, ahhoz minden egyes pontot redundánsan kell tárolnom, ha több normal, vagy több textura adatot akarok használni rajta.

Egyből rágugliztam, és olvastam is, hogy 1.x-ben iez van tessék szeretni, mert ez nekünk jó. és a multi indexeket csak 2.x tudja.

Na van esetleg erre valami trükk, hog yne kelljen redundáns adatokat tölteni a bufferbe, vagy agyaljak rajta?
-----------------------------------------
Dont Listen to the Naysayers
   
syam - Törzstag | 1491 hsz       Online status #81869   2008.02.19 13:20 GMT+1 óra  
ha jol tudom oglben ez is hasonlóan müködik, tehát mindegyik color buffer vagy fixed vagy float és mindegyikre uaz a maszkolás és blendezés vonatkozik - gf8nál van lehetőség külön maszkolásra és blendezésre

"akkor (általában) egyszerre 4 szín bufferbe tudsz renderelni" - a framebuffernek manapság nem csak 1, hanem max. 4 szín buffere lehet; ez tulajdonképpen a MRT, tehát egy PBuffer/FBO van, de ahhoz több színbuffer tartozik
alias aalberik
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #81849   2008.02.19 08:49 GMT+1 óra  
EZ DX alatt is így van, ott a külön buffereket Render Targeteknek hívják és ha egyszerre többe is akarsz képet rajzolni akkor azt meg Multiple Render Targetnek (MRT). DX9-nél meg asszem már alapból elvárás h tudja a kártya a NPo2 méreteket kezelni. Amire viszont figyelni kell (ez OGL alatt nemtudom hogy így van e, tehát ez részben kérdés is), hogy a jelenlegi kártyák (Geforce6-om legalábbis biztos) nem tudnak egyszerre különböző bitmélységű buffereket (render target-eket) használni -> Pong-omnál akartam MRT-t használni és 1 menetben kirajzolni glow-t, diffuse color-t és velocity-t is, ez utóbbit Vector4 formában (gondolom 64 bites, de XNA-ban már más a jelölés mint DX-ben) míg a többit Color (normál 8bit-4 csatorna felállásban) formátumban, és egy nagy fekete semmit kaptam.

OGL-nél egyszerre FBO-kba lehet több helyre is rendeleni? Ez most a leírásod alapján nekem nem volt tiszta ("akkor (általában) egyszerre 4 szín bufferbe tudsz renderelni" by syam).
   
syam - Törzstag | 1491 hsz       Online status #81836   2008.02.19 01:20 GMT+1 óra  
hmm,

mivel manapság szinte már-már kötelező vmilyen post process technikát használni ezért min. pbuffert használnak; ezenkívül még van FBO, de sajnos az "még nem minden kártyán tud mindent"

ha a kártya támogatja a NPOT méretű textúrákat, akkor teljesen mértékben a képernyő felbontásával egyező buffert tudsz készíteni és felhasználni textúraként sőt ha ARB_draw_buffersed is van, akkor (általában) egyszerre 4 szín bufferbe tudsz renderelni, mint1 multitextúrába renderelés

ha pedig valódi HDR-t szeretnél, ami mindenképp post processt igényel akkor pedig float texture-t kell választanod

már csak az a kérdés, h miért lassabb nálam FBO, mint PBuffer
alias aalberik
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #81834   2008.02.18 21:32 GMT+1 óra  
Értem, ThX
   
Geri - Törzstag | 2195 hsz       Online status #81832   2008.02.18 15:00 GMT+1 óra  
Idézet
ShAdeVampirE :
...csak én azt hittem (...) h az egy spéci, gyorsított cucc



Jól hitted.
A pbuffer lényege, hogy egy, a frame buffertől eltérő felbontású másodlagos "frame buffert" hozhass létre, és ezt akár közvetlenül textúrának használva renderelhess például nagy felbontású shadow mapeket.

A driverek 4096x4096ig szokták támogatni, de egyes kártyákkal csak 2048x2048ig elérhető.

Én nem használom ki, de az engine támogatja, és képes használni.
Ha nem használsz mondjuk shadow mapeket, akkor gyakorlatilag semmi értelme nincs neki.
Szokták még a renderelést is erre elvégezni, hogyha utána postprocesszálsz, mert akkor jobb esetben egy frame buffer copy-t megspórol a kari.

   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #81807   2008.02.18 10:13 GMT+1 óra  
Ok, csak én azt hittem (bár pbuffer-be nem nagyon mentem még bele) h az egy spéci, gyorsított cucc, de ezek szerint csak egy sima buffer.
   
Asylum - Törzstag | 5478 hsz       Online status #81806   2008.02.18 09:51 GMT+1 óra  
hát de nem is olyan bonyolult csinálni egyet...
width * height * sizeof(unsigned long) -out lefoglalsz ez böven elég 32 bites szineknek alfa meg minden turo vanbenne ráadásul összefüggö memoriaterület (mert hát ez a buffer is).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Geri - Törzstag | 2195 hsz       Online status #81805   2008.02.18 09:46 GMT+1 óra  
Idézet
ShAdeVampirE :
Hülye kérdés, de DX alatt pbuffer-nek van vmi megfelelője? V csak én nem találtam?



LPD3DXBUFFER pBuffer = NULL;
DWORD NumBytes = 800*600*4;
HRESULT ret = D3DXCreateBuffer( NumBytes, &pBuffer );
if(ret != D3D_OK){
return;
}

   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #81803   2008.02.18 09:31 GMT+1 óra  
Hülye kérdés, de DX alatt pbuffer-nek van vmi megfelelője? V csak én nem találtam?
   
Geri - Törzstag | 2195 hsz       Online status #81801   2008.02.18 06:18 GMT+1 óra  
Idézet
syam :
udvz,

nem tudja vki, ha pixel buffert használok akkor annak RCje lehet azonos az ablak RCjével?



sacc: nem.

eredetiDC=wglGetCurrentDC();eredetiRC=wglGetCurrentContext();
arnyek_pbuffer_hDC=wglGetPbufferDCARB(arnyek_pbuffer_hPBuffer);arnyek_pbuffer_hRC=wglCreateContext(arnyek_pbuffer_hDC);

aztán viszontlátás.

   
syam - Törzstag | 1491 hsz       Online status #81800   2008.02.18 04:47 GMT+1 óra  
udvz,

nem tudja vki, ha pixel buffert használok akkor annak RCje lehet azonos az ablak RCjével?
alias aalberik
   
~Cre@tine~> - Tag | 702 hsz       Online status #81714   2008.02.15 14:12 GMT+1 óra  
Még azért egy négyzet után korai engine-t tervezgetni, de ez már off és legközelebb szerintem oda irkáljunk.

U.I. Ja meg szerintem tesóddal tervzetess valami logót inkább. Mire elkészül a rendszer a logó is talán. Mindenütt nem lehet helytállni. Vagy programozás, vagy grafika.

   
psyche - Tag | 36 hsz       Online status #81712   2008.02.15 13:55 GMT+1 óra  
Psyche Builder.

Nem rossz, nem rossz.
A grafikus motor neve: psyche eng1ne
logó is van: http://saweb.atw.hu/logo.html

   
Miklós - Tag | 2 hsz       Online status #81711   2008.02.15 13:01 GMT+1 óra  
Open GL-ben rutinos programozót keresek egy egyedi munkára. (nem játékfejlesztés)
Ha valakit érdekel, meszaros.miklos@freemail.hu címre várnék visszajelzést.

   
~Cre@tine~> - Tag | 702 hsz       Online status #81691   2008.02.15 03:36 GMT+1 óra  
Psyche Builder.

Ezt a hozzászólást ~Cre@tine~> módosította (2008.02.15 03:41 GMT+1 óra, ---)

   
psyche - Tag | 36 hsz       Online status #81690   2008.02.15 02:41 GMT+1 óra  
már most lehet gondolkodni azon, hogy mi legyen a neve.
lehet kicsit kreatívabb is, mint: game maker,fps creator..stb.

   
~Cre@tine~> - Tag | 702 hsz       Online status #81666   2008.02.14 03:46 GMT+1 óra  
Igaz, hogy én mindig az .ISO változatot használtam eddig, hogyha újra kell telepíteni a rendszert, vagy valami, ne kelljen újra letöltögetni mindent. Akkor a netes telepítőben lehet ez benne sincs.

Jó nagy fába vágtad a fejszét. Arra vigyázz, hogy az OpenGL kezdőknek könnyű, de a tanulási görbéje más, mint mondjuk az XNA-nál, ahol nem nehezebb egy textúrázott, shaderes 3D modellt se betölteni, mint egy négyzetet. Egy időben dolgozgattam benne, nekem annyira nem jött be, hátha neked igen.

   
psyche - Tag | 36 hsz       Online status #81665   2008.02.14 03:33 GMT+1 óra  
kosz, hogy a felhívtad a figyelmem MaNiAc cikkére. elfogom olvasni.
a sünis könyv megvan. átnézem azt is. csak az ott használt matematikát kéne jobban megértenem.
hát nem tudom, de én amikor telepítettem a VC# Expresst, akkor .NET nélkül fel se rakja.
jelenleg egy ilyen: http://www.silentworks.hu/index.php
progi tervezésén dolgozom. lehet elötte kidobok vmi egyszerü lovoldozos fpst.
ha vmi érdemlegeset csinálok akkor felteszem ide is.

   
~Cre@tine~> - Tag | 702 hsz       Online status #81664   2008.02.14 03:18 GMT+1 óra  
Idézet
psyche :
itt az egyik legegyszerűbb technika arra, hogyan üzemeljük be a Taot C# alatt.
http://saweb.atw.hu/opengl.html


Na itt már végre látszik mit csináltál. Nem kötözködés képp, de azt a részt töröld ki, hogy .NET 3.5 letöltése/telepítése, mert fölösleges, ha a VC#-t is felrakod, mivel a telepítő CD, vagy DVD alapból tartalmazza azt.

Ezt pedig teszteld le. precedens
Lehet .NET 3.5-nél mindegy.
Kód:
        [STAThread]
        static void Main()


Ha megvan a sünis, könyv a benne lévő ogl progikat 1-1 ben fel tudod használni Tao-val is. Sok sikert! (Be is regeled a projectet, ha lesz valami?)

   
beast - Törzstag | 1241 hsz       Online status #81662   2008.02.14 02:58 GMT+1 óra  
Jah, bocs, elnéztem.
Azért nem véletlen, hogy pl. Doom3 engines játékokat is mind újra kell inditani egy beállitás elfogadásához...
Egyébként ez a sharelists-es megoldás amolyan félhivatalos, szóval...
S mivel nem új dologról van szó, gondolom van rá rendes implementáció nvidia és ati részről is.
Tegyél egy próbát, teszteltesd különböző konfigokon és kiderül mennyire életképes.

   
proof88 - Törzstag | 530 hsz       Online status #81654   2008.02.13 15:03 GMT+1 óra  
Nem értem, miért kell átmeneti RC. Nem elég a régi meg egy új?
A nagy hsz-emben írtam:
Idézet
Amit most nézegettem, a wgl-es rc manipuláló függvények. Sikerült működőképessé tenni az új rc-vel való dolgozást úgy, hogy wglCopyContext(régi_rc, új_rc, GL_ALL_ATTRIB_BITS), aztán wglShareLists(régi_rc, új_rc), és törlöm a régi_rc-t.

Szóval működött az, amit csináltam, a gondom az egésszel az MSDN-en leírt, számomra aggasztó mondat:
Idézet
All rendering contexts of a shared display list must use an identical pixel format. Otherwise the results depend on the implementation of OpenGL used.

Ez alapján a régi és az új RC-nek is megegyező pixel formátumot kell használnia. Nálam ez nem teljesül, mivel az új pixelformátum annyiban tér el a régitől, hogy kérek benne sample buffereket.
   
beast - Törzstag | 1241 hsz       Online status #81653   2008.02.13 14:27 GMT+1 óra  
Nop, a megoldás a wglShareLists.
A lényeg:
- van egy opengl contexted
- ha cserélni akarod, akkor hozz létre még egy átmeneti context-et, lehetőleg _ugyanazzal_ a pixel formátummal (legjobb ha minden context létrehozáskot letárolod a pixelformatdescriptort)
- mielőtt még belőnéd aktuális contextre: wglShareLists(oldRC, newRC) és ez után wglMakeCurrent
- létrehozod az új pixelformátumot, contextet
- ha megvan a vadiúj context, akkor megint wglShareLists(), most az első paraméter lesz az átmeneti rc, a második az új rc (nem a temp!)
- wglMakeCurrent új context-tel
Ne felejtsd törölni az átmeneti context-et.
Nálam működik, viszont az összes ogl állapotot újra be kell állitani, ami az előző kontextusban volt...

   
beast - Törzstag | 1241 hsz       Online status #81650   2008.02.13 12:11 GMT+1 óra  
Én nem tartom megoldásnak, hogy bent tarts annyi adatot a memóriában.
A téma érdekes, én is utána nézek.

   
proof88 - Törzstag | 530 hsz       Online status #81649   2008.02.13 12:05 GMT+1 óra  
Amúgy nem akarom benn tartani a memóriában a textúrákat, ezt lehet állítani textúránként, de kötelezően csak ilyen esetekre, NEM! Ha van 100 db textúra, amik beleférnek a VRAM-ba, akkor foglaljanak el helyet a rendszermemóriában is, csak azért, hogy ilyen esetekben gyorsabb legyen a töltés? Jobb ötletem van: inkább visszakérem a textúrákat a VRAM-ból, majd visszatöltöm őket új contextben... Sajnos a mipmap-szinteket is mind kell, mert az 1 dolog, hogy lehetne generáltatni őket, de ha pl DDS-ből származott a textúra, előre meghatározott mipmap-szintekkel, akkor ott ragaszkodni kell azokhoz.
Rájöttem hogy ez inkább engine-fejlesztés vagy hasonló topic, de ha már itt kezdtem el tárgyalni, itt is fejezem be.
   
proof88 - Törzstag | 530 hsz       Online status #81648   2008.02.13 11:50 GMT+1 óra  
Nyilván, ha a kép adatokat a memóriában tartom, akkor viszonylag gyorsan újra tudom csinálni a textúrákat. Sőt, a textúrákat is le tudom kérni, és újakat létre tudok hozni belőlük az új contextben. Ez viszont bonyolultabb. Bár végül is, nem annyira. Na mindegy, majd megírom az eredményeket.
   
proof88 - Törzstag | 530 hsz       Online status #81647   2008.02.13 11:45 GMT+1 óra  
Ok, tehát D3D maga kezeli ezt. Bizony, én OGL-elben dolgozok, és pont azért akarom így csinálni, mert zavar, hogy D3D magától csinálja.
Na, mindenesetre megnézem h x textúrát mennyi idő újratölteni úgy, ahogy írtam...
Shaderes élsimításnál még nem járok.
   
beast - Törzstag | 1241 hsz       Online status #81644   2008.02.13 11:18 GMT+1 óra  
Viszont, ha shaderes volt az élsimitás, akkor nem is kellett semmit újratölteni...

   
beast - Törzstag | 1241 hsz       Online status #81643   2008.02.13 11:17 GMT+1 óra  
Ha jól tudom, DX-nél nem kell teljesen "lerombolni" a rendszert a multisample-hez, van egy device reset, ami a megadott struktúra szerint újraépiti. OGL-nél viszont teljesen újat kell hozzá létrehozni.
Viszont dx-nél is újra kell tölteni azokat az adatokat, amik a D3DPOOL_DEFAULT-tal lettek a memoriába pakolva.
Ha jól tudom, ha nem, javitsatok ki.

   
proof88 - Törzstag | 530 hsz       Online status #81636   2008.02.13 10:13 GMT+1 óra  
Ennyire bonyolultat kérdeztem vagy senkinek sincs kedve elolvasni, mert túl hosszú?
   
proof88 - Törzstag | 530 hsz       Online status #81505   2008.02.11 14:43 GMT+1 óra  
Üdv!

Az lenne a problémám, hogy a graf. motorommal szeretném megoldani a teljes újraindítás nélküli bekapcsolását az élsimításnak. OpenGL, multisampling AA. Ez azt jelenti, hogy ne csak a motor inicializálásánál lehessen megadni az MSAA-t, hanem menet közben is. Odáig eljutottam, hogy megy az élsimítás. Viszont textúrákkal szenvedek. XD
Részletesen: program inicializálja a motort, a motor csinál ablakot meg amúgy mindent ő kezel, a programnak objektumokat ad vissza (mutatók ugyebár osztálypéldányokra). A program betöltet pár textúrát, ezek mind objektumok lesznek, legyenek mondjuk tex1 és tex2.
A program meghívja a motor SetFSAA() függvényét, ami megpróbálna okosan cselekedni. Odáig eljut, hogy bekapcsolja az élsimítást... ehhez új ablak kell, aminek a DC-jéhez beállítja az új pixelformatot, aztán ehhez új RC is kell. Mivel új az RC, ide kéne hozni az előző RC-ből a textúrákat, etc. Újratölthetném a textúrákat a motor rutinjaival automatikusan, de akkor máshol lennének a memóriában, mint ahova tex1 és tex2 mutat, magyarul a programot nem tudjuk értesíteni, hogy elévült adat van nála. Megoldást jelenthet erre az, hogy spéci módon töltöm újra a textúrákat, tehát a textúra objektumaimmal töltetem újra önmagukat, így maradnak a pointerek, ez viszont macerás, mert figyelni kell minden olyanra, amit a program eddig kért, azaz LOD, tömörítési eljárás, mipmapek, etc... Ráadásul nem vagyok benne biztos, hogy ez a legnyerőbb és leggyorsabb megoldás.
Amit most nézegettem, a wgl-es rc manipuláló függvények. Sikerült működőképessé tenni az új rc-vel való dolgozást úgy, hogy wglCopyContext(régi_rc, új_rc, GL_ALL_ATTRIB_BITS), aztán wglShareLists(régi_rc, új_rc), és törlöm a régi_rc-t. Ezzel csak az a gondom, hogy egyáltalán nem látom túl biztosnak, hogy máshol is működik. MSDN-en azt olvastam, hogy:
,,All rendering contexts of a shared display list must use an identical pixel format. Otherwise the results depend on the implementation of OpenGL used."
Nálam pl. a 2 RC pixelformatja különböző, pont azért, mert az újabbat élsimításhoz használom. Szóval lehet, hogy másik driverrel/kártyával azt kapom, hogy nincsenek meg a textúrák, vagy kapok egy runtime errort.

Nektek erről az egészről mi a véleményetek? Mert pl NFS Most Wantedban az élsimítást játék közben lehetett állítani, és tök gyorsan, tehát nem sokat tölthetett újra - kivéve, ha a memóriában tartotta a textúrákat, meg egyebeket.

Persze, azt is csinálhatnám, hogy a program tölteti újra a textúrákat a motorral a hagyományos módon, és akkor megkapja a jó mutatókat, de pont az lenne a lényeg, hogy a motor maga intézze el a piszkos munkát.
   
psyche - Tag | 36 hsz       Online status #81502   2008.02.11 13:47 GMT+1 óra  
Tökéletesen igazatok van(orphy,hacker), de olyan egyszerű projectekkel dolgozom, hogy még felesleges a .NET-et belevonszolni. A cél, hogy az OpenGL programozás alapjait ismertesem és
mindenképp kell egy Win ablak, amit a legegyszerűbb Gluttal megoldani.
Amúgy a FreeGlut is platformfüggetlen.
Az "FPS Creator+Game Maker" keveréke progi ablakkezelése erősen .NET-es lesz, de ez nem
része a cikksorozatnak.

Ezt a hozzászólást psyche módosította (2008.02.11 15:03 GMT+1 óra, ---)

   
Hacker - Törzstag | 567 hsz       Online status #81466   2008.02.11 07:20 GMT+1 óra  
Idézet
Orphy :
Idézet
psyche :
itt az egyik legegyszerűbb technika arra, hogyan üzemeljük be a Taot C# alatt.
http://saweb.atw.hu/opengl.html




Hmmm,

látom GLUT-ot használsz hozzá.
Azért itt megjegyezném, hogy az alap Windows-ot is lehet használni, akár panelre renderelve is: ha nem szempont a gépfüggetlenség, akkor lehet érdemesebb azt használni - később könnyebb lesz pl tool-okat készíteni a játékhoz.

Érdemes végigtúrni a TAO-s példákat ezügyben, főleg a NeHe-seket.



De mivel maga a .NET is pont a platformfüggetlenség miatt lett kitalálva, így elméletileg ugyanúgy kellene futnia egy tao-s proginak Linuxon, mint Windows-on. Szóval én nem ajánlom a glut használatát taoban ha c# nyelven programozol.
No [img] !
Programozz ne háborúzz!!!!

   
beast - Törzstag | 1241 hsz       Online status #81462   2008.02.11 06:30 GMT+1 óra  
Idézet
Orphy :
Hmmm,

OpenGL alatt létezik valami olyasmi, mint a DirectX .fx file-ja?
Ha igen, akkor tudtok adni róla egy linket?

Köszi


Ha az fx a shader, akkor glsl (dx - hlsl), egyéb nincs.

   
Orphy - Törzstag | 1893 hsz       Online status #81461   2008.02.11 06:24 GMT+1 óra  
Idézet
psyche :
itt az egyik legegyszerűbb technika arra, hogyan üzemeljük be a Taot C# alatt.
http://saweb.atw.hu/opengl.html




Hmmm,

látom GLUT-ot használsz hozzá.
Azért itt megjegyezném, hogy az alap Windows-ot is lehet használni, akár panelre renderelve is: ha nem szempont a gépfüggetlenség, akkor lehet érdemesebb azt használni - később könnyebb lesz pl tool-okat készíteni a játékhoz.

Érdemes végigtúrni a TAO-s példákat ezügyben, főleg a NeHe-seket.
   
Orphy - Törzstag | 1893 hsz       Online status #81460   2008.02.11 06:20 GMT+1 óra  
Hmmm,

OpenGL alatt létezik valami olyasmi, mint a DirectX .fx file-ja?
Ha igen, akkor tudtok adni róla egy linket?

Köszi
   
psyche - Tag | 36 hsz       Online status #81447   2008.02.11 01:28 GMT+1 óra  
itt az egyik legegyszerűbb technika arra, hogyan üzemeljük be a Taot C# alatt.
http://saweb.atw.hu/opengl.html

   
syam - Törzstag | 1491 hsz       Online status #81361   2008.02.09 18:13 GMT+1 óra  
vagy perlin noise-zal generáltatsz texturát akár előre renderelve akár realtime:]

http://www.pcdome.hu/image.php?image=/gallery/415/image146.jpg&caption=Neverwinter%20Nights - itt is ilyet használtak real time
alias aalberik
   
Kristf - Törzstag | 125 hsz       Online status #81295   2008.02.09 10:15 GMT+1 óra  
Na oké még próbálgatom...

   
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]