Új hozzászólás Aktív témák

• #31131 Abu85 HÁZIGAZDA Raymond #31129

  Új Válasz 2017-10-30 11:35:30 #31131

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz Raymond #31129 üzenetére

  Azért ne tekintsünk már úgy a motorstruktúra szempontjából a leképezőkre, mintha teljesen más lenne az elfogadott modell két játéknál. Abszolút nem más, függetlenül attól, hogy a játék stratégia vagy kaland. Emiatt van egységes ajánlás arra, hogy milyen a következő ideális motorstruktúra. Senki más nem mond mást a gyártók közül, ugyanis az az ideális, ha a régi leképező->iRenderSytem-szerű rendszereket úgy alakítják át, hogy két jól elkülönülő részre bontják az egészet. Ajánlott egy magas szintre helyezett leképezőrész, mi tulajdonképpen tartalmazza mindazt, amiben a célozható API-k megegyeznek. És ez alá kell behúzni legalább két alacsony szintre helyezett leképezőt, ami tartalmazza azokat, amikben a célozható API-k eltérnek (például bekötés, hazardok kezelése, memóriamenedzsment, erőforrás-korlátozások, stb.). A cél ezzel az, hogy az explicit és a legacy API-kra is tudjál egy motorban natív pathot kínálni, így nem kell wrappert bevetni, mert esetleg egy olyan dolgot a közös, magasabb szintű leképezőrészbe raktál, amit az egyik célzott API pont nem támogat. Működik wrapperrel is persze, csak rohadtul rossz lesz a hatásfoka. Ez még addig oké, amíg egy program lehetőséget ad a natív path használatára, mert akkor kit érdekel, hogy ott a wrapper. De amikor úgy jön ki valami, hogy nincs natív path-ra sem lehetőség, akkor nyilván felkiáltanak ott a gyártóknál, hogy "erről pofáztunk 2-3 GDC-n át, hogy ezt ne".

Új hozzászólás Aktív témák