.NET vs DirectX: Prestazioni… Managed

1. .NET vs DirectX: Prestazioni… Managed Francesco Carucci 3D Software Engineer Black&White Studios fcarucci@lionhead.com

2. Black&White 2 • Statistiche: • Quattro anni e mezzo di sviluppo • Circa 2 milioni e mezzo di linee di codice • Complessita’ ciclomatica totale: NP • Fino a quarantacinque ingegneri sul codice • Circa 4500 cene ordinate al fastfood • 4 bambini nati nel team durante il periodo di sviluppo

3. Problemi • Il codice si e’ evoluto a partire da quello di Black&White. • Testing interamente manuale. • Nessuna politica di testing automatico • Difficolta’ di refactoring del codice • Difficolta’ nel debugging e gestione della memoria. • Double delete e memory scribbler • Resource leak

4. .NET la soluzione? (1) • Si. • Semplificherebbe la gestione della memoria • eliminerebbe i bug comuni nella programmazione nativa • offrirebbe migliori tool di supporto al testing e al refactoring

5. .NET la soluzione? (2) • No, almeno per ora, per due motivi: • Prestazioni. Il porting di Quake in Managed C++ viaggia a circa il 90% del framerate rispetto alla versione nativa. Non e’ male. • Garbage Collector non deterministico. Non e’ l’ideale per un’applicazione real time dove il framerate deve essere il piu’ costante possibile ed il GC non garantisce un tempo di esecuzione massimo.

6. I Tool di sviluppo • Una gran parte del tempo di sviluppo e’ spesa nei tool di supporto • Tool di esportazione dell’art asset (texture, modelli, animazioni) • Tool di editing visuale (es. level editor) • Tool di scripting per definire il game play • In un tool le prestazioni contano relativamente • .NET e’ una soluzione per questo problema gia’ oggi!

7. Esempio: Landscape Editor • Questo e’ il tool di editing delle isole di Black&White 2:

8. .NET vs DirectX • Un level editor, ad esempio, condivide gran parte dell’engine grafico con il gioco. • L’engine e’ codice nativo ed implementato in termini di DirectX native. Deve andare veloce. • Il framerate costante non e’ una necessita’ di un editor visuale • Ci serve uno ‘strumento’ per coniugare le prestazioni dell’engine nativo alla produttivita’ dell’ambiente managed. • C++/CLI e’ il nostro uomo.

9. DEMO! • Creeremo un Direct3D Device unmanaged. • Useremo il Device per colorare una Form di rosso. • Fatto questo, Black&White 2 e’ solo un paio d’anni di sviluppo piu’ in la’ 

10. Facade Pattern • “Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.” GOF185 • Il Facade pattern cattura l’essenza di quello che stiamo facendo: un’astrazione ad alto livello di un motore 3D consumabile da .NET. • Cool! Anche noi programmatori 3D usiamo i Design Pattern! 

11. Facade (1) • Concetti a basso livello esposti da D3D: • 3D Device • Vertex e index buffer • Shader • Texture • Concetti ad alto livello esposti dal facade: • Oggetto 3D • Materiale • Scena

12. Facade (2) • Il facade espone solo una vista ristretta e semplificata dell’engine sottostante. • Il giusto livello di astrazione dipende dall’applicazione: • Troppo a basso livello non serve: c’e’ gia’ DirectX Managed • Troppo ad alto livello non serve: limiterebbe il campo d’applicazione

13. Sphere&Boxes (1) • Questo e’ il risultato di due settimane di R&D, e delle mie indubbie qualita’ artistiche  • Sphere&Boxes consiste in: • Un semplice motore di rendering in Direct3D native • Un motore di fisica scritto in codice nativo (Novodex) • Un framework di generazione degli shader (cool ) • Un wrapper che espone oggetti device, mesh e camera

14. Sphere&Boxes (2) • Un’applicazione C# pilota l’engine usando gli oggetti managed esposti dal facade e implementa semplici effetti di riflessione e ray casting. • Un oggetto Scene in C# implementa il render loop ed un semplice database di mesh da disegnare.

15. Sphere&Boxes (3) • Il rendering loop gira in un thread separato dalla “logica” dell’applicazione. • Prototipare un’architettura di rendering multithreaded in C# e’ rapido e indolore! • Ma poi l’implementazione finale dovra’ essere in C++ • … e wrappata per essere nuovamente accessibile al mondo managed! • Lo strumento giusto per risolvere ogni problema: • C# per scrivere il tool di visualizzazione e editing del mondo • C# per prototipare rapidamente una soluzione • C++ per spaccare il nanosecondo in quell’inner loop!

16. DEMO! I’ll give youSPHERE&BOXES Coming soon on your screens…

17. Sviluppi futuri • Valutare la piattaforma .NET come framework per sviluppare l’applicazione principale e non i soli tool di supporto. • Il linguaggio giusto per il compito giusto: • Engine in C++ • Game code in C# • Script in Python/LUA • Domani: C++ come l’assembly oggi, C# come il C++ oggi. Sviluppare ad un livello di astrazione piu’ alto.

18. Conclusione • “Every fool can write code that a machine can understand, good programmers write code that a human can understand” – Martin Fowler

19. Approfondimenti • DirectX SDK October Release • http://msdn.microsoft.com/directx/sdk/ • Novodex Physics Engine • http://www.ageia.com/novodex.html • Quake II .NET • http://www.codeproject.com/managedcpp/Quake2.asp

20. Domande… ? Fate i bravi che chiamo la mucca