Porting degli engine 3D verso nuove API architetture.

[blade9722]

Ciao a tutti,

apro questo thread per discutere di una argomento emerso in un altro:

http://www.hwupgrade.it/forum/showthread.php?t=2016250&page=68

che, amio avviso, risulta interessante, ma stava mandando pesantemente off-topic il thread.

La questione riguarda quale fra le due operazioni sia piu' semplice:

a) effettuare il porting di un engine di rendering verso una API differente, ma sulla stessa architettura hardware

oppure

b) effettuare il porting verso una differente architettura hardware, ma che si appoggia alla stessa API

che la combinazione delle due (cioe' diversa API, diversa architettura) sia piu' complessa e' banale, e non e' oggetto di discussione.

La mia tesi e' che le API siano state pensate proprio per svincolare la programmazione dell'engine ad alto livello dall'hardware, rendendo il porting verso una differente architettura una operazione quasi gratuita. Per contro, adattare l'engine verso una API differente comporta di mettere mani pesantemente al codice. Per questo propendo per la b)

Per contro, Gaxel ha espresso una visione diversa: il porting verso una differente API e' una operazione di programmazione relativamente semplice. Piu' difficile risulta ottimizzare il codice in modo da sfruttare efficientemente le risorse hardware della nuova architettura. Per questo, propende per la a).

Cosa ne pensate a riguardo?

P.S. per i moderatori: riguardo la scelta della sezione, ho dato un'occhiata a quella relativa alla programmazione e alla computer graphics, ma le ho trovate molto piu' focalizzate sul supporto tecnico. La sezione relativa alle schede video e' dedicata all'hardware. Quella piu' adatta mi e' sembrata questa, visto che si parla di engine per giochi.

[Custode]

Pur non capendoci una acca di simili questioni, trovo l'argomento interessantissimo -pare un controsenso quanto appena scritto, vero? °__°- e spero la discussione possa avvantaggiarsi anche del parere di chi i giochi li programma.

Lascio a voi la parola e mi metto in ascolto :).

[II ARROWS]

Mooolto più facile cambiare il motore grafico se devi cambiare solo l'architettura. La cosa rimane vera fino a che si rimane nell'ambito della rasterizzazione, perchè se si passa al ray tracing va rifatto da capo in ogni caso l'intero motore grafico(tanto per lanciare il punto prima che qualcun altro lo chieda).

Se non devi toccare una riga di codice della pipeline è una sciocchezza perchè sarà l'implementazione delle API ad essere diversa, tutto quello che sarà da fare è limitarsi a modificare le variabili di sistema e piccole modifiche per sfruttare le caratteristiche diverse/più potenti delle piattaforme e introdurre vari livelli di dettaglio, operazione piuttosto semplice in quanto basta caricare elementi diversi in base al dettaglio scelto.

Di contro se cambi API non si tratta solamente di cambiare il nome delle funzioni che richiami perchè sicuramente la pipeline grafica e le funzionalità che ti offrono sono diverse. Quindi dovresti riscrivere quasi completamente il motore se ti va male. E ti va male soprattutto se hai fatto un ottimo lavoro sfruttando tutte le particolarità delle librerie.

Per questo Valve s'è scazzata, hanno costruito il Source Engine in DirectX sfruttandone caratteristiche e poggiandosi sull'architettura. Portare tutto in OpenGL non è così facile e richiede molto lavoro.
Per questo i motori multipiattaforma PARTONO multipiattaforma in modo da non sfruttare nessuna peculiarità, e se viene fatto non renderla vitale.



Comunque questo andrebbe nella sezione programmazione, sì.

[martinez1983]

Seguo con estremo interesse anche questo thread!!!!;)

[blade9722]

Mooolto più facile cambiare il motore grafico se devi cambiare solo l'architettura. La cosa rimane vera fino a che si rimane nell'ambito della rasterizzazione, perchè se si passa al ray tracing va rifatto da capo in ogni caso l'intero motore grafico(tanto per lanciare il punto prima che qualcun altro lo chieda).


Occhio che gli engine di rendering professionale in ray tracing sono puramente software, e non sfruttano le API.


Se non devi toccare una riga di codice della pipeline è una sciocchezza perchè sarà l'implementazione delle API ad essere diversa, tutto quello che sarà da fare è limitarsi a modificare le variabili di sistema e piccole modifiche per sfruttare le caratteristiche diverse/più potenti delle piattaforme e introdurre vari livelli di dettaglio, operazione piuttosto semplice in quanto basta caricare elementi diversi in base al dettaglio scelto.

