@Parallax:
Igen, ez a része tényleg jó, viszont azon a problémán agyaltam mostanában, hogy hogyan lehetne a scene load részét kikerülni a gameplay futtatásakor. Úgy értem, hogy tök jó dolog ez a scripting, de ez csak azt a részt oldja meg, hogy miként módosítsunk már meglévõ dolgokat. Ha viszont az editorban oda szeretnék tenni egy dobozt, vagy akármit, akkor ahhoz el kell menteni a scene-t, majd újra kell tölteni a pályát (avagy újra kell indítani a programot) a tényleges gameplay esetén. Persze ez a kisebbik baj, azért az igen kényelmes a Unity-ben, hogy futás közben nyomhatok egy pause-t, és megnézhetem ott helyben az összes objektum állapotát, ha akarom módosíthatom, és folytathatom úgy a futást.

Valami olyasmi megoldáson gondolkoztam, hogy dev-time a gameplay kódból egy dll készülne, de maga az engine maradna static lib. Ez ugye annyiban lenne gond, hogy, ha betöltöm a dll-t, akkor a hozzálinkelt engine "duplázódva" lenne. Azonban sikerült átírnom az engine egy részét úgy, hogy Dependency Injectiont használjon. Ekkor viszont megtehetem azt, hogy az editor alkalmazáshoz már létrehozott systemek pointerjeit "átpasszolom a dll-nek", így az nem hozna létre pl. egy új renderert, hanem a már meglévõt használná.

Így viszont megoldható a hot-reload is, hiszen csak az adott dll-t kell újratölteni, és meghívni néhány entry point-jellegû függvényét.

Nem tudom, hogy ez így mennyire mûködne, de nem lenne rossz, mert akkor maradhatnék c++ban a "scripteléshez" is, az összes feature-jével együtt.

Idézet

---

Instalok :
Be kell vallani azért, hogy a Unity megoldása elég kényelmes. Adott egy editor, amiben ott helyben lehet futtatni és kipróbálni a gameplay kódot.

---

Ezért jó a Lua. Könnyû bindolni és hozzá editort írni és bármire lefordítható, amire van C compiler.

Az alapvetõ gond ezzel a megosztott dologgal ugye az, hogy a gameplay kód függ az engine liben, de ugyan úgy az editor is. Az engine jelenleg egy statikus lib, amit szimplán összelinkelek a gameplay kóddal, így nyugodtan használható az engine funkcionalitása. Viszont mivel "duplikált kódot" nem szeretnék, így nem lett volna elég, ha a gameplay kódból csináltam volna shared libet, az engine is az kellett volna, hogy legyen. Onnantól kezdve pedig ugye csak egyre bonyolultabb minden, végül ezért elvetettem az egész megközelítést. Be kell vallani azért, hogy a Unity megoldása elég kényelmes. Adott egy editor, amiben ott helyben lehet futtatni és kipróbálni a gameplay kódot.

Persze, lehet egy ahhoz hasonló megoldás is, amit írtál. Készülne a gameplay-bõl egy olyan futtatható bináris is, ami tud kommunikálni az editorral. Pontosabban az editor tud vele. Így például különbözõ signalokat tudna neki küldeni, amivel az editorból lehet resetelni egy scene-t, megállítani az update-et, stb. Persze mehet a visszafelé kommunikáció is, hasonlóan ahogy írtad (be kell valljam, a socketes kommunikáció eszembe sem jutott ), csak ugye egy egyszerû signalt küldeni könnyebb, mint egy "teljes objektumot" átküldeni. Persze az is megoldható, csak kell egy jó serializer/deserializer hozzá, így az editor bizonyos eseményekkor lekérhetné a jelenlegi adatokat egy entity-rõl / komponensrõl (mint például az objektum pozíciója). Végül is megoldható ez a socketes kommunikáció, nem is olyan rossz ötlet, bár ezt szerintem csak egy késõbbi változatnál csinálom meg, ha úgy alakul - néha tényleg muszáj egyszerûsíteni, mert így sem készül el sohasem az ember. Köszi az ötletet!

