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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    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] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [141]
Parallax - Tag | 574 hsz       Online status #210613   2016.12.09 08:59 GMT+1 óra  
A c-hez legalább könnyebb interpretert írni. Persze azért kicsit elkésett azon filózni, hogy rossze e a C++ OOP, amikor a motorokat már C#-al, meg JavaScript-el írják. Több gyakorlat és tapasztalat kell a C++ és OOP használatához ez tény, de teljesen elvetni azért egy nagy architektúránál szerintem öngyilkosság.

   
Geri - Törzstag | 2186 hsz       Online status #210611   2016.12.09 01:12 GMT+1 óra  
instalok: hát ez még így is c++ és oop, csak leveszi a hangsúlyt a manapság divatos kényszeredett osztályképzésről.

mivel én ellene vagyok az oopnek, és egyáltalán nem is használom, mondhatnám ebből kifolyólag azt, hogy ez így jó. de persze nem mondom, mert nem jó, hisz mert mi értelme oopt használni úgy, hogy közben nem is használjuk, de mégis oop-vel fertőzött marad az egész kód, ráadásul feleslegesen?

ha valaki szakítani az oopvel, akkor szakítson vele rendesen, ez a félmegoldás, amit az emberke itt reklámoz, szerintem inkább tanuljon meg hatékonyan dolgozni C99-ben, minthogy oop szintaxissal akarjon procedurálisan programozni.

persze tudok oopzni is, csak épp nem szoktam, és elnézve ezeknek a kényszeredett oop-c++ usereknek a kódját azt látom, hogy az emberek 99%-a egyszerűen nem jól használja az oopt. egy objektumorientált kód az egész egyszerűen nem úgy néz ki, és általában ezekből az overlyobjectoriented dolgokból nem lesz soha semmi, csak javíthatatlan katyvasz, aminek a fejlesztési ideje a normális tízszerese. valahogy ezek az emberek úgy gondolják, hogyha létezik valamilyen nyelvi elem, akkor azt ki kell használni, mert csak. ha törik, ha szakad, csak épp utána senki más nem képes a kódot átlátni, csak ők.

pl:
Idézet
struct Vector3 {
float x, y, z;
};

template <class T>
class Array<T> {
public:
Array() : _capacity(0), _size(0), _data(0) {}
~Array() {free(_data);}
unsigned _capacity;
unsigned _size;
T *_data;
};



pl mi a halál fasza ez? normális ember, aki megírni, dolgozni, eladni, és hónapok múlva is megérteni szeretne valamit, ilyen kódot soha a büdös életben nem ír le, egy normálisan megírt oop forráskód mégcsak közelről sem így néz ki. így programozni nem lehet, nem szabad.

aki ilyet leír, az egy mentális pótcselekvést csinál. addig sem kell a probléma érdemi részével dolgoznia, de legalább leírt valami bonyolultnak tűnő, semmire sem jó zagyvaságot, és ezt pszichológiai faktornak használva beadja magának, hogy fú de jól halad, meg minden faszom, közben meg nem, mert amíg ezt írta, addig sem csinált semmit, nem a programját írta, és ez alább ki is derül.

nem tudom, hogy ki a csávó, meg hogy mit ír, de a blogja alapján 3d-t, a frustum cullingról lamentál, de nem arról, hogy milyen módszerrel érdemes megcsinálnia, hanem látszik, hogy a csávó magával az implementálással küzd, amelyet mármár krőzus kincseként szeretne implementálni és elmaszkolni valahogy az eléggé hasznavehetetlen kódolási stílusához illesztve. látszik, hogy a normális esetben 20-30- de maximum 40-50 soros problémának csak a keretezése már önmagában egy blogbejegyzés szintű bonyolultságú dologgá eszkalálódik (nekem ez a feladat a régi enginemben összesen konkrétan 5 sor volt, amiben egy függvényhívás volt, ami 5 soros volt, amiben mégegy függvényhívás volt, ami 2 soros volt).

így programozni, dolgozni nem lehet, amikkel küzd, nem nagy bonyolultságú problémák, de ő azzá teszi őket.

