játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5455
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2521

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2189
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] [16]
Pretender - Törzstag | 2498 hsz       Online status #193978   2013.05.14 11:02 GMT+1 óra  
De, de akkor 3 geometry pass kell, hogy ezt elérd. Az nem elég, hogy egyszer depth + normal + specular, aztán lighting aztán még1 "forward" pass textúrákkal, mert akkor a 2. passban (lighting) nem tudod, hogy milyen shadinget alkalmazz / objektum.

   
Asylum - Törzstag | 5455 hsz       Online status #193977   2013.05.14 10:45 GMT+1 óra  
El se olvastad a cikkemet mi?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #193976   2013.05.14 10:04 GMT+1 óra  
Na meg ha már itt jártam ebben a topicban...

Gondolkoztam ezen a deferred shading / lighting dolgon. Ha teljesen különböző shadingeket akarunk deferred lightinggal (pl. normal mapping, SSS, ilyen-olyan amolyan shading), akkor valahogy a lighting számolás lépésben meg kell mondanunk, hogy melyik pixelre milyen shader fusson le.

Tehát kicsit visszakanyarodtam a deferred shadinghez, és valami ilyesmin gondolkoztam:
Kód:
Pass 1: G-buffer
- render depth
- render normals.rgb, render specular power in alpha
- render diffuse texture.rgb (render specular multiplier in alpha, or)
(- render specular with color)

- set stencil value based on shading type (diffuse without normal mapping, normal mapping, SSS shading, etc.)

Pass 2: Lighting
- for each shading type
    - set stencil test equals to the pre-defined value (based on shading type)
    - apply the current shader
    - shade pixels based on G-buffer
   
Pass 3: Combine
- combine G-buffer's diffuse color and Lighting texture
(- apply gamma correction)

Az eleje a szokásos G-buffer, azzal a különbséggel, hogy ismerjük, hogy az adott objektumot milyen shaderrel akarjuk majd rendereltetni, tehát azon alapulva kiírunk egy stencil értéket.

A lighting passban beállítjuk a megfelelő shadert, a stencil tesztet az adott értékre állítjuk, ami így megadja azokat a pixeleket, amikre az adott shadernek le kell futnia, majd számolunk egyet.

A vége innentől szintén ugyan az.

Gondolkoztam még azon, hogy a stencil helyett alpha testet kellene valahogy használni, mert a point light stencil test optmializálás sokat dob a dolgon.

   
Asylum - Törzstag | 5455 hsz       Online status #193975   2013.05.14 09:57 GMT+1 óra  
Szerintem k*rvara nem kerdeses
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #193974   2013.05.14 09:53 GMT+1 óra  
Van itt egy arc, aki leimplementálta, van benne kipróbálható exe is. Nem nagyon néztem még meg, csak kipróbáltam, de terveztem egyszer megcsinálni. Sokat dob(hat) a látványon, csak kérdéses, hogy megéri-e.

   
Asylum - Törzstag | 5455 hsz       Online status #193973   2013.05.14 09:50 GMT+1 óra  
Ha megcsinalod irhatnal rola vmit.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #193971   2013.05.14 07:38 GMT+1 óra  
Köszi. Ez a light propogation volume bejövős.

   
Asylum - Törzstag | 5455 hsz       Online status #193964   2013.05.13 19:06 GMT+1 óra  
- radiosity
- light propagation volume
- SSDO
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #193959   2013.05.13 18:18 GMT+1 óra  
GI-t amúgy csak raytracinggel lehet csinálni, vagy van valami kevésbé szép, de használható módszer? Illetve ez a specular dolog elég szépen nézett ki. Ez is csak raytracing?

   
syam - Törzstag | 1491 hsz       Online status #193956   2013.05.13 17:24 GMT+1 óra  
Témába (?) vágó kéz:
alias aalberik
   
