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]
dvorgaz - Törzstag | 575 hsz       Online status #129576   2010.03.23 19:53 GMT+1 óra  
Ha point sprite-okat akarok egyedi pixel shaderrel renderelni (tehát nem FFP-vel), akkor ahhoz milyen vertex shader kell?
Teszem azt be van állítva a PointSpriteEnable meg a Scaling, és PointList primitívet renderelek, a VS-ben akkor csak a középpontot kell transzformálni, vagy kell valami egyebet is (mondjuk a sprite mérete, vagy nemtom)?
   
Asylum - Törzstag | 5440 hsz       Online status #129436   2010.03.21 22:23 GMT+1 óra  
Valaki nem tud egy jó dx9-es god ray implementáciot? Erösen játszadozva a paraméterekkel ugyan sikerült egy ilyet összehoznom de...



A probléma a következö: additiv blending esetén kellene egy háttérszin a radial blurnak, de olyan, hogy egyrészt kontrasztos legyen majd a god rayyel, másrészt amikor hozzáadom az eredeti képhez, ne legyen tul világos. Ez nyilván lehetetlen....

A másik probléma meg az, hogy sm 2.0-ban a textura olvasások száma limitált, tehát nagyon ilyen "réteges". Megbluroztam kicsit de nem segitett sokat.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
fpeti - Törzstag | 1280 hsz       Online status #129435   2010.03.21 22:17 GMT+1 óra  
A térbeli kockával azért jobb, mert a z teszt a falak mögötti fényeket kiejti, így sokkal gyorsabb lehet - nem fut le a ps. Szvsz nálad is az van, hogy az a mesh-gömb nem elég nagy, ezért jó a kocka, azt könnyebben lehet pontosan méretezni, mint egy ikozaédert.. vagy mit.
   
Pretender - Törzstag | 2498 hsz       Online status #129433   2010.03.21 21:59 GMT+1 óra  
Nana', hogy fullscreen quad Valszin kiprobalom majd kockaval, avagy valamifele scissor rect cumot kell erre raereszteni. Bar lehet elobbi jobb lenne

   
fpeti - Törzstag | 1280 hsz       Online status #129432   2010.03.21 21:46 GMT+1 óra  
Én is gömbbel kezdtem, de átálltam a kockára, pont amiatt, hogy néha lecsapott egy kicsit a gömbből a low-poli mesh, akkor meg minek szenvedni vele. Most fullscreen quaddal számolod? Akkor csoda, hogy lassú.
   
Pretender - Törzstag | 2498 hsz       Online status #129428   2010.03.21 21:02 GMT+1 óra  
Igen-igen, az utobbira kozben rajottem Ennek ellenere a bug meg mindig megvan. Atirtam ugy, hogy nem gombot hasznal a point light renderelesehez, hanem a shaderben szamolja, viszont igy lenyegesen lassabb 60+ fps-rol 16-ra leesett (mondjuk a celplatform xbox, dehat valahogy ossze is kell rakni a cuccot..)

   
fpeti - Törzstag | 1280 hsz       Online status #129426   2010.03.21 20:49 GMT+1 óra  
Front face-szel csak akkor rajzolj, ha kifejezetten messze van a gömb, azaz semmiképp nem lehet a kamrea a mesh-ben, amúgy meg backface - igazából csak backface-el is meg lehetne csinálni (frontface-szel lehet egy kis sebességet nyerni bizonyos esetekben, ha azt jobban érinti az Z teszt, s több pixel esik ki.. Killzone2-s deferred paper-jében volt erről szó asszem).
A lighmap meg azért fényesebb magában, mert amikor modulálod a diffúz textúrával semmi más nem történhet vele, minthogy csökken az erőssége, hacsak nem tiszta fehér a diffúz ..
pseudo csak vörös komponensre:

lightmapR = 0.6f;
diffuseR = 1.f;
finalR = lightmapR * diffuseR; // = 0.6f, de általában diffuseR<1
   
