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] [31]
sirpalee - Tag | 1282 hsz       Online status #178665   2012.04.16 14:13 GMT+1 óra  
Ha már c++, akkor inkább DX11 esélyesebb a wp-s fejlesztésre, a DX9 tuti bukó.
raytraceisten és übermedic
   
Seeting - Törzstag | 2306 hsz       Online status #178664   2012.04.16 13:48 GMT+1 óra  
Csak egy kérdés a frameworköm jövőjére nézve:

Lehetséges, hogy a Windows Phone 7-re írt játékok megkerüljék a C# + XNA duót, és helyette natív DX9 / C++ kódra épüljenek? Szóval ha most írok egy D3D9Renderer-t, akkor ugye használható lesz a windowsos telefonokon is és nem kell az egészet újraírni C#-ban?

Szerk: Nyílván a renderernek semmi köze az OS specifikus kódhoz.
   
Seeting - Törzstag | 2306 hsz       Online status #178021   2012.04.09 15:55 GMT+1 óra  
Thx!
   
Asylum - Törzstag | 5440 hsz       Online status #178016   2012.04.09 15:25 GMT+1 óra  
A software vp a T&L emulálja szoftveresen, és olyan kártyákhoz van (pl. intel) amik nem tudnak hardveres vp-t (caps.DevCaps & D3DDEVCAPS_HWTRANSFORMANDLIGHT).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #178011   2012.04.09 15:01 GMT+1 óra  
először a hardwaressel próbálkozz, az gyorsabb.

   
versio - Tag | 659 hsz       Online status #178008   2012.04.09 14:41 GMT+1 óra  
hat pedig szoftveresen emulalt shadereket jelent, de utana olvasva lehet hogy a T&L-t , attol fugg hanyas directx-el foglalkozol, en a dx11 -et tanultam csak , regen fostos opengles voltam

Ezt a hozzászólást versio módosította (2012.04.09 15:28 GMT+1 óra, ---)
   
Seeting - Törzstag | 2306 hsz       Online status #178007   2012.04.09 13:56 GMT+1 óra  
Hali!

Tanulgatom a DX-et. Az lenne a kérdésem, hogy a D3D Device létrehozásakor, miért van minden példánál paraméterként a D3DCREATE_SOFTWARE_VERTEXPROCESSING megadva? Illetve, hogy ez mit jelent? (Mert gondolom nem szoftveres renderelést.) Illetve mi a különbség a software ill. hardware vertex processing között?

KöszI!
   
Asylum - Törzstag | 5440 hsz       Online status #174391   2012.02.08 00:16 GMT+1 óra  
Ezeket nem is kéne látnod...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
fpeti - Törzstag | 1280 hsz       Online status #174384   2012.02.07 22:38 GMT+1 óra  
Na erre varrjon valaki gombot:
IDirect3DSurface9
Elég fura, így nehéz ellenőrizni, hogy megfelelő méretű-e a z buffer egy képernyőnél nagyobb rendertargetnek ha 1 és 2 a mérete.
   
Aku-Aku - Tag | 111 hsz       Online status #174046   2012.02.01 20:56 GMT+1 óra  
@barack1: OK, köszi. Sajnos az egnine doksijában nem találta milyen árnyék újrarajzolós utasítást.

   
barack1 - Tag | 94 hsz       Online status #173990   2012.02.01 08:33 GMT+1 óra  
#Aku-Aku

Szia,

A stencil shadowt úgy kell használni, hogy ha az árnyékot vetö tárgy, vagy a fényforrás megmozdúl, akkor újra kell számolni az árnékvonalakat. Vagyis minden frame rajzoláskor, mikor már megvan a fény és a tárgy pozíciója, akkor meg kell hívni egy rutint.

Nálam pl így néz ki:

D3DXVECTOR3 vLightInWorldSpace( g_light0.Pos.x, g_light0.Pos.y, g_light0.Pos.z );
D3DXVECTOR3 vLightInObjectSpace;
D3DXMATRIXA16 matInverse;
D3DXMatrixInverse( &matInverse, NULL, &m_matTeapot );
D3DXVec3TransformNormal( &vLightInObjectSpace, &vLightInWorldSpace, &matInverse );

m_pShadowVolume->reset();
m_pShadowVolume->buildShadowVolume( g_pTeapotMesh, vLightInObjectSpace );
   