szerintem ez a blog azt példázza, hogy hogyan nem lehet dolgozni.

Ezt a hozzászólást Geri módosította (2016.12.09 01:40 GMT+1 óra, 223 nap)

   
Instalok - Tag | 530 hsz       Online status #210610   2016.12.08 23:27 GMT+1 óra  
Erről egyébként mit gondoltok? Nekem ez a megoldás kvázi a c++ és az egész OOP kidobása a kukába. Persze van benne logika, de ezek a dolgok nem véletlenül lettek kitalálva. Amiről írt, az igazából a pure C, pluszplusz nélkül.

   
Parallax - Tag | 574 hsz       Online status #210606   2016.12.07 07:48 GMT+1 óra  
@Instalok: Jó hát a pofa már átesett a ló túlsó oldalára és mindent wrapperelt olyat is, amit 2 primitív paraméterrel meg lehet oldani GC nélkül is. Így aztán csodálkozik, hogy kismilliom Lua object miatt teker a GC. A script csak event alapú vezérlésre való ("blueprint"-ek vezérlésére), nem arra, hogy a fél engine-t kiwrappereljük, aztán azzal írjunk egy nagy update ciklusba mindent.

A másik, hogy nem biztos, hogy mindig egyedül fogsz dolgozni és C++ coder már olyan, mint a fehér holló és aranyrudat kér napi fizetésnek, míg egy scriptelő minden bokorban terem fillérekért.

Nekem bejön ez a módszer, mert egyébként az editornak ígyis-úgyis wrapperelni kell bizonyos C++ osztályokat, hogy lehessen szerkeszteni, akkor meg már miért ne csináljam rendesen komplett script rendszerrel. Sima confighoz pedig table-vel meg lehet oldani az olvasás/mentés funkciót is, így editorban az egyszerűbb beállításokat is külön erőfeszítés nélkül lehet egy scaffold controllal kezelni.

Ezt a hozzászólást Parallax módosította (2016.12.07 07:56 GMT+1 óra, 225 nap)

   
ddbwo - Tag | 1625 hsz       Online status #210603   2016.12.05 21:49 GMT+1 óra  
Idézet
proof88 :
Az ablak üzenetkezelő függvényében le tudod kezelni.
WM_SYSCOMMAND, SC_MONITORPOWER, ezekre keress rá.



Köszi, működik.
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
   
proof88 - Törzstag | 528 hsz       Online status #210601   2016.12.05 16:58 GMT+1 óra  
Az ablak üzenetkezelő függvényében le tudod kezelni.
WM_SYSCOMMAND, SC_MONITORPOWER, ezekre keress rá.
   
ddbwo - Tag | 1625 hsz       Online status #210600   2016.12.05 15:04 GMT+1 óra  
Hogy lehet megoldani, hogy a win input nélkül ne kapcsolja ki a monitort amikor ablakban fut a program? Még rajzol is, meg minden, mégis kikapcsol a monitor.
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
   
Instalok - Tag | 530 hsz       Online status #210599   2016.12.05 14:24 GMT+1 óra  
Érdekes, pont tőle olvastam a múltkor valamit. Ennek a gamedev topicnak az alján ajánlotta valaki.

Látszik azért az is, hogy a Lua felvet néhány problémát is, amellett, hogy megold néhány másikat. Egyébként a pointerezgetés elkerülhető c++11 óta, a smart pointerek egész jók tudnak lenni, tulajdonképpen ugyan ott van vele az ember, mint c# esetén. Persze minden ízlés kérdése, évekkel ezelőtt is nézegettem a Lua-t, akkor nem igazán nyerte meg a tetszésemet, persze én nem is vagyok gameplay programmer.

   
Parallax - Tag | 574 hsz       Online status #210595   2016.12.05 10:07 GMT+1 óra  
@Instalok
Az editorra, mint külön fejlesztői eszközre gondoltam, ahol mehet a scriptelés,. scene szerkesztés, debug, stb. Igazából a játék logika sebesség intenzív részeket nem tartalmaz, így nagy jelentősége nincs annak a kis sebesség vesztésnek, amit mondjuk egy PlayMusic fgv hívás okozhat a wrapperen keresztül. Ha nagyon kell a sebesség még mindig ott van a LuaJit. Mivel a nyelv olyan egyszerű, mint a faék, azért nem olyan túl bonyolult annak a futtatása sem.

