- This topic has 51 replies, 12 voices, and was last updated 12 years, 6 months ago by
.
-
Kb minden témában sokkal modernebb a d3d, főleg egy 10-11-es. Nem azért mert ők sokkal okosabbak, hanem mert időről időre merték újragondolni, és nem ragaszkodtak egy 1992-ben még jó ötletnek tűnő, időközben meglehetősen idejétmúlt koncepcióhoz…
A felépítés úgy unblock szintekkel jobb d3d-ben, mert meglehetősen béna dolog a tonna függvény, főleg mikor ezek egy része csak és kizárólag azért kell, hogy a régi, visszafelé kompatibilitásból fakadó api és belső hiányosságokat elfedjék. (Bindolások, csak, hogy módosíthass egy resource-ot, nye…)
Az alap resource kezelés úgy ahogy van totális lúzerség. A resource ID-k teljesen transparensek, símán növekvő számok amik nem tartalmazzák a resource típusát, ennek folyományaként minden resource típusnak saját felszabadító függény kell, nagyszerű hibalehetőségek tárházát nyújtva ezzel. Épp ezért besetelni is ezernyi hülyeséget tudsz, de legalább a hiba outputok alapból kínosan szűkösek. Az enumok helyetti define-ok használata is kiváló hibalahetőség, meg úgy általában az egész api tele van régen jó ötletnek tűnő, és azóta úgymaradt dolgokkal.Mennyire egyszerű és logikus, hogy a D3D-ben vannnak create és set és get és draw függvények, és ezzel mindent meg tudsz csinálni… Ehhez képest opengl-ben még egy egységes naming convention sincs amivel az adott resource-ra vonatkozó függvényeket legalább egyben tartanák…
Tekintve, hogy semmilyen resource-ból nem lesz 3 milliónál több darab lekreálva, a felső 5 bit pl. tökéletes megoldás lehetne a resource típusának tárolására. Ez nagyon minimális átalakítás lenne a jelenlegihez képest, de pl. a struktúra elég alap c eszköz, ami már a lehetőségek végtelen tárházát nyitná meg a fejlesztők előtt… ;)
- You must be logged in to reply to this topic.
