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] [27]
sirpalee - Tag | 1282 hsz       Online status #108868   2009.04.14 10:47 GMT+1 óra  
A problémára a megoldás a raycast, az ütközéspontnál adaptív lépéshossz változtatással, és nyilván a bounding primitivet torzítani kell a sebességhez képest.

A többit majd a google megmondja.
raytraceisten és übermedic
   
Swinkx - Törzstag | 106 hsz       Online status #108867   2009.04.14 10:35 GMT+1 óra  
Idézet
xanat :
gondolom mivel a lovedek nagyon gyorsan mozog, nem eleg ra a sima bounding box/sphere vizsgalat, ugyanis, ha tul lassan fut a progi (de lehet enelkul is), akkor at fogja ugorni, a celpontot, es nem eszleli az utkozest. Erre van valami megoldas? valami ilyesmit hallottam, h Ray (mint sugar)... errol nezzek utanna, vagy van valami egyszeru megoldas?


Ez nem attól függ, hogy milyen gyors(lassú) a gép hanem h mekkora vektorral mozgatod el. Ha ennek nagysága túl nagy akkor "ugorhat" át tárgyakat.. 1ik megoldás pl ha lövedék által megtett utat darabokra szeded és többször is végzel ütközésvizsgálat a kisebb vektorokkal.
Amúgy énis ezzel szenvedek Nálam az a gond h lassu a vizsgálat és bizony nagyon meglátszik ez az fpsen. mozgás nélkül400, mozgással 80(ekkor 2 vizsgálat van) lövésnél viszont 20-30ra is leesik. Ezt a problémát a többszáluság megoldaná?

   
xanat - Tag | 489 hsz       Online status #108864   2009.04.14 09:43 GMT+1 óra  
gondolom mivel a lovedek nagyon gyorsan mozog, nem eleg ra a sima bounding box/sphere vizsgalat, ugyanis, ha tul lassan fut a progi (de lehet enelkul is), akkor at fogja ugorni, a celpontot, es nem eszleli az utkozest. Erre van valami megoldas? valami ilyesmit hallottam, h Ray (mint sugar)... errol nezzek utanna, vagy van valami egyszeru megoldas?
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
s1ndler - Tag | 13 hsz       Online status #108768   2009.04.13 02:30 GMT+1 óra  
Sziasztok!

Megszereztem a PureBasic 4.30-at(teljes,64 bites).
De van egy kis gondom. TrueVision3D,Xors3D példafájlokat sem tudok lefordítani, mert
nem találja a pbtv3d.libet és a xors3d.libet. Hogy kell beállítani a PureBasicet? Vagy mit kell csinálni, hogy lássa ezeket a libeket?

Köszi!

   
sirpalee - Tag | 1282 hsz       Online status #108637   2009.04.09 15:38 GMT+1 óra  
Amit régebben emlegettem, hogy ne töltsünk fel constansokat egyesével, itt van egy PCIE teszt a kártyámon (ATI stream lib-el). Szóval mindent egyszerre ha lehet.

Devices found: 2

===> Testing device 0 <===
Device type: RV770
Max resource 2D width/height: 8192/8192
Total GPU memory size: 1024 MB
Total CPU cached space size: 2047 MB
Total CPU uncached space size: 2047 MB
GPU engine clock: 750 MHz
GPU memory clock: 900 MHz
Number of timing loops: 100
[ 16 bytes] CPU->GPU= 381.081 KB/sec, GPU->CPU 563.292 KB/sec
[ 32 bytes] CPU->GPU= 1.085 MB/sec, GPU->CPU 1.081 MB/sec
[ 64 bytes] CPU->GPU= 2.174 MB/sec, GPU->CPU 2.185 MB/sec
[ 128 bytes] CPU->GPU= 3.524 MB/sec, GPU->CPU 4.282 MB/sec
[ 256 bytes] CPU->GPU= 8.346 MB/sec, GPU->CPU 7.767 MB/sec
[ 512 bytes] CPU->GPU= 17.282 MB/sec, GPU->CPU 17.202 MB/sec
[ 1024 bytes] CPU->GPU= 34.404 MB/sec, GPU->CPU 35.055 MB/sec
[ 2048 bytes] CPU->GPU= 60.370 MB/sec, GPU->CPU 65.866 MB/sec
[ 4096 bytes] CPU->GPU= 134.287 MB/sec, GPU->CPU 139.011 MB/sec
[ 8192 bytes] CPU->GPU= 272.594 MB/sec, GPU->CPU 268.016 MB/sec
[ 16384 bytes] CPU->GPU= 548.939 MB/sec, GPU->CPU 571.694 MB/sec
[ 32768 bytes] CPU->GPU= 1.101 GB/sec, GPU->CPU 1.125 GB/sec
[ 65536 bytes] CPU->GPU= 2.053 GB/sec, GPU->CPU 1.675 GB/sec
[ 131072 bytes] CPU->GPU= 2.210 GB/sec, GPU->CPU 2.020 GB/sec
[ 262144 bytes] CPU->GPU= 3.528 GB/sec, GPU->CPU 2.560 GB/sec
[ 524288 bytes] CPU->GPU= 4.316 GB/sec, GPU->CPU 3.258 GB/sec
[ 1048576 bytes] CPU->GPU= 4.734 GB/sec, GPU->CPU 3.579 GB/sec
[ 2097152 bytes] CPU->GPU= 5.003 GB/sec, GPU->CPU 3.875 GB/sec
[ 4194304 bytes] CPU->GPU= 5.067 GB/sec, GPU->CPU 3.955 GB/sec
[ 8388608 bytes] CPU->GPU= 5.165 GB/sec, GPU->CPU 4.086 GB/sec
[ 16777216 bytes] CPU->GPU= 5.189 GB/sec, GPU->CPU 3.886 GB/sec
[ 33554432 bytes] CPU->GPU= 5.161 GB/sec, GPU->CPU 3.887 GB/sec
[ 67108864 bytes] CPU->GPU= 5.279 GB/sec, GPU->CPU 3.891 GB/sec
[ 134217728 bytes] CPU->GPU= 5.336 GB/sec, GPU->CPU 3.879 GB/sec
[ 268435456 bytes] CPU->GPU= 5.390 GB/sec, GPU->CPU 3.884 GB/sec
[ 536870912 bytes] CPU->GPU= 5.235 GB/sec, GPU->CPU 3.904 GB/sec
[1073741824 bytes] CPU->GPU= 2.423 GB/sec, GPU->CPU 2.612 GB/sec
Peak CPU->GPU Bandwidth = 5.390 GB/sec [data size = 268435456 bytes]
Peak GPU->CPU Bandwidth = 4.086 GB/sec [data size = 8388608 bytes]

