játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5441
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:    2186
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]
Instalok - Tag | 532 hsz       Online status #204685   2014.09.04 09:51 GMT+1 óra  
Ja értem, akkor túlkomplikáltam. Közben eszembe jutott, hogy egy másik vertexbufferrel nem érek semmit, abba nem tudok csak úgy beleindexelni. Köszi!

   
syam - Törzstag | 1491 hsz       Online status #204684   2014.09.04 09:09 GMT+1 óra  
Szétdarabolják a modellt úgy, hogy egy mesh egyszerre csak 60-64 csontot használjon - skin partitioning-nek hívják.
alias aalberik
   
Instalok - Tag | 532 hsz       Online status #204683   2014.09.04 08:37 GMT+1 óra  
GPU Skinning esetén a shadernek ugyebár át kell adnunk a csont-transzformációkat. Eddig ezt uniform arrayként használtam, amivel kapcsolatban ugye vannak korlátozások. Például, ha kicsit régebbi kártyákkal is kompatibilis szeretnék maradni, akkor legfeljebb 60-64 mátrixot tudok csak egyszerre átküldeni.

A kérdés, hogy mi van akkor, ha több, mint 60 csontom van? Találtam néhány jó kis free modellt, néhányuk 70-80, de volt, amelyik 300 (?! szerintem teljesen indokolatlanul) csontból állt. Vajon hogy használják komolyabb helyeken? Esetleg egy dinamikus vertexbufferbe töltik a bone transformokat, és abból halásszák ki a shaderben?

   
syam - Törzstag | 1491 hsz       Online status #204618   2014.08.25 09:25 GMT+1 óra  
alias aalberik
   
peti634 - Tag | 148 hsz       Online status #204419   2014.08.02 21:55 GMT+1 óra  

OFF:
Gondoltam, akkor inkább már Bind-elgetem a textúrákat, és megpróbálom minimalizálni ezt.
Köszönöm mindenkinek a hozzászólást, és segítséget!!
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Asylum - Törzstag | 5441 hsz       Online status #204402   2014.08.02 15:42 GMT+1 óra  
Szerintem ez már sokkal nagyobb meló, minthogy megérné foglalkozni vele. Szedd szét az atlaszt, így marhára nem éri meg.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
peti634 - Tag | 148 hsz       Online status #204395   2014.08.02 10:26 GMT+1 óra  
Bocs, szerintem rosszul írtam le!
A LOD érték csak a textureLOD függvénynél lenne jó, ami webgl-be csak vertex shadernél használható (mekkora ötlet...), frag. shadernél csak a texture2D függvény 3. paramétere használható, ami nem LOD, hanem BIAS, és ez valami elmosás érték.

Ha 0 akkor nem változik semmi, ha +/-x (x bármennyi lehet) akkor eltolja a mipmap szinteket 1 egységnyivel. Itt arra gondoltam hogy minél nagyobb a depth érték(minél távolabb van az adott pont), annyival tolom a mipmap szintet, így hátha nem veszi az ucsó mipmap szintet, ez viszont hibás, mivel attól függ hogy milyen szögbe nézem az adott felületet.
Ha hegyesszögbe akkor nagy minusz értéknek kell lennie, ha derékszögbe akkor 0 körül, viszont még itt is hozzá kellene számítani a depth értéket is.
Tehát az aktuális LOD levelet kellene kitalálnom hogy mennyivel kellene eltolnom.
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Asylum - Törzstag | 5441 hsz       Online status #204393   2014.08.02 07:20 GMT+1 óra  
[0, 1]-beli depth, mondjuk nemlineáris. Mindenesetre kézzel is ki lehet számolni, akár lineárisan is, ezen már ne akadj fönt Kísérletezz.