Ja és az automatikus DI dolgot dícséretnek szántam. Mostanában néztem google talk videókat, ahol nagyon nyomatták a DI-t meg Law of Demeter-t meg minden ehhez hasonlót, és rájöttem, hogy eddig én is teljesen rosszul csináltam. (továbbá megnézve az UE4 forráskódját, õk is teljesen rosszul csinálták, hehe csak hát ugye csinálni egy singleton-t, amit elér az ember mindenhonnan könnyebb, mint normális design-t kitalálni).

Nem akartalak amúgy elbizonytalanítani. Anno én is csináltam valami hasonlót, de egy UE4 ötletet követtem: module managert írtam, de a lényege végsõ soron ugyan az volt, mint amit te csináltál. És én is azt tapasztaltam, hogy mûködött, bár én csak MSVC-vel próbáltam ki. Szóval, ha mûködik, akkor tök jó! Õk egyébként a következõ kódrészletet használták:


szerk.:
Apropó, egy apró ötlet a kódhoz, amit csináltál: Lehetne egy csak debug módban használt guarding, ami figyelné azt, hogy az implementáció ne hívja meg az szülõosztály adott függvényét, mert az jó kis végtelen ciklushoz vezetne. Erre gondolok:

A szülõ osztályban ha lenne egy check, akkor ez elkerülhetõ. Persze, a programozó bármikor tökön tudja magát lõni, ha akarja, ettõl függetlenül. Szóval lehet, h csak én vagyok túl óvatos önmagammal szemben is.

@Instalok:
Hát végül is még ezzel is lehetne dinamikusat csinálni. Ugyebár a kis példából jól látszik, hogy nem nagyon tudod mit injektálsz, ezért akár csinálhatnál valami ilyesmit:

- Adott az editor (ilyesmi komponensalapú szerkezetben). Ott meg vannak adva miféle interfészeket lehet megvalósítani. Ez egy standalone alkalmazás exe, vagy linux bináris.
- Adott egy másik ilyen projekt, ami az összes "szkriptet" tartalmazza. Persze köztes halmazt képeznek a nyilvános interfész header-ek ilyenkor.
- Ebben a másik projektben a main és az alap dolgok adnak szolgáltatásokat az editorral / runtime-al való protobufos, vagy socket-es kapcsolathoz.
- Ez a kapcsolat kézfogás-alapú, de fel van készítve arra, hogy felépül és leépül, miközben az editor várakozó helyzetbe tehetõ.

Ezek mellett már lehet olyat, hogy az editoron belül egy kis ablakban (vagy persze külsõ szerkesztõben írod a tényleg igazi c++ kódot, ami persze a másik projekt fájljait módosítja és akkor van egy gombnyomás, ami leállítja a másik socketes progit, majd az összes ottani scriptet make-eli. Ugyebár a make-elés eleve figyeli, hogy csak az új dolgokra fusson így fel a struktúra miatt és ha visszajött a shell, akkor elindul az editor másik fele, ami szól, hogy készen vagyunk.

Persze ez már nem csak a barátom tartaná szerintem kicsit overcomplicated-nek, de szerintem mûködne. A dolog elõnye ugye, hogy használhatod ugyanazt a c++ fordítódat, amit egyébként is (a legújabb lambdákkal, meg unique pointerekkel), de itt már nem lehet std::vector paramétereket átadni meg hasonlók... ez itt legalábbis nehezebb lenne akárcsak egy DLL-nél.

Ami esetleg még érdekes lehet, hogy ha magad akarsz valamit és nem mondjuk Lua-t, hogy esetleg valami FORTH variációt magadnak tudsz implementálni. Ahhoz persze megírod a fordítód és még kifejezõ is, viszont az tuti ziher, hogy szerintem valami meglévõ megoldás jobban optimalizál majd...

Az se rossz mondjuk, ahogy most van a leírásod alapján. Végülis tetszik. Elsõre én is mindig valami bonyolultat akarok, aztán lesz valami olyan, ami egyszerû és meg is felel. Majd persze az is tud szépen fejlõdni ;-)

ui.:
"Látom azért automatikus dependency injection is van a frameworkben."

- Túl sok volt az enterspájz programming már és ilyeneket csinálok )

"Arra kell figyelni, hogy vannak fordítók, amik az "unused object"-eket kioptimalizálják, azaz a static registernél erre lehet, hogy figyelni kell majd."