===> Testing device 1 <===
Device type: RV770
Max resource 2D width/height: 8192/8192
Total GPU memory size: 1024 MB
Total CPU cached space size: 2047 MB
Total CPU uncached space size: 2047 MB
GPU engine clock: 750 MHz
GPU memory clock: 900 MHz
Number of timing loops: 100
[ 16 bytes] CPU->GPU= 311.599 KB/sec, GPU->CPU 538.543 KB/sec
[ 32 bytes] CPU->GPU= 991.135 KB/sec, GPU->CPU 1.092 MB/sec
[ 64 bytes] CPU->GPU= 2.144 MB/sec, GPU->CPU 2.177 MB/sec
[ 128 bytes] CPU->GPU= 3.674 MB/sec, GPU->CPU 3.959 MB/sec
[ 256 bytes] CPU->GPU= 8.559 MB/sec, GPU->CPU 8.576 MB/sec
[ 512 bytes] CPU->GPU= 16.573 MB/sec, GPU->CPU 17.449 MB/sec
[ 1024 bytes] CPU->GPU= 34.169 MB/sec, GPU->CPU 35.274 MB/sec
[ 2048 bytes] CPU->GPU= 67.741 MB/sec, GPU->CPU 70.146 MB/sec
[ 4096 bytes] CPU->GPU= 120.324 MB/sec, GPU->CPU 142.510 MB/sec
[ 8192 bytes] CPU->GPU= 274.649 MB/sec, GPU->CPU 234.617 MB/sec
[ 16384 bytes] CPU->GPU= 556.412 MB/sec, GPU->CPU 559.665 MB/sec
[ 32768 bytes] CPU->GPU= 1.094 GB/sec, GPU->CPU 1.120 GB/sec
[ 65536 bytes] CPU->GPU= 2.025 GB/sec, GPU->CPU 2.140 GB/sec
[ 131072 bytes] CPU->GPU= 2.170 GB/sec, GPU->CPU 2.157 GB/sec
[ 262144 bytes] CPU->GPU= 3.524 GB/sec, GPU->CPU 3.136 GB/sec
[ 524288 bytes] CPU->GPU= 4.354 GB/sec, GPU->CPU 4.034 GB/sec
[ 1048576 bytes] CPU->GPU= 4.756 GB/sec, GPU->CPU 4.451 GB/sec
[ 2097152 bytes] CPU->GPU= 4.954 GB/sec, GPU->CPU 4.854 GB/sec
[ 4194304 bytes] CPU->GPU= 5.009 GB/sec, GPU->CPU 4.975 GB/sec
[ 8388608 bytes] CPU->GPU= 5.077 GB/sec, GPU->CPU 4.963 GB/sec
[ 16777216 bytes] CPU->GPU= 5.107 GB/sec, GPU->CPU 3.808 GB/sec
[ 33554432 bytes] CPU->GPU= 5.064 GB/sec, GPU->CPU 3.761 GB/sec
[ 67108864 bytes] CPU->GPU= 5.130 GB/sec, GPU->CPU 3.772 GB/sec
[ 134217728 bytes] CPU->GPU= 5.138 GB/sec, GPU->CPU 3.744 GB/sec
[ 268435456 bytes] CPU->GPU= 5.121 GB/sec, GPU->CPU 3.734 GB/sec
[ 536870912 bytes] CPU->GPU= 4.716 GB/sec, GPU->CPU 3.804 GB/sec
[1073741824 bytes] CPU->GPU= 2.430 GB/sec, GPU->CPU 2.613 GB/sec
Peak CPU->GPU Bandwidth = 5.138 GB/sec [data size = 134217728 bytes]
Peak GPU->CPU Bandwidth = 4.975 GB/sec [data size = 4194304 bytes]
raytraceisten és übermedic
   
