.NET vs DirectX:
Prestazioni… Managed
Francesco Carucci
3D Software Engineer
Black&White Studios
[email protected]
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
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
.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
.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.
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!
Esempio: Landscape Editor
• Questo e’ il tool di editing delle isole di Black&White 2:
.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.
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’ 
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! 
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
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
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
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.
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!
DEMO!
I’ll give you
SPHERE&BOXES
Coming soon on your screens…
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.
Conclusione
• “Every fool can write code that a machine can
understand, good programmers write code that a
human can understand” – Martin Fowler
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
Domande…
?
Fate i bravi che chiamo la mucca