http://www.gamedev.net/topic/462133-how-does-the-gpu-choose-mipmap-level/
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
peti634 - Tag | 148 hsz       Online status #204392   2014.08.01 23:24 GMT+1 óra  
gl_FragCoord.z milyen értéket kellene felvennie?
Én kirajzoltam mint szín érték, de mintha folyamatosan 1.0 lett volna, (gondolom a kamerától való távolság lenne).
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Asylum - Törzstag | 5441 hsz       Online status #204383   2014.08.01 21:14 GMT+1 óra  
Kód:
float lod = mix(0, ami_még_jó, gl_FragCoord.z);


de lehet célszerűbb lenne egy 1D textúrát megcímezni hogy ne pixelenként változzon már
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
peti634 - Tag | 148 hsz       Online status #204369   2014.08.01 09:23 GMT+1 óra  
Asylum:
Igen így csinálom, elsőnek feltöltöm 0. level texImage2D-vel, és utána glGenerateMipmap, a textura atlasz képet pedig többféle képen próbáltam. (lent láthatsz is példát), de ugyan az a hiba jön elő. (a távolba már össze mossa az 1x1-es textúra miatt.

WebGL-ben nincs texture2DLod fragment shadernél, viszont (google 1. találat), azt írja, hogy texture2D 3. paramétere használható erre.

Ennek kiszámításában már segítséget szeretnék kérni. Ha + számot adok meg akkor közelebb jelennek meg a mipmap, és így a hiba is. Viszont ha - értéket írok, akkor egyre távolabbra tolja a mipmap leveleket, és így a hiba is csak nagyon távolról jön elő.
A gond az hogy ez egy konstans érték, így egy bizonyos távolságból biztosan elő fog jönni.

Gondolom valahogy folyamatosan csökkenteni kellene a kamerától való távolság függvényében, vagy hogy épp milyen textúra LOD-ot használ, ezt viszont szerintem nem tudom lekérdezni.

szerk:
Szerintem ki kellene számítani a LOD szintet, ezt pedig úgy, hogy milyen szögbe van a vertex a kamerához? Gondolom ide kellene egy normál irány. Ha ez megvan, akkor hozzáveszem még a kamera távolságot is, és ha elér egy bizonyos értéket, akkor folyamatosan csökkenteném a bias-t, így ráerőltetve, hogy ne az 1x1 textúrából vegyen mintát.

Ezt a hozzászólást peti634 módosította (2014.08.01 09:52 GMT+1 óra, ---)
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Asylum - Törzstag | 5441 hsz       Online status #204361   2014.07.31 23:16 GMT+1 óra  
Idézet
peti634 :
texImage2D-nél a levelet egyre nagyobbat adok meg, egyre csökkenő felbontással.



NE!

Első szintet töltsd fel aztán glGenerateMipmap.
Az atlaszt meg úgy csináld meg ahogy írtam.

Ha így se jó akkor használd shaderben a texture2DLod-ot.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
peti634 - Tag | 148 hsz       Online status #204334   2014.07.31 09:41 GMT+1 óra  
már nincs meg, de valami ilyesmi volt:
for (var i = 128, j = 1; i>=1; i/2 , j++){
var c = document.createElement("CANVAS";
c.width = i;
c.height = i;
var cont = c.getContext("2d";
cont.drawImage(this,0,0,i,i);
gl.texImage2D(gl.TEXTURE_2D, j, gl.RGBA, gl.RGBA,gl.UNSIGNED_BYTE, c);
}
Az eredeti kép pedig 256 volt.

Most azzal próbálkozok, hogy a 3-4 textúrába töltők fel különböző egyre kisebb képet, és a távolságtól függően fog dönteni melyik méretet kell használni, úgymond saját mipmap.
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Instalok - Tag | 532 hsz       Online status #204333   2014.07.31 09:10 GMT+1 óra  
Esetleg a mipmap feltöltés kódrészletet be tudnád másolni? Bár nem hiszem, hogy hiba lesz benne, lehetséges, hogy csak ennyit enged meg a specifikáció.

   
peti634 - Tag | 148 hsz       Online status #204329   2014.07.31 08:44 GMT+1 óra  
Próbáltam, de ilyenkor úgy veszi hogy nem adtam meg, tehát fekete lesz az a mipmap, amit nem adtam meg. Ha az 1x1-es hiányzik, akkor az elég távoli részek lesznek feketék.
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Instalok - Tag | 532 hsz       Online status #204328   2014.07.31 08:05 GMT+1 óra  
Azt is megteheted akár, hogy egy bizonyos felbontásnál kisebbeket nem adsz meg. Azaz például az utolsó néhány mipmap mérete ugyan akkora lesz - már ha ilyet enged az OpenGL

   
peti634 - Tag | 148 hsz       Online status #204327   2014.07.31 07:34 GMT+1 óra  
texImage2D-nél a levelet egyre nagyobbat adok meg, egyre csökkenő felbontással.
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Matzi - Szerkesztő | 2519 hsz       Online status #204325   2014.07.31 00:09 GMT+1 óra  
Hogyan állítod elő a mipmap szinteket? Könnyen megeshet, hogy elég lenne csak ott lekorlátozni az előállított szinteket (akkor is, ha ezt esetleg kézzel kell csinálni).
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
peti634 - Tag | 148 hsz       Online status #204324   2014.07.30 22:29 GMT+1 óra  
Igen, én is ezt vettem le
A kérdés az hogy milyen megoldás lehetséges akkor?
Megoldható e valahogy a textúra atlasz, vagy minden egyes textúrát bindelnem kellesz?
(esetleg Cube map?)
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Instalok - Tag | 532 hsz       Online status #204323   2014.07.30 21:55 GMT+1 óra  
Rákerestem gyorsan google-ben, első blikkre azt írták itt-ott, hogy OpenGL ES ilyet nem tud, és ha jól tudom a WebGL az tulajdonképpen OpenGL ES. Majd a guruk megmondják.

   
peti634 - Tag | 148 hsz       Online status #204322   2014.07.30 21:34 GMT+1 óra  
Sajnos nagyon úgy tűnik hogy ilyen lehetőség nincs, enélkül megoldható?
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Instalok - Tag | 532 hsz       Online status #204318   2014.07.30 18:35 GMT+1 óra  
Nem tudom, hogy WebGL-ben van-e, de
Kód:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0-base value);

Ezzel korlátozd le a mipmapek számát a textúrának megfelelően, ha szükséges.

   
peti634 - Tag | 148 hsz       Online status #204317   2014.07.30 18:19 GMT+1 óra  
Mivel WebGL-be dolgozok, így kérném még annyiba segítségeteket hogy:
http://www.khronos.org/files/webgl/webgl-reference-card-1_0.pdf

Nem látok semmi hasonló beállítást, lehet marad 1 kép 1 textúrába elv?
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Matzi - Szerkesztő | 2519 hsz       Online status #204314   2014.07.30 17:48 GMT+1 óra  
Sajnos a paddingnak is megvan a maga korlátja. Konkrétan ha eléri a legalsó mipmat szintet, akkor egyetlen pixel lesz a textúra, a benne található információ átlagával, és akkor azt fogja kitenni. Limitálni kell a maximális mipmap szinteket annyira, hogy még ne mossa össze őket.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
peti634 - Tag | 148 hsz       Online status #204313   2014.07.30 17:45 GMT+1 óra  
igen igen, közbe rájöttem, a texImage2D-nél levelt növelve, egyre kisebb képeket kell neki beadni, gondolom így kellene

De mi van akkor hogy ha egy 128x512-es textúrát akarok mipmapolni?
Az utolsó 1x4-es kép után mit adok be? 1x2, és 1x1 a levelet növelve?
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
syam - Törzstag | 1491 hsz       Online status #204312   2014.07.30 17:36 GMT+1 óra  
Szerintem a mipmapelés mossa össze. Textura atlas - paddolni kell még mindig
alias aalberik
   
peti634 - Tag | 148 hsz       Online status #204311   2014.07.30 17:08 GMT+1 óra  
Valamit elrontanék?
A következő textúrát használom:


A kordinátáim a következőek:
x: 0.125 - 0.375
y: 0.25 - 0.75

Sok kis vertexet rajzolok ki, ezekre mind ezt a koordinátát használom, viszont a következő képet kapom:

A távolban a másik textúra színe látszódik már.

A MIN filterem Mipmap-ot használ, de bármilyen beállítás van, akkor is előjön ez a jelenség. Ha Nearest, vagy Linear akkor már persze jó, viszont nagyon csúnya így. Hogy tudom ezt kijavítani?

Mint látható egy Voxel típusú engine készülget, úgy hogy jó lenne ha sok textúrát tudnék használni egy kirajzolással.
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Asylum - Törzstag | 5441 hsz       Online status #204257   2014.07.26 18:03 GMT+1 óra  
textúra atlaszoknál az a szabály, hogy a résztextúrák 2 hatványak legyenek és csak a saját méretük többszörösénél kezdődhetnek. Pl. egy 32x32-es textúra kezdődhet 0, 32, 64, stb.-nél.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
peti634 - Tag | 148 hsz       Online status #204255   2014.07.26 17:47 GMT+1 óra  
A "jól" alatt gondolom azt érted hogy közvetlenül egymás mellet legyenek a textúrák.

Nagyobb textúráknál is gond lehet az hogy ha egy világosabb mellett egy sötétebb textúra van, vagy linear-nál csak a közvetlen (1 pixel) szomszédokat mossa össze?
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Instalok - Tag | 532 hsz       Online status #204254   2014.07.26 16:33 GMT+1 óra  
Ha jól packeled az atlaszt, akkor teljesen jó. Gondolj csak bele, mindegy, hogy 16*32x32, vagy 128x128, a méret ugyan annyi. Cserébe kevesebb a textúraváltás, ami viszont jó.

Mipmapeket gondolom használsz, ha linear filteringről volt szó. Elég kicsi textúráknál elő szokott fordulni. Esetleg megpróbálhatod egy fél pixelnyit odébbtolni a textúra-koordinátákat.

   
peti634 - Tag | 148 hsz       Online status #204253   2014.07.26 16:23 GMT+1 óra  
értem, erre gondoltam.
A felbontás csak példa, nagyobb képeket használok.
Továbbra is gondolkodok azon hogy használjak inkább Cube textúrákat?
8*6 mégis csak 48 textúra, a sima 8 helyett.
A textúra atlasz nem túl memória pazarló?
Sebességben mennyire rossz Cube-ot használni?
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
syam - Törzstag | 1491 hsz       Online status #204243   2014.07.25 23:06 GMT+1 óra  
peti634:
textúra atlasz
ha viszont ilyen kicsi felbontású textúra kell érdemes meggondolni, hogy per-vertex nem lehet-e megoldani a kérdésed
alias aalberik
   
peti634 - Tag | 148 hsz       Online status #204241   2014.07.25 20:46 GMT+1 óra  
esetleg GL_LUMINANCE?
Szerintem ha olyat használsz ami csak komponenst tárolsz (R v G v B v A), és GL_BYTE a típusa, akkor ettől kevesebbet nem fogsz tudni használni, minden képpontnak legalább Byte méretűnek kell lennie, ha jól gondolom.

Nekem is lenne egy kérdésem:
Egy textúra részeit hogy tudom külön külön használni?
Ezalatt azt értem hogy mondjuk egy 16x16-os képet feltöltök, és a vertexre csak 8x8-at húzok rá, vagyis 0-0.5 értéket használok. Ezzel viszont az a gondom hogy ha LINEAR-re van állítva, akkor a szélén lévő pixeleknél beleveszi a másik kép képpontjait is. (ha ez a 8x8 rész fehér, a többi pedig fekete, elég feltűnő
Hogy lehet, vagy ti hogy oldjátok ezt meg?
Mivel általában 8 textúrát lehet feltölteni maximum egy renderelésre, de ha nekem többre van szükségem akkor mi a teendő? Esetleg használjak Cube textúrákat (8*6 kép)?

Mennyire lenne jó megoldás ha a 2 kép között hagynék 1 pixel rést, viszont távolról már több pixel is átlagolni fog, nem csak a közvetlen közelébe lévő pixeleket, nem?
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Instalok - Tag | 532 hsz       Online status #204234   2014.07.24 18:38 GMT+1 óra  
Ha egy fekete-fehér képet akarok textúrába renderelni (igazából a kiszámolt árnyékokról lenne szó, ezt akarom postproces lépésben a jelenethez hozzáadni), akkor milyen formátumot érdemes választani? Az RGBA8 elég pazarlónak tűnik, mivel fekete-fehér, és ráadásul csak 2 különböző érték lenne a textúrában. Láttam R8-at meg R3_G3_B2-t is, csak nem tudom, hogy ezek milyen szinten vannak támogatva.

Itt például azt írták, hogy a GL_R8 elég új dolog még.

   
Geri - Törzstag | 2186 hsz       Online status #203943   2014.06.30 18:48 GMT+1 óra  
mintha a d3d11-et, vagy a gl4et használná egyáltalán valaki

   
syam - Törzstag | 1491 hsz       Online status #203942   2014.06.30 18:33 GMT+1 óra  
Igen, végre értelmes újdonságok kerülnek bele. A D3D12 párjának szánják.

Egyelőre csak tippelik milyen extensionök kerülnek be a coreba.
alias aalberik
   
Elodin - Tag | 172 hsz       Online status #203941   2014.06.30 18:07 GMT+1 óra  
Hol?

   
Geri - Törzstag | 2186 hsz       Online status #203940   2014.06.30 17:46 GMT+1 óra  
micsoda hiánypótló ._.'

   
syam - Törzstag | 1491 hsz       Online status #203939   2014.06.30 16:36 GMT+1 óra  
Jön az OpenGL 5 !
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #203042   2014.05.24 07:24 GMT+1 óra  
Ennek az emberkének a tapasztalatai azt mondják, hogy az általában nvidia kártyán gyorsabb (wtf?). Bár, ezzel csökkenne a CPU-oldali terheltség (nem kell ténylegesen áttranszformálni a vertexeket, csak kiszámolni a pozíciókat), illetve nem kellene dinamikus VBO sem.

Bár a paper alapján nem teljesen értem, hogy mennyivel jobb, mint uniformként átadni, mert per instance kellene rajzolni, amivel nem tudom mennyire vagyok előrébb...

Harmadik megoldásként esetleg: statikus VBO, a vertexdata állna továbbá egy ID-ból is, és a mátrixokat / pozíciókat uniform array-ként passzolnám át a shadernek. Az az adott vertexnél megindexeli a tömböt az ID alapján. Persze ennek vannak korlátai, például, hogy egy teljes arrayt kell átpaszírozni a GPU-nak, illetve ez a mennyiség limitált (ha jól rémlik nagyjából 60 mátrix mehet át egyszerre).

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

   
syam - Törzstag | 1491 hsz       Online status #203041   2014.05.24 01:24 GMT+1 óra  
Persze. Pseudo-instancing.
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #203040   2014.05.23 22:53 GMT+1 óra  
Köszi! Ja-ja, nem egy nagy munka. Statikus tömb (vertexek), dinamikus vbo, és vertexek pozíciójának tologatásánál van jobb módszer is?

   
syam - Törzstag | 1491 hsz       Online status #203039   2014.05.23 21:17 GMT+1 óra  
Csakis batch.
A point mérete maximalizálva van és pixelben van megadva.

A vertex shader használatának egyik mintapéldája billboardot rajzolni
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #203037   2014.05.23 17:53 GMT+1 óra  
Point sprite-ot hogy érdemes megoldani? GL_POINTS-al rajzolni, és a "beépített" point-sprite-ot használni, vagy kézzel batchelni a kis négyzeteket?

szerk.:
Ahogy így olvasgattam kicsit, néhányan panaszkodtak rá, hogy itt-ott máshogy működik. Hát, nem tudom, igazából nem egy túl nagy meló megcsinálni a batchelést.

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

   
glezmen - Törzstag | 381 hsz       Online status #203023   2014.05.22 15:51 GMT+1 óra  
Idézet
Pretender :
A cikk fele arról szólt, hogy azért kell más megoldást használni (lowlevel szint, direktben a kártyát csesztetni, API nélkül), mert nem működik rendesen az Ogl4 + Intel páros.


igy van, de ez nem az OpenGL hibaja (vagyis nem "nem tud Intelen mukodni" hanem az Intele, mert nem kepes egy normalis OpenGL drivert csinalni a vackaihoz
gondolom ebbol mar egyenesen kovetkezett, hogy ha nem kepes o maga OpenGL drivert irni a kartyaihoz, akkor legalabb alacsony szintu hozzaferest biztositson, hogy a (nem DX-es) fejlesztok tudjanak kezdeni valamit a hardware-rel
   
Geri - Törzstag | 2186 hsz       Online status #203021   2014.05.22 13:26 GMT+1 óra  
szerintem úgyis a szoftveres renderelés a jövő, ahhoz meg nem kell api

   
Pretender - Törzstag | 2498 hsz       Online status #203020   2014.05.22 12:58 GMT+1 óra  
A cikk fele arról szólt, hogy azért kell más megoldást használni (lowlevel szint, direktben a kártyát csesztetni, API nélkül), mert nem működik rendesen az Ogl4 + Intel páros. Na és akkor mi legyen a megoldás? Hát hagyjuk ki az Ogl-t. Oké, nyilván ez csak egy része az egésznek, de simán benne van (legalábbis nekem). Értem én, hogy nem (feltétlen) ez a fő mondanivaló, de akkor is az OpenGL tűnik "hibásnak", mert azt akarják kihagyni, és helyette valami mást használni. Aminek persze lennének egyéb előnyei (sebesség?) is valószínűleg, de akkor is.

szerk.:
Idézet
Ha kiindulunk abból, hogy az Epic tapasztalt programozóinak nagyjából másfél évre van szükségük ahhoz, hogy tényleg gyorsra és stabilra összerakják a modern OpenGL-t a legújabb Intel hardverekhez, akkor felmerül a kérdés, hogy gyorsabb lenne-e hagyni az OpenGL-t, és szimplán direkten leprogramozni az IGP-kre egy-egy leképzőt.

Persze az is más dolog, hogy ezt a játékfejlesztő cégek tehetnék meg, az Intel drivereket viszont nem tudják átírni. A fene vigye el az Intelt!

   
glezmen - Törzstag | 381 hsz       Online status #203019   2014.05.22 10:59 GMT+1 óra  
Idézet
Pretender :
Azért érdekes, hogy a cikk szavaiból az jön le, hogy az OpenGL egy hulladék, mert "nem megy" Intel kártyákon... értem én, hogy sok Intel van, de ha a többi driverrel működik, akkor nem lehet, hogy fordítva kellene a problémát megközelíteni, és az Inteleseket csesztetni, h tanuljanak meg programozni és szabványt betartani?



nem tudom ezt hogy sikerult leszurni belole, szerintem nagyon masrol szol a cikk
ha mar mindenaron opengl-intel vonalra akarod szukiteni, akkor inkabb annyi a mondanivalo, hogy az intel szarik az opengl-re, ezert a fejlesztok szopnak
   
Pretender - Törzstag | 2498 hsz       Online status #203018   2014.05.22 10:37 GMT+1 óra  
Azért érdekes, hogy a cikk szavaiból az jön le, hogy az OpenGL egy hulladék, mert "nem megy" Intel kártyákon... értem én, hogy sok Intel van, de ha a többi driverrel működik, akkor nem lehet, hogy fordítva kellene a problémát megközelíteni, és az Inteleseket csesztetni, h tanuljanak meg programozni és szabványt betartani?

   
glezmen - Törzstag | 381 hsz       Online status #203017   2014.05.22 09:44 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]