Elf - Törzstag | 932 hsz       Online status #108357   2009.04.04 15:50 GMT+1 óra  
I, Robot
1. A robotnak nem szabad kárt okoznia emberi lényben.
2. A robot engedelmeskedni tartozik az emberi lények utasításainak.
3. A robot tartozik saját védelméről gondoskodni.
   
xanat - Tag | 489 hsz       Online status #108339   2009.04.04 12:46 GMT+1 óra  
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
sirpalee - Tag | 1282 hsz       Online status #108337   2009.04.04 12:26 GMT+1 óra  
1 : Tanulj meg magyarul.

2 : Ilyen nincs.
raytraceisten és übermedic
   
sedix - Tag | 30 hsz       Online status #108317   2009.04.04 08:17 GMT+1 óra  
Na én egy ingyenes engint keresek amit kőnyű fejleszteni meg hát sok mindent is tudjon aki tud ilyen az létszíves dobjon egy linket.
Köszi előre is.

   
xanat - Tag | 489 hsz       Online status #106884   2009.03.17 12:04 GMT+1 óra  
ofkorsz, használom.... látom amúgy te is...
nem akarok már minden hülyeséget itt megkérdezni
creatorson nemtudom, hogy van-e példa, csak fórumban kérdeztem valamit, hogy mitől olyan lassú... végig se gondoltam...
és voilá: http://forums.xna.com/forums/p/27436/150971.aspx#150971

Ezt a hozzászólást xanat módosította (2009.03.17 12:16 GMT+1 óra, ---)
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
sirpalee - Tag | 1282 hsz       Online status #106876   2009.03.17 11:02 GMT+1 óra  
xanat a példát a creatorsról szedted?

remélem azért nem egyesével rajzolod ki őket
raytraceisten és übermedic
   
Kuz - Törzstag | 4455 hsz       Online status #106875   2009.03.17 10:58 GMT+1 óra  
Látom te is használod a creators forumot.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
xanat - Tag | 489 hsz       Online status #106872   2009.03.17 09:17 GMT+1 óra  
yes, sir

aziiigeeeen....
500 vonal, ami halad lefelé 2 10K poly-s modell kíséretében 7FPS
ezen még dolgozni kell

Ezt a hozzászólást xanat módosította (2009.03.17 09:39 GMT+1 óra, ---)
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
sirpalee - Tag | 1282 hsz       Online status #106871   2009.03.17 09:15 GMT+1 óra  
Passz, próbáld ki . Csak akkor az alfa beállítását kell jól csinálni, hogy felfelé csökkenjen az alfája, és akkor szebb eredményt kaphatsz (meg így kevesebb adat a vb).

Szerintem elsőnek csináld meg cpu-n számolva, pár ezer particle-re, aztán jöhet a gpu-s megoldás .
raytraceisten és übermedic
   
xanat - Tag | 489 hsz       Online status #106869   2009.03.17 09:11 GMT+1 óra  
és az milyen megoldás, ha nem kap textúrát? úgy értem, hogy nem is 2db háromszöget csinálnék, hanem vonalakat rajzolnék csak ki. az hülyén néz ki?
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
xanat - Tag | 489 hsz       Online status #106855   2009.03.17 04:32 GMT+1 óra  
hehe. tényleg szép kis olvasmány.... hát itt az ideje kipróbálni, hogy hogy működik. köszi!

Ezt a hozzászólást xanat módosította (2009.03.17 09:11 GMT+1 óra, ---)
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
sirpalee - Tag | 1282 hsz       Online status #106854   2009.03.17 03:56 GMT+1 óra  
Röviden leírva, van egy vertex array-ed ami tartalmazza, az uv-ket, vagy id-ket, hogy egy textúrában hol van letárolva a pozíciója a részecskének, és ehhez kell a vertex textúra, és az sm3.0, ha ki akarod rajzolni (persze lelőve minden sampling a textúrán). Innen a kirajzolás része adott ugye, ha alapban pontokat akarsz kirajzolni. Ha már Esőcseppeket (pl mint sprite-k) akkor 2 triangle minden esőcsepp és minden esöcseppnek tudnia kell a vertex textúrán a pozícióját, plusz egy extra paraméter, hogy az esőcseppben melyik vertex ő, és az alapján kell legenerálni a pozícióját (ez geometry shaderrel nincsen). Ez maga a kirajzolás fázis.

A számítás fázishoz, elég pontoként kezelni az esőcseppeket (mondjuk megcsinálhatod hogy a quados vertex buffer elejére kerül minden 2-es tri párból egy pont, és akkor ezeken mész végig, és akkor nem kell 2 külön vertex buffer). Aztán a scene-d le kell tárolni valahogy, hogy tudd számolni az esőcseppek ütközését. Egy nagyon alap módszer, ami kompozitban működik, hogy screen spacebe számolsz, és a z buffer alapján nézed az ütközéseket (pl fusion tud ilyeneket). Kiszámolod a kezdeti z buffer pozíciót, a végsőt (persze ezeket eltolod a képernyőn), és közte 2-3 interpolációs pontot, és megnézed ütközik-e ott felülettel (akkor ha bizonyos közelségben van az ottani pixel z mélységéhez képest). Ez nem lesz a legszebb megoldás, viszont könnyű leírni a scene-t. Ha már komolyabbat akarsz, akkor kell valami scene felépítés a textúrán, és ott kell megkeresni, hogy pár interpolációs lépésnél ütközik-e.