Pretender - Törzstag | 2498 hsz       Online status #129410   2010.03.21 15:25 GMT+1 óra  
Ugy is probaltam, de akkor meg ha kivulrol, vagy belulrol lattam akkor 2x olyan eros volt, mint kellene, ha pedig szinten a mettszetnel, akkor pedig az elozonek a fele, tehat akkor volt a normalis erossegu.

   
dvorgaz - Törzstag | 575 hsz       Online status #129409   2010.03.21 15:21 GMT+1 óra  
Idézet
Pretender :
Mar csak egy kerdes:
A point lightot gomb (mesh) kirajzolasaval csinalom. Ha a gombon belul vagyok, akkor forditott 3szog korbejarasi irany, ha kivul, akkor pedig a normalis korbejarasi irannyal rajzolom, azonban van egy olyan eset, amikor egyik se jo: pontosan a gomb egyik haromszogeben vagyok, illetve olyan helyen, hogy a gomb egy reszet belulrol, masik reszet kivulrol latom. Erre tud-e valaki egy okos megoldast?
ilyesmik: http://www.youtube.com/watch?v=CP4Hdsa-bCY



Próbáltad kikapcsolni a Backface cullingot a gömbök rajzolásánál?
   
Pretender - Törzstag | 2498 hsz       Online status #129408   2010.03.21 13:55 GMT+1 óra  
Nekem felmerult Egyelore ugyis muszaj igy futtatnom a gepem miatt, igy kihozza a 60 fps-t (512x512 gbufferrel).
Fako: Hatha megnezed a ketto kozotti kulonbseget, latod, hogy a "jobb felso" az olyan kontrasztosabb, vagy nem is tudom hogy mondjam. Egyelore egy kis cheattel megoldottam, szorzom kettovel a light texturat


szerk.:
Mar csak egy kerdes:
A point lightot gomb (mesh) kirajzolasaval csinalom. Ha a gombon belul vagyok, akkor forditott 3szog korbejarasi irany, ha kivul, akkor pedig a normalis korbejarasi irannyal rajzolom, azonban van egy olyan eset, amikor egyik se jo: pontosan a gomb egyik haromszogeben vagyok, illetve olyan helyen, hogy a gomb egy reszet belulrol, masik reszet kivulrol latom. Erre tud-e valaki egy okos megoldast?
ilyesmik: http://www.youtube.com/watch?v=CP4Hdsa-bCY

Ezt a hozzászólást Pretender módosította (2010.03.21 14:56 GMT+1 óra, ---)

   
Asylum - Törzstag | 5440 hsz       Online status #129407   2010.03.21 13:34 GMT+1 óra  
Fel sem merül hogy más mérete legyen mint a backbuffernek ha párhuzamos renderelést használsz.
A fakó alatt nem tudom mit értesz.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #129402   2010.03.21 09:27 GMT+1 óra  
Meg egy aprosag: A gbuffer meretet hogy erdemes megvalasztani?
- 2 hatvanya meretu negyzet (pl. 512*512)
- kepernyo merete (pl. 1024 * 768 )

bar ez inkabb shaderprog topic, de ha mar van itt hsz-em, akkor idefuzom hozza:
Miert lehet az, hogy a light render target texturajan (fent balrol a 4. negyzet) kontrasztosabb, mint a vegso kepen (nekem olyan fakonak tunik)? A vegso kepnel csak az eredeti color-t es a light-ot szorzom ossze. (a light intensity == 2.0f)
Kód:
float3 diffuse = tex2D(colorSampler, In.TexCoord).rgb;
float3 light   = tex2D(lightSampler, In.TexCoord).rgb;

return float4(diffuse * light, 1.0f);

ja, a kep:


Ezt a hozzászólást Pretender módosította (2010.03.21 11:40 GMT+1 óra, ---)

   
Pretender - Törzstag | 2498 hsz       Online status #129386   2010.03.20 23:05 GMT+1 óra  
color -> fekete, normal -> szurke, depth -> feher
De szerintem teljesen mindegy, lehet ugy is menni fog, hogy nem torlom semmivel (sajnos xna nem tudta megorizni a ClearTexture(..) metodust, igy azt is effekttel + fullscreen quad renderrel kell megoldani...)