Aku-Aku - Tag | 111 hsz       Online status #173981   2012.02.01 00:08 GMT+1 óra  
Köszi, akkor ez kipipálva. Marad az engine és a shadow stencil mint a probléma oka.

   
fpeti - Törzstag | 1280 hsz       Online status #173972   2012.01.31 21:28 GMT+1 óra  
Idézet
Aku-Aku :


Nem dx függő a dolog, a dx-et használó app (itt az engine) dönti el, hogy mit rajzol a stencilbufferbe, azaz hogy hozza létre a fény helyzetétől függő árnyéktestet.
   
Aku-Aku - Tag | 111 hsz       Online status #173970   2012.01.31 20:53 GMT+1 óra  
Sajnos eléggé kezdő vagyok 3D engine-k területén, ezért ha rossz helyen tettem fel ezt a kérdést, akkor nyugodtan át lehet mozgatni a megfelelő topikba.
Egy olyan 3D engine-t használok ami DirectX-szel működik, kizárólag.
Az egyes objektumoknál stencil árnyékokat képeztetek.
Az a probléma, hogy ha egy mozgó dinamikus fényforrást használok, akkor ez egyes entity-k által vetett árnyék mérete nem változik a fényforrástól való távolság függvényében.
Vajon csak én paraméterezem/scriptelem rosszul az engine-t, vagy DirectX - stencil shadow párban ilyen nem lehetséges?

   
Quantum - Tag | 30 hsz       Online status #173563   2012.01.26 09:59 GMT+1 óra  
Nem siklottam, csak a (folyamatosan - ámde lassan - eltűnő ) dilettantizmusomnak köszönhetően félreértettelek.

   
Matzi - Szerkesztő | 2519 hsz       Online status #173561   2012.01.26 09:55 GMT+1 óra  
Ezek szerint az én tippem is jó volt, csak elsiklottál felette.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Quantum - Tag | 30 hsz       Online status #173560   2012.01.26 09:53 GMT+1 óra  
Rossz volt a sorrend. És tényleg! Azért sok mindenre kell itt figyelni. No nem baj, így tanul a paraszt gyerek.
Köszönöm szépen mindannyiótoknak a segítséget!
(Tudtommal DirectX 10 felett már nincs FFP.)

   
barack1 - Tag | 94 hsz       Online status #173518   2012.01.25 19:27 GMT+1 óra  
Hogy hozod létre az inputlayoutot?
Valószínüleg a sorrend a hibás. Általában ( position, normal, tex ) . Nálad viszont a normál és a texture fordítva van.

DX11 -ben én így hozom létre az inputlayoutot :

D3D11_INPUT_ELEMENT_DESC desc[] =
{
{ "POSITION", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, 0, D3D11_INPUT_PER_VERTEX_DATA, 0 },
{ "NORMAL", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, 12, D3D11_INPUT_PER_VERTEX_DATA, 0 },
{ "TEXCOORD", 0, DXGI_FORMAT_R32G32_FLOAT, 0, 24, D3D11_INPUT_PER_VERTEX_DATA, 0 },
}

DX::except( d3dDevice->CreateInputLayout( desc, 3, vertexShaderBytecode->Data, vertexShaderBytecode->Length, &out->layout ) );


Idézet
Quantum :
A vertexstruktúra ennyi:
Kód:
struct VertexType
{
D3DXVECTOR3 position;
D3DXVECTOR2 texture;
D3DXVECTOR3 normal;
};

De, nyilván itt is be kell állítani a vertex declarationt, ahhoz a D3D10_INPUT_ELEMENT_DESC struktúrát kell feltölteni, majd átadni a Direct3D eszköz CreateInputLayout() metódusának.
Egyébként ha jobban érdekel a DX10 - 11, akkor ajánlom a Rastertek weboldalt, vagy pedig a Taking Initiative-ot.

   
Pretender - Törzstag | 2498 hsz       Online status #173516   2012.01.25 19:06 GMT+1 óra  
de shaderrel rajzol azt mondta

   
Asylum - Törzstag | 5440 hsz       Online status #173514   2012.01.25 18:39 GMT+1 óra  
Az a struktúra tuti nem lesz jó ffp-n. Valami ilyesmi a sorrend: pos, color, norm, tex
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #173510   2012.01.25 17:09 GMT+1 óra  
Nem igazán, az OpenGL mostanában jobban tetszik nomeg a legtöbb gépen még mindig dx9 megy csak (konkrétan az összes olyanon, amit én használhatok ) Próbáld meg fixed function kirajzolgatni a normalok meg ilyeneket, ott lehet a gond (vagy a vb létrehozásnál.. dx9-ben egyszerűbb volt )

   
Quantum - Tag | 30 hsz       Online status #173509   2012.01.25 16:54 GMT+1 óra  
A vertexstruktúra ennyi:
Kód:
struct VertexType
{
D3DXVECTOR3 position;
D3DXVECTOR2 texture;
D3DXVECTOR3 normal;
};