Aztán 2 lehetőséget meg kell vizsgálni. Ha ütközik, akkor ugye nem esőcseppet kell rajzolni, hanem egy placcsanást, azt meg valahogy jelezni kell abban a textúrában ahol a pozíciókat tárolod (tehát már itt több textúra kell, és figyelni kell hogy max 4 vertex textúrád lehet). Ha meg placcsanás akkor alapban másként kell kinéznie a cuccnak, és máshonnan kell rárakni az alfás textúrát, nem az esőcseppet, hanem a placcsanását (annyi ttudsz nyerni ha ez egy textúrában van, csak más uv pozíciókban).

Röviden, szenvedés, dx9 alatt. Most hirtelen ezt varázsoltam, hogy lehet megoldani dx9 alatt is, geoshaderrel nagyságrendekkel egyszerűbb és szebb megoldás . De közel sem kapsz ilyen sebességet.

Lehet van értelme indexelni, de nem árt utánaszámolni, attól függően hány paramétert használsz, lehet több adatot küldesz át indexelve, mint nyersen az egész buffert.
raytraceisten és übermedic
   
xanat - Tag | 489 hsz       Online status #106853   2009.03.17 03:41 GMT+1 óra  
sm 3.0 nem probléma.
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
sirpalee - Tag | 1282 hsz       Online status #106852   2009.03.17 03:31 GMT+1 óra  
Az ilyen szintű eső, csak dx10 alatt megoldható egyszerűen. XNA alatt már nyűgösebb , sőt mivel ez geometry shaderes, ott ez a módszer sehogy. Ha meg meg akarod csinálni dx9 alatt is, minimum sm3.0 kell hozzá.
raytraceisten és übermedic
   
xanat - Tag | 489 hsz       Online status #106848   2009.03.17 03:11 GMT+1 óra  
hogy lehet a leggyorsabbra csinálni az esőt egy játékban? úgy értem, hogy szép is legyen.
http://www.youtube.com/watch?v=-yxnETZ6RZk&feature=related
ez pl. jól néz ki. de milyen elven működhetne, hogy ne legyen túl lassú?
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
fpeti - Törzstag | 1283 hsz       Online status #105738   2009.03.03 10:31 GMT+1 óra  
Én épp csinálok egyet, semmi bonyolult, textfileból tölti a formcontolok tulajdonságait, egy textúrát használ az egész tilerészekre bontva, így egy drawcall-al megy ki egy form + 1 drawcall karakterkészletenként.
Amúgy MFC-re hajaz, vagy egy formmanager, minden formot ő tart kézben, minden formon vannak kontrol elemek, (eddig gomb,radiogroup, editline féle) amik egy közös osztályból származnak.
Időnként mindenki kap egy draw() és egy work() fv hívást, a draw nem rajzol, csak egy vec3+diffuse+texcoord vertexbufferbe feltöltögeti a kirajzolandó háttér, keret quadjait, a végén az egészet egyszerre rajzolja ki.Minden formnak van saját alfája, valamint a diffuz elemek alfájával minden elem átlátszóságát be lehet állítani.

A work() meg 'meghajtja' a gui elemeket a formon, ha övé a fókusz, és ha generál vmilyen üzenetet, akkor a nevével fémjelezve beteszi egy kis listába.

Még plusz majd lesz egy dll belőle, emiatt a lenyomott bill kódokat (+WM_CHAR) üzeneteket átadom minden work() fv-nek.

Tessék egy kép róla, jelenlegi állapotában (sírtam mikor megláttam, lehet nem örömömben )
http://ilab.hu/jf/datas/users/776-lilgui.jpg
   
Matzi - Szerkesztő | 2519 hsz       Online status #105733   2009.03.03 07:16 GMT+1 óra  
A helyzet az, hogy nem nagy vasziszdasz, az oké, de szeretném jól megcsinálni. Például hogy lehessen scriptelni, és dinamikusan felépíteni, mint ahogy komolyabb játékokban is lehet. ÖTleteim is vannak a megoldásra, csak kíváncsi voltam, hogy valaki más ügyködött e ilyesmivel, hátha értékes tapasztalatokat tud átadni. Ezek szerint nem így van.
Azért köszi.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5441 hsz       Online status #105708   2009.03.02 09:51 GMT+1 óra  
Konkrétan enginefejlesztésröl nincs könyvem, guifejlesztésröl pláne nem, utóbbi azért nem egy olyan nagy wasistdas; pl. beadandónak is kiadták, hogy irjak gui szerkesztöt java-ban (én inkább rajprogramot választottam ).

Viszont van néhány könyvem (pdf-ben) amik áttekintik az enginefejlesztéshez szükséges dolgokat (dx-en keresztül). Csak akkor rakom fel öket ha kellenek is, mert amugy hát hmm tudjátok de psszt

Introduction to 3D game programming with directx 9.0
3D game programming all in one
Game development with directx 9
Game design theory and practice
Game programming tricks of the trade
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
syam - Törzstag | 1491 hsz       Online status #105704   2009.03.02 09:27 GMT+1 óra  
a guira a legjobban használható példa szerintem, a guichan;
használatra, tanulásra és továbbfejlesztésre is nagyon alkalmas és érthető felépítésű (legalábbis számomra)
alias aalberik
   