- Amikor kitaláltam, akkor meg voltam gyõzõdve, hogy szabványosan meg kell hívódjon ez a kód. Szoktam több fordítón is tesztelni optimalizálva is ezeket a kódjaimat és nem volt még ezzel baj, de ez persze nem jelenti, hogy nincs ezzel talán szopás. Most el is bizonytalanodtam :-)

@Prenex:
Igen, ez a megközelítés már eddig is megvolt/megvan - csak saját implementációval -, csak pont az lett volna a lényege, hogy a hot reload lehetséges legyen. Látom azért automatikus dependency injection is van a frameworkben. Arra kell figyelni, hogy vannak fordítók, amik az "unused object"-eket kioptimalizálják, azaz a static registernél erre lehet, hogy figyelni kell majd.

Azóta már találtam az editorhoz egy másik megközelítést. Próbáltam ugye azt elérni, hogy hasonlóan mûködhessen majd, mint a Unity: átírom a scriptet/komponenst/akármit, lefordítom dll-be, az editor újratölti, és máris látom az editorban a változtatásokat. Ez viszont magával húzná a dll-ek bonyolultságát, így végül elvetettem.

Azt a kevésbé "szép" megközelítést választottam, hogy az editor ilyen szempontból buta, és direktben nem tud a gameplay komponensekrõl. Cserébe az editor csak egy adatszolgáltató. Azaz egy objektumra definiál egy új komponenst xy névvel, amihez fel tud venni értékeket [key, value] alakban. Maguknak a komponenseknek a feladata parse-olni és használni az adatot. Magyarán megfordítottam az irányt: az editornak továbbiakban nem lesz függõsége a gameplay lib, csupán adatokat szolgáltat, amit a gameplay lib felhasznál. Így legalább nem kell megoldanom azt sem, hogy hogyan olvassam ki a komponensekbõl az editor számára látható elemeket.

Instalok:

Az általad felvetett két alternatíva mellett egy engine esetén még talán érdekes lehet a komponensalapú megközelítés is. Lényegében a DLL / shared object is ilyen (runtime komponens), de mostanában azzal szoktam kísérletezgetni, hogy fordítási idejû komponens-architekturákkal mókolok. Arról van szó, hogy ez egy ugyan olyan plugin szerkezet, mintha DLL, SO, vagy OSGi lenne és a hasonló heavyweight dolgok, de nem runtime - sõt amikor egy plugint ki akarok cserélni, vagy mondjuk letöltesz egy komponenst, akkor újra kell fordítani a kódot.

Tudom ez nem teljesen drag&drop, viszont nagyon egyszerû megcsinálni és átlátható szerintem az architektúra. A minimalista barátomnak, már így is "túl overcomplicated" lett és egyébként is kíváncsi vagyok kinek mi a véleménye.

https://github.com/prenex/LightWeightComponents

- Itt megtalálható a jelenlegi változat (direkt egy minimál példa van csak megvalósítva, de majd csinálok ezzel valami nagyobb progit is).
- Ez még szerintem változni fog. Például bekerülnek a komponensekbe tehetõ bináris asset-ek és filozofálok a make-elés egyszerûsítésén.

Ha nem kell mindenáron dinamikusnak lennie, akkor szerintem ez egy engine esetén is járható út lehet. Az ötlet teljesen ingyenes és opensource, csak említs meg ha használod ;-)

A Lua beépített módon támogatja az OOP-t, de annyira rugalmas, hogy osztály, egységbe zárás és öröklkés könnyen megoldható. Lehet AngelScript-et is használni, ami már majdnem olyan, mint a C++, de ott asszem a futás közbeni kód módosítás nem annyira rugalmas, mint Lua alatt, pedig ez a script egyik alap lényege.

A legnagyobb gondom talán csak az marad így, hogy hogyan rendeljek egy adott scriptet egy objektumhoz. Mert ugye a script követheti a komponenses megközelítést (van néhány "eseménykezelõje", és igazából ennyi), csak valahogy ezt társítani is kell egy adott objecthez.