De, nyilván itt is be kell állítani a vertex declarationt, ahhoz a D3D10_INPUT_ELEMENT_DESC struktúrát kell feltölteni, majd átadni a Direct3D eszköz CreateInputLayout() metódusának.
Egyébként ha jobban érdekel a DX10 - 11, akkor ajánlom a Rastertek weboldalt, vagy pedig a Taking Initiative-ot.

   
Pretender - Törzstag | 2498 hsz       Online status #173507   2012.01.25 16:34 GMT+1 óra  
Nem tudom amúgy, dx10-et nem ismerem. Mondom, rajzold ki a normalokat vonalakkal.

Betöltővel kapcsolatban:
apróság: m_indexCount = m_vertexCount; elég csak a ciklus után.
a VertexType struktúra hogy néz ki?
dx10-ben vertex declaration-t nem kell beállítani?

   
Quantum - Tag | 30 hsz       Online status #173505   2012.01.25 16:11 GMT+1 óra  
Köszönöm szépen a reakciókat.
barack1 - Az indexbuffert akkor leveszem. Köszönöm az infót.
Matzi - "Sajnos" a fájlban teljesen jól van leírva minden. 3ds Max-ból húzatom ki a modelleket. Csináltam olyat is, hogy fogtam a Cpp-n belül beírt kockát és azt vittem ki egy hirtelen ötletből fakadó fájlformátumba, de abból beolvasva is összekavarodnak a normálok. Itt található az eredeti obj fájl: 2297-objfile.obj.txt
Pretender - Shaderrel renderelek (DX10-ben csinálom, tudtommal itt másképp nem is lehetséges ). A normálok normalizálva vannak (furcsa ez a két szó egymás mellett ). Olyat csináltam amúgy, hogy vertexshader-ben a normálvektorokhoz mérten színeztem, innen látszik az összevisszaság.
Megcsináltam azt, hogy a 147. sorba (ahol feltöltöm az indexbuffert) lekérdezem egy MessageBox-ban a normálok értékeit, de a vertexbuffernek csak az első elemét volt hajlandó kiírni (aztán valami kivételt kaptam és kilépett). Szóval arra gondolok, hogy lehet, hogy a dinamikus tömbbel van a baj.

   
Pretender - Törzstag | 2498 hsz       Online status #173503   2012.01.25 15:26 GMT+1 óra  
Shaderrel renderelsz? Ha nem, akkor lehet olyan gond is, hogy nincsenek normalizálva a normálok. Bár nem hiszem, hogy az ilyen képet eredményezne.
Illetve esetleg amit megtehetsz, hogy kirajzolod a normalokat. VB létrehozás után nem törlöd, hanem vonalakat rajzolsz: kezdőpont position[ i ], végpont position[ i ] + normals[ i ], és akkor látható lesz, hogy hogy állnak a normálok.

Lehet rosszul emlékszek, de amikor én obj betöltőt írtam anno, akkor magamnak ki kellett számolni a normalokat, mert valamiért rosszul tárolta el. Használj inkább x-et, azt se sokkal nehezebb betölteni ám

   
Matzi - Szerkesztő | 2519 hsz       Online status #173501   2012.01.25 14:53 GMT+1 óra  
Quantum:
Nem lehet, hogy a descriptorodban vannak elcsúszva vagy rossz sorrendben a mezők?
Esetleg azt a filet is belinkelhetnéd.
Illetve még talán az lehet, hogy a normáljaidat is eltolod transzformáláskor.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
barack1 - Tag | 94 hsz       Online status #173500   2012.01.25 14:48 GMT+1 óra  
Szia,

