Sviluppo PC e Console: una panoramica

Prima che inizi il flame, mi preme dire che in questo articolo non entrerò nel merito dell’eterna polemica “giochi console VS. giochi PC”, bensì vi racconterò qualche cosa sullo sviluppo per console confrontandolo con lo sviluppo per PC.

Ordinerò i pensieri per categorie.

MEMORIA

Come sappiamo, su PC abbiamo come minimo 2GB di memoria più la memoria video , mentre su console ne abbiamo un quantitativo decisamente inferiore: se consultiamo Wikipedia, scopriamo che le console next-gen hanno circa 512MB di RAM tra memoria video e memoria di sistema.

Sapendo questo, capiamo che l’approccio all’uso della memoria deve essere estremamente attento. Non solo: il modo in cui si tratta la memoria cambia completamente.

Per farvi un esempio: quando su PC si libera 1MB di memoria, non cambia praticamente niente, mentre su console è un quantitativo che viene accolto con gaudio e tripudio.

Inoltre il PC è una macchina dinamica, che potrebbe avere più o meno memoria, quindi un gioco potrebbe voler utilizzare quella memoria aggiuntiva. Nonostante questo, dovrà stare attento: il gioco non è l’unica applicazione che sta funzionando sul PC, quindi le risorse potrebbero essere già utilizzate in piccola o larga parte.

Su console questo problema non esiste: la memoria è una risorsa nota e possiamo utilizzarla come preferiamo.

Questo ovviamente cambia l’approccio: su console una soluzione conveniente è quella di utilizzare delle pool di memoria che allocano dei grossi blocchi per poi gestire le piccole allocazioni internamente, e queste pool possono essere fisse.

Su PC questa soluzione può funzionare, ma non sfrutterà il maggior quantitativo di memoria. Sarà quindi necessario avere un sistema che dimensiona le pool a seconda del sistema.

Inoltre, abbiamo il problema della frammentazione della memoria: siccome su PC la memoria potrebbe essere in qualunque stato, potrebbe succedere ad esempio che abbiamo 8GB di RAM di cui 4 liberi, ma il blocco più grosso è, poniamo, di 4MB. Se il gioco vuole allocare una pool da 16M, il sistema non troverà niente da usare e quindi utilizzerà la memoria virtuale, ossia l’hard disk.

A quel punto il nostro gioco inizierà a scattare orrendamente mentre l’hard disk verrà stressato.

Ci verrebbe da pensare che quindi su PC è meglio allocare la memoria in pezzi più piccoli, magari con l’allocatore standard. Questa soluzione comunque non va bene, poiché potrebbe aumentare ulteriormente la frammentazione in un ambiente in continuo mutamento: se una pool viene allocata in memoria, fintanto che è lì tutte le allocazioni saranno in memoria. Se invece uso l’allocatore standard, magari la prima allocazione va in memoria, poi va via e l’antivirus si prende quel pezzo. Poi ne arriva un’altra e finisce nella memoria virtuale. Capiamo che non vogliamo che questo accada: per quanto possibile vogliamo predicibilità nelle nostre azioni.

Per questo, nonostante tutto, su PC è comunque meglio usare delle pool la cui dimensione sappia adattarsi alla memoria fisica presente. Magari non automaticamente, ma semplicemente linkata alle varie impostazioni nelle opzioni (qualità della grafica, qualità dell’audio e così via).

L’utente cambierà le impostazioni in modo che il gioco vada bene sul suo PC. Oppure metterà tutto a manetta e quando tutto scatterà e laggherà sul suo Pentium 3 con 512MB di RAM, andrà sui forum gridando ai programmatori che non sanno ottimizzare.

CPU

Saltando l’ovvietà (ossia che i PC hanno tanti tipi di CPU mentre le console hanno lo stesso modello per tutta la loro vita), in genere i PC offrono dei set di istruzioni standard (altivec, MMX, SSE e così via). Le console, invece, hanno praticamente sempre delle CPU custom.

Non è che in realtà siano proprio custom, cioè costruite da zero apposta per la console: sono più che altro processori standard con istruzioni da altri modelli, con l’aggiunta magari di qualche istruzione aggiuntiva fatta apposta e una modifica alla memoria di cache.

Questa soluzione porta a scrivere codice per console in maniera molto più a basso livello rispetto a quello che si farebbe su PC.

Oltre a questo, il fatto che i processori per PC siano tutti diversi porta a scrivere codice in maniera “scolastica”, ossia pulita, ordinata e standard: sarà il compilatore a ottimizzare dove può. Su console, invece, l’avere una sola CPU significa che possiamo fare ottimizzazioni molto forti: ad esempio possiamo lavorare sull’eliminazione dei branch se essi sono un problema per quella CPU. Magari il compilatore avrà delle direttive speciali, che noi potremo usare abbondantemente  durante la stesura del nostro gioco. Questo porterà a codice di certo meno leggibile, ma nettamente più veloce per quella specifica CPU.

GRAFICA

