játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5444
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:    2188
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]
Asylum - Törzstag | 5444 hsz       Online status #165881   2011.10.02 12:43 GMT+1 óra  
Ha pl. plasmagunra gondolsz, akkor rendes ütközésvizsgálat kell (ami alatt sweep test-et értek).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
ddbwo - Tag | 1625 hsz       Online status #165877   2011.10.02 12:21 GMT+1 óra  
Ja visszatérve a nyíl példára, a kezdő és végpont megadja az irány vektor, a végpont vagy kezdőpont pedig lehet a lövedék modelljének középpontja.

Ha nincs ütközés mondjuk fallal, akkor a modell megjelenik, különben történik aminek kell, megmaradó nyilaknál meg a falon számolt végponton jelenik meg egy új objektum, a régit lehet törölni még a rajzolás előtt. Hogy semmiképpen ne jelenjen meg olyan helyen, ahol nem is lehetne. Pl fal mögött. De ha a kezdőponton jelenik meg mindig, annak jónak kell lenni,.

De magát a lövedék fizikáját vonalként vagy szakaszként a legspórolósabb kezelni. persze a tengelyen végig lehet küldeni karikákat, hogy hengernek számítson. meg ha indokolt, lehet korong, gömb, hasáb, stb. A lehető legegyszerűbb kell ami leírja a lövedék viselkedését.