Di contro se cambi API non si tratta solamente di cambiare il nome delle funzioni che richiami perchè sicuramente la pipeline grafica e le funzionalità che ti offrono sono diverse. Quindi dovresti riscrivere quasi completamente il motore se ti va male. E ti va male soprattutto se hai fatto un ottimo lavoro sfruttando tutte le particolarità delle librerie.

Per questo Valve s'è scazzata, hanno costruito il Source Engine in DirectX sfruttandone caratteristiche e poggiandosi sull'architettura. Portare tutto in OpenGL non è così facile e richiede molto lavoro.
Per questo i motori multipiattaforma PARTONO multipiattaforma in modo da non sfruttare nessuna peculiarità, e se viene fatto non renderla vitale.


Infatti, uno degli elementi della discussione fra me e Gaxel ha riguardato proprio il porting del Source Engine. Per lui non e' stato esteso alla PS3 per via della differente architettura hardware, ma questo varrebbe anche per XBOX 360, per me per via delle API, mentre sulla console Microsoft non c'e' questo problema.

Comunque questo andrebbe nella sezione programmazione, sì.

Ma, questa sezione e' piena di thread di utenti che postano frammenti di codice e chiedono aiuto. Forse andrebbe messo in "altre discussioni sull'informatica". Faccio richiesta ufficiale di spostamento nella sezione ritenuta opportuna.

[blade9722]

Dall'altro thread

Su Xbox, non credo che Microsoft permettesse una cosa del genere... l'os usato sfruttava una versione particolare di DirectX 8.1... e credo che ID abbia convertito il Tech 4 in D3D prima di portarlo su Xbox.

Mah, diciamo che questa e' una curiosita'. Puo' darsi che abbiano effettuato il porting dell'engine, ma non e' detto. A dispetto di quanto si dice in alcuni forum, il primo GLQuake puo' essere tranquillamente giocato su sistemi a 64bit, basta sovrascrivere il file OpenGL32.dll della directory del gioco con quello contenuto in windows/system. Ho citato questo solo per far capire come possa essere semplice aggiungere il supporto OpenGL al kernel di Xbox, purche' ovviamente ci sia anche nei driver per la GPU (e dovrebbe, visto che e' una Ge-Force 4). Non dare per scontato che Microsoft abbia implementato meccanismi di blocco di librerie di terze parti, non lo ha mai fatto. E' una pratica tipica di Apple.


Sul perdere il filo del discorso, è probabile, io comunque quando parlavo di "supporta anche OpenGL, quindi non ci vuole molto a fare il porting dell'API", intendevo PS3. Chiaro che se in Valve non vogliono implementare le OpenGL nel Source fanno quello che vogliono, ma il Source su PS3 gira tranquillamente, visto che Orange Box c'è anche per console Sony, solo che il porting lo ha fatto EA.


Gira tranquillamente non direi, visto che il porting e' stato molto criticato per le performance scadenti. Ancora, come fai a dire ad essere sicuro che EA abbia effettuato il porting dell'engine, e non il porting del gioco su un engine differente? Hai delle fonti a supporto della tesi o e' solo una tua supposizione?


Sul discorso API, ripeto che non sto facendo un discorso di hadware puro. Anche la sola gestione della memoria diversa tra Xbox360 e Windows, cosa che non dipende da nessuna API, ma dall'architettura propria del sistema, costringe ad allocare e sfruttare risorse in maniera diversa.

Per quanto ne so, le API grafiche servono per interfacciarsi con la scheda grafica, per eseguire quelle "semplici" operazioni che una volta facevano direttamente gli engine software... man mano che l'hardware si è evoluto, si è passato dal semplice T&L agli shader, e di conseguenza, dato che tutto quello che prima era fatto via software, ora viene fatto via hardware... le API si sono evolute. Ma restano una semplice interfaccia per informare l'hardware di cosa si vuole fare e in che maniera, OpenGL fatta in una maniera, D3D fatta in un altra (in realtà sono abbastanza simili), cambiando hardware, non dovrebbe cambiare nulla a livello di istruzioni (le API restano quelle), ma potrebbe cambiare a livello di cosa fare, quando e come.
__________________

[gaxel]

Dall'altro thread



Mah, diciamo che questa e' una curiosita'. Puo' darsi che abbiano effettuato il porting dell'engine, ma non e' detto. A dispetto di quanto si dice in alcuni forum, il primo GLQuake puo' essere tranquillamente giocato su sistemi a 64bit, basta sovrascrivere il file OpenGL32.dll della directory del gioco con quello contenuto in windows/system. Ho citato questo solo per far capire come possa essere semplice aggiungere il supporto OpenGL al kernel di Xbox, purche' ovviamente ci sia anche nei driver per la GPU (e dovrebbe, visto che e' una Ge-Force 4). Non dare per scontato che Microsoft abbia implementato meccanismi di blocco di librerie di terze parti, non lo ha mai fatto. E' una pratica tipica di Apple.