szerk.:
Ugy nez ki megy neki clear nelkul is

Ezt a hozzászólást Pretender módosította (2010.03.20 23:30 GMT+1 óra, ---)

   
Asylum - Törzstag | 5440 hsz       Online status #129385   2010.03.20 22:54 GMT+1 óra  
Rózsaszínnel kell törölni különben nem müködik!! Sőt a legrosszabb esetben a világegyetem is teljesen megsemmisülhet!!!

Ugye még véletlenül sem törölted le feketével???
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #129384   2010.03.20 22:52 GMT+1 óra  
deferred shadingnel mennyire lenyeges, hogy a render targeteket megfelelo szinnel toroljuk? Ugyertem a kovetkezo frame-ben ugyis az egesz ujra lesz renderelve, de azert szukseges torolni, valamilyen szinnel?

   
syam - Törzstag | 1491 hsz       Online status #129359   2010.03.20 04:10 GMT+1 óra  
Ősi tapasztalat, hogy nvidián nehéz debugolni vagyis nehezen derülnek ki a hibák. Erre célra az ati kártyák a kitünő tesztalanyok
alias aalberik
   
fpeti - Törzstag | 1280 hsz       Online status #129358   2010.03.20 04:00 GMT+1 óra  
Asylum:
Ez szép munka volt ilyen egy rohadt hibát.
Érdekes is ez amúgy, hogy talán a legfontosabb Direct3D-s fv ez a DrawIndexedPrimitive() - végül is ezzel rajzolunk - és ennek ellenére totál alul dokumentált, alapból senki nem érti melyik param mi is, használom pár éve, de ezt se tudtam
(asszem én mindig az teljes tartományt beállítottam, persze az meg lassít(hat))
   
Asylum - Törzstag | 5440 hsz       Online status #129357   2010.03.20 03:51 GMT+1 óra  
Oké srácok megvan a probléma, ugyh erre most figyeljetek:

Az nvidia karik bolondállóbbak mint az atik. És ez hatalmas nagy BAJ.
A DrawIndexedPrimitive() valahogy igy néz ki:

Kód:
HRESULT DrawIndexedPrimitive(
  [in]  D3DPRIMITIVETYPE Type,
  [in]  INT BaseVertexIndex,
  [in]  UINT MinIndex,
  [in]  UINT NumVertices,
  [in]  UINT StartIndex,
  [in]  UINT PrimitiveCount
);


- A BaseVertexIndex többnyire nem érdekes az maradhat 0.
- A MinIndex már valamivel fontosabb: ez az adott hivásra vonatkozó lehetö legkissebb vertex indexe. Tehát ha az indexbuffer végignyálazása során sosem történik hivatkozás egy X vertex indexnél kisebbre, akkor X legyen a MinIndex.
- NumVertices...ez az amit kurvára félreértettem. Ez nem a hivatkozott vertexek száma, hanem a legnagyobb és legkisebb vertex index különbsége + 1. Vagyis ha mondjuk a rajzolás során összesen csak 5 vertexet használsz, de ezek a vertexbufferben egy 17 hosszu összefüggö területen vannak elszórva, akkor 17 lesz a NumVertices. Az nvidia a rossz értelmezést is elfogadja. Az ati nem.
- StartIndex...ez elég nyilválnvaló, innen kezdödnek azadott rajzolás indexei az indexbufferben.
- PrimitiveCount...trivi
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5440 hsz       Online status #129244   2010.03.17 14:32 GMT+1 óra  
Ami nem feltétlenül jó egy fejlesztőnek...az nvidia driverek még ilyen elképesztö hibákat is eltürnek, hogy rosszul adom meg a vertexek méretét.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Seeting - Törzstag | 2306 hsz       Online status #129243   2010.03.17 13:40 GMT+1 óra  
Nekem meg olyan volt, hogy az OpenGL renderelése ati kártyán beszart szegmens hibával, nvidia kártyán meg hiba nélkül pörgött... Mint később kiderült, nvidiára igényesebb driverek vannak.
   