Ezt a hozzászólást ddbwo módosította (2011.10.02 12:28 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
   
Matzi - Szerkesztő | 2519 hsz       Online status #165870   2011.10.02 10:58 GMT+1 óra  
Speciel az FPS-ek többségében a sima gépfegyver lövedékek egyetlen vonal ütközést vizsgálnak a lövés pillanatában, és utána kb random a lőpálya valamelyik szakaszát felvillantják. Van egy játék, amiben ez nagyon durván megfigyelhető, a többiben nem feltűnő.

A lassabb lövedékeknél, pl gránát, rakéta, stb... ott valószínűleg rendesen kell ütköztetni és mozgatni.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
ddbwo - Tag | 1625 hsz       Online status #165863   2011.10.02 10:22 GMT+1 óra  
A lövedék sebességéből meg lehet kapni, hogy mekkora távot tesz meg egy "logic step" alatt. A kezdőpont és a végpont közt egy vonal keletkezik, amire vonalas ütközésvizsgálatot lehet csinálni.
Amennyire kell, annyira pontos lesz a vizsgálat és tévedhetetlen, csak minden step-nél az előző végpontból kell a következőt kiszámolni. Így be lehet iktatni a ballisztikus pályát is, gellert, meg ami kell.

Ha a vonal ütközést mutat, a kezdőpontból kis karikákat lehet "kilőni" a végpont felé, hogy kiderüljön az ütközés pontos helye, valamint hogy a fal miatt meddig érvényes a golyó. Csak hogy el legyen kerülve a falon átlövés meg ilyenek.

A megjelenítés lehet sárga csík, ami a vonal tört részére vagy egészére kerülhet. Vagy bármi más. De pl a cod-okban meg sok fps-ben így van megoldva és elég életszerű szokott lenni.
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
   
zeller - Törzstag | 464 hsz       Online status #165862   2011.10.02 09:25 GMT+1 óra  
Projectile-ok.
Tfh van olyan fegyver, vagy barmi, aminek a lovedeke nem fenysebesseggel halad, hanem lathatoan animalni kell, szoval ugyanolyan mozgasallapottal rendelkezo merev testkent kell kezelni, mint barmely masik jatekbeli objektumot, csak eppen rovidebb eletu.
Ezt hogyan szokas optimalizalni? Meg egyaltalan kezelni
Elvileg akar rajzolhatnank is csak egy valamit minden frame-ben egy kicsit eltolva es elore kiszamoljuk az idopontot amikor talalkozik, a hatasat pedig kesleletve fejti ki egy dummy valami.
Vagy erdemesebb merev testet es utkozeseket kezelni? Akar egy nyilvesszonel is?

   
zeller - Törzstag | 464 hsz       Online status #165133   2011.09.24 13:58 GMT+1 óra  
Gondoltam, hogy triggert teszek ra, de tulzasnak tartottam, minek ilyen eroforrast hasznalni egy mashogy is megoldhato problemara.
De aztan lehet, hogy atirom ugy, majd meglatjuk.

   
borsi - Tag | 180 hsz       Online status #165125   2011.09.24 12:24 GMT+1 óra  
Unitytől függetlenül az ilyen line of sight problémákat általában triggerré alakított colliderekkel szokás megoldani. Az más kérdés, hogy a fizikai motor milyen adatszerkezetet és algoritmust használ az ütközés vizsgálathoz. És nem hinném hogy kevésbé lenne optimális a megoldás, mintha saját algoritmust használnál.

   
Pretender - Törzstag | 2498 hsz       Online status #165124   2011.09.24 12:23 GMT+1 óra  
Valóban, valószínűleg a háttérben ez is ilyesmit alkalmaz, mint amit írtak / írtunk lentebb.

Amúgy szerintem a közös jf-projekthez kell neki, szóval szerintem Unity-s cuccra gondolt. De lehet, hogy tévedek

   
Matzi - Szerkesztő | 2519 hsz       Online status #165122   2011.09.24 12:16 GMT+1 óra  
borsi:
Ez egy unity specifikus cucc, ami valószínűleg szintén térfelosztással operál a háttérben. Tehát használni egyszerűbb ugyan, de a működése nem az. Illetve ugye a kérdésben nem szerepelt, hogy unity specifikus megoldás kellene.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
borsi - Tag | 180 hsz       Online status #165121   2011.09.24 12:12 GMT+1 óra  
Ezeknél van jóval egyszerűbb megoldás is: trigger. Minden toronyhoz csatolsz megfelelő méretű triggert (empty child sphere collider-el), csak azokat kell ellenőrizni OnTriggerStay()-ben, amik éppen benne vannak.
Konkrét példák itt: http://technology.blurst.com/unity-physics-trigger-collider-examples/

   
Pretender - Törzstag | 2498 hsz       Online status #165115   2011.09.24 10:31 GMT+1 óra  
Előfordulhat olyan eset, hogy 8 trillio kilométerre van egy ellenfél? Amúgy meg lehet ilyen voxelgridet (olyasmi, mint a quadtree, csak ez egyenlő "dobozokból" áll, és statikus) csinálni pl., és akkor csak a (optimális esetben) szomszédos gridben lévő ellenfelekre kell letesztelni. De szerintem két vektor távolságának kiszámolása nem egy olyan nagyon-nagy feladat, hogy ne bírja...
Kód:
v1 = (x1,y1,z1)
v2 = (x2, y2, z2)
d = sqrt((x2-x1)^2 + (y2-y1)^2 + (z2-z1)^2)

de gondolom ezt tudod te is...

szerk.:
ájh, látom, elkéstem

   
syam - Törzstag | 1491 hsz       Online status #165114   2011.09.24 10:30 GMT+1 óra  
A toronyból frustum cull ami közben távolság alapján sorba is rendez.
Aztán utána választhat a leggyengébb, legközelebbi stb. között.
alias aalberik
   
Matzi - Szerkesztő | 2519 hsz       Online status #165113   2011.09.24 10:29 GMT+1 óra  
Térfelosztás. 4fa, 8fa, uniform grid, BSP, stb... A konkrét választás a pálya adottságaitól függ. Én egy TD-nél, ami ugye egy korlátolt fix pályán játszódik a talajszinten, vagy az uniform gridet használnám, vagy ha valamiért nagyon muszáj, akkor esetleg 4fát. Először kiszámolod, hogy a tornyod melyik mezőket látja a térfelosztásban (optimálisan ez elég kevés lesz), és azon belül nézi meg az egységeket. Az egységeket meg minden elmozdulás után hozzárendeled a mezőhöz, amiben állnak.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
zeller - Törzstag | 464 hsz       Online status #165112   2011.09.24 10:16 GMT+1 óra  
Tower defense.
A toronynak celpontot kell talalnia.
Az alapjan donti el, hogy valaki celpont-e, hogy a ket helyvektor kulonbsegenek abszoluterteke kisebb mint a hatotavja.
Amig nem talalt ilyet, pasztazza az ellenfeleket a palyan.
A kerdes:
hogyan lehetne felokositani az algoritmust, hogy a teljesen szoba nem joheto, pl 8 trillio kilometerre levo ellenfeleket ne akarja feleslegesen megnezni?
Esetleg mas megkozelitessel kellene csinalni az algot?

   
zeller - Törzstag | 464 hsz       Online status #163009   2011.09.08 09:23 GMT+1 óra  
Entity systemek megint:
Az ok, hogy az entityk komponensei csak markerek, hogy mit kell veluk csinalni.
Az elvi nyeresegunk, mivel az entityk is helyet foglalnak a memoriakban, az n-1 virtualis fuggveny tabla.
Az entityknek kell legyen sajat allapota, kulonben ddbwo scripthez jutnank, ahol
cicapoziciok[100000] es hasonlo tombok lennenek. Ezt senki sem akarhatja...

Tfh minden viselkedeshez kulon komponenst vagy elemi komponensek egy halmazat rendeljuk, ezaltal
a kiscica = kis + cica(es cica = negylabu+allat+...) a nagycica meg = nagy +cica

Es most jon a drawback! Valahogyan neked definialnod kell, hogy a nagy meg a kis dolgok hogyan viselkednek. Ezt pedig fuggvenyekkel irod le. Azaz amit nyertel, azt majdnem elvesztetted, nem?

Persze kirajzolasnal elvileg nem, hiszen n vertexet ugyaugy rajzolsz mint 2n-t. Jateklogikanal viszont a veszteseg sokkal nagyobb lesz, mint amit nyernel. Minden viselkedesre meg kell irnod a fuggvenyt, amit aztan tipusazonositas segitsegevel kell meghivnod az objektumra. Ez amiatt, hogy az entityknek es a komponenseknek nincsenek fuggvenyeik, valahogy igy fog kinezni:
Kód:
if e is okos:
   okosanKovet(e, player)
if e is buta
   butanKovet(e, player)

Megfelelo mennyisegu tipusnal nehezen karbantarthato es terjengos kodot eredmenyez.

Elfogadom, hogy megjelenitesnel, hangoknal a funkcionalis dekompozicio polimorfikus objektumokon (buzzword: entity system) hatekonyabb mint az objektum orientalt. Ezt Szirmay is megmondta mar szggrafon.
De minden mas esetben nem. Szerintem.

   
borsi - Tag | 180 hsz       Online status #162424   2011.09.03 12:19 GMT+1 óra  
Ezt a kérdést úgy oldja meg, hogy a komponensek nem részei az entitynek, külön-külön megfelelő adatszerkezetekben vannak tárolva. A kapcsolat az összetartozó komponensek között annyi, hogy mindnek ugyan az az "entity id"-ja. Esetleg optimalizálásként az entityk tárolhatnak pontereket a komponenseikre. És így egy systemnek csak a megfelelő komponenseken kell végig menni, nem az entityken.

Például a hang systemnek kell a megfelelő pozíció és hangeffekt komponens, a render systemnek kell a pozíció és a renderelni kívánt adat (shader, vbo, ebo, stb), a fizika systemnek kellhet a sebesség, pozíció, bounding box, stb. Ha még azt megoldjuk, hogy egy komponenst csak egy system írhasson, akkor könnyen párhuzamosítható is.

De amúgy csak azt próbálom összefoglalni, amit a lent linkelt két cikkből megértettem, mert még soha nem csináltam ilyesmit.

Ezt a hozzászólást borsi módosította (2011.09.03 12:28 GMT+1 óra, ---)

   
zeller - Törzstag | 464 hsz       Online status #162391   2011.09.03 09:11 GMT+1 óra  
Ez szerintem elegge spanyolviasz.
Funkcionalis dekopozicio, polimorfikus 'objektumokon'. Csak ehhez nem kell entity systemnek nevezni...

A kulcs tenyleg ott van, hogy nem kell minden kodot objektumorientaltan megirni, de ezt Stroustrup is megmondta, ezert nem pure oo a c++.

pszeudokod szinten ez valami ilyesmi lehet:
Kód:
macska is allat
entity1 is macska
//etc

system allatsiomogato

fun simogat():
   foreach entity:
       if entity is allat:
            doSimogat(entity);


A kulcskerdes, hogy hogyan optimalizalod a kodot arra, hogy ne kelljenmindig a tipust identifikalni.
Mondjuk index szerkezettel, mapekben.

   
fpeti - Törzstag | 1290 hsz       Online status #162376   2011.09.02 23:16 GMT+1 óra  
Idézet
syam :
vannak az alap építőelemek (mesh, shape, light stb) amiket node-okhoz lehet rendelni a node-okból csontvázat, a csontvázat pedig szereplőhöz.


Lehet kezdem lassan fogni.. de nálam marad az öröklődés egyelőre
   
syam - Törzstag | 1491 hsz       Online status #162371   2011.09.02 22:55 GMT+1 óra  
Ezt nehéz röviden leírni: vannak az alap építőelemek (mesh, shape, light stb) amiket node-okhoz lehet rendelni a node-okból csontvázat, a csontvázat pedig szereplőhöz.

Ezeket az elemeket lehet / kell tárolni a térfelosztásban, fizikában, játék logikában, script rendszerben stb.

Attól függően mi mivel rendelkezik és miben tárolom írom meg hozzá a függvényt. Így pl vminek szüksége van aabb-re, vminek nem.

Oda kell rá figyelni az elején, de utána automatán megy a szereplődarabolás, robbantás, öltöztetés, ha modell a tüzet fog stb.

Ha pedig bármi kétség merül fel, csak meg kell nézni a táblázatot ^^
alias aalberik
   
fpeti - Törzstag | 1290 hsz       Online status #162367   2011.09.02 22:32 GMT+1 óra  
Idézet
syam :
Jéé, én ilyet csináltam - nekem is van egy ilyen rácsom, h mi milyen részekből áll


Ebben nincsenek a dolgok 'egységesítve'? Mondjuk le akarok kérni egy pozíciót, aabb-t, akkor azt hogy lehet megcsinálni? Minden objektumtípusra külön meg kell írni, vagy hogy?
Minden objektumtípus külön listában van?
- nem értem ezt - (10 sor kód elég lett volna a duma helyett - sokan savallják is a kommentekben)
   
ddbwo - Tag | 1625 hsz       Online status #162366   2011.09.02 22:29 GMT+1 óra  
Az alap gondolatmenet a következő. Ha pl valami alap mozgó dolog van, adott egy sima tömb:

float data[512][9], van 512 lény egység, aminek van 9 float mozgás adata.

Az ismert sorrend a következő lehet modelleknél példának okáért:

{pos_x, pos_y, pos_z, vec_x, vec_y, vec_z, speed, rot_x, rot_y, rot_z}

A kezelő metódus a következőt teszi mozgásnál pl:

void move()
{
for (int num = 0;num<512;num++)
{
data[ num ] [ 1 ] += data[ num ] [ 4 ] * data[ num ] [ 7 ];
data[ num ] [ 2 ] += data[ num ] [ 5 ] * data[ num ] [ 7 ];
data[ num ] [ 3 ] += data[ num ] [ 6 ] * data[ num ] [ 7 ];
}
}

kirajzolásnál a pozíció az első három adat, a forgás az uccsó három, a blur a hetedik.

Ugyanezen logika alapján lehet keverni minden mást. Minden egységnek megvan minden adat, de csak azokat alkalmazza a rendszer, amik az adott tárgyra tartoznak, a többi nulla. Pl egy fának nincs vektora és sebessége.

Persze ez most nagyon egyszerű példa, mert nem raktam current_pos-t, meg next_pos-t és nincs fizikai algoritmus sem. De tisztán látszik hogy nem oop, mégis megvannak a tárgyak a maguk módján. Ezek konkrétan sprite-ok...

@syam:
Na ugye, nem nagy cuccok, ki lehet őket taláni.
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
   
syam - Törzstag | 1491 hsz       Online status #162365   2011.09.02 22:12 GMT+1 óra  
Jéé, én ilyet csináltam - nekem is van egy ilyen rácsom, h mi milyen részekből áll
alias aalberik
   
borsi - Tag | 180 hsz       Online status #162364   2011.09.02 22:07 GMT+1 óra  
Ez a link rövidebben összefoglalja, de pont ezért elég felületes is. Jelenleg még én is csak emésztem és próbálom papíron meg fejben összerakni, hogy ebből hogyan lesz egy működő egész. Az egyik alapvetés, hogy ne használjunk benne oop kódot, hoz némi kihívást.

   
ddbwo - Tag | 1625 hsz       Online status #162363   2011.09.02 21:26 GMT+1 óra  
Idézet
borsi :
A komponens alapú játékfejlesztéssel van már valakinek tapasztalata? Konkrétan az ilyen durván data-driven megoldásra gondolok, ahol egy entity csak egy id ami összekapcsolja az összetartozó komponenseket.



Ha jól veszem ki, akkor arról szól a rendszer, hogy mindennek megvan a lényeges funkciója, jellemzője, tulajdonsága, ami alapján működésbe lép, vagy ami alapján használják.
Szerintem hasonlóval kísérleteztem Blenderben. De ez eléggé feltétel rendszerekre épül, mivel a tulajdonságokat a megfelelő logikai halmaz alapján lehet beazonosítani.
Ez sem annyira különleges, mint ahogy beállítják.

Ráadásul minden egységnek kell metódus, de azt írja hogy nem, pedig akkor mi alapján választaná meg az egység a lehetőségek közül a vélt jó reakciót?
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
   
ddbwo - Tag | 1625 hsz       Online status #162362   2011.09.02 21:07 GMT+1 óra  
@Parallax:

Értem én, hogy sok embernek, főleg fiatalabb korosztálynak (pl 18 év alatt) idő kitapasztalni a dolgokat, vagy fel kell venni a kód szemléletet, mert még új. De nekem már nagyon rég óta nem kell hosszan gondolkodnom semmin, elég látnom egy helyzetet és megvan minden megoldás.

Most minden gúnyolódási szándék nélkül, nekem ez az egyszer jönnek a szívások ilyen "jön a zsákos ember és elvisz" félének tűnik. Még sosem láttam olyat, amit igazán nehéz megoldani. Persze megint lehetne jönni egy csinálj Szudoku megoldó algoritmust tanáccsal.

Egy játék szintjén semmi váratlan feladat nem érhet... A következő mondatom önteltnek tűnhet, de az a legnagyobb hátrányom, hogy tisztában vagyok a képességeimmel.
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
   
borsi - Tag | 180 hsz       Online status #162360   2011.09.02 21:00 GMT+1 óra  
A komponens alapú játékfejlesztéssel van már valakinek tapasztalata? Konkrétan az ilyen durván data-driven megoldásra gondolok, ahol egy entity csak egy id ami összekapcsolja az összetartozó komponenseket.

   
Parallax - Tag | 579 hsz       Online status #162359   2011.09.02 20:40 GMT+1 óra  
zeller: Természetesen én se céges projectről beszélek, hanem sajátról. A cégesben sajnos sok dilettáns is beleszarik, nem lehet normálisan betartani semmit. Az ördögtől valónak titulálnak sokszor teljesen alap dolgokat is, főleg, ha több cég is összedolgozik és különböző szintű emberek, az mekkora káosz. Saját project kódjára öröm ránézni, esetleg újrahasznosítani, az más eset. Aztán, hogy ez mennyire jó arról csak annyit, hogy legtöbb helyen húzzák-vonják adott felépített rndszerüket. Onnan nem tudnak kimozdulni, legfőképp tervezés hiánya, l'art pour l'art fejlesztés, pontosabban gányolás miatt. Látszólag gyorsan haladnak ideiglenesen, de csak egy helyben járnak.

ddbwo: Majd rájössz, ez hosszú évek és szívások folyamata lesz, nem csak úgy sitty-sutty. A programozás egy gondolkodásmód, aminek érési folyamata van. Érdemes nézni mindenféle fejlesztési, programozási módszert és használni, megérteni. Elsőre hülyeségnek, erőltetett dolgoknak tűnő módszerekre rájössz, hogy ez hosszútávon tök jó. Sebességben akkora különbség nincs egy magasszintű nyelven belül, hogy ne érné meg. Ha sebeségezni kell, akkor asm, de kinől a szakállad mire abban megírod és át is látod. A script jó ötlet, extrém gyors fejlesztés, csak legyen hozzá jó debug lehetőség, különben visszaüt.

   
ddbwo - Tag | 1625 hsz       Online status #162358   2011.09.02 20:15 GMT+1 óra  
OOP-ben sem hiszem hogy minden automatice jön létre, két sort azért csak be kell szúrni valahova... De összefoglalhatom egy metódusba az egészet és akkor csak ennyi látszana:

enemy_logic();

Attól még vannak benne if -ek, meg struktúrák, meg minden, csak nem látszik. A legelső barbár if-es módot sosem használtam, minek kérdezni hogy van-e kolbász, ha egyszer tudom hogy van?

Persze izlések és pofonok. Nekem ez a minimális programozási modell bejön, mert teljes a kontrollom minden felett. És mi lehetne gyorsabb, mint egy egyszerű struct tömb végigpörgetése, ahol ráadásul minden egy helyen van, így a memória a legminimálisabban sem tördelt?

Én magamnak átlátom azt is, ha csak egy float enemy[10][512][12] van, és egy metódus fut végig az egészen. Ezt is használtam mostanában.

Amiben biztos vagyok, hogy ennél nincs gyorsabb és egyszerűbb megoldás. Persze a class-osat is ismerem, meg is tudom csinálni, de ez gyorsabban is gépelhető egyedül. Nekem megfelel a gépi utasítás szint is, már a metódus megnevezéséből is tudom, hogy mire jó.
Biztos nem ez a legszebb kinézetre, de a legminimálisabb. És bármit meg tudok csinálni vele.

Ha látnátok, h milyen rövid egy-egy cucc. Na de nem reklám, mindenki használja csak azt amit, mert biztos van oka, hogy miért azt használja.

---
Viszont komolyan tervezem mostanában a python integrációját, amiben majd szépen .py fájlokban fogok scriptelgetni, a python már a kisujjamban van, vagy két hétig nyúztam aztat.
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
   
zeller - Törzstag | 464 hsz       Online status #162356   2011.09.02 19:50 GMT+1 óra  
Sokszor sajnos nem a hardcore modularitas, design for reuse and extend a nyero, legalabbis a valo eletben, de szerintem ez azert van mert sok a kokler. Ha mindenki pro lenne es nem kv-val toltene a munkaideje felet, akkor nem igy lenne.
De ez tan mar off ide...

   
Parallax - Tag | 579 hsz       Online status #162355   2011.09.02 19:41 GMT+1 óra  
Pont a végeredmény érdekében alakultak ki nem véletlenül bizonyos dolgok. Lehet tolni is egy kocsit, meg bele is lehet ülni és menni 100-al.

   
zeller - Törzstag | 464 hsz       Online status #162354   2011.09.02 19:39 GMT+1 óra  
Annyit hozzatennek, hogy cpp-ben a struct == class aminek minden tagja publikus. C-ben valoban nem lehetnek tagfuggvenyei.

De mindenki ugy kodol ahogy akar.
Amugy is a vegeredmeny szamit, meg hogy mennyit hoz a konyhara. A hajukat hullato maintenance programmerek csereszabatosak

   
Parallax - Tag | 579 hsz       Online status #162351   2011.09.02 19:07 GMT+1 óra  
Kalóz mester: A struct-nak nincsenek tagfüggvényei. A struct csak adatokat tárol és globális fgv-ek végeznek az egyes struct-okon adat manimpulációkat. Ez így most ilyen felemás valami. OOP is, meg nem is. Ehhez nem kell iskola ez egy paradigma, amihez a nyelv ki van alakítva. Lehet szembe úszni is az árral, de ahogy írták nem kifizetődő egy esetleges újrahasznosítható, neadj isten javítható kóddal szemben. És ez csak az alap, programtervezési mintákat is átláthatóbb OOP-vel megoldani. Az egész értelme, hogy te mind ember nem gépi utasításokat nézel, hanem egy beszédes kódot, amiről ránézésre átlátod, hogy mit takar a jelentése, amiből egy halom másik kódot is egyből megértesz nem csak azt a 10 sort.

   
zeller - Törzstag | 464 hsz       Online status #162348   2011.09.02 18:51 GMT+1 óra  
En mindossze annyit mondtam meg a kezdetek kezdeten, hogy az if elkerulheto, ha indokolt, pl polimorfizmussal...
Ez sokszor melegen ajanlott. pl. 12 elagazasos ifek eseten, amit jelenleg sajnos sokat latok...

Es jo struktura mellett a kod sokkal rovidebb es olvashatobb, konnyebben kiterjeszthetobb lesz. strukturfuggony nelkul ddbwo kodja minden uj entityvel +2sor lesz, az entitin felul.

Masik oldalrol, ha nem indokolt, akkor ne csinaljuk.

   
gopher - Törzstag | 496 hsz       Online status #162344   2011.09.02 17:29 GMT+1 óra  
Meg még ezer dolog. Hosszú futamidejű és nagy projekt esetén ezek az apróságok nagyon-nagyon sokat számítanak.
   
ddbwo - Tag | 1625 hsz       Online status #162343   2011.09.02 17:28 GMT+1 óra  
Na amikor a struktúrák listája struktúrákba jönnek, az a struktúrfüggöny, úgy már nem kéne.
De típusonként ennyi amit kézileg kéne beállítani pluszba anélkül is.
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
   
gopher - Törzstag | 496 hsz       Online status #162342   2011.09.02 17:25 GMT+1 óra  
Na ez az. Ha ezt OOP-vel csinálod, ehhez a részhez már nem kell hozzányúlnod.
   
ddbwo - Tag | 1625 hsz       Online status #162341   2011.09.02 17:25 GMT+1 óra  
xD Ugyanoda sorba jöhetnek. De nekik más csekker és más doitbaby kell, mert repülnek, ezért máshogy reagálnak a környezetre. xD

fly_enemy

for (int num = 0;num < max_num;num++)
{
zombie[ num ].csekker();
zombie[ num ].DoItBaby();
bat[ num ].csekker();
bat[ num ].DoItBaby();
}
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
   
gopher - Törzstag | 496 hsz       Online status #162340   2011.09.02 17:21 GMT+1 óra  
Hol vannak a denevérek? (Entity_Bat)
   
ddbwo - Tag | 1625 hsz       Online status #162339   2011.09.02 17:15 GMT+1 óra  
gányul hirtelen elnagyoltan:

struct enemy
{
float pos[3]
(stb, stb)

void csekker() { ... }
void DoItBaby() { ... }
}

enemy zombie[512];
max_num = 512;

for (int num = 0;num < max_num;num++)
{
zombie[ num ].csekker();
zombie[ num ].DoItBaby();
}
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
   
gopher - Törzstag | 496 hsz       Online status #162338   2011.09.02 17:08 GMT+1 óra  
@ddbwo: a különböző process eljárások meghívását hogyan oldod meg egy sima for-ral?
   
ddbwo - Tag | 1625 hsz       Online status #162337   2011.09.02 17:07 GMT+1 óra  
@Pretender:
Akkor visszatértünk a gyökerekhez, beigazolódott, hogy bárki tud programozni minden suli nélkül azonnal. A pár hónapot más mondta, sziget editorom meg már van, és if - es pongom is van egy jó ideje.
Ha az összes megoldásomat elolvasod mindenhonnan, szerintem meg simán kiderül, hogy bármit összerakok ha olyanom támadna.

@Zeller:
Ez csak egy másik megoldás. Nálam is vannak struktúrák, meg írhatok class-okat is, de a megöröklött metódusok if-eket takarnak, ha hatások alapján vagy idő alapján reagálnak valamire.

@gopher
A struktúrák öröklött metódusait én is for-al bonyolítom le az egységek száma alapján. Az sem stájsz.

Az if nincs elkerülve. Ott vannak a metódusokban...
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
   
gopher - Törzstag | 496 hsz       Online status #162336   2011.09.02 17:00 GMT+1 óra  
Az OOP-t (és azon belül a polimorfizmust) nem csak az if-ek elkerülésére használjuk.

Ezt inkább nézzük úgy, hogy van Entity, abból van Entity_Zombie és Entity_Bat. Mind a kettőnek van "process" metódusa. És van egy listánk is: list<Entity*>. Minden entitás process-szét meg akarjuk hívni:

Kód:
for (i = list.begin(); i != list.end(); i++) (*i)->process()


Jóval átláthatóbb, mintha lenne mind ezekre struktúránk, és azokhoz tartozó process eljárások:

Kód:
EntityZombie z;
EntityBat b;

for (i = 0; i < count; i++)
{
    Entity e = list[i];
   
    switch (e.type) {
         ENTITY_ZOMBIE:
              z = (EntityZombie)e;
              EntityZombieProcess(z);
              break;
         ENTITY_BAT:
              b = (EntityBat)e;
              EntityBatProcess(b);             
              break;
    }
}


A count meghatározásáról, meg arról, hogy mivan, ha új típusú entitást teszünk be, ne is beszéljünk
   
zeller - Törzstag | 464 hsz       Online status #162335   2011.09.02 16:44 GMT+1 óra  
ddbwo:
polimorfizmus, a teljesseg igenye nelkul.
if(kolbasz)
doKolbaszThings();
if(szalami)
doSzalamiThings();

Helyett:

class HentesAru {
public:
virtual void doThings() = 0;
}

class Szalami : public HentesAru {
public:
void doThings(){...}
}

class Szalami : public HentesAru {
public:
void doThings(){...}
}

...
HentesAru *bigyo = new Szalami();
bigyo->doThings();

vagy

HentesAru *bigyo2 = new Kolbasz();
bigyo2->doThings();

ugyanott vagyok. If nelkul.
Bar lehet, hogy a falnak beszelek...

btw, hogy lehet 'kod' formazassal idetenni ezt?

   
Pretender - Törzstag | 2498 hsz       Online status #162334   2011.09.02 16:39 GMT+1 óra  
oké, nem is tudom mit erőlködök Még mindig a szokásos jut eszembe: "A hülyének úgysem tudod megmagyarázni, hogy hülye, mert hülye."
Oké, te így gondolod, akkor lássuk a nagy programokat (főleg, hogy pár hónapos munkára beígértél egy crysis-t), "if-"et írni egy 10 éves is tud

   
ddbwo - Tag | 1625 hsz       Online status #162331   2011.09.02 16:17 GMT+1 óra  
Nemhogy csak egy része, de elhagyhatatlan része. If nélkül maga a program dinamikus jellege nem lenne meg. Csak lefutna magában és nem lehetne beleszólni a dolgokba. De minden érdemi metódus is if-ekből épül fel. Az algoritmusok menetét meg maguk az előtte ellenőrzött feltételek módosítják.

Persze attól még minden más is része a programnak, de átvitt értelemen egy stóc if-ből áll az érdemi rész.
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
   
Pretender - Törzstag | 2498 hsz       Online status #162329   2011.09.02 16:01 GMT+1 óra  
Jó, de én magáról a technikáról beszéltem... addig oké, hogy iffel lehet csekkolni dolgokat, de attól még nem lesz neked shadered, ilyen-olyan rendszered... az if is a része, ennyi, de az csak egy darab logikai művelet a sok közül...

   
ddbwo - Tag | 1625 hsz       Online status #162327   2011.09.02 15:45 GMT+1 óra  
@Pretender:

if (deferred_shading)
{
deferred_shading_m();
}

Na ugye?

Hát pedig csak pár if, azt kész a progi.

A deferred shading-ből sem lesz A.I. vagy fizika. Az egy elhagyható oldalág, sőt, zsákutca a teljes program szempontjából, ami a számolgatások után meg is szűnik.
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 | 5444 hsz       Online status #162325   2011.09.02 15:26 GMT+1 óra  
Ha már stream processzor: ott nincsenek bitmüveletek.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #162324   2011.09.02 15:22 GMT+1 óra  
szerintem magával a felvetéssel van baj, h programozás = if/else. Hiába írogatnék egy rakat feltételt, abból még nem lesz deferred shading

   
Akybron - Törzstag | 456 hsz       Online status #162323   2011.09.02 15:15 GMT+1 óra  
Vannak rendszerek, ahol költséges az IF (pl. Messze kell ugrani, PipeLine-t újra kell tölteni, cache-en kívülre esik, stb), esetleg nem is létezik (pl. Régebbi shader nyelvek, bizonyos DSP-k). Ilyen esetben másképp kell megoldani.

Olvasnivaló:

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