xanat - Tag | 489 hsz       Online status #105703   2009.03.02 09:23 GMT+1 óra  
ez engem is érdekelne, éppen valami menün dolgozok.
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
Matzi - Szerkesztő | 2519 hsz       Online status #105701   2009.03.02 07:00 GMT+1 óra  
Lenne pár kérdésem.
Szeretnék egy fapados engine kezdemény féleséget csinálni, önmagam szórakoztatására, meg egyetemi beadandó feladatnak. Ennek sarokkövei, hogy nem akarok nagyon külsős megoldásokat használni, hanem sokkal inkább szeretném saját magam megírni, amit lehet. Szintén nem akarok áttérni más technológiára sem, de azért szeretnék igényesen dolgozni.

Először is, szeretnék összedobni egy igényes GUI-t, ami ne adj isten, még akár scriptelhető is lenne. Nem akarom hardcode-olni, de az is felmerült, hogy egy designerrel generálnék kódot, amit belefordítanék a programba. A másik lehetsőég, hogy runtime építem fel az egészed, de ott ilyen referencia dolgokkal problémák vannak, meg nem sok ötletem van, hogy hogyan lehetne (lehetőleg relfection, switch-case, meg hasonlók nélkül) hívogatni függvényeket futásidőben, úgy, hogy scriptből rakom össze a felületet. Foglalkozott már valaki ilyesmivel? Hogy lehet szépen, tisztán és hatékonyan megcsinálni?
Másrészt hogyan oldjam meg az objektumok hivatkozásait? Csináljak egy egyedi ID-t, aztán sorrendezzem a létrehozást refereancia topológia szerint?

Ugyanez van a scriptekkel (nem, nincs LUA, nem akarok), mindenképpen kell valami hackelés? Gondolom kell valamiféle interface jellegű dolgokat írni, de mennyire lesz ez ronda?

Jut eszembe, ha valaki tud valami jó olvasmányt linkelni általában engine fejlesztés témakörben, az jöhet.