Asylum - Törzstag | 5440 hsz       Online status #129231   2010.03.16 22:58 GMT+1 óra  
Nem a csiga volt a tesztalany. Egyelöre ugynézki, hogy driver hiba vagy a dx túl régi azon a gépen (ati X300).
Egy kb 200 ezer polis modellröl volt szo.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
fpeti - Törzstag | 1280 hsz       Online status #129226   2010.03.16 22:07 GMT+1 óra  
Nagyon durva lenne ha ekkora különbségek lennének.
Tesztelgetni kéne ha van rá mód, egy kockával plö mit csinál. Esetleg 4 byteos indexeket használsz? Nem túl sok a 3szög a csigában?
   
Asylum - Törzstag | 5440 hsz       Online status #129206   2010.03.16 11:46 GMT+1 óra  
Nem tudja valaki, hogy mégis mi a fene különbség van az ati és az nvidia között dx programozás szempontjából?

Ati kártyákon ilyet csinál a progi, hogy vagy abszolut rosszul rajzolja a mesh-t (mintha félreindexelne), vagy egyáltalán nem rajzol semmit.

Esetleg a vertexbufferben levö elemk sorrendje számit? pl. pozicio, texcoord, normál vagy pozicio, normál, texcoord?
Elvileg a vertexdeclaration adja meg pp-n, nade ffp-n honnan lehet ezt tudni??
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Geri - Törzstag | 2185 hsz       Online status #128526   2010.03.06 19:00 GMT+1 óra  
Azok a cső túlfelén találhatók.

   
Pretten - Tag | 74 hsz       Online status #128525   2010.03.06 18:57 GMT+1 óra  
Na, ez már valami! Hull, domain, meg a többi az hiányzik.
   
Geri - Törzstag | 2185 hsz       Online status #128524   2010.03.06 18:16 GMT+1 óra  

   
Asylum - Törzstag | 5440 hsz       Online status #128179   2010.02.26 17:22 GMT+1 óra  
Mindkettö lassu, én a device->SetXXShaderConstantF()-et használom. Ezzel viszont vigyázni kell mert transzponálva adja át a mátrixokat (asszem).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #128172   2010.02.26 14:09 GMT+1 óra  
ha ahelyett, hogy:
Kód:
effect->SetMatrix("paramname", &matrx);

azt irom, hogy:
Kód:
effect->SetValue("paramname", matrix, sizeof(MATRIX));

az lassabb lesz-e? Illetve ha az lesz, akkor eszrevehetoen-e?

   
Asylum - Törzstag | 5440 hsz       Online status #127996   2010.02.23 13:27 GMT+1 óra  
Ja és akkor a megoldás is (ötlet):

Adjuk át a vertexhsadernek a near és far értékét. Ezek segitségével kiszámolhato egy lináris mélység érték (például éldetektáláshoz). Tudjuk, hogy ez 0 és 1 közötti, tehát ha a normalizált normálvektort felszrozom vele akkor nem is kell az alfa csatorna (bár kicsit többet számoltunk).

Kód:
pos = mul(matWorld, pos);
pos = mul(matViewProj, pos);
   
norm = normalize(mul(matWorld, norm));

normd.a = ((pos.w - near) / (far - near));  // eleme [0, 1]
normd.rgb = (norm * 0.5 + 0.5) * normd.a;
normd.a = 1;


A mélység kinyerése a texturábol pedig triviális:

Kód:
float4 color = tex2D(sampler1, tex0);
float depth = length(color.xyz);


Persze a normált megint normalizálni kell.


szerk.: ötletnek jó, a baj az, hogy a lebegőpontos precízió közbeszól.