Matzi - Szerkesztő | 2521 hsz       Online status #193955   2013.05.13 17:10 GMT+1 óra  
A hierarchiával lehet spórolni, de az oldalak iránya nem sokat jelent. Sőt, a normálok miatt akkor még valamiféle átlagolást is kéne ejteni, szóval ront a helyzeten ha lapos oldalú kockákként képezed le őket. A hierarchikusan felépített fában viszont gyorsabb a keresés, mert egész térrészeket dobhatsz el. Persze ez nem jelenti azt, hogy feltétlenül gyorsabb a poligonális objektumokra vett sugárkövetésnél, mert ugye függ a méretezéstől. Pl poligonok száma, objektumok száma, térfelosztás, vagy éppen a voxelhierarchia felépítése. Meg pl amíg poligonális modellekre jól kitalált animációs módszerek vannak, addig voxelesre még csak alig.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
bolyzsolt - Törzstag | 607 hsz       Online status #193954   2013.05.13 16:54 GMT+1 óra  
Egy voxel-alapú 3D térben vajon nem gyorsabb a raytracing/raycasting, mint egyébként? Tehát ha az objektumok a térben kizárólag a három tengelyre merőleges lapokból állnak, vagy esetleg pont ugyanakkora kockákból (pl. Minecraft) van felépítve a jelenet, akkor vannak olyan optimalizációk, amik ilyen esetben tudnak hatni a sebességre?

   
__z - Tag | 69 hsz       Online status #193867   2013.05.06 13:53 GMT+1 óra  
Szerintem jónak tűnik.
(Ugyebár a XOR azonos bitek esetén 0-ra, eltérőeknél 1-re áll be, tehát az egyenlőségvizsgálat előtti rész tulajdonképpen a subnet biteken való eltérés "értékét" adja vissza. )

Ezt a hozzászólást __z módosította (2013.05.06 14:05 GMT+1 óra, ---)

   
zeller - Törzstag | 470 hsz       Online status #193866   2013.05.06 13:21 GMT+1 óra  
ja leves. Transzoformalva a mondatot.
Az alabbi keplet jo-e arra,m hogy eldontsuk 2 IP azonos subneten van-e.

   
DMG - Szerkesztő | 3172 hsz       Online status #193865   2013.05.06 13:16 GMT+1 óra  
Baszki hétfő vam fáradt vagyok. Levesere???
-----------------------------------------
Dont Listen to the Naysayers
   
zeller - Törzstag | 470 hsz       Online status #193864   2013.05.06 13:02 GMT+1 óra  
e.
2 IP azonos subneten levesere ugye jo ez az ellenorzes?
Kód:
((ipA ^ ipB) & subnetMask) == 0

   
ddbwo - Tag | 1625 hsz       Online status #193312   2013.04.10 17:24 GMT+1 óra  
Idézet
Asylum :
Mennyire common az, hogy a klasszikus megvilágitási egyenlettöl eltérve nem az árnyékos részt szorzod be egy kisebb 1 értékkel, hanem ahol nincs árnyék ott beszorzod a képet egy nagyobb 1 értékkel?



Szeretek kísérletezgetni, meg nem is olvastam először utána, úgyhogy mindkét megközelítést próbáltam tunningolni. Ez miatt meg nem is igazán tudom pontosan mi a common. Én használom.

Ezen a két képen biztosra a második van, meg utána még kettőn. Aztán néhányon fordítva. Meg összevissza.


http://jatekfejlesztes.hu/kep.php?id=abba39804

http://jatekfejlesztes.hu/kep.php?id=7710de501

Kimérten mindkettő ugyanúgy néz ki, csak kicsit máshogy kell őket belőni. Teljesítményben lehet eltérés megoldástól függően. A legutóbbi videóra a második kicsit gyorsabbnak tűnt.

Gondolom attól is függ, hogy hogyan van kialakítva, meg alkalmazva...
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Asylum - Törzstag | 5455 hsz       Online status #193304   2013.04.10 08:56 GMT+1 óra  
Idézet
Matzi :
HDR nélkül nem nagyon van értelme, azzal együtt használva akár működhet is a dolog. Persze ahhoz biztos rendesen be kell lőni az értékeket újra. Egész más intervallumokat kell hozzá beállítani.

Hol láttál te ilyet?



Az osszes ceges program igy csinalja es olyan artifactos mint a seggem (es ram adjak h javitsam ki ) Azert kerdem mert nem akarom ugy elkuldeni oket a picsaba hogy utana se jartam. Ja HDR-rol assetudjak mi (meg gamma korrekcio sincs).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
versio - Tag | 664 hsz       Online status #193303   2013.04.10 06:57 GMT+1 óra  
en nem ajanlom , pont most szivtam vele 3 napig , az onarnyek artifactos lesz, nalam a problema az Oren Nayar diffusenal jott elo, mert tovabb shadeli az objectet , nem vag le 90 foknal

   
Matzi - Szerkesztő | 2521 hsz       Online status #193301   2013.04.09 23:41 GMT+1 óra  
HDR nélkül nem nagyon van értelme, azzal együtt használva akár működhet is a dolog. Persze ahhoz biztos rendesen be kell lőni az értékeket újra. Egész más intervallumokat kell hozzá beállítani.