Ezt a hozzászólást Matzi módosította (2009.03.02 07:23 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 | 5441 hsz       Online status #105528   2009.02.27 07:01 GMT+1 óra  
hohóó azt már javitottam eleget (mostmár ugy süvit hogy huss). Najo biztos van még mit optimalizálni de szerintem most elég jó. Meg különbenis ráérek (igazábol nem mert csomo beadnadom van).

szerk.: na megis van...pár óra alatt megvolt...mondjuk a material nem lett általános egyelöre.
Diohéjban leirom (nehogy ebevegyétek hogy igy fonetikusan van az enginben is )

Kód:
class Séder
{
protected:
    KonstansTábla tábla;
    ...
};

...

class KonkrétD3DVertexSéder : public Séder
{
private:
    LPDIRECT3DVERTEXSHADER9 shader;
    ...
};

...

class KonkrétD3DPixelSéder : public Séder
{
private:
    LPDIRECT3DPIXELSHADER9 shader;
    ...
};

...

class Anyag
{
protected:
    Séder* vertexséder;
    Séder* pixelséder;

    ...
};


Legyen ennyi adott, a betöltés vhogy igy történik, hogy (ez most a memóriából való betöltés, de a fájlos is hasonlo lesz csak nem kell külön vs meg ps nevet megadni).

Kód:
Menedzser::AnyagCsinál(anyagneve, vsneve, psneve, vsadat, psadat)
{
    anyag = KeresAnyag(anyagneve);
    if( anyag ) return anyag;

    vs = KeresSéder(vsneve);
    if( !vs ) vs = MegkeresMegfelelöAnyagBetöltö->BetöltVertexSéder(vsneve);

    ps = KeresSéder(psneve);
    if( !ps ) ps = MegkeresMegfelelöAnyagBetöltö()->BetöltPixelSéder(psneve);

    anyag = MegkeresMegfelelöAnyagBetöltö()->Összefüz(anyagnév, vs, ps);
    return anyag;
}

Ezt a hozzászólást Asylum módosította (2009.02.27 08:16 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
proof88 - Törzstag | 528 hsz       Online status #105519   2009.02.27 06:36 GMT+1 óra  
Én is ezt akartam írni, de nem akartam megint azzal előjönni, hogy ne ezen fejlessz, mert azért valamilyen szinten én is annak a híve vagyok, hogy minél jobban gazdálkodjunk az erőforrásokkal. De ha már sirpalee elmondta, akkor ezen felbátorodva én is mondom, hogy keress más bottlenecket a motorodban és azt javítsd inkább. Pl a rajzolási sebességeken, amiket engine versenyen szereztél (tudom, hogy szép sebességeket értél el, de legyen még gyorsabb ).
   
Asylum - Törzstag | 5441 hsz       Online status #105466   2009.02.27 04:16 GMT+1 óra  
oké hát akkor proxy (nemtom ez a jo kifejezés-e).
köszi.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
sirpalee - Tag | 1282 hsz       Online status #105461   2009.02.27 03:25 GMT+1 óra  
Asylum túlbonyolítod. Még ha több száz shadert töltesz is be, az is elvan bőven a videókártyán, hogy szinte semmi helyet sem foglal (a byte kód nagyon kicsi). Induláskor töltsd be az összeset, és kilépéskor meg töröld az összeset, aztán pointereket kérdezel le a resource managertől.

Nem éri meg annyit ezzel szórakozni, amennyit nyersz memóriában.

A material meg csak kap egy pointert a vsh-ra psh-ra, stb és belövi őket (statek és így tovább). És ha törli magát akkor nem bözgeti a közös resource-ket.

Asylum
azért mert ha van egy anyag ami már mindkettöt használja, akkormár célszerübb lenne arra visszaadni egy pointert és nem csinálni egy másikat. Meg egyébként is kicsit hackelésnek tünik, ilyen VertexShaderProxy bevezetése (nincs külön vs osztály, az Anyag osztályba vannak rejtve a konkrét vs és ps-ek).


Pedig pont az ilyen példák miatt megéri. Ha túl sokat tud az anyag osztályod, akkor nehéz portolni, vagy áttolni más rendszerre. Pl ha függetleníted az alap dolgokat, egy portolásnál a materialhoz már hozzá se kell nyúlni, mert az már nem az api szintű osztályokhoz tartozik.

Amúgy nálam jóval alapszintűbb resource típusok vannak, mint nadamnál, inkább elvi, logikai felosztása az egyes erőforrásoknak mint a végleges felhasználási. De shadereknél én is hasonló elnevezést használok, amit vagy egy könyvtárszerkezetből (egy pakstream-en keresztül) lehet betölteni, vagy ha megírom akkor egy pakkelt fájlon keresztül streamelni.

vsh - vertex shader
hsh - hull shader
dsh - domain shader
gsh - geometry shader
psh - pixel shader
csh - computer shader
raytraceisten és übermedic
   
nadam - Törzstag | 364 hsz       Online status #105456   2009.02.27 01:53 GMT+1 óra  
Nálam a ReourceManager egymástól független resource típusok gyűjtőhelye. Minden resource típushoz van egy getXXX függvény, hogy név alapján elkérd. (getModel(modelName), getTexture(textureName)) Mindent egy példányban tölt be, berakja egy resource típus specifikus Map-be, és legközelebb már onnan adja vissza.

Ilyen független resource típusok nálam:

- modellek
- hangok (sound bufferek)
- textúrák
- shader fx - ek

Nem látom, hogy miért ne lehetne még két resource típusom, hiszen logikailag totálisan olyan resourceok mint a textúrák:

- vsh - k
- psh - k

Most nem értettem az előző hozzászólásodat. Persze, hogy mindent csak egy példányban kell betölteni, hol itt a gond?

Szerk.:
Ja, lehet, hogy értem, hogy mit mondasz. Hogy magukat az Anyag példányokat, amik Texture-okra, shaderekre, stb.. hivatkoznak (tehát tulajdonképpen csak pointereket tartalmaz) is szeretnéd újrahasznosítani?
Akkor mondjuk egy XML file-ban lehessen definiálni névvel nevezett anyagokat, és a resource managerben kell egy:

getAnyag(anyagNév)

A fentiek mellé, ami belül persze a fentieket hívja meg.

Ezt a hozzászólást nadam módosította (2009.02.27 02:04 GMT+1 óra, ---)
   
Asylum - Törzstag | 5441 hsz       Online status #105453   2009.02.27 01:48 GMT+1 óra  
azért mert ha van egy anyag ami már mindkettöt használja, akkormár célszerübb lenne arra visszaadni egy pointert és nem csinálni egy másikat. Meg egyébként is kicsit hackelésnek tünik, ilyen VertexShaderProxy bevezetése (nincs külön vs osztály, az Anyag osztályba vannak rejtve a konkrét vs és ps-ek).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
nadam - Törzstag | 364 hsz       Online status #105452   2009.02.27 01:35 GMT+1 óra  
Az miért nem jó, hogy vsh-k és a psh-k egyszerűen független resourceok, amiket a hagyományos módon el lehet kérni a resource managertől. (mint ahogy a textúrák meg a modellek is függetlenek...)

resMan.getVsh(vshName)

resMan.getPsh(pshName)

Ez akkor semmiben nem különbözik más közönséges resourceoktól, nem?
   
Asylum - Törzstag | 5441 hsz       Online status #105451   2009.02.27 01:13 GMT+1 óra  
refcountolés természetesen megvan, nem erre próbáltam kilyukadni, hanem arra, hogy ha sima std::map-et használok akkor egy kulcshoz egy érték tartozhat pedig két anyagban is benne van, igy ha az eredetit törlöm akkor nem lesz többé beregisztrálva, hogy a másikban még benne van.

másik: ez a névösszerakás nekem is eszembe jutott, csak megint az van, hogy betöltöm az "alma.vsh", "citrom.psh"-t és a kettö összege naná h nincs bent a hashtáblában.

egyébként ez lehetne programozási feladat is; minél hatékonyabban megoldani a lentebb vázolt problémát, esetleg nem csak kettö hanem n db fájlra.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
dothumour - Tag | 75 hsz       Online status #105449   2009.02.26 22:01 GMT+1 óra  
Idézet
Asylum :
De most legyünk szemetek; kiszurunk szegény resource managerrel, mégpedig ugy, hogy nem egy fx fájlba irjuk az anyagot, hanem külön vsh és psh-ba. Na ennek mondjatok egyrtéelmü azonositot


Kód:
// a "&" csak poénból van benne...
int id = SomeHashAlgorithm(vshName + "&" + pshName);
// II
int id = manager.getIndexOf(vshName + pshName);

Idézet
Asylum :
És akkor most kutyafüle van kéremszépen mert az "alma.vsh" két külön anyagban is benne van, képzeljük el, hogy az eredetit most törlöm...


Kód:
void manager.deleteStuff(int index) {
    Stuff[index].refCount--;
    if (Stuff[index].reCount == 0) {
        reallyDeleteStuff(index);
    }
}
٩(͡๏̯͡๏)۶

   
Asylum - Törzstag | 5441 hsz       Online status #105447   2009.02.26 17:46 GMT+1 óra  
Csak érdekességképpen felteszem a kérdést, mert kicsit elgondolkodtatott.
Van ugye az .fx fájl, ez szép és jó, a fájlnév elvileg egyértelmüen azonositja az adatot (gyakorlatilag k*rvára nem, javaslom az átnevezést). Vagyis a resource manager egy minimális szinten meg tudja elözni a programozó hülyeségét és nem tölti be kétszer ugyanazt a nevü fájlt.

Csodálatos, menjünk kicsit tovább. Memóriából való betöltés. Húzósabb, kéne valami egyértelmü azonosito ennek is, hát nosza kérjünk betöltéskor egy nevet (nyilván a kiterjesztést is megadjuk, hogy logaritmikus idöben megtalálja a szerencsétlen betöltöjét is).

De most legyünk szemetek; kiszurunk szegény resource managerrel, mégpedig ugy, hogy nem egy fx fájlba irjuk az anyagot, hanem külön vsh és psh-ba. Na ennek mondjatok egyrtéelmü azonositot Ugyanis az azonosito egy párt azonosit, igy ha mondjuk legközelebb ugyanezt a vsh-t egy másik psh-val akarom betölteni, akkor értelmeszerüen új azonositót kell megadnom, igy az a vsh kétszer lesz betöltve. Nem túl jó. Egy példán keresztül szemléltetem:

Kód:
Anyag* a1 = menedzser->AnyagCsinál("a1.fx", "alma.vsh", "banan.psh");
Anyag* a2 = menedzser->AnyagCsinál("a2.fx", "alma.vsh", "citrom.psh");

// "alma.vsh" kétszer van betöltve!!!


Oké gondolkodjunk másképp. Csináljuk azt, hogy ne, kérünk külön azonosítót, hanem a regisztrációs map-be berakjuk külön az ("alma.vsh, a1) és ("banan.psh", a1) párt.
Igy amikor be akarjuk tölteni megint az "alma.vsh"-t, akkor látjuk, hogy dehát ez már bent van, szuper megörülünk neki, a "citrom.psh" pedig nincs bent még, nosza klónozzuk az a1-et és állitsuk be neki pixelshadernek a "citrom.psh" -t (nyilván betöltjük). És akkor most kutyafüle van kéremszépen mert az "alma.vsh" két külön anyagban is benne van, képzeljük el, hogy az eredetit most törlöm...

Persze erre van kitalálva az std::multimap...ezzel a jószággal valahogy igy nézne ki a fenti probléma:
Megtaláltuk az "alma.vsh"-t, egyelöre csak egyszer, méghozzá a1-el. Klónozzuk, "citrom.psh" betölt, stb. nevezzük a klónozott anyagot a2-nek, akkor most berakjuk az ("alma.vsh", a2) és ("citrom.psh", a2) párt is a multimapbe.

A probléma látszólag megoldódott, de tegyük fel, hogy van sok ("alma.vsh", ai) és mondjuk egy db ("citrom.psh", b) pár a multimapben (i = 1...n)
Akkor most probáljuk betölteni az "alma.vsh"-t és "citrom.psh" -t.

Kód:
Anyag* a3 = menedzser->AnyagCsinál( "alma.vsh", "citrom.psh");


"alma.vsh"-ra visszakapunk n db ai Anyagot, "citrom.psh" -ra egyet, b-t. Most akkor meg kell néznünk, hogy véletlenül nem egyezik ez a b valamelyik ai-vel és a végén egy (nem annyira de mégiscsak) lassu megoldást kapunk.

Folytatom ha eszembe jut még valami ezzel kapcsolatban, de most alszom.

Ja és a kérdés: van-e erre hatékony megoldás, azon kivül amit én fogok kitalálni nagy kinlodással vagy sok megszoritással.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
kicsy - Szerkesztő | 4304 hsz       Online status #104607   2009.02.14 18:13 GMT+1 óra  
Meg a játékoshoz és mozgásához ezer dolog fog kapcsolódni, amire most még nem gondolsz, kezdve mondjuk az ütközésvizsgálattal.
kicsy ● SilentVertigo Team - project Solarah
http://blog.yscik.com
   
xanat - Tag | 489 hsz       Online status #104496   2009.02.13 14:11 GMT+1 óra  
igen, végülis jogos...
sőt az autós játékoknál is célszerű (bár én nem azt akarok), ugyanis a kamera ugye késleltetve van, ha fordul az autó...
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
fpeti - Törzstag | 1283 hsz       Online status #104494   2009.02.13 13:56 GMT+1 óra  
Én a másodikra szavazok, mert lehet később a kamerát függetlenül is akarod majd a játékostól mozgatni (pl cutscene-nek esetén, vagy a player halálakor mutathatja kívülről fps-nél, stb.)
Szvsz úgy érdemes, hogy a kamerát lehessen hozzákapcsolni mindenféle ojjektekhez (pl autóban ülve is esetleg másképp kell majd)
   
xanat - Tag | 489 hsz       Online status #104491   2009.02.13 13:35 GMT+1 óra  
lövést most hagyom 1 darabig, mostanában mással foglalatoskodok.
Addig itt egy általános kérdés. szerintem nem triviális:
- ha fps/tps, vagy akármilyen olyan játékot írunk, ahol a kamera és a játékos is mozog, akkor hogy érdemes:
- kamerát mozgatom+forgatom, és ahhoz a játékost
vagy
- játékost mozgatom+forgatom, és ahhoz a kamerát?
(bár ez függhet a típustól, jelen esetben fps-ről lenne szó)
ez lehet, h hülye kérdés, meg most mindenki így rám fog hőkölni, de engem érdekel.
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
sheridan - Tag | 55 hsz       Online status #104150   2009.02.07 01:39 GMT+1 óra  
Van térfelosztásod? Mert ha emellett döntöttél, akkor a kellő gyorsasághoz már az is kell...

   
xanat - Tag | 489 hsz       Online status #104149   2009.02.06 23:47 GMT+1 óra  
huh, tehát ha realisztikusra kell akkor túl sok mindenre kell figyelni. Valószínűleg úgy lesz hogy egy kis szakaszt mozgatok elég gyorsan. no persze láthatatlan szakaszt...
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
TPG - Tag | 3402 hsz       Online status #104146   2009.02.06 13:33 GMT+1 óra  
Idézet
fpeti :
Egyébként sokszor elhanyagolják a repülési időt, pedig pisztolyoknál már pár 10 méterre is elég soká ér el (mondjuk 250-300m/sec esetén már 30 méterre is 0.1mp). Mondjuk egy Doom3-s gémnél, ahol a max táv 5 méter, nem gond (nyehe)


Pisztolynál meg géppisztolynál nem nagyon számít, de pl.: mesterlövész puskánál már eléggé ha rendeltetésszerűen használják. Vegyünk egy Dragunov-ot, a torkolati sebesség 830m/s, a maximális hatásos lőtáv 600m körül van, a maximális lőtáv pedig 1300m körül. A 600m-t 0.72sec alatt teszi meg a golyó, az 1300m-t pedig 1.56sec alatt. Ezek azért már felfogható időintervallumok, 1sec alatt simán ki lehet térni a golyó útjából. Másrészt ilyenkor a golyó már elég időt tölt a levegőben ahhoz hogy a pályáját a környezeti hatások lényegesen befolyásolhassák. Nem véletlen figyelik a mesterlövészek a szélirányt is a távolság mellett (sőt még a annak is szerepe van hogy mekkora a hőmérséklet-különbség az adott légrétegek közt amin a golyó áthalad).
Reality is almost always wrong. - House

   
gaborlabor - Moderátor | 4449 hsz       Online status #104145   2009.02.06 13:26 GMT+1 óra  
miva'?
nemtom, úgy értem, hogy nem shotgun, meg nem gépfegyver, hogy lehessen is látni a késleltetést. mondok egy példát: m1 garand.

   
Asylum - Törzstag | 5441 hsz       Online status #104144   2009.02.06 13:23 GMT+1 óra  
úgyérted egycsövessel
a "lövet" szerintem azt jelenti, hogy ujratöltés nélkül hányat tud löni
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #104143   2009.02.06 13:20 GMT+1 óra  
CoD-ban (legalábbis 1-ben meg 2-ben) viszont konstans idő a lövedéknyom megjelenítésének késleltetése.
Ki lehet próbálni, kicsit vicces: oda állsz szembe egy falhoz, amilyen közel csak lehet, és belelősz valami egylövetűvel. Szemmel látható a késleltetés, amit valszeg arra terveztek, hogy ha több száz méterre lősz el, akkor legyen realisztikus. De ezek csak ilyen apróságok szerintem, a játékélményen nem sokat változtat.

   
fpeti - Törzstag | 1283 hsz       Online status #104141   2009.02.06 12:17 GMT+1 óra  
Egyébként sokszor elhanyagolják a repülési időt, pedig pisztolyoknál már pár 10 méterre is elég soká ér el (mondjuk 250-300m/sec esetén már 30 méterre is 0.1mp). Mondjuk egy Doom3-s gémnél, ahol a max táv 5 méter, nem gond (nyehe)
   
syam - Törzstag | 1491 hsz       Online status #104135   2009.02.06 09:56 GMT+1 óra  
akkor nem mozog a "golyó", ha már becsapódott és akkor már semmilyen vizsgálat nem kell
alias aalberik
   
sheridan - Tag | 55 hsz       Online status #104121   2009.02.06 07:37 GMT+1 óra  
Ha nem mozog a golyó, akkor nem kell szakasz. Csak ray-triangle ütközésvizsgálat. És kész.

   
sirpalee - Tag | 1282 hsz       Online status #104117   2009.02.06 07:15 GMT+1 óra  
Szakasszal kell megcsinálni, a pont nem jó (illetve gyorsan "átrepülhet" különböző objektumokon).
raytraceisten és übermedic
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] > 20 < [25] [27]