Può anche essere, effettivamente... DirectX 8 non piacevano a Carmack, che ha iniziato a fare apprezzamenti alle librerie MS da Direct X 9.


Gira tranquillamente non direi, visto che il porting e' stato molto criticato per le performance scadenti. Ancora, come fai a dire ad essere sicuro che EA abbia effettuato il porting dell'engine, e non il porting del gioco su un engine differente? Hai delle fonti a supporto della tesi o e' solo una tua supposizione?

A no, questo non lo so... però, mi sembra sempre più semplice convertire l'engine in Open GL che rifare tutto il gioco su un altro engine... poi tutto può essere. Certo è che se Valve l'ha fatto bene, alla fine si tratta di cambiare poco anche passando a un engine diverso... forse si fa prima, effettivamente.

[Ashgan83]

Mi sembra che il quesito non sussista, in quanto se delle API sono state sviluppate per un determinato hardware fare il porting diventa, per un programmatore, un'operazione banale. La risposta è b). Le api servono proprio per programmare ad alto livello, quindi dei dettagli implementativi dell'hardware sui cui gira te ne sbatti altamente. La a) è senza dubbio più impegnativa in quanto devi riscrivere tutto il codice in pratica.

[blade9722]

Mi sembra che il quesito non sussista, in quanto se delle API sono state sviluppate per un determinato hardware fare il porting diventa, per un programmatore, un'operazione banale. La risposta è b). Le api servono proprio per programmare ad alto livello, quindi dei dettagli implementativi dell'hardware sui cui gira te ne sbatti altamente. La a) è senza dubbio più impegnativa in quanto devi riscrivere tutto il codice in pratica.

Stavo per dire: hai invertito la corrispondenza fra i contenuti a) e b), poi mi sono reso conto che nel primo post ero io ad averli invertiti, l'ho corretto :D

[II ARROWS]

A no, questo non lo so... però, mi sembra sempre più semplice convertire l'engine in Open GL che rifare tutto il gioco su un altro engine...Scusa, ma non mi pare così complicato capire che è molto più facile usare quello che già c'è piuttosto che rifarlo da capo...

[blade9722]

Scusa, ma non mi pare così complicato capire che è molto più facile usare quello che già c'è piuttosto che rifarlo da capo...

Guarda che il porting di un gioco da un engine ad un altro non è una operazione così immediata. Textures e modelli li trasferisci subito, basta convertirli nel nuovo formato, se diverso. Gli shader però ti tocca riscriverli, visto che DirectX e OpenGL usano linguaggi diversi. Le animazioni non so. Dopodichè dovrai sistemare tutti i vari asset che definiscono il gioco, i vari trigger, script, etc...

Riguardo il caso dell'Orange Box, posso speculare su come farei io: probabilmente, se dovessi prender impegni per il porting di tutti i titoli Valve, il porting dell'engine a lungo termine sarebbe più efficiente. Se si tratta di uno o due titoli, potrebbe convenire il porting del gioco su un engine esistente.

Ad ogni modo, questa operazione non è proprio di pertinenza del thread.

[Xilema]

Ci vorrebbe il parere di Fek...

[II ARROWS]

Guarda che il porting di un gioco da un engine ad un altro non è una operazione così immediata. Textures e modelli li trasferisci subito, basta convertirli nel nuovo formato, se diverso. Gli shader però ti tocca riscriverli, visto che DirectX e OpenGL usano linguaggi diversi. Le animazioni non so. Dopodichè dovrai sistemare tutti i vari asset che definiscono il gioco, i vari trigger, script, etc...L'ultima frase la leviamo subito dicendo che se il lavoro è fatto bene, essendo una cosa indipendente dalla grafica, non la devi neppure toccare da lontano(tranne appunto nel caso di PS3 che utilizza una architettura strana).

Per il resto, è sicuramente meno dispendioso che dover convertire il motore grafico perchè queste cose le dovresti fare comunque...

[martinez1983]

Io mi sento di sposare la tesi b!!!!
Partendo dalla definizione di API,(interfaccia di programmazione di una applicazione) sono ogni insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per un determinato compito.
Le API permettono di evitare ai programmatori di scrivere tutte le funzioni dal nulla!!!
Inutile dire che se devi effettuare il porting di un engine di rendering verso una API differente la situazione sia molto complessa!!!

E poi scatta anche il vantaggio di conoscere già le API sulle quali hai già operato!!!


Magari se intervenisse una persona che i giochi li programma sarebbe perfetto!!(come detto da Custode)