Belenéztem a kódodba, és úgy tünik, hogy jó, kivéve, hogy az index buffered 32 bites. Az ATI vagy az NVIDIA kártyák közül az egyik nem támogatja a 32 bites indexbuffert. A 16 bites indexbuffert viszont minden 3D kártya támogatja. Persze valószínüleg nem ez okozza a problémádat, de azért ezt is jó lenne kijavítanod.
   
Quantum - Tag | 30 hsz       Online status #173482   2012.01.25 07:56 GMT+1 óra  
Okés, megnézem, mit tehetek. Addig is itt a forrás kód:
2297-objreader.cpp.txt

   
Asylum - Törzstag | 5440 hsz       Online status #173477   2012.01.24 23:40 GMT+1 óra  
Generáltasd ujra a normálokat.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Quantum - Tag | 30 hsz       Online status #173476   2012.01.24 23:09 GMT+1 óra  
Sziasztok!
Egy érdekes problémával állok szemben. Írtam egy obj olvasót, de valahogy nem akarja az igazságot.
Az algoritmus működése:
Beolvassa egy-egy vektorba a vertexeket, a normálvektorokat és a textúra koordinátákat. Majd utána szépen feltölti a vertexbuffert a 'f' karakterrel kezdődő sorok alapján.
A hiba:
Úgy tűnik, mintha rosszul olvasná be a normálisokat. Ez persze azért furcsa, mert miután breakpoint segítségével megnézem a kész vertexbuffert, elvileg minden klappol (leírtam papírra is). Azért is érdekes a helyzet, mert csináltam egy kocka modellt Cpp-ban (azaz kézzel), ott tök jól működik minden!
A mellékelt képen jól látható, hogy mi a jelenség. Hogy a földi halandók is értelmezni tudják a képet, a lapokat betűkkel láttam el. Az L a fényforrás.
Ha kell, elküldöm a forrásokat is (csak ide nem másolom be, retek hosszú).
Segítségeteket előre is köszönöm.
2297-vsproblem.png

   
Asylum - Törzstag | 5440 hsz       Online status #169261   2011.11.22 18:39 GMT+1 óra  
Idézet
reptile :
A kulon target is jo, de egy fullscreen shadowmaskot ne blurozz - abban nem lesz sok koszonet Ideoda fognak maszatolodni az eles hatarok. (nem csak a penumbra, hanem ahol tenyleg elesnek kene lennie, pld ket object egymast felig takarja a kepen)



Bilateral filter

Teljesen jól müködik.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #169205   2011.11.22 10:43 GMT+1 óra  
a soft shadow a szép, kell az a blur vagy valami más.
de egyelőre más gondok vannak. Majd rákeresek, ha lesz időm, ha jól sejtem valahogy így: 2Cascaded shadow maps flickering", vagy swimming, vagy ilyesmi. Az a helyzet, hogy ahogy mozgatom a kamerát, úgy "villog" az árnyék, mert ugye folyamatosan igazítja hozzá.

   
reptile - Tag | 15 hsz       Online status #169199   2011.11.22 10:12 GMT+1 óra  
A kulon target is jo, de egy fullscreen shadowmaskot ne blurozz - abban nem lesz sok koszonet Ideoda fognak maszatolodni az eles hatarok. (nem csak a penumbra, hanem ahol tenyleg elesnek kene lennie, pld ket object egymast felig takarja a kepen)

   
Pretender - Törzstag | 2498 hsz       Online status #169187   2011.11.22 06:48 GMT+1 óra  
Igen, ez sem rossz, azóta viszont inkább úgy csinálom, hogy előtte egy külön rendertargetbe kiszámolom az árnyékot, úgyis blurozni is kellene majd..

   
reptile - Tag | 15 hsz       Online status #169177   2011.11.21 23:26 GMT+1 óra  
Erdemes lenne atgondolni, mi is van a shaderben, egy directional + shadow meg ps2.0-n is ki kene, hogy jojjon. Ha mindenkepp multipassolni akarsz, megprobalhatod a kovetkezot:

1. rakj le egy ambient pass-t a destinationba, valoszinuleg ugyis kell.
2. szamold csak az arnyekot, es csak a destination alpha-ba ird bele. (colorwriteenable=alpha)
3. a directionalt szamold, es allitsd be ugy a blendinget, hogy srcblend=destalpha, destblend=one