Ráadásul a Lua-t nem ismerem, de amennyit foglalkoztam gameplay kóddal, ott elõfordult, hogy kellett (érdemes) volt használni öröklõdést, stb., amit egy c-alapú programozási nyelv nyilván biztosít.

Egy ésszerû határt érdemes meghúzni a drag&drop és a szövegszerkesztõ között

Igen, lehet, hogy valami ilyesmiben fogok én is kikötni. :/

Bár, megfelelõ mennyiségû UE4 és/vagy Unity után nagyon szimpatikus az a módszer, hogy saját komponenseket alkothatunk, amiket az editorban is látunk, és csak simán "rádobjuk" a game objectekre.

Én simán luából engedem rommá scriptelni az enginemet, editoromat és a guimat.

Anno a cégnél használtunk valamiféle lazy dll load dolgot. Ha jól rémlik, valami olyasmi volt a lényege, hogy megmondtuk a linkernek, hogy semmi gond, hogy nem találja a függvényt, majd menet közben betöltünk egy dll-t, amiben benne lesz.

Megközelítem másképp: scriptelésen gondolkozok, és a leggyakoribb megoldás, amit láttam, az az, hogy az engine-t dll-be fordítják, és nagy részét exportálják (amit ugye használhatóvá akarnak tenni a kliens által). Elõnye az, hogy használhatsz egy jól megszokott programozási nyelvet, le tudod fordítani, és gyors (fõleg, ha c++ban írod a scripteket is). Hátránya meg nyilván az, hogy shared lib lesz az engine, mindenféle dolgot ki kell exportálni, arról nem is beszélve, hogy az STL-t nem használhatod, mert még a vector-t sem lehet értelmesen kiexportálni.

A másik megközelítés az, hogy az engine-t nem bántjuk ilyen szempontból, maradhat akár statikus lib is, cserébe a script az, amit runtime betöltünk, és futtatunk.

Ezen belül ugye lehet több megoldás is:

Lehet valamilyen virtuális gép / interpreter, ami egy saját nyelvet dolgoz fel, és meghívja az engine megfelelõ részét. Ennek több hátránya is van. Például az, hogy amennyiben egy új funkció bekerül az engine kódba, azt majdhogynem duplikálni kell. Megírjuk magát a kódot, meg azt a kódot is, ami ezt futtatja a scriptbõl. Továbbá egy saját VM/Interpreter megírása akár bonyolult is lehet, és lassabbá is teheti a futást.

A másik, ami eszembe jutott az a fent említett lazy dll loading. Olyat lehet-e valahogy csinálni, hogy az engine marad statikus lib, a scripteket szintén c++ban írom (felhasználva az engine headeröket), de valahogy megmondom neki, hogy ne aggódjon a linkeléskor, mert menet közben meg fogja találni a függvényeket / objektumokat?

Szóval valahogy így nézne ki a dolog:
Engine - lib
Application - exe
Game - dll
Természetesen az Application-be belefordítom az Engine-t. Az alkalmazás indításakor pedig fogná a Game.dll-t, és betöltené. Azonban a Game.dll-hez nem lehet hozzálinkelve az Engine.lib, mert akkor ugye minden "duplikálva lenne". Itt kellene az, hogy amikor a Game.dll-t fordítom, akkor ne hasaljon el a linker, hogy nem találja a függvényeket, amiket meg akarok hívni.

Így gondoltam én is, azért kérdeztem. Azután javasolni akartam, hogy azon projekt beállításait nézze át, amelyikbõl a dll fordul. Hülye azért nem vagyok.

Úgy lesz egy dll ahogyan egy exe. Egyszeruen a projektek nagy része lib-be fordul, a dll meg azokat beépíti.

Közben megtaláltam, hogy az egyik project újrafordítása gyanúsan magával rántja az összes többi projectet, és ez hozza létre a dll-t a többibõl

Itt forceolom a pdb generálást, és így mûkszik.

Hogy lesz a halom projektbõl egyetlen dll?

Visual studio-ban van egy solutionben egy halom project, az egészbõl lesz egy dll. A dll-hez kéne pdb fájl, de nem sikerült rájönnöm, hogy tudok csinálni.

A projecteknél be van állítva, hogy generáljanak, minden project saját build mappájába kerül is egy, de azokat nem lehet használni a dll-el, egy közös meg nincs.

