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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
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]
Joga - Törzstag | 1791 hsz       Online status #93184   2008.07.28 02:14 GMT+1 óra  
Thx, gl, asszem igazad van

Ezek szerint alapértelmezett, hogyha a textúrám szürkeárnyalatos

Kipróbálom, azt ha nem megy, akkor fpeti kulcsszava + google


Szerk.: Vagy lehet, hogy a szín értékeit beszorozza a textúra értékeivel, És így hozza létre, és alapból ugye a fehér szín miatt jelenik meg a textúra változatlanul

Szerk2.: Igen, ebben az esetben át kell alakítani a textúrámat, hogy minden szín fehér legyen, az alpha pedig a megnyitott képnek megfelelő, így lehet majd színezgetni

Ezt a hozzászólást Joga módosította (2008.07.28 03:07 GMT+1 óra, ---)
(ಠ ›ಠ) Stewie!

   
fpeti - Törzstag | 1295 hsz       Online status #93171   2008.07.27 13:46 GMT+1 óra  
Idézet
Joga :
Részecskerendszereknél szoktam látni, hogy egy részecskének az alphamapját( fehér: 1.0 alpha..Fekete: 0.0 , szürke 0.5, stb ) Nyitják meg textúraként, majd ezt valahogy a kiválasztott színnel kombinálják ( glColor3f )
Ilyet hogyan kell csinálni, mit kell beállítani?Esetleg nem tud valaki egy kis leírást?


per-pixel alpha blending-nek hívják ezt talán.. csak DX-ben tudom, hogy kell, de hátha rá tudsz ezzel keresni.
   
gaborlabor - Moderátor | 4449 hsz       Online status #93170   2008.07.27 13:03 GMT+1 óra  
Nem egészen értem mire gondolsz, de olyan van, hogy egy szürkeárnyalatos képet töltesz be textúraként és azt használod. Akkor ha a poly kirajzolása előtt a színt pirosra állítod pl, akkor ahol a textúrán fehér van ott lesz teljesen piros, ahol fekete ott ugye fekete. Ez az alapértelmezett működés. De át is lehet állítani a glTexEnvf( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, xyz); fgv-vel. (xyz lehet pl GL_MODULATE, az az alap).
Ha baromságot mondtam, valaki javítson ki.

Ezt a hozzászólást gaborlabor módosította (2008.07.27 14:00 GMT+1 óra, ---)

   
Joga - Törzstag | 1791 hsz       Online status #93166   2008.07.27 05:57 GMT+1 óra  
Részecskerendszereknél szoktam látni, hogy egy részecskének az alphamapját( fehér: 1.0 alpha..Fekete: 0.0 , szürke 0.5, stb ) Nyitják meg textúraként, majd ezt valahogy a kiválasztott színnel kombinálják ( glColor3f )
Ilyet hogyan kell csinálni, mit kell beállítani?Esetleg nem tud valaki egy kis leírást?
(ಠ ›ಠ) Stewie!

   
gaborlabor - Moderátor | 4449 hsz       Online status #92766   2008.07.19 05:50 GMT+1 óra  
Próbálta már valaki az OpenGL Window Framework nevű találmányt?

GLUT-ból elegem lett, mert nem lehet normálisan kilépni a mainloopból, freeglutban van glutLeaveMainLoop() de az meg hibát dobott, mi szerint inicializálást előtt akartam kilépni a hurokból... Na akkor telt be a pohár, elolvastam beast cikkeit meg a NeHe-s tutorialt, a kettőből összehegesztettem valamit, ablakos módban működik, fullscreennél elszáll a prog.

Arra gondoltam, minek szívni az ablakozás megírásával, biztos írtak már rá valami elegáns megoldást mondjuk egy osztály formájában, és azt találtam, amit fentebb linkeltem. A feature listája egész szép. Ha nincsenek vele kapcsolatban negatív tapasztalatok akkor közelebbről is megnézem, mert 1. ránézésre nagyon bejövős.

   
gaborlabor - Moderátor | 4449 hsz       Online status #86948   2008.05.10 09:55 GMT+1 óra  
Örülök, hogy összejött.
ezzel a vistával csak a gond van...

   
Etom - Tag | 6 hsz       Online status #86947   2008.05.10 09:53 GMT+1 óra  
Idézet
gaborlabor :
Nem saját kódja van, hanem pl PhysX sample. Meg legújabb driver. (lásd physx topic)

Rákerestem Google-ban, és ezt találtam:
http://www.opengl.org/pipeline/article/vol003_7/

Én nem olvastam végig, de ír erről a problémáról is. Elsőnek megpróbálnám kikapcsolni az Aero-t.