Hol láttál te ilyet?
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5455 hsz       Online status #193300   2013.04.09 22:15 GMT+1 óra  
Mennyire common az, hogy a klasszikus megvilágitási egyenlettöl eltérve nem az árnyékos részt szorzod be egy kisebb 1 értékkel, hanem ahol nincs árnyék ott beszorzod a képet egy nagyobb 1 értékkel?

Az én véleményem az, hogy ez egy kibaszottnagy baromság, viszont jól fakeli az indirect lightot (pl. egy szobában vagy). Van ennek valami mélyebb magyarázata, vagy szimplán perverzió/hozzá nem értés?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5455 hsz       Online status #191757   2013.03.02 21:43 GMT+1 óra  
A lexer-parser is egy menet. És pont azért használják, mert sokkal egyszerübb vele megcsinálni.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #191746   2013.03.02 17:03 GMT+1 óra  
Ügyes real-time syntax tree építéssel szerintem jó karakterenként is olvasni. Szerintem azért csinálhatták úgy, mert akkor a darabolás bonyolultabb, viszont eltárolni / ellenőrizni egyszerűbb. Zárójelek, utólagos kiértékelések, akármik. Legalábbis én így "hirtelen" nem találok hibát a karakterenkénti olvasásban, ha tényleg nem lassabb (bár én anno az x parsernél azt vettem észre, h karakterenként kiolvasni lassabb, mint bizonyos szeparátor karakterenként - ami itt mondjuk csak egyszerűen a whitespace volt).

   
bolyzsolt - Törzstag | 607 hsz       Online status #191744   2013.03.02 16:50 GMT+1 óra  
Saját kis programnyelvemhez írok fordítót. Körbenéztem a neten, és azt láttam, hogy kivétel nélkül mindenki a lexing->parsing metódust használja ilyenkor. Én viszont kísérleteztem egy egymenetes fordítóval, ami tulajdonképpen karakterenként megy végig a forráskódon, és így állít össze belőle syntax tree-t. Elvileg minden szintaktikai hibalehetőséget le tudok kezelni vele, és nem tűnik lassúnak sem.

Itt jön be a kérdésem: miért ragaszkodik mindenki a fent említett lexeres módszerhez? A lexer ugye elég bonyolult regular expressionok segítségével bontja darabokra a forráskódot, aztán ezen még át kell menni a parserrel, hogy a kód ellenőrizve legyen és syntax tree-vé alakuljon. A regex-ek tudtommal nem a gyorsaságukról híresek, legalábbis ha egy "kurzor" segítségével karakterenként végigmegyek egy szövegen és így darabolgatom, elméletileg nincs olyan regex ami ezen a módszeren sebességben túltesz. Illetve általában jó pár regexnek végig kell mennie a forráson, ami azt jelenti, hogy többször is végigfutnak elég bonyolult ellenőrzések

Ráadásul ezeket a regexeket meg is kéne írni valakinek (nekem), amit jobb szeretnék kihagyni, ha lehet Szóval, mi a brutális hülyeség az én módszeremben, ami miatt mindenki más lexerrel szenved?

   
ddbwo - Tag | 1625 hsz       Online status #188684   2012.11.08 21:04 GMT+1 óra  
Idézet
VultureHunter :
A baricentrikus koordinátákra gondoltam, de ott háromszögre alkalmazzák, működhet itt is szerintetek?



Matematikailag egy négyzet két háromszögre is bontható.
A lineáris interpolációval az a gond, hogy négy vertexből gyakran nem jön ki a plane egy síkra, így megtörik a tényleges felület, a számolt meg kicsit máshol lesz mint a vizuális. Persze ez nem mindenhol feltűnő.

---
u.i:
Ja már hogy a "nem koplanáris" azt jelenti... Jóvan.