Kb. semmit nem találtam az interneten ezzel kapcsolatban, bárkinek bármi tapasztalata/ötlete a témában?

Akkor inkább maradok annál, hogy egy quadtreem lesz, úgyse lesz túl sok layer, ha meg mégis, akkor ez van. Úgysem osztok egy bizonyos méretnél kisebbre.

Így.

Kellene nekem valami trükk ahhoz, hogy egy Quadtree-t hogy tudnék általánosra megcsinálni. Úgy értem, hogy van mondjuk geometriám, pontfényem, meg késõbb még kitudjami. A geometriák viszont layerenként vannak rendezve (hogy lehessen csak egy adott layert rajzolni), de például a fények viszont nem.

Tehát kell nekem egy quadtree layerenként, ami (egyelõre csak) a geometriák rendezéséért felelõs, meg kell egy "global" quadtree, ami a nem layerhez tartozó (egyelõre csak point light van) objektumok rendezéséért felelõs.

No persze azt meg lehetne csinálni, hogy van egy base class, mondjuk IQuadTreeElement, ami meg tudja mondani a befoglalóját, és tartalmaz egy enumot is, ami megjelöli a típusát. Így egységesen lehetne kezelni az egészet. Amikor pedig lekérdezem a látható IQuadTreeElement-eket, akkor a típus alapján tudok switchelni, és a megfelelõ kis bucketbe rakni.

Nyilván ez mûködõképes, csak kíváncsi vagyok, hogy azért van-e ennél szebb megoldás. Valami közös õs mindenképpen kelleni fog, mert valahol tárolnom kell, hogy egy adott elem az melyik cellába tartozik (hogy transzformálás esetén el tudjam távolítani az adott cellából, ha szükséges).

szerk.:
Nyilván meg lehetne fordítani, és azt mondani, hogy már maga a QuadTree is layerenként tárolja a geometriát, csakhogy ebben az esetben túl sok fölösleges felosztása lenne. Ha például egy layeren csak 1-2 elszórt objektum van, akkor a teljes quadtree-t elég csak néhány alkalommal darabolni. Ha viszont egy quadtree tartozik mindenkihez, akkor a többi layer miatt már kisebb részekre van darabolva, ezzel kvázi növelve a tesztelendõ cellák számát.

Nézd meg ezt, talán van benne vmi használható.

Az értelmesebb játékok kezelik a RightAlt-ot, mint billentyût, szóval nem, nem felejtem el.

Nincs ilyen, hogy "right alt", csak egy shortcut a Ctrl Alt-ra, szóval felejtsd el.

Igen, és ennek állítólag történelmi okai vannak. Valószínûleg valami olyasmi lesz a megoldás, hogy amikor VK_CONTROL érkezik, akkor GetKeyAkármivel megnézem, hogy a right alt (aka AltGr) le van-e nyomva, és ha igen, akkor "elnyelem" az üzenetet.

Én úgy tudom, nem, mivel nincs AltGr gomb (ahogy én tudom), és ezért muszáj így lennie. Sõt, ha lenyomod a bill-en, a Ctrl, és Alt gombot, akkor ugyan azt kapod mintha az AltGr-t nyomnád. Én legalábbis így tudom.

Nincs WinAPI topic, szóval ide:
Megvan a keydown/keyup detektálás, csak amikor "Alt Gr"-t, avagy Right Altot, avagy WinAPI-ban VK_RMENU-t nyomok, akkor elõtte küld egy VK_LCONTROL-t is, mivel AltGr = Alt+Ctrl.
Ki lehetne ezt valahogy kerülni? Az a baj, hogy elõször jön a Ctrl, és utána az Alt.

A következõ megoldással megspórolod a static_cast-ot, de nem ugyanazzal a névvel fogsz hivatkozni a típusra és az enumra.

A szebb megoldás az, hogy ilyet nem csinálsz... Nem erre való az enum.

@Asylum:
Igen, én is oda szoktam írni a "= 0"-t, csak most itt lemaradt.