persze ehhez az kell, hogy a destination alpha-t ne hasznald masra. idalis esetben pedig a harom pass-t (vagy az 1-2, 2-3) ossze lehet vonni.

   
Pretender - Törzstag | 2498 hsz       Online status #168997   2011.11.19 15:52 GMT+1 óra  
nem közben akarok váltani
- kirenderelem a shadinget (directional most konkrétan)
- blenddel "rákeverek" egy árnyékot. Az azonos shaderben való árnyékszámolás nem volt jó, "kiakadt", szerinte túl sok const registert használtam Ráadásul blurozni akarom. Persze lehet, hogy nem is így kéne, ahogy én akarom, nem tudom.

szerk.:
közben rájöttem, h miért mondtad.. jogos... Majd kitalálom hogy hogy legyen...

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

   
Asylum - Törzstag | 5440 hsz       Online status #168991   2011.11.19 15:12 GMT+1 óra  
Nem árt tisztában lenni a rendering pipeline-al. Amikor raszterizálsz, akkor már nem tudsz pixel shadert váltani, azt mindenféle rajzolás elött kell megtenni. A poziciot amugy ki lehet irni egy fp targetbe.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #168989   2011.11.19 15:03 GMT+1 óra  
Van 2 pixel shaderem. Az egyikben először kiszámolok benne valamit (konkrétan deferred shadingnél visszaszámolom a world pozíciót), azután pixel shadert váltok, és azt az értéket szeretném használni, amit az előbb kiszámoltam. Minden ugyan az, a kamera nem mozdult, stb.
Van erre lehetőség, vagy a másik ps-ben is újra kell számolnom az adatot? Textúraként visszadobni nem jó.

   
Quantum - Tag | 30 hsz       Online status #168900   2011.11.18 12:01 GMT+1 óra  
Köszönöm szépen, ez valóban működött!
Sejtettem amúgy, hogy valami ZBuffer gondja lesz. Próbáltam valamit állítani, de ha elállítottam, akkor a hiányos ismeretemnek köszönhetően nem indult el az alkalmazás (gondolom az initD3D E_FAIL értékkel tért vissza).
Még egyszer köszönöm a gyors segítséget!

   
Asylum - Törzstag | 5440 hsz       Online status #168898   2011.11.18 11:45 GMT+1 óra  
D3DFMT_D16 helyett haszn'aj D3DFMT_D24S8-at.
Az itteni gepen amugy jol megy.

Amugy az en oldalmon is talalsz up-to-date (es majdnem helyes) d3d kodot.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Quantum - Tag | 30 hsz       Online status #168896   2011.11.18 11:27 GMT+1 óra  
Sajnos ezek sem oldják meg. Beállítottam a példakódban szereplő vágósík méreteket, ugyanaz történt.
Feltöltöttem a forráskódot és egy release verziót. Hátha észrevesztek valamit.
2297-renderproblem.rar

   
Matzi - Szerkesztő | 2519 hsz       Online status #168894   2011.11.18 11:02 GMT+1 óra  
Én még hirtelen a Cullingra tudok gondolni, próbáld meg kikapcsolni, hogy úgy javul e. A másik, ami hasonló hibát tud okozni, ha összekevered a jobb és balkezes koordináta rendszert, bár azt egy fokkal nehezebb elkövetni.

Illetve ha a távoli vágósík nagyon távoli, akkor lehetnek problémák. Szóval próbáld a két vágósíkot közelebb hozni egymáshoz, de úgy, hogy a modell még benne legyen.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Quantum - Tag | 30 hsz       Online status #168890   2011.11.18 10:20 GMT+1 óra  
A törlést is beállítottam.
Kód:
g_D3DDevicePtr->Clear( 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, BACKGROUND_COLOR, 1.0f, 0 );

g_D3DDevicePtr->BeginScene();
...

   
Asylum - Törzstag | 5440 hsz       Online status #168888   2011.11.18 10:11 GMT+1 óra  
Nem torlod le a zbuffert.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Quantum - Tag | 30 hsz       Online status #168887   2011.11.18 10:08 GMT+1 óra  
Ezek "sajnos" be vannak kapcsolva.
De ha esetleg rosszul kódoltam volna, beszúrom ezt a részletet:
Kód:
if( FAILED( g_D3DDevicePtr->SetRenderState( D3DRS_CULLMODE, D3DCULL_CCW ) ) )
{
return E_FAIL;
}