C++ scripttel próbálkoztam én is, de az már annyira összetett nyelv, hogy ahhoz futtatót írni 100%-ban azért kemény dió, teljes megoldás ehhez nem hiszem, hogy lesz. A másik, hogy játék logika szintjén én már nem akarok a pointerekkel, template-ekkel, meg egyebekkel vacakolni, csak gyorsan, produktívan dolgozni egy magas szintű API-val/nyelvvel és erre az ilyen dinamikus scriptek sokkal jobbak.

Még egy érdekesség:
Lua in the Stingray 3D game engine:


Egy próbát megér ez is, meg a te módszered is, aztán meglátod, hogy hosszútávon, amikor az engine-el több játékot is kell fejleszteni, több platformra is, melyik módszer a hatékonyabb.

   
Instalok - Tag | 530 hsz       Online status #210592   2016.12.05 08:40 GMT+1 óra  
@Parallax:
Ja hogy az az ablak nem egy külön alkalmazás, hanem az editor által megnyitott ablak.

Igen, a VS edit & continue nem az igazi, általában nem is erőltetem, ha ilyesmi van. Az lenne az előnye amúgy a c++ scriptnek, hogy release módban nyilván nem dll készülne belőle, hanem összelinkelődne azzal a kóddal, ami egy alkamazást indít el, így a lehető legnagyobb teljesítményt tudná adni, míg egy Lua esetén az interpretálás és extra függvényhívások mindig lassítanak.

Amit egyébként néztem még az a Runtime-Compiled-C++, ami egy egész jó ötlet egyébként. Megnézem azért majd a Lua-t is, köszi a tippet meg a videót!

   
ddbwo - Tag | 1625 hsz       Online status #210582   2016.12.03 08:18 GMT+1 óra  
Elveszett a mozgó aabb vágása polygonba programom (fogalmam sincs hogy hívját, de a lényeg, hogy belevágja az aabb-t a poligonba a mozgás iránya szerint és ráilleszti a legközelebbi pontra), tud valaki egy jó anyagot hozzá, hogy ne kelljen kikísérletezni? A válasz (vagyis a mozgatás) is fontos lenne, azzal voltak gondjaim egyszer.

u.i: nem intersection, hanem tulképp rávetíti az aabb-t a polyra.
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
   
Parallax - Tag | 574 hsz       Online status #210580   2016.12.03 00:47 GMT+1 óra  
Scene módosítása pause közben az editorral nem értem miért lenne probléma, ugyanúgy módosul, mint ahogy játék közben módosulnak az elemek, párhuzamosan pedig, hogy ezt hova és hogy mented már független ettől. A Lua pedig sokkal dinamikusabb és egyszerűbb, mint a C#, szóval ami Unity-vel megoldható az Lua-val egyszerűbben megoldható. Többek között a futás közbeni módosítás/kód újratöltés az egyik erőssége, ami miatt érdemes használni. (pl az angelscript ilyet nem tud, a C# is csak korlátozottan).

