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 #208423   2015.10.07 13:02 GMT+1 óra  
Nem tudok sűrűbben cikket írni mert baromi sok meló : / (ez is két hónap volt)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
zeller - Törzstag | 464 hsz       Online status #208420   2015.10.06 17:32 GMT+1 óra  
Jo cikk. Az elejebe tehettel volna tobb abrat a kepletekhez. Regen volt mar...

   
Asylum - Törzstag | 5440 hsz       Online status #208378   2015.09.28 20:44 GMT+1 óra  
Köszi, csak annyit szeretnék kérni, hogy a blogbejegyzésre (amit ide beraktam) mutasson a link, mert ott számolja a statisztikát
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2519 hsz       Online status #208375   2015.09.28 18:41 GMT+1 óra  
Done.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Lord_Crusare - Törzstag | 1286 hsz       Online status #208369   2015.09.28 11:56 GMT+1 óra  
Fú, köszi, ez baromi hasznos!

   
Asylum - Törzstag | 5440 hsz       Online status #208367   2015.09.28 10:11 GMT+1 óra  
Physically based rendering cikk:

http://darthasylum.blog.hu/2015/09/28/physically_based_rendering

Ha most visszaemlékszem arra, hogy annak idején milyen cikkek voltak itt az oldalon a Phong modellről, akkor ezt a technológiát egy újabb mérföldkőnek kell tekintem, sőt ez kellene hogy az új generáció standardja legyen innentől kezdve (a látszólagos nehézsége ellenére).

Lenne szíves valaki befrissíteni a blogszemlét? Szerintem ez megér annyit
Thx
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Bukta - Tag | 308 hsz       Online status #207097   2015.03.17 13:35 GMT+1 óra  
Következőre már az lesz írok egy sajátot aztán tudom mi hol van honnét hova megy a sin meg a cos. Tegnap már átnéztem kézzel hogyan lehet forgatni 1-1 tengelyen. Kicsit tovább fog tartani, de 2D-be is írtam saját Vector2 osztályt és minden működött vele.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Asylum - Törzstag | 5440 hsz       Online status #207093   2015.03.16 22:24 GMT+1 óra  
Idézet

Lényegében rossz a forward.



Mert rossz oldalról szorzod...

Szvsz a jf ott kezdődik hogy saját matlibet írsz és nem hagyatkozol ilyen nem egyértelmű szarokra (glm ugyanilyen fos).

