Miért XNA?

Most pedig írnék arról, hogy miért az XNA-t választottuk, és egyáltalán mi az.
Többen máshogy definiálják, de én maradnék annál, hogy egy framework.

Mit is jelent ez?
A 'framework' szóra rákeresve az angol-magyar szótárban, többek között a 'keret', 'váz' szót találjuk. Tehát az XNA egy keretrendszer, ami röviden, tömören annyit tesz, hogy rengeteg alap dolgot tartalmaz, amit saját magunknak kellene megírni mondjuk c++ DirectX kombóval (de akár c# MDX (= Managed DirectX) kombóval is). Magát a keretrendszert c#-al lehet használni, ebből adódott, adódik, és adódni is fog vita. A teljesítményt és a memóriakezelést hozzák fel a vita tárgyaként, mondván, hogy míg c++ esetén teljesen a mi kezünkben van a memóriakezelés (érsd: akkor foglalsz le és szabadítasz fel memóriát, amikor csak akarsz - meg nyilván amikor értelme is van -), addig a c# esetén az ún. GC (= Garbage Collector) irányítja ezeket, amire érkezik a sok támadás, miszerint nem látja el jól a feladatát (természetesen már sikerült bebizonyítani, hogy teljesen jól működik, talán a későbbiekben csinálok is erről egy felmérést, ha nagyon unatkoznék :)). Van néhány pontatlanság a wiki-s cikkben. Csak egyetlen példát írnék:
"Minden objektum törlődni fog, de nem tudni mikor." - Én pontosan tudom, hogy mikor fog törlődni: Akkor, amikor megszűnik rá minden hivatkozás. Csak egy példa a content kezelésre (XNA-s lebutított kódrészlet: )

---

/*Létrehozunk egy lokális content managert minden egyes pályához.*/
ContentManager content;

/*Amikor betöltjük a pályát*/
public void Load(...)
{
/*Elkészítjük a lokális content managert*/
content = new ContentManager(game.Services, game.Content.RootDirectory);

/*content betöltés...*/
}

/*Amikor kilépünk a pályáról, illene törölni mindent, amit erre a pályára betöltöttünk*/
public void Unload()
{
/*Itt a lényeg csupán annyi lenne, hogy minden egyes Model-t, Texture2D-t, és egyéb betöltött dolgokat 'null'-ra kell állítani. Ezzel tudjuk jelezni a GC-nek, hogy már nincs rá szükségünk*/

/*Miután mindent null-ra állítottunk, amit törölni szeretnénk:*/
content.Unload();
content = null; /*Megszűntetjük a hivatkozást a helyi content managgerre*/

GC.Collect(); /*Majd szólunk a GC-nek, hogy ideje takarítani :)*/
}

---

És lám, minden eltűnt, aminek kell. (én pl. úgy csináltam, hogy több 4048-as bmp-t betöltöttem (~12mb volt egy), majd töröltem őket, és ezt többször egymás után)

A másik, amit támadni szoktak az a JIT (= Just In Time) fordítás, ami azt a feladatot látja el, hogy futásidőben optimalizálja az adott gépre a kódot, szemben a c++ fordítókkal, amelyek natív kódot fordítanak, és éppen arra a gépre van optimalizálva, amelyikre "beállították" a fordítót. Az előbbi nyilván valamekkora teljesítményt igényel, ezért valamilyen szinten van is igazság abban, amit mondanak: nagy teljesítményigényes programok esetén a c#ban készültek lassabban futnak, mint a c++os változatuk.

De hát akkor kinek jó ez?
A casual/indie fejlesztőknek, illetve olyan embereknek, akik játékot szeretnének készíteni, és nem azzal akarnak foglalkozni, hogy az utolsó cseppig optimalizálják a saját (vagy egy ingyenesen letölthető / megvásárolt) engine-t. Emellett fontos megemlíteni a Multiplatform támogatást. Ezek közül is (számomra) mérhetetlenül fontos az Xbox360-ra való fordítás lehetősége. Ha a c++os játékunkat akarnánk Xbox360-ra fordítani, akkor ahhoz meg kellene vennünk a DevKit-et (= Developer Kit), amiről nincs információm, hogy mennyibe kerül, de amit félfüllel hallottam, az magánembernek (hacsak nem milliomos) szerintem megfizethetetlen. Természetesen XNA-val sem tudunk ingyen Xbox-ra fordítani, meg kell venni az éves díjú ún. Premium Account-ot (~20.000Ft/év); bővebb infó itt.
Természetesen, ha valakinek nem elégséges a rendszer által nyújtott teljesítmény, akkor szabadon átírhat nagyjából mindent, de nem hiszem, hogy egy garázsprojekt számára nem lenne elegendő.

Tehát senki sem fog tudni XNA-val Crysis 4-et fejleszteni, de nem is erre találták ki.