Ez lényegében ugyanaz, mint, amit te írsz, csak itt a Lua kód és scene file módosul és fordítódik párhuzamosan, te meg egy DLL-t fordítgatsz és töltesz be. Annyival rugalmasabb a Lua, hogy ott bármit meg lehet nézni és módosítani, míg a DLL-nél csak azt, amire az editor rálát, közben pedig a fordítgatás, újratöltögetés sokkal nagyobb időveszteség, mint egy script esetén. Akkor már egyszerűbb.ha a VisualStudio edit and continue-val futás közben átírod a C++ kódot, de persze ez is korlátozottabb, mint egy script. A C++ amúgy se erre lett kitalálva, szerintem scriptelésre scriptet kell használni.

   
Instalok - Tag | 530 hsz       Online status #210579   2016.12.02 11:59 GMT+1 óra  
@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.

   
Parallax - Tag | 574 hsz       Online status #210577   2016.12.02 00:11 GMT+1 óra  
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.

   
Instalok - Tag | 530 hsz       Online status #210446   2016.10.26 20:53 GMT+1 óra  
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:
Kód:
// If we're linking monolithically we assume all modules are linked in with the main binary.
#define IMPLEMENT_MODULE( ModuleImplClass, ModuleName ) \
    /** Global registrant object for this module when linked statically */ \
    static FStaticallyLinkedModuleRegistrant< ModuleImplClass > ModuleRegistrant##ModuleName( #ModuleName ); \
    /** Implement an empty function so that if this module is built as a statically linked lib, */ \
    /** static initialization for this lib can be forced by referencing this symbol */ \
    void EmptyLinkFunctionForStaticInitialization##ModuleName(){} \
    PER_MODULE_BOILERPLATE_ANYLINK(ModuleImplClass, ModuleName)


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:
Kód:
class ServiceA
{
public:
    virtual void foo()
    {
        if (impl)
            impl->foo();
    }

private:
    ServiceA* impl;
};

class ServiceAImpl : public ServiceA
{
public:
    void foo() override
    {
        ServiceA::foo(); // inf loop
    }
};

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.

Ezt a hozzászólást Instalok módosította (2016.10.26 21:03 GMT+1 óra, 266 nap)

   
Prenex - Tag | 14 hsz       Online status #210443   2016.10.26 18:48 GMT+1 óra  
@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 :-)

Ezt a hozzászólást Prenex módosította (2016.10.26 18:55 GMT+1 óra, 266 nap)

   
Instalok - Tag | 530 hsz       Online status #210441   2016.10.26 10:23 GMT+1 óra  
@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.

   
Prenex - Tag | 14 hsz       Online status #210439   2016.10.26 06:49 GMT+1 óra  
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 ;-)

   
Parallax - Tag | 574 hsz       Online status #209940   2016.08.01 07:46 GMT+1 óra  
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.

Ezt a hozzászólást Parallax módosította (2016.08.01 07:52 GMT+1 óra, 353 nap)

   
Instalok - Tag | 530 hsz       Online status #209939   2016.08.01 06:59 GMT+1 óra  
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.

   
syam - Törzstag | 1491 hsz       Online status #209938   2016.07.31 23:18 GMT+1 óra  
Egy ésszerű határt érdemes meghúzni a drag&drop és a szövegszerkesztő között
alias aalberik
   
Instalok - Tag | 530 hsz       Online status #209937   2016.07.31 23:06 GMT+1 óra  
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.

   
syam - Törzstag | 1491 hsz       Online status #209936   2016.07.31 22:57 GMT+1 óra  
Én simán luából engedem rommá scriptelni az enginemet, editoromat és a guimat.
alias aalberik
   
Instalok - Tag | 530 hsz       Online status #209934   2016.07.31 10:37 GMT+1 óra  
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.

   
Instalok - Tag | 530 hsz       Online status #209700   2016.05.31 14:10 GMT+1 óra  
Í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.

   
Matzi - Szerkesztő | 2519 hsz       Online status #209699   2016.05.31 13:51 GMT+1 óra  
Úgy lesz egy dll ahogyan egy exe. Egyszeruen a projektek nagy része lib-be fordul, a dll meg azokat beépíti.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Elodin - Tag | 171 hsz       Online status #209698   2016.05.31 13:49 GMT+1 óra  
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.

   
Instalok - Tag | 530 hsz       Online status #209697   2016.05.31 13:34 GMT+1 óra  
Hogy lesz a halom projektből egyetlen dll?

   
Elodin - Tag | 171 hsz       Online status #209696   2016.05.31 13:29 GMT+1 óra  
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?

   
Instalok - Tag | 530 hsz       Online status #209618   2016.05.18 16:26 GMT+1 óra  
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.

   
Asylum - Törzstag | 5440 hsz       Online status #209615   2016.05.18 13:28 GMT+1 óra  
Kód:
template <typename T>
class QuadTree
{
    // ...
};