Továbbá azt is tudom, h lehet használni static_cast-ot, de nem ez volt a kérdés. Nem az enum i. elemét akarom elérni, hanem az enum i. eleméhez képest vett k. elemet (ahol az i nem egy szám, hanem az enum egy adott értéke). Ahogy azt lentebb írtam:

Csak ez nyilván nem C-style casttal, hanem static_cast-okkal. Engem az érdekelt, hogy van-e ennél szebb megoldás, nem az, hogy ez valid-e, vagy sem. De azért köszi

@Matzi:
Hm, ez egész tetszetõs ötlet, egyelõre ott rondálkodik az a pár static cast, de ha még néhányszor kell, akkor tuti írok én is valami hasonlót.

Az enum egy speciális állatfaj, mivel semmi sem garantálja, hogy folytonos a tartomány amit lefednek. Én erre a cégnél, amikor sok enumunk volt mindig 0 és NUM elem kozott, akkor írtam egy iterátor osztályt, ami egyszerre volt int (vagy valami underlying type) meg a num, és azt adta vissza, amlyiket kellett. Pluszban lehetett inkrementálni. A vége valami ilyesmi lett:



Ha kell kuldok kódot, de elég egyszeru.

Az otthoni enginemben meg egy statikus tárba be lehet tolni az elemeket meg a nevuket egyesével. A hatránya, hogy statikus inicializációt igényel, de nem folytonos range-eket is kezel, plusz string nevet, ami hasznos ha ki kell írni fileba.

Elõször is:



különben a fordító vad dolgokat csinálhat. Egyékbként meg a szabvány leírja, hogy static_cast használható enumokra.

Ha van egy enum classom, például:

Meg egy for ciklusom is [0, 3), akkor hogy lehet a legszebben elérni az adott elemet? Mivel nem szeretem a C-style castokat c++ban, így mindig kiírom a static_cast-ot, így viszont elég csúnya lesz:

A "standard" enumokkal ugye mûködik az egyszerû összeadás, de mivel ez erõsen típusos, így azt nem engedi meg...

Ha idõt akarsz spórolni, akkor használhatod az ICU-t:

http://site.icu-project.org/

Az UTF-8-ról tudom, hogy változó szélességû, de pl. az UTF-16 már fix. Nemrég pedig ezt olvastam, ahol beszél errõl egy picit.

Igazából eleve használhatnék 2 byte-os "karaktereket", igazából egy minimális memóriapazarlás csak a hátránya. No meg ugye a blogon emlegetett byte ordering is, de ha saját magamnak kezelem, akkor úgysincs belõle gond.

Egyébként itt van a videó az általad linkelt pdf-hez.

szerk.:
Most olvasom csak, hogy az UTF-16 is változó hosszúságú. Még jó, hogy az egyetemen hülyeséget tanítanak.

Ezt olvasd el mindenképp. Pl mert az UTF eleve nem fix szélességu, amit sokan nem tudnak.
Egyébként meg a font renderelés más téma, ott be szokták gyujteni a lokalizációs fájlokból a szimbólumokat és valamilyen formában kirenderelni egy textúrába.

UTF8

win-en ebbõl MultiByteToWideChar() és ki tudod rajzolni.

Csináltam egy alap localization systemet, ami egyelõre semmi extra, csak egy kulcs alapján megkapok egy stringet, amelyet a jelenleg betöltött localization file határoz meg.

A problémám csak annyi, hogy ez jól mûködik minden olyan nyelvre, amelynek a karakterkészlete belefér 1 byte-ba, mert a betöltött szövegeket std::string-ként tárolom, amely viszont nem lesz jó például a japán nyelvre (kivéve a romanji, katakana, hiragana írásokat), hiszen a kanji sok ezer szimbólumból áll.

A gond például ott kezdõdik, hogy kell egy másik karakterábrázolás (2 byte már úgy gondolom elég lenne, 2^16=65536 különbözõ karakter), valamilyen Unicode dologgal. Érdemes csinálni egy saját "stringet", amely ezeket is tudja tárolni? Ott van a varchar, de arról azt olvastam, h compiler függõ, hogy végül mekkora lesz a mérete.

Továbbá felmerül a gond az ingame text rendereléssel, ahol szintén valahogy társítani kell az adott textúrakoordinátákhoz a megfelelõ szimbólumokat, de ez már másik topic lesz.

