XNA e C # rispetto ai 360's nel processore degli ordini

Dopo aver letto questo rant , sento che probabilmente hanno ragione (visto che Xenon e CELL BE sono entrambi estremamente sensibili al codice ignorante ramificato e cache ), ma ho sentito che anche le persone stanno facendo i giochi con C #.

Quindi, è vero che è impossibile fare qualcosa di professionale con XNA, o mancava il poster che rende XNA l'API killer per lo sviluppo del gioco?

Per professionista, non intendo nel senso che puoi guadagnare da esso, ma più nel senso che i giochi più professionali hanno modelli di fisica e sistemi di animazione che sembrano fuori dalla portata di un linguaggio con barriere così definite agli intrinseci . Se volessi scrivere un sistema di collisione o un motore fluidodinamico per il mio gioco, non credo che C # mi offra la possibilità di farlo mentre il generatore di codice di runtime e la mancanza di intrinseci interferiscono con le prestazioni.

Tuttavia, molte persone sembrano lavorare bene all'interno di questi vincoli, realizzando i loro giochi di successo ma evitando apparentemente qualsiasi problema per omissione. Non ho notato alcun gioco XNA fare qualcosa di complesso diverso da ciò che è già fornito dalle librerie o gestito da shader. Questo è evitare le dinamiche di gioco più complesse a causa delle limitazioni di C # o solo le persone che si stanno concentrando per farlo ?

In tutta onestà, non riesco a credere che la guerra dell'intelligenza artificiale possa mantenere molte unità di intelligenza artificiale senza un approccio orientato ai dati o alcuni sporchi hack di C # per farla funzionare meglio dell'approccio standard, e immagino che anche questa sia in parte la mia domanda, come le persone hanno hackerato C #, quindi è in grado di fare ciò che i programmatori di giochi fanno naturalmente con C ++?

OK, solo per creare alcuni buchi in quel rant che hai collegato:

• "C # si basa su un interprete" Just In Time " - sbagliato - è un compilatore JIT . Dopo che un metodo è stato JITted una volta , il codice compilato viene riutilizzato per ogni chiamata. Il codice compilato è molto vicino al codice nativo pre-compilato.
• "Xenon CPU è un" processore "sul posto - intende" in ordine "? - E: "La CPU Xenon non ha previsioni di diramazione" . Implica che ciò significhi che la compilazione JIT produce naturalmente un codice errato che deve essere riordinato dalla CPU e provoca molte ramificazioni, il che è un'assurdità assoluta . Gli stessi consigli sulle prestazioni per l'esecuzione su questa architettura CPU si applicano sia a C ++ che a C #.
• "[JIT] richiede un flushing costante sul 360" - sbagliato, il codice compilato può essere mantenuto nella cache come qualsiasi altro codice normalmente compilato. (Se intende svuotare la tubazione, vedere il punto precedente.)
• "generics [...] usa la generazione di codice" - i generics sono JITted come tutto il resto e, come tutto il resto, il codice JITted è veloce. Non ci sono penalità di prestazione per l'uso di generici.
• "tutte le parti sexy del linguaggio [...] richiedono la previsione di entrambi i rami ..." - come si applica anche al C ++? - "... o [...] generazione di codice sul posto" - intende JITting? Ho già detto che è veloce? (Non andrò in tutti i luoghi in cui il CLR desktop utilizza la generazione effettiva del codice, una funzionalità non supportata da Xbox 360!)
• "[C # non ha] le enormi librerie [di C ++]" - tranne, diciamo, XNA stesso? E molto altro ancora . (Comunque, questo è un punto abbastanza giusto.)

XNA su Xbox 360 viene eseguito su una versione modificata di .NET Compact Framework CLR. Non ho dubbi che non sia all'altezza della versione desktop. Probabilmente JITter non è altrettanto buono, ma non penso neanche che sia cattivo . Sono sorpreso che non abbia menzionato il Garbage Collector, che è terribile rispetto al CLR desktop.

(Naturalmente - non si dovrebbe colpire il garbage collector in un gioco professionalmente sviluppato in ogni caso , così come è necessario stare attenti con le allocazioni in qualsiasi gioco di livello professionale.)

(Per una discussione tecnica effettiva su .NET Compact Framework, forse inizia con questa serie di articoli: panoramica , compilatore JIT , GC e heap .)

