Az ideális grafikus motor
2007-05-24T20:42:48+02:00
2007-05-29T10:33:27+02:00
2022-07-19T06:43:12+02:00
  • Szóval több nyelven használható DLL-t csinálsz.

    Ehhez a következőket kellene betartani:

    - Pascal exportok:

    pl.:
    void _export _pascal MyFunc() { ... }

    Nem vagyok benne biztos, de nekem a Borland C++ fordító a pascal exportokat nagybetűvel rakja ki a DLL-be, tehát MYFUNC-ként

    - C++ módban az
    extern "C"
    ne maradjon ki, mert különben összebarmolja az export nevét az eljárásnak (kukacot, meg egy rakás krix-kraxot pakol a név után)

    - Az objektumok metódusai is exportálhatók a DLL-be. De ha használni is akarod őket, akkor az elég macerás lesz. Valami ilyesmi formában exportálja ki (asszem): objektum@metódus.
    Azt nem t'om, hogy
    extern "C"
    -nél milyen néven exportál, majd megnézem.

    - Akármilyen nyelvet is használsz, egy header, vagy unit stb. mindig kell. C nyelvben használhatsz
    #pragma startup
    -ot és
    GetProcAddress
    -eket a procedúrák lekéréséhez a program elején. Szerintem egy Delphi unit-ban is lehet inicializációs kódot írni
    Mutasd a teljes hozzászólást!
  • Amúgy mellesleg igen, sokat segítettél soft shadow ügyben.
    Köszi!
    Mutasd a teljes hozzászólást!
  • Nekem mindegy melyiket használod, mint mondtam nagyából mind egy kaptafára megy.

    Remélem a soft shadow-val kapcsolatban többet segítettem.
    Mutasd a teljes hozzászólást!
  • Ehh, köszi, de direkt említettem, hogy a DLL szerkezetét szeretném valahogy jól kitalálni.
    Amúgy attól félek - bár elég gyorsak a mai gépek -, hogy érezhető sebességcsökkenés lenne érezhető, ha COM-ot használnék.
    Nyilván nem a grafikai teljesítmény csökkenne, de ha ciklusonként elég sok függvényhívás lenne, akkor lehet, hogy számítana.
    Na jó, akkor sem annyira. De amit lkedves linkelt, az a megoldás eléggé tetszik.
    Mutasd a teljes hozzászólást!
  • Elolvastam a linkelt cikket és nagyon tetszik, leginkább a vége.
    Azt hiszem, én is valami hasonlót csinálnék. Köszi!
    Mutasd a teljes hozzászólást!
  • Hű... muszáj lenne nekem a registry-ben is regisztrálni a COM osztályokat?


    A COM használata esetén van egy alap osztály:

    #define STDMETHOD(method) virtual HRESULT STDMETHODCALLTYPE method
    #define STDMETHOD_(type,method) virtual type STDMETHODCALLTYPE method

    class IUnknown
    {
    // *** IUnknown methods ***
    STDMETHOD(QueryInterface) (THIS_
    REFIID riid,
    LPVOID FAR* ppvObj) PURE;
    STDMETHOD_(ULONG,AddRef) (THIS) PURE;
    STDMETHOD_(ULONG,Release) (THIS) PURE;

    // *** IClassFactory methods ***
    STDMETHOD(CreateInstance) (THIS_
    LPUNKNOWN pUnkOuter,
    REFIID riid,
    LPVOID FAR* ppvObject) PURE;
    };

    Az összes többi COM-os osztályt ebből örökítesz, továbbá a DLL-ben kell, hogy legyen egy létrehozó függvény, és az átvinni kívánt függvények mind virtual típusúak kellenek, hogy legyenek. Így működik pl. az egész DirectX. Ez a megoldás továbbá lehetővé teszi, hogy akár sima C-ből is elérd a kívánt függvényeket az objektumban/osztályban, csak ne akard tovább örökíteni. Itt sehol senki se kötelez arra, hogy bejegyezd a registry-be, továbbá ez a megoldás így önmagában nem platform függő. De használhatsz más hasonló megoldásokat is, de lényegében mind egy kaptafára mennek.
    Mutasd a teljes hozzászólást!
  • hogyan csináljam a soft shadow-kat


    Javaslom az Nvidia SDK-ban szereplő simplesoftshadow példa programot írányított fény forráshoz. Pont fény forráshoz, pedig vagy nem csinálsz soft shadow-t és egy szerű stencil árnyékokat használsz, vagy soft stencil shadow-t csinálsz ( 1 lépésben egyszerű stencil árnyék, a jelenetről lehúzol egy shadow map-et, és minden egyes pixel lekérdezésénél az árnyékokat tartalmazó textúrából még kiolvasod a jelkenet shadow mapjéből, hogy bizonyos hibahatárokon belül illeszkedik-e a felületre, ha illeszkedik, akkor hozzászámolod, ha nem eldobod.) Vagy pedig a simplesoftshadow példa programm mintájára megcsinálod Shadow-cubemappel, ahogy az id Software csínálja majd a Trinity-Engine-jükben majd.
    Mutasd a teljes hozzászólást!
  • Kedvenc problémámat feszegeted, ami kb úgy hangzik: miért zabálja fel az általam használt eszközkészlet az általam létrehozott tartalmat? Vagyis: ha írok egy "akármilyen utility-t", akkor azt pl C++-ban, Win alatt csinálom, nem ismerek "királyi utat" arra, hogy ugyanezt más környezetben felhasználjam. Ha használok valamilyen eszköztárat erre, akkor ahhoz kötöm magam - és jellemzően ezek is valamilyen (pl M$) környezethez kötnek.

    Szerintem egyébként akkor jársz jól, ha megcsinálod a "nagyon szép", C++ OO motort, és külön figyelsz arra, hogy a platform-specifikus részeket (settings olvasás/írás, GUI, erőforrások elérése, etc) elkülönítsd a "magtól". (pl windows.h include csak util classokban, amiknek megcsinálhatod a linux verzióját, ha kell).

    Aztán, felhasználod az aktuális platformod képességeit arra, hogy a motort becsomagold (windows esetén ez lehet COM az ő szája íze szerint, linuxon esetleg valami más); amit aztán az adott környezetben a felhasználó oldalról standard, bár platformfüggő módon el lehet érni.
    Nem tudom, a Delphi hogyan tud C++-ban írt DLL-t kezelni; de talán a COM-ba csomagolt motor elérésére már van standard eszköze. Sőt, íme egy cikk C++ osztály közvetlen használatáról... Sőt, állítólag a Delphi devguide is értekezik erről.

    Nyilván overhead van, amikor a motor és a használó környezet határát átléped - viszont jól tervezett motornál ez talán nem túl gyakori, hiszen a 3D világod éli az életét, és csak bizonyos események bekövetkezése kezelendő "odakint".
    Mutasd a teljes hozzászólást!
  • Mert az sem túl elegáns megoldás, hogy többféle DLL-t fordítok, egyet, amit Delphiben írtam, egyet, amit C++-ban írtam, stb...
    Mutasd a teljes hozzászólást!
  • Hű... muszáj lenne nekem a registry-ben is regisztrálni a COM osztályokat? COM-on kívül nincs más lehetőségem? Meg ha azt mondom, hogy Linuxon is lehessen használni?
    Mutasd a teljes hozzászólást!
  • Component Object Model, aminek kicsit utána kellene nézned...
    Mutasd a teljes hozzászólást!
  • Üdv Mindenkinek!

    Nagy dilemmával fordulok hozzátok.
    Az a helyzet, hogy szeretnék "összedobni" egy jobb grafikus motort, már csináltam egy nagyon alapszintűt (PR00FPS), és alapjaitól kezdve újraírnám az egészet.
    A segítséget nem ahhoz kérném, hogy pl. hogyan csináljam a soft shadow-kat, hanem a szerkezeti megvalósítás hogyan nézzen ki.
    Bővebben: most nagyon úgy érzem, sőt ez biztos is, hogy ahogy az előző, ez is DLL lenne. Azonban azt szeretném, ha a legtöbb, DLL kezelésre képes (WinAPI) prog. nyelvből használni lehessen. Első hallásra ez egyszerű, ha olyan típusokat használok, amik mindenhol megvannak, de itt nem ez a lényeg, hanem az, hogy ha létrehozok egy 3D-s objektumot, akkor annak meghívhassam a metódusait. Tehát olyan DLL-t csinálnék, ami kívülről is objektum-orientált, tehát ha megírom C++-ban a DLL-t, akkor Delphiből is metódusokat hívhassam meg a létrehozott objektumnak.
    Ha mondjuk Delphiben írnám a DLL-t akkor ott egyszerűen el tudom képzelni, hogy objektumot adok vissza a hívó proginak, ami persze mutató, és hívhatom a host delphis progimból az objektum metódusait úgy, hogy objektum.metódus1, stb. Szóval ez a gond, nem tudom, hogy lehetne egyszerűen megvalósítani ezt.

    Továbbá, arra is elképzeléseket várok, hogy milyennek tartjátok az ideális motort, kezelés szempontjából, tehát ez így elég kényelmes lenne-e, ha nektek kéne ilyen "kívülről is OO DLL-lel" dolgoznotok.

    A válaszokat előre is köszönöm!
    Mutasd a teljes hozzászólást!
abcd