Sziasztok!
World of Warcraft: Warlords of Draenor szerverhez csinálásához keresek embereket. Jelenleg 5en vagyunk(a wow részlegen), a munkálatokat már elkezdtük, átlag életkor 21+ A csapat teljesen komolyan gondolja amit csinál, amúgy egy "Multigaming" vagyunk, és jó pár játékhoz csinálunk szervereket (Minecraft, GTA5, WoW, ArmA 3 stb...) Saját szervergépekkel, és hozzáértõ emberekkel. akit érdekel a dolog az keressen bátran, Aki úgy gondolja hogy van elég ideje és sokat tud foglalkozni a dologgal, annak egy csekély havi szintü fizetést fel tudok ajánlani, nem valami nagy összeg(20-35k ft) de a semminél jobb. Természetesen a szerver beindulása után részesedést jár a bevételbõl

Amilyen tudású emberekre szükség van:
C++
C#
Visual Studio ismerete
MySQL és Scriptelés
TrinityCore ismerete nem hátrány, de nem is kötelezõ

Ha érdekel keress meg privát üzenetbe, Skypeon (raptor212) emailen:xsm023@gmail.com vagy TS3 szerverünkön: aviorgaming.com (Brendon néven találtok meg)

Igen, tudom, hogy mi a diamond megoldása, viszont inkább annak az elkerülése érdekelt.

Nem igazán értem viszont a feltevésedet. Viszont (ha jól értem), nem szeretem a túlzottan vegyes osztályokat, inkább maradjon csak meg külön-külön. Ha nincs külön vertex- és index buffer, akkor nagyon jó, mert ugyan azt az osztályt lehet példányosítani, és kész. Ráadásul ez az egész így csak annyit mond meg, hogy van egy olyan osztály, ami úgy viselkedik, mint egy vertex buffer. Hogy ez konkrétan hogy van implementálva, az aztán tökre nem érdekes a magas szinten. Ennyi nekem elég is.

Megint rossz megközelítés. Ne absztrahálj low level dolgokat, mert újabb apikban nincs is vertexbuffer (csak buffer). De említhetném a GL 4-es shader storage buffert is. Vastag réteget csinálj és azt specializáld (GLMesh, DXMesh, stb.).

diamond problemre meg olvasd el az öröklõdésrõl szóló cikkemet (virtuális öröklés a megoldás).

Milyen patternnel lehetne szépen megoldani az alábbit?

Van egy BufferObject osztály, ami a vertex- és index bufferek közös tulajdonságait, mûveleteit tartalmazza. Ebbõl öröklõdik maga a VertexBuffer és IndexBuffer osztály, ami kiegészíti a saját funkcionalitásával.

Ebbõl a kettõbõl öröklõdik az API-specifikus osztály (pl. OGLVertexBuffer). itt jön a problémám: az OpenGL szintjén a két osztály kb. csak egy enumban tér el, azaz jó lenne, ha közös õsük lenne. Ekkor viszont el is jutottam a "diamond inheritance" problémáig.

Egyetlen megoldásként egyelõre azt találtam ki, hogy van egy OGLBufferObject osztály is, ami az OpenGL szinten közös dolgokat tartalmazza, továbbá ugyan úgy megvan az OGLVertexBuffer és OGLIndexBuffer osztály is, ami implementálja a pure virtual függvényt, ami csak meghívja a megfelelõ enummal az OGLBufferObject egy függvényét. Na szóval valami ilyesmi (természetesen ez csak vázlat, de a lényeg benne van)

Van-e esetleg erre valami okosabb megoldás, vagy "jóezígy"?

szerk.:
Ja igen, a Vertex- és IndexBuffer osztályoknak a BufferObject osztályból kell öröklõdniük, mert használják annak bizonyos függvényét/függvényeit.

Szóval, ha az ember dynamic libet akar használni, akkor implementáljon saját containereket? Esetleg változott ez a dll-export dolog a 11-es szabvánnyal?

Nem viszem túlzásba, nagyon sok csúnya dolgot láttam abban a kódban. Például nagyon sok globális változójuk van, nem használt, csúnyán rendszerezett kód, hatalmas (néha több ezer soros) függvények, stb. Viszont miután megfejtek egy adott részt, vannak benne jó ötletek, azokat adaptálom, és a saját számíze szerint megvalósítom, ha megtetszett.