Ezt a hozzászólást ddbwo módosította (2012.11.08 21:10 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
VultureHunter - Tag | 27 hsz       Online status #188676   2012.11.08 08:54 GMT+1 óra  
Köszönöm a linket, jelezni fogom, ha sikerült megoldanom a feladatot.

   
M4 - Tag | 187 hsz       Online status #188674   2012.11.08 08:17 GMT+1 óra  
Igen, gondolom. Bár már régen tanultam erről.
Amúgy ha a vertexek négyzetrácson vannak, esetleg jó lehet a bilineáris interpoláció:
http://en.wikipedia.org/wiki/Bilinear_interpolation

   
VultureHunter - Tag | 27 hsz       Online status #188672   2012.11.08 07:06 GMT+1 óra  
Sziasztok!

A következő kérdésem lenne: egy terep vertexei közül kiválasztom az avatar talppontjához legközelebb eső legkisebb indexű vertexet, majd ezek index szerinti közvetlen (legközelebbi) szomszédjait - az így kapott 4 vertex meghatároz egy területet (nem feltétlenül koplanáris...), hogy tudom meghatározni a magasság értékek alapján súlyozva, egy a területen belüli pont magasságát? A baricentrikus koordinátákra gondoltam, de ott háromszögre alkalmazzák, működhet itt is szerintetek?

   
Pretender - Törzstag | 2498 hsz       Online status #188530   2012.11.02 11:08 GMT+1 óra  
Összefűzés az a konkatenálás, azaz concat / concatenate (ahogy Eldor mondta).
Az append az inkább a hozzáfűzés / hozzáadás.

   
Eldor - Tag | 163 hsz       Online status #188527   2012.11.02 07:41 GMT+1 óra  
Szerintem inkabb concatenation, vagy concat.

   
Sorenke - Tag | 72 hsz       Online status #188522   2012.11.02 00:23 GMT+1 óra  
megtaláltam amit keresni akartam de nem tom a nevét még mindig XD

   
Joga - Törzstag | 1791 hsz       Online status #188521   2012.11.02 00:08 GMT+1 óra  
kérdem, hogy neked megfelel-e, mert szerintem így hívják
(ಠ ›ಠ) Stewie!

   
Sorenke - Tag | 72 hsz       Online status #188504   2012.11.01 20:16 GMT+1 óra  
Idézet
Joga :
append?


Most kérded vagy mondod?

   
Joga - Törzstag | 1791 hsz       Online status #188489   2012.11.01 18:14 GMT+1 óra  
append?
(ಠ ›ಠ) Stewie!

   
Sorenke - Tag | 72 hsz       Online status #188484   2012.11.01 16:11 GMT+1 óra  
Ennek mi a neve?

int alma = 111;

LoadPicture("Az_elleresi/utvonal_" + alma);

konkrétan a zárójelben lévő ősszéfűzésnek a neve érdekelne angolul !!!!!

   
Pretender - Törzstag | 2498 hsz       Online status #185630   2012.08.05 08:35 GMT+1 óra  
Ha valaki esetleg egy ilyennel foglalkozna rajtam és HG-n kívül, annak mondom, hogy a ReadHeadernél ne felejtse el az elején ezt:
Kód:
memset(HeaderData->FileName, 0, sizeof(HeaderData->FileName));


Más:
Működik a becsomagolás, kicsomagolás, nézőke valamelyik filera, minden csudijó, azonban most kicsit elgondolkoztam.
Ha mondjuk a packemben van egy alma nevű file, aminek a mérete mondjuk 100 byte. Mi történik, ha egy szintén alma nevű filet akarok bemásolni oda? A totalcmd okosan megkérdezi, hogy felülírom-e, ha nem, akkor skippeli, tehát csak a felülírással kell foglalkozni.

Na már most 3 lehetőség van:
- az új alma mérete is 100, ekkor csak az adott részre kell ugrani a packben, és szimplán a "helyére" írni az újat.
- az új alma mérete < 100, ekkor még szintén megtehetjük, hogy a helyére írjuk, de marad egy kis "fölösleg", amit valahogy el kell tüntetni.
- az új alma mérete > 100, ami ugye azt jelenti, hogy ha odaírnánk, akkor "belelógna" a következő adatba, így kell egy kis plusz helyet csinálni neki.

Azaz ha az új file mérete != régi file mérete, valamit ügyeskedni kell. Az nekem elég durva megoldásnak tűnik, hogy fogom az utána lévő részeket, és memcpyvel átmásolom kicsit odébb. Főleg, hogy - ha jól tudom - azért van egy kis korlátja a memcpynek, azaz egy 2gb-s pack esetén nem lesz túl vicces dolog ilyet csinálni.

Tehát ami a legjobb lenne, hogy ha lenne egy olyan eljárás, ami a file egy adott részét törli. De úgy, hogy az utána lévő részek a "helyére" kerüljenek. Ekkor simán a file végébe írnám az új adatot.

   
Pretender - Törzstag | 2498 hsz       Online status #185528   2012.08.02 09:28 GMT+1 óra  
Nafene, pedig megnéztem vagy 10x köszi hát, próbálgatom, majd jelentkezek, ha nem megy

szerk.:
Most volt egy 10-20 percem, nézegettem, marha jól ki van találva ez a TotalCmd. Adtak egy interfacet, amit meg kell valósítani, érthetően leírták a wikis oldalon, hogy mi mit csinál, és nekünk mit kell csinálni.

Röviden:
Amikor meg akarjuk nyitni majd a packfilet, lefut az OpenArchive: Itt semmi mást nem kell tennünk, csak vissza kell dobni egy handlert a fileról (pl. CreateFile). Ezután egy loopban lefut a ReadHeader: itt a mi kis headerjeinket olvassuk be, ahol legalább a fájlnevet, létrehozási dátumot, méretet meg kell határozunk (ez tök jó, ezek úgy is el voltak tárolva). Ha nincs több file, akkor E_END_ARCHIVE. A legvégén CloseArchive, ahol meg természetesen lezárjuk a handlert.

A tömörítés rész sem bonyolult, igazából csak a megfelelő függvényekbe be kell helyettesítenünk a mi kis kódolásunkat / dekódolásunkat. Remélem ismét lesz egy kis időm foglalkozni vele hamarosan, majd jelentkezek

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

   
bolyzsolt - Törzstag | 607 hsz       Online status #185526   2012.08.02 08:08 GMT+1 óra  
Idézet
Pretender :
Lehet, h hülye vagyok, de pl. azt se találtam meg, hogy hol van a totalcmdnek valami libje, hogy le tudjam fordítani a saját kis pluginemet


http://www.ghisler.ch/wiki/index.php/Developer's_corner
Az M4 által linkelt lap alján volt eldugva ez a link

   
Pretender - Törzstag | 2498 hsz       Online status #185523   2012.08.02 07:32 GMT+1 óra  
@zeller: Például mert a *.tar-t meg tudja nyitni bármelyik kispista is, aki nem ért hozzá.
@HG: ha rájönnék, hogy hogy kell, mindenképpen szólnék
@M4: ezeket már én is nézegettem, egybe leírást viszont nem nagyon találtam

szerk.:
Lehet, h hülye vagyok, de pl. azt se találtam meg, hogy hol van a totalcmdnek valami libje, hogy le tudjam fordítani a saját kis pluginemet

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

   
M4 - Tag | 187 hsz       Online status #185502   2012.08.01 15:10 GMT+1 óra  
HomeGnome - Szerkesztő | 2919 hsz       Online status #185495   2012.08.01 13:46 GMT+1 óra  
@Pretender: Egy ilyen plugin engem is érdekelne. Sőt, az lenne a legjobb, ha megadom a formátumomat és megcsinálnád nekem is...

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
zeller - Törzstag | 470 hsz       Online status #185494   2012.08.01 13:37 GMT+1 óra  
Milyen sajat pack filet? Miert eri meg a befektetest ezt csinalni siman a tar hasznalata helyett?

   
Pretender - Törzstag | 2498 hsz       Online status #185487   2012.08.01 10:06 GMT+1 óra  
Esetleg foglalkozott már valaki totalcmd plugin írásával? Csináltam egy saját pack fájlt, egyelőre egy adott folder összes fileját tudom csak egyszerre becsomagolni. Ez később folyamatos content hozzáadása esetén nem túl kényelmes, így gondoltam valami Total Commander alá épülő pluginra, amivel úgy tudnék pakolni / kivenni a saját fileomból, mintha csak egy zip lenne.

   
zeller - Törzstag | 470 hsz       Online status #185317   2012.07.29 15:05 GMT+1 óra  
Zarojelben jegyzem meg hogy az entity system is oop. A hasznalt patternek a teljesseg igenye nelkul:
composite, strategy, decorator, visitor, chain of responsibility, flyweight. Nem feltetlenul mind egyszerre.
Az oop != heterogen kollekciok epitgetesevel.

   
clarDrum - Tag | 11 hsz       Online status #185222   2012.07.28 11:29 GMT+1 óra  
Értem, akkor lesz min gondolkodni. Köszönöm a segítséget!

   
gaborlabor - Moderátor | 4449 hsz       Online status #185194   2012.07.27 17:51 GMT+1 óra  
Idézet
clarDrum :
Erről tud valaki bővebben valamit és hogy megérné-e ezen az úton haladni??


Komponens rendszert akkor éri meg építeni, ha nagyon sok, nagyon változatos tulajdonságú entitás szerepelhet a játékban. Ebből ugye alap esetben (OOP) az következne, hogy az osztályhierarchia jó nagy, jó sok osztállyal és kapcsolattal. Ez mondjuk még felépíthető, de komoly gondok léphetnek fel, ha valamikor a fejlesztés során pl kitalál a designer egy új entitást (vagy módosít egy meglévőt) ami sehogy sem illeszkedik a hierarchiába. Komponens rendszer esetén hozzáadsz/elveszel 1-2 új komponenst és kész. Viszont az elején több munka van vele, szóval meg kell gondolni, hogy megéri-e.

   
clarDrum - Tag | 11 hsz       Online status #185186   2012.07.27 16:23 GMT+1 óra  
Köszönöm a válaszokat, illetve a megerősítést ebben.
Egyébként most olvasgattam ebben a témában és találtam egy olyat, hogy Component-Based Entity System. Ha jól vettem ki, a lényege az, hogy egy-egy objektum kívül álló komponensekből épül fel és magában az objektumban csak valamilyen azonosító, illetve az őt alkotó komponensek listája vagy (map-je) található. Az összes többi tulajdonsága, metódusa az osztályon kívül helyezkedik el.
Erről tud valaki bővebben valamit és hogy megérné-e ezen az úton haladni??

Köszönöm még egyszer!

   
DMG - Szerkesztő | 3172 hsz       Online status #185171   2012.07.27 10:46 GMT+1 óra  
Szerintem is jó.

Én is hasonlót használok.
-----------------------------------------
Dont Listen to the Naysayers
   
Pretender - Törzstag | 2498 hsz       Online status #185170   2012.07.27 10:15 GMT+1 óra  
Ez teljesen jó szerintem, nálam is hasonlóan van Van egy Node3D osztályom, abból származnak a különböző típusú objektumokhoz az osztályok.

   
clarDrum - Tag | 11 hsz       Online status #185169   2012.07.27 09:26 GMT+1 óra  
Sziasztok!
Egy 2D-s programot csinálok tanulmányi célzattal c++-ban, opengl és sfml segítségével. A programban elsősorban szeretnék egy olyan rendszert megvalósítani, amely alkalmas sok fajta objektumot kezelni, és amelyet később azután átültethetnék más projektekbe. A játék-objektumok (NPC-k, powerup-ok, fegyverek, lövedékek...) kisebb-nagyobb mértékben különböznek tulajdonságaikban, de hatással vannak egymásra (pl.: ütközésnél máshogy reagálnak). A problémám az adat-struktúra felépítésével kapcsolatos. Talán a legkézenfekvőbb módszer osztály-hierarchia kiépítése lenne, viszont bizonytalan vagyok abban, hogy megérné-e rengeteg osztályt írni az összes különböző játék-objektum típusra és viselkedésre. A kérdésem az lenne, hogy milyen módszerek léteznek entity-system-ek írására, kialakításásra?
Az én szerény ötletem az, hogy lenne egy nagy játék objektum kezelő rendszer (osztály), amely képes hozzáadni és törölni objektumokat a listájához, valamint frissíteni (és kirajzolni?) azokat.

Kód:
//cEntitySystem osztályban:
std::list<cBaseGameObject*> m_GameObjects;

//Valahol a programban:
m_pEntitySystem->AddUnit(Position, unitType);

m_pEntitySystem->UpdateAllUnits(double stepTime);

m_pEntitySystem->RenderAllUnits();


Legyen mondjuk egy alap (cBaseGameObject) ősosztály, amiből származtatom az összes többi gyerekosztályt a rengeteg típusra? Azt később viszont nehéz lenne módosítani.

Pl.:
[code]
class cBaseGameObject
{
//...
};

class cLightEnemy : public cBaseGameObject
{
//...
};

class cHealthPowerUp : public cBaseGameObject
{
//...
};

//és még rengeteg osztály
[\code]

Valaki foglalkozott már ezzel vagy ehhez hasonló témával?
Elnézést, ha bonyolult és hosszú, remélem jó helyre írtam.
Köszönöm a tanácsokat, ötleteket előre is!
Üdv, cD.

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