Qui parlo di GPU e di memoria video. Scavalcando la questione “PC = tante schede, Console = una soluzione”, vale la stessa regola delle ottimizzazioni già vista per la CPU.

Oltre a questo, le console potrebbero offrire soluzioni impensabili nel mondo PC: ad esempio una soluzione che su PC dovrebbe essere eseguita su GPU, su console potrebbe essere conveniente farla su CPU. Pensiamo alla PS3 e le sue SPU.

La grafica è generalmente il punto su cui i giochi PC e console possono differenziarsi maggiormente, poiché i PC moderni (tipo Intel i7 con una scheda DX11, Win7 64bit con 8GB di RAM) sono nettamente più potenti delle console presenti al momento sul mercato.

Questo ovviamente impone dei problemi nel fare giochi multipiattaforma: fare una versione PC che utilizzi tutto il suo ben di Dio significa fare shader apposta, avere asset apposta e un’organizzazione della memoria apposta.

Questo impatta tutti gli stadi di produzione:

  • I grafici dovranno fare texture più grandi e modelli più dettagliati apposta per il PC;
  • I programmatori dovranno fare degli shader apposta, che su console potrebbero proprio non esistere (o potrebbero non essere shader);
  • Soluzioni “brute force” che su PC possono essere fatte senza particolari accorgimenti, su console potrebbero richiedere uno studio nettamente piu’ attento;
  • I tool dovranno gestire delle pipeline di conversione piuttosto differenti tra le varie versioni;
  • Gli screenshot andranno fatti dalle varie versioni per sottolineare le differenze. Allo stesso tempo non devono creare danno alle versioni meno spinte, poiché anche quelle versioni devono andare sul mercato;
  • Il marketing dovrà veicolare attentamente le informazioni delle varie versioni.

Capiamo facilmente che una versione PC dei giochi moderni che ne sfrutti appieno la potenza diventa un problema più che altro di costi.

AUDIO

Qui si entra in un campo incredibilmente variegato, forse ancora più  di quello della grafica.

La musica è un asset che può essere piuttosto pesante (per occupazione della memoria, per la decompressione e per il mix), per questo il suo trattamento può essere completamente diverso da macchina a macchina. Ad esempio, su Nintendo DS si usa molto il formato MOD (o XM), poiché consente una qualità eccellente con poca memoria usata e un basso costo computazionale per la decodifica. Purtroppo, ad oggi, è diventato un po’ difficile trovare persone che conoscano e sappiano usare i tracker (nonostante esistano programmi eccezionalmente moderni come Renoise).

Sulle console più potenti e sui PC, invece, non c’è problema nell’usare MP3 , OGG o qualunque formato di compressione che utilizzi modelli cocleari. Nonostante questo, potrebbero esserci delle situazioni (ad esempio per degli effetti sonori molto piccoli o particolari) in cui l’uso di WAV a 8 bit o a un basso sample rate potrebbe generare file più piccoli rispetto alle compressioni MP3, con la medesima qualità e senza il costo aggiuntivo della decompressione.

Tutti questi problemi, su PC, possono probabilmente essere del tutto ignorati (fintanto che l’audio non prende troppo tempo ad essere elaborato, caricato e decompresso), mentre su console sono un problema costante.

Direi che ho detto abbastanza per stimolare le vostre idee: per le domande vi lascio ai commenti.

Tutti i diritti di questo articolo sono riservati. Vietata la riproduzione.

10 comments on “Sviluppo PC e Console: una panoramica

  1. Prima di tutto mi complimento per l’articolo, hai fatto luce su molte cose che non pensavo minimamente. 🙂

    Solo una domanda anche se un pò banale, le CPU delle attuali console hanno processori con istruzioni CISC o sono rimasti RISC come nelle oldgen? Visto che in questa gen abbiamo visto che su ps3 è stato possibile installare Linux e le varie dashboard/XMB in game, mi è sempre spuntato questo dubbio. 😀

  2. Jay wrote:

    Solo una domanda anche se un pò banale, le CPU delle attuali console hanno processori con istruzioni CISC o sono rimasti RISC come nelle oldgen? Visto che in questa gen abbiamo visto che su ps3 è stato possibile installare Linux e le varie dashboard/XMB in game, mi è sempre spuntato questo dubbio.

    Mi viene il sospetto che non sia una domanda così banale, soprattutto per quel che riguarda l’architettura PS3. Il core di Cell dovrebbe essere in qualche modo PowerPC, da cui il probabilmente non eccessivo lavoro di porting di linux (la versione PowerPC esisteva già ed esiste ancora, in barba alla Apple che ha abbandonato l’architettura); il fatto è che ci sono anche le SPU, che bisogna vedere che tipo di instruction set hanno. Poi penso che sia un po’ spaccare il capello in quattro, a cercare di categorizzarlo con una classificazione forse ormai obsoleta…

  3. Mi sa che e’ roba che non posso dire 🙁 Pero’ credo che wikipedia possa risponderti 🙂

Leave a Reply