if( FAILED( g_D3DDevicePtr->SetRenderState( D3DRS_NORMALIZENORMALS, TRUE ) ) )
{
return E_FAIL;
}

if( FAILED( g_D3DDevicePtr->SetRenderState( D3DRS_ZENABLE, D3DZB_TRUE ) ) )
{
return E_FAIL;
}

if( FAILED( g_D3DDevicePtr->SetRenderState( D3DRS_ZWRITEENABLE, TRUE ) ) )
{
return E_FAIL;
}

A restoreDeviceObjects() függvényen belül van.

   
Matzi - Szerkesztő | 2519 hsz       Online status #168885   2011.11.18 09:37 GMT+1 óra  
Gyors tipp: Úgy néz ki, mintha nem lenne bekapcsolva a ZWriteEnable vagy a ZEnable, és ezért rajzolná a közelebbire a távolabbit.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Quantum - Tag | 30 hsz       Online status #168884   2011.11.18 09:32 GMT+1 óra  
Sziasztok!
Nekem egy rendereléssel kapcsolatos kérdésem lenne.
A projektem úgy néz ki, hogy van egy X fájlból betöltött mesh-em, természetesen egy kamerám, egy fényforrásom. Az egyelőre kamera szabadon mozog a modell környezetében. Az a nagy bajom, hogy a kamera bizonyos pozícióiban a modell több területen is hibásan jelenik meg. Ilyeneket kell elképzelni, hogy vannak polygonok, amik normálvektorai a kamera felé néznek és bár közelebbi polygonok eltakarják azokat, mégis láthatóak. Vagy, miközben mozog a kamera a modellhez képest, a modell bizonyos területei villogásszerűen eltűnnek, majd újra megjelennek. Egyfajta sávozódást is megfigyeltem. Mellékelek két képet a probléma szemléltetésére:


Nyisztor Károly kódjai alapján építettem fel a programot. Nem tudom, mit barmolok el, nála teljesen jól megy, nálam meg ilyen hibákat csinál. Már napok óta ezzel küzdök.
Zbuffer meg van, 16 bites. Minden renderelés előtti reset-et is beállítottam. Az egyetlen használhatónak tűnő (de csak tűnő próbálkozás, az a vágósík méretének változtatása. Ha előrébb tolom a közelebbi vágósíkot, akkor ez egy kevésbé feltűnő jelenség, de mégis ott van és bármekkorára változtatom a közelebbi vágósíkot, teljesen úgysem tűnnek el a tárgyalt megjelenítési hibák. Továbbá a példakód bármekkora vágósík mellett is tökéletes.
Ha kell forrás, küldök.
Segítségeteket előre is köszönöm.

   
fpeti - Törzstag | 1280 hsz       Online status #168856   2011.11.17 20:19 GMT+1 óra  
Ha full dinamikus (nincs olvasás belőle - ez fontos - dicard,readonly ), akkor egyébként is könnyen megeshet, hogy a driver új memóriaterületet ad lock-oláskor, főleg, ha még a másikat használja. Valaki arra esküszik, hogy 2 buffer kell, egyikbe írunk, a másikat a gpu használja, de szvsz tökmindegy, a vga belső lelkivilága dönt ezekről úgyis.
Én lock-olni szoktam, létrehozás ritkább. Nemrég néztem, 64k vertex lock-reupload (32 byte per vertex) szinte nem vesz el időt a régi konfigomon, szal elég gyors.
   
Asylum - Törzstag | 5440 hsz       Online status #168852   2011.11.17 19:44 GMT+1 óra  
Ha dynamic akkor az AGP memorybe kerül (CPU és GPU között megosztott).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #168839   2011.11.17 17:01 GMT+1 óra  
Hát amikor létrehozod, akkor is kell lockolni Szóval ha mindig létrehoznád, akkor vesztenél sebességet, a felszabadításét és a létrehozásét. Van egy flagje a vb-nek meg az ib-nek, ahol be tudod lőni, hogy dynamic legyen, ilyenkor ha jól tudom valami más elérésű memóriába teszi, ahonnan gyorsabban eléri

   
Frissebbek | Korábbi postok
[1] [2] [3] > 4 < [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [31]