Hát öcsém tökön döföm magam.
Kilőttem a feladatkezelőben a dwm.exe-t és már megy is.
Nem gondoltam volna hogy csak ennyi az egész.
Örök hála..

   
gaborlabor - Moderátor | 4449 hsz       Online status #86944   2008.05.10 09:30 GMT+1 óra  
Nem saját kódja van, hanem pl PhysX sample. Meg legújabb driver. (lásd physx topic)

Rákerestem Google-ban, és ezt találtam:
http://www.opengl.org/pipeline/article/vol003_7/

Én nem olvastam végig, de ír erről a problémáról is. Elsőnek megpróbálnám kikapcsolni az Aero-t.

   
Joga - Törzstag | 1791 hsz       Online status #86943   2008.05.10 09:22 GMT+1 óra  
forráskód?

Szerk.: Ha beraksz valami tárgyat, akkor megy?
Lehet, hogy bekapcsoláskor nem törlöd le egy színnel az egészet, ezért oloyan, mintha átlátszó lenne
(ಠ ›ಠ) Stewie!

   
Etom - Tag | 6 hsz       Online status #86942   2008.05.10 09:20 GMT+1 óra  
Hi,
Lenne nekem egy érdekes problémám.
Az OpenGL-es samplek nem működnek megfelelően.
Megnyílik a windows-os ablak és tök átlátszó a keret kivételével.
íme: Screenshot

   
Joga - Törzstag | 1791 hsz       Online status #86597   2008.05.06 09:26 GMT+1 óra  
Thx


Szerk.: Találtam egy példaprogramot is
offset.c

Ezt a hozzászólást Joga módosította (2008.05.06 10:38 GMT+1 óra, ---)
(ಠ ›ಠ) Stewie!

   
gaborlabor - Moderátor | 4449 hsz       Online status #86593   2008.05.06 08:58 GMT+1 óra  
Íme az én (valszeg favágó) módszerem:
Először kirajzolod rendesen. Aztán
glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
Meg feketére állítod a színt, és akkor szerintem nem is kell kikapcsolni a textúrázást, úgyis fekete lesz.
És kirajzolod mégegyszer.
Lehet, hogy z-fighting lesz belőle.
De ha kikapcsolod a depth testet (glDisable(GL_DEPTH_TEST)), akkor az azért nem jó, mert akkor az összes éle látszani fog. (Egyébként a glDepthFunc-al lehet szabályozni a depth test működését.)
Én ezt próbálnám ki:
glPolygonOffset

szerk.: az "OpenGL röviden"-ben van egy példa, ami pontosan azt csinálja, amit te szeretnél, asszem valami tölcsért vagy mit rajzolnak ki így. A könyvem nincs itthon, nem tudok belenézni, de ha jól rémlik, ők is a glPolygonOffset-et használják.

   
Joga - Törzstag | 1791 hsz       Online status #86591   2008.05.06 08:26 GMT+1 óra  
Azt hogyan lehet megcsinálni, hogy egy testet úgy rajzjak ki, hogy az élei feketék legyenek?..Szóval én először arra gondoltam, hogy kirajzolom a testet( GL_QUADS, stb ), aztán meg az éleket ( GL_LINE_LOOP ), de ilyenkor elvileg a depth buffer miatt van, amikor a látom a vonalat, van amikor nem, ha jól tudom

vagy be lehet állítani, hogyha a depth bufferben egyezés van, akkor is rajzolja ki azt, amit akarok, vagy ez mindig véletlenszerűen, vagy előre meghatározott módon van?
(ಠ ›ಠ) Stewie!

   
proof88 - Törzstag | 530 hsz       Online status #84983   2008.04.11 13:31 GMT+1 óra  
Azóta kommenteztem a wglCopyContextes részt, most már ment mind2 kontexttel a dolog a suliban, itthon viszont a Voodoo3-mal kék halál lett, és szintén 0 hivatkozás... sajnos így nem tudok debuggolni, hogy egyből kék halál lesz, mindenesetre gyanítom, hogy kb akkor, mikor csinálom az új contextet... a neten kerestem, de nem találtam olyan példaprogit, ami csinálna 2 ablakos, 2 rc-s rendszert...
   
beast - Törzstag | 1241 hsz       Online status #84965   2008.04.11 10:39 GMT+1 óra  
Kössz kicsy.

   
Kristf - Törzstag | 125 hsz       Online status #84960   2008.04.11 09:00 GMT+1 óra  
Kösz, ezzel sikerült megoldani.

   
beast - Törzstag | 1241 hsz       Online status #84951   2008.04.11 07:22 GMT+1 óra  
EnumDisplaySettings
ChangeDisplaySettings

Hmm, pedig okés mindkét link...

(Zárójeleket nemszereti)

Ezt a hozzászólást kicsy módosította (2008.04.11 07:44 GMT+1 óra, ---)

   
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 | 2198 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 | 5512 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 | 2198 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 | 2198 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.
   
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]