Így.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #209614   2016.05.18 10:46 GMT+1 óra  
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.

Ezt a hozzászólást Instalok módosította (2016.05.18 10:54 GMT+1 óra, 428 nap)

   
Tunyu - Tag | 444 hsz       Online status #209555   2016.05.06 20:01 GMT+1 óra  
Nézd meg ezt, talán van benne vmi használható.

   
Instalok - Tag | 530 hsz       Online status #209554   2016.05.06 14:43 GMT+1 óra  
Az értelmesebb játékok kezelik a RightAlt-ot, mint billentyűt, szóval nem, nem felejtem el.

   
Asylum - Törzstag | 5440 hsz       Online status #209552   2016.05.06 12:35 GMT+1 óra  
Nincs ilyen, hogy "right alt", csak egy shortcut a Ctrl Alt-ra, szóval felejtsd el.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #209528   2016.04.29 11:01 GMT+1 óra  
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.

   
peti634 - Tag | 148 hsz       Online status #209527   2016.04.29 07:59 GMT+1 óra  
É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.
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Instalok - Tag | 530 hsz       Online status #209526   2016.04.28 19:00 GMT+1 óra  
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.

   
Eldor - Tag | 162 hsz       Online status #209477   2016.04.18 19:36 GMT+1 óra  
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.

Kód:
namespace EnumName
{
enum
{
    E0 = 0,
    E1,
    E2,
}
}

typedef int EnumName_t;

   
Asylum - Törzstag | 5440 hsz       Online status #209476   2016.04.18 12:48 GMT+1 óra  
A szebb megoldás az, hogy ilyet nem csinálsz... Nem erre való az enum.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #209475   2016.04.18 12:44 GMT+1 óra  
@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:
Kód:
Enum::Data + k
-->
(int)Enum::Data + k
-->
(Enum)((int)Enum::Data + k);

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.

   
Matzi - Szerkesztő | 2519 hsz       Online status #209472   2016.04.18 11:24 GMT+1 óra  
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:

Kód:
for (auto elem : Enumerator<EnumType>())
{
  // Implicit cast to both types
  int a = elem;
  EnumType b = elem;
}


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.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5440 hsz       Online status #209471   2016.04.18 11:23 GMT+1 óra  
Először is:

Kód:
Blah = 0


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.

Kód:
TheEnum nthelem = static_cast<TheEnum >(n);
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #209467   2016.04.18 09:22 GMT+1 óra  
Ha van egy enum classom, például:
Kód:
enum class
{
    Blah,
    BlahBlah,
    Data0,
    Data1,
    Data2
}

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:
Kód:
for (uint32 i = 0; i < 3; ++i)
{
    const TheEnum theVal = static_cast<TheEnum>(static_cast<uint32>(TheEnum::Data0) + i);
}

A "standard" enumokkal ugye működik az egyszerű összeadás, de mivel ez erősen típusos, így azt nem engedi meg...
Kód:
const TheEnum theVal = TheEnum::Data0 + i;

   
Asylum - Törzstag | 5440 hsz       Online status #209180   2016.03.12 22:02 GMT+1 óra  
Ha időt akarsz spórolni, akkor használhatod az ICU-t:

http://site.icu-project.org/
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #209179   2016.03.12 20:42 GMT+1 óra  
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 a hozzászólást Instalok módosította (2016.03.12 21:16 GMT+1 óra, 494 nap)

   
Matzi - Szerkesztő | 2519 hsz       Online status #209177   2016.03.12 19:09 GMT+1 óra  
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.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5440 hsz       Online status #209174   2016.03.12 10:42 GMT+1 óra  
UTF8

win-en ebből MultiByteToWideChar() és ki tudod rajzolni.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #209173   2016.03.12 07:53 GMT+1 óra  
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.

   
Sliden - Tag | 3 hsz       Online status #209128   2016.03.02 12:27 GMT+1 óra  
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)

Ezt a hozzászólást Sliden módosította (2016.03.03 15:41 GMT+1 óra, 503 nap)

   
Frissebbek | Korábbi postok
[1] > 2 < [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [141]