Azért ne vidd túlzásba ezt az UE4 majmolást...a globális változók nem thread safe-ek, késõbb nagy szopás lehet belõle.

Na megint jövök a furcsaságaimmal. Böngészve az UE4 forráskódját, megtetszett ez a moduláris felépítés, viszont van néhány dolog, amit statikusan szeretnék linkelni. És hogy LoadModule() esetén ne keresse a dll-t, így valahogy be kell a managernek regisztrálni, hogy ez a modul bizony egy statikusan linkelt modul.

Erre volt benne egy jó ötlet, készítettek a regisztráló osztályt, ami a konstruktorában meghívja a manager megfelelõ függvényét. Röviden valami ilyesmi:

Az adott modul implementációjakor pedig egy makró segítségével készítenek ebbõl egy static objektumot, ami elvileg beregisztrálná. Ez ugye az adott modul egy cpp file-jába kerül.

Na most a problémám itt következik. Lebuildeltem static libként, hozzálinkeltem a másikhoz, viszont ez a változó nem inicializálódik.

Gondolom valahol (valószínûleg linkeléskor) eldobta, mert nem hivatkozik rá senki. Az UE4 kódjában (Runtime/Core/Public/Modules/ModuleManager.h) van is a makróban egy erre hivatkozó rész:

Viszont azt nem találom meg, hogy erre ki hivatkozik.

Különösebb build-toolok és automatikus kódgenerálás kifejlesztése nélkül van-e lehetõség valahogy inicializálni azt a változót?

szerk.:
Ok, mágikus módon megjavult, egyetlen linker beállítással a futtatható programon:

Viszont észnél kell lenni, meg kell majd nézni (egyszer), hogy g++al milyen eredmény születik.

szerk. 2:
Ja értem! Azért javult meg, mert ezzel az opcióval nem magát a libet, hanem az objecteket linkeli a programhoz?

szerk. 3:
Igen, megtaláltam, itt egy bejegyzés errõl.

Lentebbi példához kapcsolódóan:

Véleményem szerint ennek mennie kellene:

Viszont abban az esetben is írja a hibaüzenetet, ha a T-nek van GetType függvénye. Azonban, ha kicsit megcsavarom a dolgot, és a címével próbálkozok, akkor megjavul:

Viszont az rtti-t perf miatt kikapcsolni oltari hulyeseg. A 90-es evekbol visszamaradt rossz szokas. nem ezen fog mulni a 60 fps, leszamitva azt az esetet, ha mocsokszar compilert hasznalsz.

Egyébként egy ilyen értéket jelenleg is használok megkülönböztetésre, de eddig eszembe nem jutott volna az, hogy virtuális függvényt használjak.

Jelenleg egyébként egy elég hacky megoldást használok. Van egy define-om, ami definiál egy egyszerû static függvényt, ami visszatér egy 32 bites integerrel, magával a függvény címével.

Ahol a Component::Type egy uint32 define (hogy késõbb akár uint64-re is lecserélhetõ legyen).

Illetve magát a component hozzáadását egy template függvénnyel csinálom, így könnyen el is tudom tárolni az adott példányhoz tartozó típust is, innentõl kezdve pedig mûködhet a virtual függvényes dolog.

Az enummal meg valóban csak annyi a baj, hogy elõre tudni kell, hogy milyen gyerekek lesznek pontosan.

Köszi a hozzászólásokat.

Ez lehet hogy egyszerûbb, de nem jól alkalmazható több lépcsõs öröklés esetén, illetve a parentnek elõre kell tudnia minden gyerekosztályról. Az én változatomban elvileg bármikor utólag is bõvíthetõ, anélkül, hogy hozzá kellene nyúlni a meglévõkhöz.
Persze, ha csak az egyszerûség számít, akkor az enum is elég, ráadásul nincs benne virtuális függvény, ami spórolhat egy vtable-t.

Egyszerûbb ha:



Az idtech4 ezt egyetlen makróval oldja meg ami minden osztály elején ott van (és nincs beleégetve az enum).