Ezt a hozzászólást Asylum módosította (2015.03.17 13:55 GMT+1 óra, 827 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Bukta - Tag | 308 hsz       Online status #207087   2015.03.16 13:47 GMT+1 óra  
Nah igen ez a yaw, pitch, roll kamera kell nekem. De beírtam Asylum a kodod és hát nem igazán szuperál. Vmit még mindig elcseszek. Ja és OpenTK-t használlok, de ugyanaz mint a gl kb. Itt a kód:

Kód:
Matrix4 perspective = Matrix4.CreatePerspectiveFieldOfView(1.0f, Width / Height, 0.01f, 2000f);
GL.MatrixMode(MatrixMode.Projection);
GL.LoadIdentity();
GL.MultMatrix(ref perspective);

Matrix4 view = Matrix4.Identity;
view = Matrix4.Mult(view, camera.MatrixFromYawPitchRoll(camera.Yaw, camera.Pitch, camera.Roll));
camera.Forward = Vector3.Transform(new Vector3(0,0,-1), view);
camera.Position += camera.Forward / 10f;
view = Matrix4.Mult(view, Matrix4.CreateTranslation(camera.Position.X, camera.Position.Y, camera.Position.Z));

GL.MultMatrix(ref view);
GL.MatrixMode(MatrixMode.Modelview);
GL.LoadIdentity();


Azt csinálja hogy folyamat megy a Z tengelyen, de akármerre yaw-olok meg rollozok,.. mindig a Z tengelyen megy ugyanabba az irányba a kamera. Lényegében rossz a forward.
Instalok a te módszeredet még nem igazán próbáltam.

ui. a forgatós kodot innét vettem: http://www.opentk.com/node/3758 (ezt csak bemásoltam ránézésre nem igazán akartam megérteni )
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Asylum - Törzstag | 5440 hsz       Online status #207078   2015.03.15 22:27 GMT+1 óra  
Rossz oldalról közelíted meg...ha jól értem spectator kamerát akarsz (bár egy repülős játékhoz miért pont azt?), persze arra is lehet használni a lookat-ot csak nincs értelme. Milyen matlibet használsz?

Kód:
mat4 view = rotate(yaw, pitch, roll);
vec3 forward = view * vec3(0, 0, -1);

eyepos += forward * speed;
view = translate(eyepos) * view;
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #207073   2015.03.15 19:11 GMT+1 óra  
Csinálhatsz egy olyat, hogy készítesz egy orientation matrixot, amiben eltárolod a forgatást. Majd, ha megvan, hogy a középponttól mennyire szeretnéd látni a modellt, akkor eltranszformálod azt a vektort ezzel az orientation matrix-szal, valami ilyesmi:
Kód:
orientation.yawPitchRoll(rotate);
eyePosition = position + Vector3::transform(eyeOffset, orientation);

Majd ezzel már tudod használni a lookAt függvényt.

   
Bukta - Tag | 308 hsz       Online status #207072   2015.03.15 18:32 GMT+1 óra  
Okés köszönet, de az a forgatás akkor is kell a repcsi irányításához :/ . Van a kamera pos, meg van a target, és a targetet a kamera körül kéne mozgatni. De akárhogy csinálom mindig az origo körül mozgatja.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Instalok - Tag | 530 hsz       Online status #207069   2015.03.15 17:33 GMT+1 óra  
Van külön mátrix erre, amit te számolsz, az a world mátrix A view mátrixra nézd meg a lookAt nevűt. Ennek van 3 pozíciója: hogy honnan nézel, mit nézel, és mi a world up.

   
Bukta - Tag | 308 hsz       Online status #207068   2015.03.15 17:17 GMT+1 óra  
view = identity;
view = scale*rotate*translate;
Így és azem ez a jo sorrend. de csak forgatom. scale nem játszik.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Asylum - Törzstag | 5440 hsz       Online status #207067   2015.03.15 16:15 GMT+1 óra  
Hogyan számolod ki a view mátrixot?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Bukta - Tag | 308 hsz       Online status #207065   2015.03.15 15:58 GMT+1 óra  
Üdv

Jó régen forumoztam már itt, ugyhogy elejtek egy kérdést 3D-s repülős játékot akarok készíteni. Viszont már az elején elakadtam :/ megcsináltam a sík pályát -később domborzatot is- de a kamera mozgatás nem megy. Azt akarom h ha nyomom az előre gombot akkor a kamera menjen előre (arra amerre néz). Viszont akkor tudni kéne az irányvektort. Volt pár 5letem, de nem jöttek be. Nektek biztos nem nagy varázslat ezt megoldani .

Előre is kösz!
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Instalok - Tag | 530 hsz       Online status #207003   2015.03.12 11:35 GMT+1 óra  
Idézet
Asylum :
ui.: még jó hogy elolvastam, én is rájöttem egy kurvanagy marhaságra az engineben


Szívesen!

   
Asylum - Törzstag | 5440 hsz       Online status #207002   2015.03.12 10:10 GMT+1 óra  
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Dark_Secrets_of_shader_Dev-Mojo.pdf

ui.: még jó hogy elolvastam, én is rájöttem egy kurvanagy marhaságra az engineben

Ezt a hozzászólást Asylum módosította (2015.03.12 10:32 GMT+1 óra, 833 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #206990   2015.03.11 19:14 GMT+1 óra  
Igazából csak a lentebb említett problémáim vannak. Egyébként nem tudom elképzelni, hogy nagyon lassítana az, hogy éppen a vec3-nak melyik konstruktorát használom, illetve, hogy változóból kap-e értéket. A többit a szerény GLSL tudásomnak megfelelően írtam meg.

   
syam - Törzstag | 1491 hsz       Online status #206989   2015.03.11 18:21 GMT+1 óra  
Mi pontosan az a "mikre"?
alias aalberik
   
Instalok - Tag | 530 hsz       Online status #206988   2015.03.11 18:11 GMT+1 óra  
Van valahol valami tips & tricks gyűjtemény, hogy mikre érdemes ilyenkor figyelni?

   
syam - Törzstag | 1491 hsz       Online status #206987   2015.03.11 17:55 GMT+1 óra  
A shader compiler gyártónként változik vagyis egyik jobban optimalizál, mint a másik vagy egyáltalán nem.
Ha shadert generálsz akkor mindenképp érdemes saját kódoptimalizálót szerezni/írni, hogy ne bízd magad a véletlenre.
alias aalberik
   
Instalok - Tag | 530 hsz       Online status #206986   2015.03.11 17:27 GMT+1 óra  
Nem, generálok node-okból, mint az UE4 Material editorja. Tudom, hogy vannak többféle konstruktorai, csak az a kérdéses, hogy ezek között (illetve aközött, hogy beírod a konstans értéket, vagy változóból olvassa ki) van-e sebességbeli különbség.

   
Asylum - Törzstag | 5440 hsz       Online status #206985   2015.03.11 17:14 GMT+1 óra  
Vektor konstruktor lehet egyelemű is:

Kód:
vec2 a = vec2(0.5);


Automatikus generálás alatt pedig mit értesz konkrétan? Fordítást egy másik nyelvről?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #206983   2015.03.11 16:04 GMT+1 óra  
Van valami performance drawback-je a változók használatának (GLSL version 110)?
Kód:
vec2 a = vec2(0.5, 0.5);

vs
Kód:
float a = 0.5;
vec2 b = vec2(a, a);

Nyilván ép ésszel nem írnék le olyat, mint a második, de most shader auto-generáláson dolgozok, és ha az ilyesmi nem lenne gond, az nagy könnyítés lenne.

Illetve ehhez hasonlóan az alábbi is felmerült:
Kód:
vec2 a = vec2(1.0, 2.0);
vec3 b = vec3(a, 3.0);

vs
Kód:
vec2 a = vec2(1.0, 2.0);
vec3 b = vec3(a.x, a.y, 3.0);

   
Asylum - Törzstag | 5440 hsz       Online status #206933   2015.03.06 18:34 GMT+1 óra  
http://m.cdn.blog.hu/da/darthasylum/tutorials/C++/ch40_deferred.html
http://m.cdn.blog.hu/da/darthasylum/tutorials/C++/ch52_compute.html

A png egy vicces állat, mert úgy tudom külön be lehet állítva neki gamma érték (de feltételezheted, hogy 2.2). Ha srgb textúrába töltöd be, akkor a textúra olvasás automatikusan degammázza (pow(x, 2.2)). A gamma korrekciót viszont én mindig egy külön shaderrel oldom meg (pow(color.rgb, 1.0 / 2.2)). Van srgb framebuffer is de az nekem mindig furán működik... Nézd meg a forward+ kódot.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #206920   2015.03.06 08:58 GMT+1 óra  
Most akkor hogy van ez a gamma korrektálás?

Van egy input png textúrám, ezt dekódolom RGBA-ba, ezt töltöm fel a GPU-ra (GL_RGBA8, GL_RGBA, GL_UNSIGNED_BYTE)

Vannak FBO-k. Nevezetesen (deferred shading) egy GBufferem és Lighting bufferem, a következő textúrákkal:
GBuffer: GL_RGBA8, GL_RGBA8
Lighting: GL_RGBA16F

A geometriát renderelem a gbufferbe, az abban eltárolt adatokat használom fel a lighting buffer előállításához, majd azokat az információkat renderelem a back bufferbe (egyelőre, később az is egy FBO lesz, hogy lehessen ügyesen postprocesselni). A backbufferem gondolom RGBA8.

Most akkor mikor melyik irányba kell mit csinálni? Esetleg SRGB textúra? Próbáltam felfogni, hogy mi hogy van, de ahogy kipróbáltam, úgy elég furcsa eredményt kaptam.

   
Instalok - Tag | 530 hsz       Online status #206593   2015.02.12 06:17 GMT+1 óra  
A 100 szerintem jóval 60 fölött van. De ezek szerint ez természetes jelenség, jól van.

   
Asylum - Törzstag | 5440 hsz       Online status #206588   2015.02.11 21:22 GMT+1 óra  
Mert a játék nem 60 fps felett megy hanem valszeg jóval alatta
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
proof88 - Törzstag | 528 hsz       Online status #206587   2015.02.11 20:13 GMT+1 óra  
valszeg véletlenül pont annyi fps-ed van azokban a játékokban, hogy vsync nélkül sincs feltűnő tearing.
   
Instalok - Tag | 530 hsz       Online status #206585   2015.02.11 18:21 GMT+1 óra  
Most lettem csak arra figyelmes, hogy (csak és kizárólag) fullscreen módban, ha mozgok a kamerával, hullámzik a kép. A vsync nyilván megoldja a problémát, de hogy lehet az, hogy a játékoknál, amivel játszom, nem tapasztalom ezt a jelenséget? Az update-ek 60x hívódnak meg másodpercenként, a rajzolás viszont egyelőre nincs korlátozva.

   
Asylum - Törzstag | 5440 hsz       Online status #206568   2015.02.10 14:25 GMT+1 óra  
Nem, simát is lehet (image-ként).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
syam - Törzstag | 1491 hsz       Online status #206567   2015.02.10 13:56 GMT+1 óra  
Ha jól tudom compute shadernek csak immutable texturet lehet bekötni.
alias aalberik
   
Instalok - Tag | 530 hsz       Online status #206566   2015.02.10 09:16 GMT+1 óra  
Nem jól fogalmaztam. Nyilván nem úgy értettem, hogy 1-nek, hanem, hogy olyan hívásoknak. Viszont a glTexImage2D OGL 2.0 óta van, míg a másik úgy látom, hogy egy új dolog, OGL 4.2.

   
Asylum - Törzstag | 5440 hsz       Online status #206565   2015.02.10 09:03 GMT+1 óra  
Nem azt írja...azt írja, hogy ez az egy hívás megfelel egy glTexImage2D ciklusnak (azaz a storage egy menetben tölti fel az összes mip szintet). DE utána többször már nem módosítható a formátum.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #206562   2015.02.09 15:43 GMT+1 óra  
Annyit olvastam róla, h immutable, de nem tudtam, hogy emiatt gyorsabb is lehet. Köszi!

szerk.:
Mondjuk a doksi szerint a glTexStorage2D GL_TEXTURE_2D paraméterrel való hívása megfelel a
Kód:
glTexImage2D(target, i, internalformat, width, height, 0, format, type, NULL);

hívásnak.
Idézet
The behavior of glTexStorage2D depends on the target parameter. When target is GL_TEXTURE_2D, GL_PROXY_TEXTURE_2D, GL_TEXTURE_RECTANGLE, GL_PROXY_TEXTURE_RECTANGLE or GL_PROXY_TEXTURE_CUBE_MAP, calling glTexStorage2D is equivalent, assuming no errors are generated, to executing the following pseudo-code:

   
Asylum - Törzstag | 5440 hsz       Online status #206552   2015.02.09 14:03 GMT+1 óra  
A storage egy módosíthatatlan textúrát csinál (immutable), ez rajzoláskor optimálisabb, mert a driver nem végez rajta ellenőrzéseket.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #206548   2015.02.09 11:35 GMT+1 óra  
Van valami értelme glTexStorage2D-t használni glTexImage2D helyett? Mikor melyiket?

   
Levente - Tag | 24 hsz       Online status #206407   2015.01.26 21:08 GMT+1 óra  
Sikerült megoldani. x64 es glew volt a lib-be. És ezzel szenvedtem 3 napig.
De végre működik, köszi a segítséget.

   
Levente - Tag | 24 hsz       Online status #206405   2015.01.26 20:31 GMT+1 óra  
szerintem megtalálja, mert ha megcserélem és a freeglut-ot includolom először akkor a glew jelez, hogy a őt kéne először includolni

   
Instalok - Tag | 530 hsz       Online status #206402   2015.01.26 20:25 GMT+1 óra  
Pedig ez a fordítási linkelési hiba arról árulkodik, hogy valami linkelés nem jó. Esetleg rossz libet fordítasz hozzá, vagy meg sem találja?

   
Levente - Tag | 24 hsz       Online status #206399   2015.01.26 19:48 GMT+1 óra  
Igen arról az oldalról csináltam meg, a linkelések is megvannak, de még mindig ugyan az. A glew-l van valami mert a freeglut-ot, os rész futtatom csak az lefut rendesen létre is hozza az ablakot, de ha glew-os rész hozzá csapom akkor nem megy.

   
Instalok - Tag | 530 hsz       Online status #206396   2015.01.26 16:55 GMT+1 óra  
Nem kellene a libet belefordítani? Úgy tudom, hogy attól, hogy van egy dll-ed, attól még egy libbel össze kell fordítani. No persze ez egy kicsi lib ilyenkor, mert alapvetően csak függvénypointerek vannak benne.

Gondolj csak bele, a fordító nem tudhatja, hogy mik vannak a dll-ben, amíg meg nem mondod. Van ilyenkor egy statikus libed, ami megmondja, hogy milyen függvényeid vannak milyen szignatúrával, és ezt oldja fel dinamikusan (dll-ből)

Itt le is van írva, hogy hozzá kell fordítanod.
Idézet
Remember to link your project with glew32.lib, glu32.lib, and opengl32.lib

   
Geri - Törzstag | 2185 hsz       Online status #206393   2015.01.26 16:07 GMT+1 óra  
inkludáld be kézzel

   
Levente - Tag | 24 hsz       Online status #206392   2015.01.26 15:44 GMT+1 óra  
MSVC-t használok.
GLEW_STATIC csak annyit változtat hogy __imp__-et lehadja a hibaüzenetből.

   
Elodin - Tag | 170 hsz       Online status #206387   2015.01.26 11:19 GMT+1 óra  
Nekem is volt vmi. ilyesmi régen, asszem egy #define GLEW_STATIC megoldja a problémát, ha az include-ok elé rakod.

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #206385   2015.01.26 10:16 GMT+1 óra  
Idézet
Asylum :
Ne szórakozz lib-el, a glew egy darab c fájl...

Már amennyiben be akarod fordítani a projectedbe a cuccot. Én pl. nem szeretem az ilyesmit.

Levente, milyen C++ fordítót használsz? MSVC? GCC?
Dare to imagine!
http://www.insaneidea.hu
   
Asylum - Törzstag | 5440 hsz       Online status #206375   2015.01.24 21:52 GMT+1 óra  
Ne szórakozz lib-el, a glew egy darab c fájl...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Levente - Tag | 24 hsz       Online status #206373   2015.01.24 16:05 GMT+1 óra  
Köszönöm a tippeket!

De lenne egy kérdésem a GLEW-t próbálom beállítani, de fordításnál állandóan elakad és ezt írja ki error LNK2019: unresolved external symbol __imp__glewInit@0 referenced in function _main és ennek társait. Beállítottam az include és lib mappát is, a DLL-t is megkapja, de csak nem akar jó lenni. Vagy a kódba lehet a hiba?

   
Asylum - Törzstag | 5440 hsz       Online status #206363   2015.01.23 14:07 GMT+1 óra  
Rövid időn belül ezek is elvaultak lesznek, ha kijön az opengl next. Nem az a lényeg, hogy melyik tutoriálból tanulod meg az opengl-t, hanem hogy melyikből szerzed meg a megfelelő szemléletet. Én pl. sokáig csak directx-el foglalkoztam, aztán egy állásinterjú kapcsán volt 1 hetem megtanulni az opengl-t is.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
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]