Il modo in cui è del tutto aspecifico riguardo alla sua terminologia rende difficile persino capire cosa significhi. O è in modalità massima, o non sa di cosa sta parlando.

Ora che abbiamo ottenuto che fuori strada, qui ci sono alcune cose che si fa perdere su utilizzando XNA sulla 360, piuttosto che andare nativo :

• Accesso all'unità SIMD / Vector per eseguire calcoli in virgola mobile CPU davvero molto veloci
• Capacità di usare un codice in lingua nativa che sarà probabilmente un po 'più veloce di C #
• Capacità di essere un po 'più pigro di come allocare memoria
• I giochi XBLIG hanno accesso solo a 4 dei 6 core (ma abbiamo ancora tutte e 3 le CPU e non sono neanche core completi, quindi non perdiamo molto) - non sono sicuro che questo si applichi a XNA non XBLIG Giochi
• Accesso diretto a DirectX per eseguire trucchi grafici davvero oscuri

Vale anche la pena sottolineare che si tratta solo di restrizioni sul lato CPU. Hai ancora accesso completamente gratuito in esecuzione sulla GPU.

Ho descritto queste cose in questa risposta a quella che è effettivamente la stessa domanda di questa. Come ho già detto in questa risposta, XNA è assolutamente adatto allo sviluppo "professionale" .

L'unico motivo che dovresti evitare è perché non puoi assumere talenti C #, concedere in licenza motori C # e riutilizzare il codice C # esistente nello stesso modo in cui puoi con la base esistente di conoscenza C ++. O perché potresti anche scegliere come target una piattaforma che non supporta C #.

Naturalmente, per molti di noi che non sono sviluppatori "professionisti", XNA è la nostra unica opzione per salire su Xbox 360, facendo il punto controverso.

Per rispondere alle altre tue domande:

Nulla in C # si ferma voi utilizzando approcci data-orientati in sostanza, esattamente nello stesso modo in cui li usereste in C ++.

C # non ha la possibilità di incorporare automaticamente il codice in fase di compilazione e (senza andare a controllare) Sono abbastanza sicuro che il JITter del CLR compatto non possa incorporare i metodi (il CLR desktop può). Quindi, per il codice critico per le prestazioni, potrebbe essere necessario incorporare manualmente in C #, dove C ++ fornisce assistenza.

Probabilmente un motivo più grande per cui spesso non vedi cose ad alta intensità di matematica come il rilevamento delle collisioni e le simulazioni di fluidi in C # è la mancanza di accesso all'unità vettoriale (come menzionato sopra).

Dovresti definire "professionale". Potresti fare Angry Birds, Plants vs Zombies, ecc? Assolutamente. Potresti fare Crysis 2, COD, Halo? Ne dubito. L'uso di C # avrà davvero un impatto solo su giochi che richiedono molta CPU e devono anche comprimere ogni ultimo byte di memoria (perdi nella garbage collection), quindi c'è ancora molto da fare.

Come strumento di apprendimento per le persone che iniziano, strumento di prototipazione, piattaforma per scrivere giochi in grado di affrontare il trade off, ecc., È fantastico e ha un sacco di potenza e semplicità, non è progettato per realizzare ciò che avresti necessariamente chiama i giochi "AAA". Inoltre toglie molto al dolore e alla sofferenza di cui le persone devono preoccuparsi con il porting multipiattaforma e la compatibilità.

Se ti viene in mente un gioco fantastico e ti imbatti nei limiti di ciò che puoi fare con XNA, allora suggerirei di contattare direttamente la MS, se l'idea è davvero abbastanza buona potrebbero lasciarti mettere le mani su uno sviluppo completo kit.

Il semplice fatto è che non è necessario un elevato numero di poligoni, un'illuminazione full HDR o la fisica più interessante del mondo per creare un gioco interessante e se il tuo piano di gioco non include nessuno di questi, perché non andare più veloce soluzione dei tempi di sviluppo?

i giochi più professionali hanno modelli di fisica e sistemi di animazione

È solo sbagliato. I giochi professionali hanno ciò di cui hanno bisogno per implementare il loro gameplay e ottenere il loro aspetto artistico, e niente di più, anzi, niente di meno. Un gioco non è più professionale perché sembra più realistico o ha una fisica più dettagliata. Un gioco professionale raggiunge il suo gameplay e gli obiettivi visivi, nei tempi, nel budget, ecc., E le navi e guadagna.