Ezt a hozzászólást Asylum módosította (2010.02.23 14:30 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2519 hsz       Online status #127994   2010.02.23 13:03 GMT+1 óra  
Szerintem azért, hogy a közeli dolgoknak nagyobb felbontás jusson, és jobban megkülönböztesse őket. Ha jól tudom ez az exponenciális számítás szándékos.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5440 hsz       Online status #127993   2010.02.23 12:55 GMT+1 óra  
Már régóta töröm ezen a fejem, hogy amikor egy shaderben z mélységet számolok többnyire mindig fehér az eredmény.

Találtam erröl egy cikket is, de ki is számoltam, és tényleg.
A projekcios mátrix vhogy igy néz ki:

Kód:
elsö sor
második sor
0   0   f / (f - n)    1
0   0  -nf / (f - n)   0


Innen ha most kiszámoljuk, hogy mi történik a z koordiánátval:

Kód:
z' = f(z - n) / (f - n)


A perspektiv osztás után pedig:

Kód:
mélység = z' / z   azaz mélység = (fz - fn) / (fz - zn)


Az alábbi teszt eredmények mutatják, hogy ez KIBASZOTT SZAR:

Kód:
f = 200, n = 1


   z  |  mélység
------+-----------
    1 |   0
   50 |   0.98
  100 |   0.99
  200 |   1


Már 50-re majdnem 1!!!! Ez mi a francér van???

A másik nagy probléma, hogy texturába rendereléskor hiába irok az alfába 0.5-öt vagy akármit, mindig 1 lesz benne (ha nincs engedélyezve alpha blend, ha viszont az van akkor meg átlátszanak a modellek....).

Ez tényleg ennyire idióta módon van kitalálva???

Ezt a hozzászólást Asylum módosította (2010.02.23 13:09 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5440 hsz       Online status #127945   2010.02.22 14:01 GMT+1 óra  
Csak annyira mint minden microfos cucc.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2519 hsz       Online status #127943   2010.02.22 13:56 GMT+1 óra  
a DXUT dolgai mennyire lassúak? Felmerült bennem, hogy kellene kicsit optimalizálni, amit csináltam, és például a kamera elég lassúnak tűnik, ha esetleg más is az, akkor kiváltanám.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Matzi - Szerkesztő | 2519 hsz       Online status #127555   2010.02.13 14:00 GMT+1 óra  
Találtam utalást valami "stream out statistics query" nevű dologról, de nem találtam róla leírást. Gondolom nem arról van szó, hogy végignézem a stream elemeit, hogy meddig vannak benne adatok.

Szerk: Megtaláltam.

Ezt a hozzászólást Matzi módosította (2010.02.13 14:40 GMT+1 óra, ---)
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5440 hsz       Online status #127554   2010.02.13 13:06 GMT+1 óra  
Hacsaknem egy "konstanson" keresztül. pl. dx9-ben van ilyen, hogy GetVertexShaderConstantX()
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2519 hsz       Online status #127553   2010.02.13 12:31 GMT+1 óra  
Meg lehet oldani valahogy, hogy a shader visszaadjon egy skalár értéket? Konkrétan a geometry shader által átengedett vertexek számát szeretném megkapni. Az instanceinghoz kell, de ugye hiába áll elő a buffer, ha nem tudom hány elemből áll, nem tudom megmondani hány instanceot kell kirajzolnia.
(C++ Dx10)
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5440 hsz       Online status #127501   2010.02.11 16:34 GMT+1 óra  
Ahaaa...köszi
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
jacktheblackpanther - Tag | 1 hsz       Online status #127491   2010.02.11 09:19 GMT+1 óra  
Idézet
Asylum :
Vááááh.
Teszteld

Ez azt irja hogy kb. 1000 instance-ig gyorsabb (és 1 re uannyi).

http://http.download.nvidia.com/developer/presentations/GDC_2004/Dx9Optimization.pdf

Szerintem viszont poligonszám-függö...pl. a csigára lassabb volt 1000 alatt is.



Picit félreérteted... A batch size azt jelenti, hogy egyetlen objektum hány polyból áll. Az instancing addig baromi gyors, amíg az instancolt mesh befér az chipen lévő vcache-be (itt 500 környékén éri el a maximumot, és diffuse shaded, vagyis 3x4+3x4 - mivel diffuse shaded, tehát pozíció és normál - per vertex adat, plusz index buffer, ami exhas kb 16ks vcache-re utal). Nyílván amíg onnan lehet pullolni az adatokat és nem kapsz egy halom cache miss-t, akkor baromi gyors lesz az egész render. Nem néztem újabb kártyákon teszteket, de nem valószínű hogy 32k-nál nagyobb vcache lenne input assemblerenként a kártyán.

   
Asylum - Törzstag | 5440 hsz       Online status #127487   2010.02.10 23:42 GMT+1 óra  
Vááááh.
Teszteld

Ez azt irja hogy kb. 1000 instance-ig gyorsabb (és 1 re uannyi).

http://http.download.nvidia.com/developer/presentations/GDC_2004/Dx9Optimization.pdf

Szerintem viszont poligonszám-függö...pl. a csigára lassabb volt 1000 alatt is.

Ezt a hozzászólást Asylum módosította (2010.02.10 23:56 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2519 hsz       Online status #127485   2010.02.10 22:51 GMT+1 óra  
Vajon sokkal lassabb, ha egy egyedülálló mesh-t is instanceolva teszek ki (természetesen egyetlen instanceként), mintha simán nem instanceolva tenném?
(DX 10)
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
fpeti - Törzstag | 1280 hsz       Online status #127471   2010.02.09 22:47 GMT+1 óra  
Sajna a DirectInput hanyagolva lett ms által, (állítólag már vista-ban sem működik minden), manapság inkább megint a winapi-s hívásokat javasolják, annál egyszerűbb meg, hogy kezeled a WM_KEYDOWN és WM_KEYUP-ot nem nagyon van, csak egy bool tömb kell neki, nem ciklus.A lenyomott billentyűt meg raktározhatod egy saját bufferben (ha lenyomta és még nem volt lenyomva akkor..), az egeret ugyanígy (WM_LBUTTONDOWN stb). Amúgy szvsz nevetségesen van megcsinálva, pl egy textbox-hoz a WM_CHAR kiváló lenne, de csak a keyboard egy részét 'veszi' (enter-től jobbra semmit.)
   
Pretender - Törzstag | 2498 hsz       Online status #127468   2010.02.09 21:27 GMT+1 óra  
Amik itt le vannak irva, azok nalam is megvannak egy kicsit talan tovabbfejlesztett(?) formaban. Bar az a makro erdekesnek tunik, nekem kulon van KeyIsPress(...), KeyIsPressed(...), MouseButtonPress(..) stb metodus. (Lehet hogy ez az egeszsegesebb, de amaz kicsit talan altalanosabb)

   
HomeGnome - Szerkesztő | 2919 hsz       Online status #127464   2010.02.09 20:40 GMT+1 óra  
DirectInput-hoz több cikk is található az oldalon, a Segédletek / S - Programozás JátékFejlesztés listában:
- (C++) Foxi 2D-s programozás leckéi 4. - Billentyű
- (C++) Foxi 2D-s programozás leckéi 5. - Egér
- (C++) DirectX programozás 8. - DirectInput (by Crusader)
- (C++) Monster3D Tutorial 5. - DirectInput (by Ford Fairlane)
érdemes őket átnézni.

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
Asylum - Törzstag | 5440 hsz       Online status #127460   2010.02.09 18:47 GMT+1 óra  
a ciklust nem fogod megúszni; a háttérben a winapi is legalább egyszer végignyáálazza a billentyüzet buffert. Amiben hazsnosabb a dinput az az, hogy egy adott billentyü állapotát egy lépésben le lehet kérni.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #127456   2010.02.09 16:28 GMT+1 óra  
Ha jo helyen neztem, akkor az WINAPI-s. Elfelejtettem mondani, hogy jo lenne directinput-os megoldas. (vagy nem jo osztalyt neztem?)

   
Asylum - Törzstag | 5440 hsz       Online status #127455   2010.02.09 15:35 GMT+1 óra  
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #127452   2010.02.09 15:20 GMT+1 óra  
Szuksegem lenne 4 funkciora:
Kód:
- bool lenyomtam-e egy gombot?
- DWORD melyik gombot nyomtam le?
- bool lenyomtam-e egy egergombot?
- DWORD melyik egergombot nyomtam le?

Az elsohoz peldaul lehetne ugy, hogy:
Kód:
for (DWORD i = 0; i < 256; i++)
{
    if (KeyIsPressed(i)) //ilyenem van
        return true;
}

de ez nem tunik tul optimalisnak. Ugyan ennyit tudok a tobbihez. Van esetleg valami optimalis megoldas? google-n keresgelve eleg raw megoldasokat talaltam.

   
Asylum - Törzstag | 5440 hsz       Online status #127317   2010.02.05 17:06 GMT+1 óra  
Én is éppen ezen dolgozom (csak dx9 alatt).
A következöt találtam ki (még folyamatban az implementácio): az instance-ok indexeit elhelyezem egy kd-fában de úgy, hogy egy külön tömbben (std::vector) cserélgetem a kd-fa bejárása során az elemeket, majd amikor végeztem a bejárással, akkor a tömb alapján rendezem át a konkrét instance buffert. (ugyanis ha közvetlenül a bufferben cserélgetném akkor az elsö csere után invalid lenne a fa).

Néhány szempont:

- ha egy csucs teljesen kint van akkor ott nem kell tovább vfc tesztelni
- ha teljesen bent van akkor mindet ki kell rajzolni, nem kell több vfc teszt
- ha metszi a frustumot akkor tovább kell menni a vfc tesztekkel
- eldöntendö, hogy levél csucs esetén a benne lévö objektumokat is vfc tesztelje-e vagy csak rajzolja ki

Például kezdetben a következö az elrendezés (a bejárás végéig a buffer nem változik):

Kód:
k = 4

tomb:  1 2 3 4 5
buffer: 1 2 3 4 5


Mondjuk a fa bejárása folyik és kiderül, hogy a 3-as nem látszik, kicserélem a k-adikkal, majd k-t csökkentem, a tömb indexet viszont nem léptetem, hiszen most az 5-öst kell tesztelni.

Kód:
k = 3
tomb: 1 2 5 4 3


Késöbb kiderül, hogy a 4-es sem látszik, azt speciel ki se kell cserélni, de k-t megint csökkenteni kell.

Kód:
k = 2
tomb: 1 2 5 4 3


Véget ért a bejárás, most a tömb alapján átrendezhetö a buffer, majd 0- tol k-ig mehet a rajzolás.
Ez még erösen brain storming szóval lehet hogy finomitani kell; egyelöre a kd-fa van implementálva (az octree tul sok memoriát foglal és lassu). Az enginem topcijábairom majd az implementácio lépéseit amint lesz vmi.

szerk.: dx10 alá nemrég találtam egy pdf-et:

https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/misc/siggraph_asia_08/GPUBasedSceneManagementLargeCrowds.pdf

Ezt a hozzászólást Asylum módosította (2010.02.05 17:19 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2519 hsz       Online status #127291   2010.02.04 22:53 GMT+1 óra  
Olyat hogyan lehet megcsinálni a legkönnyebben, hogy van egy instanceingelt objektum csoportom, és abból pár objektumot nem akarok megjeleníteni, de ugye kivenni sem szeretném a listából. Tudom, hogy meg lehet adni a kezdő indexet és a darabszámot, így a végére/elejére rakottak könnyen kihagyhatóak, de kicsit macerás állandóan rendezgetni, meg ugye eltolja az instance indexeket, amivel lehet "egyediesíteni" az objektumokat.
Szóval lehet ilyen ideiglenes szűrést gyorsan és egyszerűen?

Ja igen, DX10 és C++

Elsősorban frustrum cullingra és részletességi beállításokra kellene (közeli fák modellek, a távoliak csak billboardok).
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
fpeti - Törzstag | 1280 hsz       Online status #127006   2010.01.28 12:39 GMT+1 óra  
dx9:
Szvsz ha magad megszorzod a vektorokat a mártrixokkal cpu-n.
Lehetne mondjuk textúrába is renderelni, de rendertartgetet lekérni meg sokáig tart(hat).
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] > 9 < [10] [15] [20] [25] [30] [31]