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] [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]
Instalok - Tag | 540 hsz       Online status #208966   2016.01.13 22:52 GMT+1 óra  
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.

   
Asylum - Törzstag | 5444 hsz       Online status #208965   2016.01.13 18:02 GMT+1 óra  
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).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 540 hsz       Online status #208963   2016.01.13 12:45 GMT+1 óra  
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)
Kód:
class BufferObject
{
    // .... közös dolgok

    // implementálandó függvény
    virtual void Upload(offset, size) = 0;
};

class VertexBuffer : public BufferObject
{
    // ... kiegészítések
};

class IndexBuffer : public BufferObject
{
    // ... kiegészítések
};

class OGLBufferObject
{
public:
    uint32 GetId() const
    {
        return id;
    }

protected:
    void OGLUpload(target, maxsize, offset, size, data)
    {
        if (!id)
        {
            // ... create buffer (<-- target)
        }
        else
        {
            // ... bind buffer (<-- target)
        }
       
        // ... fill data (<-- target)
    }
   
private:
    uint32 id;
};

class OGLVertexBuffer : public VertexBuffer, public OGLBufferObject
{
    void Upload(offset, size) override
    {
        OGLUpload(GL_ARRAY_BUFFER, GetMaxSize(), offset, size, GetData());
    }
};

class OGLIndexBuffer : public VertexBuffer, public OGLBufferObject
{
    void Upload(offset, size) override
    {
        OGLUpload(GL_ELEMENT_ARRAY_BUFFER, GetMaxSize(), offset, size, GetData());
    }
};

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.

   
Instalok - Tag | 540 hsz       Online status #208819   2015.12.19 14:11 GMT+1 óra  
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?

   
Instalok - Tag | 540 hsz       Online status #208814   2015.12.16 22:36 GMT+1 óra  
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.

   
Asylum - Törzstag | 5444 hsz       Online status #208813   2015.12.16 21:47 GMT+1 óra  
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.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 540 hsz       Online status #208812   2015.12.16 18:57 GMT+1 óra  
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:
Kód:
template <class M>
class Register
{
    Register() { Manager::Get().RegisterStatic(&Register<M>::InitializeModule);

    M* InitializeModule() { return new M(); }
};

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.
Kód:
static Register<MyModule> registerForMyModule;

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:
Kód:
// [...]
/** 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(){} \
// [...]

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:
Kód:
Use Library Dependency Inputs -> true

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.

Ezt a hozzászólást Instalok módosította (2015.12.16 20:24 GMT+1 óra, 675 nap)

   
Instalok - Tag | 540 hsz       Online status #208687   2015.11.25 11:54 GMT+1 óra  
Lentebbi példához kapcsolódóan:

Véleményem szerint ennek mennie kellene:
Kód:
static_assert(std::is_function<decltype(T::GetType)>::value, "Not a COMPONENT_GROUP");

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:
Kód:
static_assert(std::is_function<typename std::remove_pointer<decltype(&T::GetType)>::type>::value, "Not a COMPONENT_GROUP");

Ezt a hozzászólást Instalok módosította (2015.11.25 12:13 GMT+1 óra, 696 nap)

   
zeller - Törzstag | 464 hsz       Online status #208684   2015.11.24 09:33 GMT+1 óra  
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.

   
Instalok - Tag | 540 hsz       Online status #208683   2015.11.23 17:54 GMT+1 óra  
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.
Kód:
#define COMPONENT_GROUP()\
public:\
    inline static Component::Type GetType() { return reinterpret_cast<Component::Type>(&GetType); }

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.

   
Matzi - Szerkesztő | 2519 hsz       Online status #208681   2015.11.23 16:17 GMT+1 óra  
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.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5444 hsz       Online status #208680   2015.11.23 14:19 GMT+1 óra  
Egyszerűbb ha:

Kód:
class ParentClass
{
public:
    enum Types { ChildType1, ChildType2 };

    inline Types GetType () const { return mytype; }

protected:
    ParentClass (Types type) { mytype = type; }

private:
    Types mytype;
};


Az idtech4 ezt egyetlen makróval oldja meg ami minden osztály elején ott van (és nincs beleégetve az enum).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2519 hsz       Online status #208678   2015.11.23 10:24 GMT+1 óra  
Szerintem is felesleges egyetlen egy típusvizsgálatért bekapcsolni az egész RTTI-t. A legtöbb esetben úgyis kb arra leszel kíváncsi, hogy egy Parent pointer az A vagy a B gyerekre mutat e. Mivel közös az ős, egy virtuális függvényhívással meg tudod oldani. Kicsit macera (bár csinálhatsz rá egy makrót), de elég gyors és biztonságos. Ennél több elég ritkán kell.

Kód:
class Parent {
  static const UID TypeID = 1;
  virtual bool IsType(UID type) const { return TypeID == id; }
}

class ChildA : public Parent {
  static const UID TypeID = 2;
  virtual bool IsType(UID type) const override
    { return TypeID == id || Parent::IsType(type); }
}

class ChildB : public Parent {
  static const UID TypeID = 3;
  virtual bool IsType(UID type) const override
    { return TypeID == id || Parent::IsType(type); }
}

....

Parent* valami = ...;
if (valami->IsType(ChildA::TypeID))
{
...
}


Értelemszerűen az UID típust értelmezheted aminek csak szeretnéd, akár stringnek is, bár az lassúcska. Mi például string hashekkel dolgozunk, ami kód írásakor offline számítható, és commenben odaírod, hogy mi az eredetije, vagy csinálsz egy konstanst valahol ugyanazzal a névvel, amiből a hash számolódott. Van ugyan egy kicsi esély az ütközésre, de az kb nulla.
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 #208677   2015.11.23 10:04 GMT+1 óra  
Jo, igaz (runtime-t akartam irni, csak hulye vagyok), a lenyeg, hogy nem tamogatott. Nem vagyok benne biztos, hogy a java miatt, de az android dokumentacio explicit emliti, hogy felejtsd el.

   
Asylum - Törzstag | 5444 hsz       Online status #208676   2015.11.23 09:53 GMT+1 óra  
Ez nem a compiler hibája hanem a java-é...úgy tölti be a dll-eket, hogy nem publikálja az rtti-t, innen jön ez a hiba. A compilerrel semmi baj nincs.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
zeller - Törzstag | 464 hsz       Online status #208675   2015.11.23 09:40 GMT+1 óra  
az android nem tamogatott platform a c++ szamara szvsz. rendes szamitogepeken van rendes compiler.

   
syam - Törzstag | 1491 hsz       Online status #208674   2015.11.23 09:34 GMT+1 óra  
Én "saját" rtti-t használok.
alias aalberik
   
Asylum - Törzstag | 5444 hsz       Online status #208673   2015.11.23 08:58 GMT+1 óra  
Én kerülném a dynamic_cast-ot is, meg az rtti-t is. Androidon jött elő az a probléma, hogy dll-eken keresztül nem működik a dynamic_cast és ez kurvanagy szopás, mert most írthatom ki az engineből.

Javasonlám inkább az idtech4 megoldását.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 540 hsz       Online status #208671   2015.11.23 06:59 GMT+1 óra  
Egyébként ismételten rákeresve az RTTI és dynamic_cast dolgokra, itt például azt írják, hogy nem annyira vészes. Mondjuk azzal meg egyetértek, hogy ha túl sok helyen kell dynamic_cast-ot használni, akkor az egy rosszul tervezett program.

   
Parallax - Tag | 579 hsz       Online status #208670   2015.11.22 23:29 GMT+1 óra  
Hiába az as, a feltétel scope-ján kívül kell egy változót deklarálni mindenképpen. Egyébként az OOP patternek zömének alapja a polimorfizmus, anélkül kár is C++ t használni, elég a C.

   
Instalok - Tag | 540 hsz       Online status #208669   2015.11.22 22:22 GMT+1 óra  
C#-ban is használhatod rögtön az "as"-t, null-t ad vissza, ha nem konvertálható. Hát, akkor lehet, hogy dynamic_cast lesz a vége.

   
Parallax - Tag | 579 hsz       Online status #208668   2015.11.22 21:22 GMT+1 óra  
Igazából, ha C#-ban az is-t használod, akkor utána az as-al kell konvertálni, vagyis az már helyből két dinamikus művelet, míg C++ nál már a feltételben is megkaphatod az eredményt egyből:
Kód:
if (auto b = dynamic_cast<Behavior *>(c))
    b->...

   
zeller - Törzstag | 464 hsz       Online status #208667   2015.11.22 17:29 GMT+1 óra  
az rtti kikapcsolasa hulyeseg. a dynamic cast meg jo

   
Instalok - Tag | 540 hsz       Online status #208665   2015.11.22 11:37 GMT+1 óra  
A dynamic_cast mennyire ördögtől való? Általában a RTTI-t kikapcsolom (gondolom ez performance boost is), de dynamic_cast-hoz viszont (nyilvánvalóan) szükséges. Egyetlen helyen akarnám csak használni, de ott is csak arra, hogy megállapítsam, hogy egy adott objektum az egy adott osztály gyereke-e. Komponens-alapú dologhoz kellene.
Kód:
class Component { };
class Behavior : public Component { };
class MyBehavior : public Behavior { };

void Add(Component* c)
{
    // C#-ban ennyivel el lehet intézni, itt használnám a dynamic_cast-ot.
    if (c is Behavior) { ... }
}

Add(new MyBehavior());

   
Asylum - Törzstag | 5444 hsz       Online status #208632   2015.11.13 12:25 GMT+1 óra  
Használd a fantáziád:

Kód:
template <bool value>
class where
{
private:
    where ();
};

template <>
class where<true> {};

template <class T>
class MyClass : where<is_base_of<Base, T>::value>
{
};
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 540 hsz       Online status #208620   2015.11.12 16:32 GMT+1 óra  
Hát, ezzel nagyjából ott vagyok, ahol eddig, minden esetre tanulságos ez a megoldás, lehet, hogy eszembe sem jutott volna. Pedig így megnézve logikus...

   
Asylum - Törzstag | 5444 hsz       Online status #208612   2015.11.12 09:45 GMT+1 óra  
A conceptek nem részei a szabványnak. Amúgy még így lehet megcsinálni:

http://stackoverflow.com/questions/2631585/c-how-to-require-that-one-template-type-is-derived-from-the-other

Tessék egy rövidebb verzió:

Kód:
template <class A, class B>
struct is_base_of
{
    static const int test(A*);
    static const short test(...);

    static B* get();

    enum { value = (sizeof(test(get())) == sizeof(int)) };
};

Ezt a hozzászólást Asylum módosította (2015.11.12 09:53 GMT+1 óra, 710 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 540 hsz       Online status #208606   2015.11.11 18:51 GMT+1 óra  
static_assert-en kívül van-e lehetőség template típusellenőrzésre? Azt szeretném megnézni, hogy az adott típus az gyereke-e egy másiknak. Természetesen csak és kizárólag compile-time. Hasonlóan, mint C#-ban a where feltétel generic esetén. Egyelőre csak ennyi van a függvény elején:
Kód:
static_assert(std::is_base_of<ComponentBase, T>::value, "Not a component!");

Olvastam valamit a Concept-ről, de az VS 2013 alatt (még?) nem működik, és nem szeretnék váltani, főleg nem emiatt.

   
Instalok - Tag | 540 hsz       Online status #208037   2015.08.02 08:57 GMT+1 óra  
Oké, ez jogos.

   
Asylum - Törzstag | 5444 hsz       Online status #208035   2015.08.02 08:39 GMT+1 óra  
Már hogy a fakkba ne lehetne

Kód:
// alma.cpp

class Alma
{
public:
    inline void Foo() {}
};


C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 540 hsz       Online status #208028   2015.08.01 19:33 GMT+1 óra  
Oké, hogy az egy hint, viszont ha nem a headerben van, akkor NEM LEHET inline. Néztem jó pár cikket ezzel kapcsolatban, és megállapították, hogy egyszerű getter/setter függvények esetén NAGYON sokat dob az inline.

C++ban meg nincs olyan, hogy property - vagy értsem ezalatt a getter/setter függvényeket?

   
Parallax - Tag | 579 hsz       Online status #208027   2015.08.01 19:30 GMT+1 óra  
Idézet
Instalok :
Ha nem a headerbe teszem a definíciót, akkor nem lehet inline. Szóval a kérdés még mindig áll. Inline esetén egyébként semmi nem kerül a dll-be, a fordító panaszkodik is, ha inline függvényt akarsz exportálni. Property?


Nincs olyan, hogy inline, ez csak egy kívánság, ami vagy teljesül, vagy nem. Cserébe viszont állandóan újra fog fordulni minden, amit érintenek ezek a fgv-ek. getter/setter = property.
Optimalizálni ott kell, ahol a program dolgozik, nem pedig mindent. Általában a program 10%-a fut az idő 90%-ban, itt kellene optimalizálni, nem feltétlen inline-ozással, ami mint írtam tetszőleges.

   
Instalok - Tag | 540 hsz       Online status #207987   2015.07.22 20:18 GMT+1 óra  
Ha nem a headerbe teszem a definíciót, akkor nem lehet inline. Szóval a kérdés még mindig áll. Inline esetén egyébként semmi nem kerül a dll-be, a fordító panaszkodik is, ha inline függvényt akarsz exportálni. Property?

   
Parallax - Tag | 579 hsz       Online status #207986   2015.07.22 19:09 GMT+1 óra  
Ha a headerbe teszed a kidolgozást is, akkor mi fordul a dll-be? cpp-ke rakd szerintem a property-ket is.

   
Instalok - Tag | 540 hsz       Online status #207983   2015.07.22 15:33 GMT+1 óra  
Ha egy dll-ként használható modult csinál valaki, akkor tervezés szempontjából melyik a szebb?
- az egyszerű get/set függvények inline függvények, azaz a headerben vannak definiálva
- még az akár 1 soros gettereknek is csak a deklarációja van a headerben, a definíció mindig a cpp fileban található (természetesen ez alól kivételek a template függvények, amelyek kötelezően a headerben találhatóak)

   
VMware28 - Tag | 2 hsz       Online status #207878   2015.07.02 09:52 GMT+1 óra  
Hello, Lead játékfejlesztőt keresek egy nemzetközileg elismert magyar játékfejlesztő céghez. Jó a fizu, jó a csapat. Szívességből írtam ide ki, hátha valakit érdekel. Ha igen, írj nekem az akos.szabadi@hotmail.com címre.

   
Parallax - Tag | 579 hsz       Online status #207778   2015.06.12 00:10 GMT+1 óra  
A program bonyolultságát nem az dönti el, hogy konzolos, vagy ablakos. Kompatibilitási okai vannak a konzolnak régi DOS-os programok miatt. Még ma is vannak olyan fejlesztői eszközök, amik DOS-os kimenetet állítanak elő a programnak pl.: Progress és a mai napig írnak ebben ügyviteli rendszereket kórházaknak stb. Játékfejlesztésnél igazából editornál használunk ablakos nyomógombos felületet, játéknál egy üres render ablak kell csak, amire OpenGL, vagy DirectX-el rajzolunk, a konzolos részt mondjuk logolásra lehet használni.

   
itamas - Tag | 77 hsz       Online status #207764   2015.06.08 19:00 GMT+1 óra  
Hát igen, az Assembly már eléggé hardverközeli nyelv, s valóban, arra mindenesetre jó volt a róla szóló könyv bújása, hogy megtudjam, mik azok a regiszterek, mitől 8, 16, 32 ... bites egy program vagy operációs rendszer (ekkora regisztereket bír kezelni, ha jól értelmeztem).
De a C++-ra visszatérve: a konzolos részét használva is lehet legalább olyan jó progikat készíteni, mint az ablakossal? Egyáltalán: miért van elkülönítve a két rész? Elvileg azért pakolja alapból teli a szerkesztőablakot ablakkezelő kódokkal az induláskor, hogy könnyítse a programozó dolgát - engem inkább elriaszt.
Asylum, jók a cikkeid (ezek alapján is fogok majd nekiállni a tanulásnak) és aranyos a hörcsögöd is.
   
Asylum - Törzstag | 5444 hsz       Online status #207763   2015.06.08 15:14 GMT+1 óra  
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Parallax - Tag | 579 hsz       Online status #207761   2015.06.08 13:16 GMT+1 óra  
A C/C++ (mert azért ez eggyütt használandó sok esetben) elég mély téma, igazán jól művelni sok év kérdése. Assembly-vel C++ állásinterjún szoktak szivatni, igazából nem is maga a nyelv, hanem a hardver ismeret a lényeg, hol mennyi elemi utasítást lehet megspórolni, a memória melyik részére teszi az adatot éppen a program, vagy melyik memóriába, "itt mit csinálhat a compiler" és hasonló kérdésekre tudsz válaszolni és aszerint programozni, vagy mások elszúrt programjait helyrehozni.

   
itamas - Tag | 77 hsz       Online status #207760   2015.06.08 12:57 GMT+1 óra  
Idézet
Nomad :
én egy kis bengabali vok de én tavaly előtt tanultam meg a c++-t internetes tutorialokból szerintem nem volt nehéz megtanulni úgyhogy szerintem nyugodtan kezdhet azzal az ember csak egy kis idő kell mire az ember elkezdhet opengl meg ilyen komolyabb dolgokkal foglalkozni...

Irigyellek, jóeszű gyerek lehetsz. Én pár hónapja beszereztem egy rakás programozási szakkönyvet, de még mindig ott tartok, hogy sehol. Igaz, nem is nagyon volt még időm gyakorolni, de talán most nyáron...
A C++-t hajtanám én is, mert úgy látom, ez a fórumtéma pörög itt a JF.hu-n, nem a sima C-s vagy C#-os, úgyhogy ebből azt szűrtem le, hogy ez a legalkalmasabb a játékfejlesztésre is.
Idézet

(az utóbbi 2 hónapban megtanultam az assembly-t)


Pedig az kemény dió lehet. És van egyáltalán valami létjogosultása az Assemblynek a mostani korszerű és korszerűsített programozási nyelvek között? Vagy azt is fejlesztették?
Annakidején megvettem Agárdy Gábor: Gyakorlati Assembly c. könyvének első kötetét; az eleje még érthető volt számomra kb. a szövegek kiíratásáig, de utána már mintha veszített volna a szájbarágósságából és nem sokat értettem belőle...
   
sasukekarakter - Tag | 16 hsz       Online status #207757   2015.06.06 14:02 GMT+1 óra  
Mivel ugyan az Mint a terep2 Remake-ek mely, CTruck3D vagy is ennek a játéknak
Simon_hasur fejlesztett ládásul köze van a c/c++, openGL Grafikával.


https://youtu.be/B74QvPGyBYM
   
proof88 - Törzstag | 528 hsz       Online status #207589   2015.05.07 21:26 GMT+1 óra  
Bocsi, ezt benéztem. Nem fogtam fel, hogy eleve azt írta, hogy "beépített típusokat".
   
Asylum - Törzstag | 5444 hsz       Online status #207588   2015.05.07 09:37 GMT+1 óra  
Erre gondoltam igen. Ha nem muszáj akkor ne adjunk puskát a programozó kezébe.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2519 hsz       Online status #207587   2015.05.06 23:26 GMT+1 óra  
Szerintem arra gondolt, hogy egy sima getter felesleges hogy const referenciát adjon vissza. Az esetek többségében egy sima érték visszaadás is elég, még akár gyorsabb is lehet a végeredmény. Míg ha egy const ref-re ha const castot hívsz, akkor settert csináltál a getterből. Nem szerencsés, még akkor sem ha a a "felhasználó" a hülye.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
proof88 - Törzstag | 528 hsz       Online status #207586   2015.05.06 22:15 GMT+1 óra  
Furcsállom Asylum hogy ezt írtad. A const az én szememben arra való, hogy megmondjuk a fordítónak, hogy mit nem szeretnénk módosítani, így ő vigyáz arra hogy véletlenül se tegyük meg, valamint hogy mit nem szeretnénk ha más módosítana. A const_cast az egy workaround arra hogy ha mégis módosítanánk erőszakkal, a lehetőség megvan, de az már szembeszegül az alkotó által felállított szabállyal, miszerint az ott const. Tehát a felelősség azé aki hülyeséget csinál. Ha egy objektumra szeretnék referenciát visszaadni, akkor inkább azt csinálnám, mint hogy érték szerint adjam vissza, nem? Ptr sem jobb ebből a szempontból. A cpp-ben mindenre van valami apró trükk, de érdemes bizonyos szabályokat betartani.
   
Instalok - Tag | 540 hsz       Online status #207585   2015.05.06 12:06 GMT+1 óra  
Aki const_castot ír, azt le kell lőni.

Egyébként ilyen szempontból ez mindennél probléma, amit nem érték szerint adsz át. Szóval nem kell const_castolgatni, és nincs gond. Egyébként változó, általában enumoknál, booloknál, meg ilyesmiknél érték szerint adom vissza.

   
Asylum - Törzstag | 5444 hsz       Online status #207584   2015.05.06 11:47 GMT+1 óra  
Btw. ilyet ne írj le...

Kód:
const int& getX()


Beépített típusokat mindig érték szerint, mert még a végén ráhív egy const_cast-ot és nézhetsz...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 540 hsz       Online status #207581   2015.05.05 13:03 GMT+1 óra  
Igen, mondjuk lehet, hogy úgy leszek az egésszel, hogy aki szétbirizgálja a headert, annak egészségére (rajtam kívül úgysem fogja használni senki ). Egyébként van forceinline, én a getterekhez azt használtam. Ha jól rémlik az olyasmi, hogy a fordító nem nagyon ellenőrzi le, hogy ez jogos-e inline-nak, hanem azt mondja, h "oké, akkor az lesz".

   
Asylum - Törzstag | 5444 hsz       Online status #207580   2015.05.05 12:34 GMT+1 óra  
Az inline is csak egy hint, semmi nem garantálja, hogy az lesz (dinamikus kötés esetén meg nem is lehet). Ha a fordító még fordítási időben ki tudja következtetni a típust, akkor inlineosíthatja persze.

Teljesítménykritikus dolgoknál le szokták szarni a tervmintákat. Pl. a GLM library csak headerökből áll, így az egész inlineolódik, de bárki belepiszkálhat (ez egyébként is saját felelősség...).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
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]