Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Una scelta sofferta ma giusta...
23 views
Skip to first unread message
Gianpaolo Ingegneri
Jan 9, 2012, 5:44:41 PM1/9/12
to
Dopo l'entusiasmo per i risultati ottenuti di recente, mi sono riscontrato
con una dura realtà. Voler produrre un lavoro buono dal punto di vista
grafico è una pura utopia per il singolo individuo, chiunque esso sia. La
competizione nel settore è qualcosa di esasperante, puro autolesionismo. Non
puoi creare qualcosa di originale senza confrontarti con la marea di lavori
fatti da altri ed alla fine non sei neppure certo di aver fatto la scelta
giusta, perchè scopri che di documentazione ne esisteva un'altra marea... e
per cosa poi? Non stiamo parlando di fisica quantistica (che trovo
rilassante al confronto), ma di "semplice" computer grafica. Basta, ho la
nausea degli shader, della loro assurdità concettuale, delle 5000 e passa
schede grafiche sul mercato delle devi considerare mentre sviluppi con
quelle piccole sfumature e compromessi tra aspettative del pubblico e
risultato finale. La computer grafica ha raggiunto la sua massima entropia,
ormai si ragiona direttamente in watt. Non posso pensare di produrre un
lavoro da amatoriale e destinarlo a schede che superino i 95 watt, perchè
dovrei proporre della grafica che non mi posso permettere ed i costi
dell'hardware surclassano la qualità del prodotto. Fine del discorso.
Dopo aver implementato con successo la deferred lighting con tanto di
antialiasing msaa pseudo-fake inventato da me, mi sono reso conto che gli
altri obiettivi sarebbero stati troppo dispendiosi, come le migliaia di luci
sullo schermo ed ottimizzazione estrema del light-culling, ombre in tempo
reale, global illumination, SSAO, post processing effects, atmosferic
scattering, fft ocean simulator, etc... Niente, ho deciso di cambiare schema
per garantire la sopravvivenza del mio progetto, ho dovuto prendere la
sofferta decisione di accantonare momentaneamente le best features per
ritornare ad uno schema più limpido, puntando tutto su una grafica semplice
ed alla portata degli utenti che si accontentano delle pure e semplici idee.
Per il momento metterò da parte la questione delle luci da interni e mi
concentrerò sugli altri aspetti più videoludici, tra cui una migliore
gestione delle risorse, della fisica e delle animazioni.
con una dura realtà. Voler produrre un lavoro buono dal punto di vista
grafico è una pura utopia per il singolo individuo, chiunque esso sia. La
competizione nel settore è qualcosa di esasperante, puro autolesionismo. Non
puoi creare qualcosa di originale senza confrontarti con la marea di lavori
fatti da altri ed alla fine non sei neppure certo di aver fatto la scelta
giusta, perchè scopri che di documentazione ne esisteva un'altra marea... e
per cosa poi? Non stiamo parlando di fisica quantistica (che trovo
rilassante al confronto), ma di "semplice" computer grafica. Basta, ho la
nausea degli shader, della loro assurdità concettuale, delle 5000 e passa
schede grafiche sul mercato delle devi considerare mentre sviluppi con
quelle piccole sfumature e compromessi tra aspettative del pubblico e
risultato finale. La computer grafica ha raggiunto la sua massima entropia,
ormai si ragiona direttamente in watt. Non posso pensare di produrre un
lavoro da amatoriale e destinarlo a schede che superino i 95 watt, perchè
dovrei proporre della grafica che non mi posso permettere ed i costi
dell'hardware surclassano la qualità del prodotto. Fine del discorso.
Dopo aver implementato con successo la deferred lighting con tanto di
antialiasing msaa pseudo-fake inventato da me, mi sono reso conto che gli
altri obiettivi sarebbero stati troppo dispendiosi, come le migliaia di luci
sullo schermo ed ottimizzazione estrema del light-culling, ombre in tempo
reale, global illumination, SSAO, post processing effects, atmosferic
scattering, fft ocean simulator, etc... Niente, ho deciso di cambiare schema
per garantire la sopravvivenza del mio progetto, ho dovuto prendere la
sofferta decisione di accantonare momentaneamente le best features per
ritornare ad uno schema più limpido, puntando tutto su una grafica semplice
ed alla portata degli utenti che si accontentano delle pure e semplici idee.
Per il momento metterò da parte la questione delle luci da interni e mi
concentrerò sugli altri aspetti più videoludici, tra cui una migliore
gestione delle risorse, della fisica e delle animazioni.
mutek
Jan 11, 2012, 11:51:16 AM1/11/12
to
On Mon, 09 Jan 2012 23:44:41 +0100, Gianpaolo Ingegneri wrote:
...
E' un problema classico da un pò...ma non a caso ora scegli se fare brute
force nel mondo PC o concentrarti su una verticalizzazione del tipo: PS3/
Wii/Xbox360/iP*/DS/PSP ognuna rappresenta un mercato e dei potenziali
fruitori...
Sul lato PC vedo poche speranze in termini di risorse per ottimizzazioni
ed iniziative personali...
Piuttosto molla tutto prendi le SDL in C o i binding che vuoi e
concentrati sulla giocabilita.
mutek
...
>
> Dopo aver implementato con successo la deferred lighting con tanto di
> antialiasing msaa pseudo-fake inventato da me, mi sono reso conto che
> gli altri obiettivi sarebbero stati troppo dispendiosi, come le migliaia
> di luci sullo schermo ed ottimizzazione estrema del light-culling, ombre
> in tempo reale, global illumination, SSAO, post processing effects,
> atmosferic scattering, fft ocean simulator, etc... Niente, ho deciso di
> cambiare schema per garantire la sopravvivenza del mio progetto, ho
> dovuto prendere la sofferta decisione di accantonare momentaneamente le
> best features per ritornare ad uno schema più limpido, puntando tutto su
> una grafica semplice ed alla portata degli utenti che si accontentano
> delle pure e semplici idee. Per il momento metterò da parte la questione
> delle luci da interni e mi concentrerò sugli altri aspetti più
> videoludici, tra cui una migliore gestione delle risorse, della fisica e
> delle animazioni.
giocabilità.
> Dopo aver implementato con successo la deferred lighting con tanto di
> antialiasing msaa pseudo-fake inventato da me, mi sono reso conto che
> gli altri obiettivi sarebbero stati troppo dispendiosi, come le migliaia
> di luci sullo schermo ed ottimizzazione estrema del light-culling, ombre
> in tempo reale, global illumination, SSAO, post processing effects,
> atmosferic scattering, fft ocean simulator, etc... Niente, ho deciso di
> cambiare schema per garantire la sopravvivenza del mio progetto, ho
> dovuto prendere la sofferta decisione di accantonare momentaneamente le
> best features per ritornare ad uno schema più limpido, puntando tutto su
> una grafica semplice ed alla portata degli utenti che si accontentano
> delle pure e semplici idee. Per il momento metterò da parte la questione
> delle luci da interni e mi concentrerò sugli altri aspetti più
> videoludici, tra cui una migliore gestione delle risorse, della fisica e
> delle animazioni.
E' un problema classico da un pò...ma non a caso ora scegli se fare brute
force nel mondo PC o concentrarti su una verticalizzazione del tipo: PS3/
Wii/Xbox360/iP*/DS/PSP ognuna rappresenta un mercato e dei potenziali
fruitori...
Sul lato PC vedo poche speranze in termini di risorse per ottimizzazioni
ed iniziative personali...
Piuttosto molla tutto prendi le SDL in C o i binding che vuoi e
concentrati sulla giocabilita.
mutek
Davide Pasca
Jan 14, 2012, 12:35:15 AM1/14/12
to
On Tuesday, January 10, 2012 7:44:41 AM UTC+9, Gianpaolo Ingegneri wrote:
[...]
Se invece vuoi rimanere in proprio, allora meglio mirare piu' a dei titoli, piuttosto che dissipare troppa energia cercando di fare tutto. Ottimizzare per un PC generico e' un lavoro molto impegnativo, troppo per una persona che non deve fare solo quello.
La mia scelta come indipendente e' stata quella di puntare su iPhone (ed iPad a seguire). Lavoro principalmente su PC, ma ho un target molto meglio definito e questo semplifica le cose di molto.
mumble mumble
Davide
[...]
> scattering, fft ocean simulator, etc... Niente, ho deciso di cambiare schema
> per garantire la sopravvivenza del mio progetto, ho dovuto prendere la
> sofferta decisione di accantonare momentaneamente le best features per
> ritornare ad uno schema più limpido, puntando tutto su una grafica semplice
> ed alla portata degli utenti che si accontentano delle pure e semplici idee.
> Per il momento metterò da parte la questione delle luci da interni e mi
> concentrerò sugli altri aspetti più videoludici, tra cui una migliore
> gestione delle risorse, della fisica e delle animazioni.
Devo concordare. Per lavorare su progetti piu' ambiziosi, bisogna essere in una compagnia grande.. e guadagnare liberta' di lavorare su un certo tipo di cose.
> per garantire la sopravvivenza del mio progetto, ho dovuto prendere la
> sofferta decisione di accantonare momentaneamente le best features per
> ritornare ad uno schema più limpido, puntando tutto su una grafica semplice
> ed alla portata degli utenti che si accontentano delle pure e semplici idee.
> Per il momento metterò da parte la questione delle luci da interni e mi
> concentrerò sugli altri aspetti più videoludici, tra cui una migliore
> gestione delle risorse, della fisica e delle animazioni.
Se invece vuoi rimanere in proprio, allora meglio mirare piu' a dei titoli, piuttosto che dissipare troppa energia cercando di fare tutto. Ottimizzare per un PC generico e' un lavoro molto impegnativo, troppo per una persona che non deve fare solo quello.
La mia scelta come indipendente e' stata quella di puntare su iPhone (ed iPad a seguire). Lavoro principalmente su PC, ma ho un target molto meglio definito e questo semplifica le cose di molto.
mumble mumble
Davide
Max Coorp
Jan 14, 2012, 9:00:43 AM1/14/12
to
> Devo concordare. Per lavorare su progetti piu' ambiziosi, bisogna essere
> in una compagnia grande.. e guadagnare liberta' di lavorare su un certo
> tipo di cose.
> Se invece vuoi rimanere in proprio, allora meglio mirare piu' a dei
> titoli, piuttosto che dissipare troppa energia cercando di fare tutto.
> Ottimizzare per un PC generico e' un lavoro molto impegnativo, troppo per
> una persona che non deve fare solo quello.
in un progetto serio c'è molto altro da definire. Di recente ho trovato un
programmino che edita le mappe di New Super Mario Bros Wii su pc, si chiama
Reggie!. Visto che è completo e fa riferimento ad un titolo famoso che
implementa delle piene features di gioco, me lo sto studiando un po' per
migliorare il mio lavoro in questa direzione. Sto progettando dei templates
generici per la gestione di tiles, items, enemies e quant'altro possa
servire all'interno di un gioco, parallelamente allo sviluppo di un editor
di mappe 2D e 3D. Il mio scopo è quello di creare un editor generico per la
creazione di risorse utili da poter interfacciare al mio framework, così da
minimizzare la quantità di lavoro per la creazione di un titolo completo.
Anche in questa direzione il lavoro da fare è tremendo, per cui mi sono reso
conto che stavo perdendo tempo in una cosa troppo pesante quanto inutile.
Diversamente da come dicono molti, sono convinto che per garantire una buona
giocabilità serva molta più programmazione e pianificazione di quanta ne
possa servire per la grafica da urlo, il fatto è che la grafica troppo
avanzata ruba del tempo prezioso e alla fine resta uno sfizio per pochi
intenditori di schede pesanti o per un pubblico di nicchia, mentre senza la
giocabilità lo stesso gioco non ha motivo di esistere. Dal mio punto di
vista, la programmazione di petto con SDL e C non è sufficiente a garantire
un titolo che abbia la minima possibilità di successo. Per fare un esempio,
si rischia di spendere dei mesi per poi ritrovarsi con qualcosa del genere:
http://www.youtube.com/watch?v=B2XtgBCmJ_M
http://www.youtube.com/watch?v=F2LUZhgay8w
http://www.youtube.com/watch?v=KVW57pUiSe4
Com'è possibile vedere, la giocabilità in questi casi non c'entra neppure
con la grafica ma con una scarsa dinamica di gioco, che spesso può derivare
dalla mancanza di tempo e di risorse, soprattutto se si devono programmare
sempre le stesse cose di sana pianta. Secondo me questi esempi rappresentano
il limite della programmazione di petto con poche risorse, nonostante
l'impegno e la buona volontà. Per par condicio, metto nel mucchio degli
esempi negativi anche un gioco che ho fatto in passato a 20 anni, quando
anch'io programmavo di petto, creando il codice che mi serviva quando mi
serviva:
http://www.youtube.com/watch?v=OcRTRsZGpL8
Al contrario, la programmazione con sviluppo parallelo di framework mi ha
aiutato a produrre dei lavori di gran lunga superiori dal punto di vista
tecnico, con la comodità che posso sempre riciclare il codice per gli altri
progetti.
Gianpaolo Ingegneri
Jan 14, 2012, 9:03:52 AM1/14/12
to
> Devo concordare. Per lavorare su progetti piu' ambiziosi, bisogna essere
> in una compagnia grande.. e guadagnare liberta' di lavorare su un certo
> tipo di cose.
> Se invece vuoi rimanere in proprio, allora meglio mirare piu' a dei
> titoli, piuttosto che dissipare troppa energia cercando di fare tutto.
> Ottimizzare per un PC generico e' un lavoro molto impegnativo, troppo per
> una persona che non deve fare solo quello.
Davide Pasca
Jan 15, 2012, 11:09:25 AM1/15/12
to
On Saturday, January 14, 2012 11:03:52 PM UTC+9, Gianpaolo Ingegneri wrote:
> Com'è possibile vedere, la giocabilità in questi casi non c'entra neppure
> con la grafica ma con una scarsa dinamica di gioco, che spesso può derivare
> dalla mancanza di tempo e di risorse, soprattutto se si devono programmare
> sempre le stesse cose di sana pianta. Secondo me questi esempi rappresentano
Capisco quello che dici, ma secondo me ci sono comunque tante cose che vanno riscritte per ogni gioco. La logica di gioco e la UI sono quelle cose per le quali si possono avere dei fondamenti, ma ad un livello piu' alto richiedono comunque tanto codice custom.
> Com'è possibile vedere, la giocabilità in questi casi non c'entra neppure
> con la grafica ma con una scarsa dinamica di gioco, che spesso può derivare
> dalla mancanza di tempo e di risorse, soprattutto se si devono programmare
> sempre le stesse cose di sana pianta. Secondo me questi esempi rappresentano
Quello che ho notato e' che le features effettivamente utili ad un gioco dipendono in parte dai gusti (metodi propri) ed in parte da come si evolve durante la scrittura di un gioco e poi ad ogni nuovo titolo, quando c'e' piu' spazio per ripensare alcune cose e provarne di nuove.
Per cui, in sostanza vedo un framework come una cosa personale e che dovrebbe essere sviluppata secondo le necessita' di un gioco, piuttosto che cercando di anticiparle piu' di tanto.
mumble mumble
Davide
Gianpaolo Ingegneri
Jan 15, 2012, 5:05:28 PM1/15/12
to
> Per cui, in sostanza vedo un framework come una cosa personale e che
> dovrebbe essere sviluppata secondo le necessita' di un gioco, piuttosto
> che cercando di anticiparle piu' di tanto.
programmatori sono incoerenti perchè puntano subito al risultato e non
riescono a produrre un framework le cui componenti possano essere
riutilizzate in futuro. Poi è vero che certe caratteristiche non si possono
anticipare però è possibile fornire un certo numero di utilità per
semplificare le necessità più ricorrenti, il resto te lo programmi da solo
ma facendo molta meno fatica. Col mio framework posso spaziare
tranquillamente dal clone di pacman allo shotemup in soggettiva con uno
sforzo di programmazione sicuramente inferiore alla semplice programmazione
di petto, o senza l'onere di dover ricostruire un framework da capo, quanto
meno per la gestione delle risorse di base. Forse il mio vantaggio deriva
dall'aver spaziato in argomenti di ingegneria del software che non
riguardano soltanto lo sviluppo dei videogames, ma qualsiasi tipo di
applicazione. Se ad esempio dovessi fare un software di video sorveglianza o
per l'analisi dei trend commerciali, utilizzerei lo stesso framework al
quale sto lavorando.
Davide Pasca
Jan 20, 2012, 5:52:47 AM1/20/12
to
On Monday, January 16, 2012 7:05:28 AM UTC+9, Gianpaolo Ingegneri wrote:
[...]
[...]
> ma facendo molta meno fatica. Col mio framework posso spaziare
> tranquillamente dal clone di pacman allo shotemup in soggettiva con uno
> sforzo di programmazione sicuramente inferiore alla semplice programmazione
> di petto, o senza l'onere di dover ricostruire un framework da capo, quanto
> meno per la gestione delle risorse di base. Forse il mio vantaggio deriva
> dall'aver spaziato in argomenti di ingegneria del software che non
> riguardano soltanto lo sviluppo dei videogames, ma qualsiasi tipo di
> applicazione. Se ad esempio dovessi fare un software di video sorveglianza o
> per l'analisi dei trend commerciali, utilizzerei lo stesso framework al
> quale sto lavorando.
umm sinceramente il tuo discorso non mi convince.. il tuo vantaggio e' rispetto a chi ?
> tranquillamente dal clone di pacman allo shotemup in soggettiva con uno
> sforzo di programmazione sicuramente inferiore alla semplice programmazione
> di petto, o senza l'onere di dover ricostruire un framework da capo, quanto
> meno per la gestione delle risorse di base. Forse il mio vantaggio deriva
> dall'aver spaziato in argomenti di ingegneria del software che non
> riguardano soltanto lo sviluppo dei videogames, ma qualsiasi tipo di
> applicazione. Se ad esempio dovessi fare un software di video sorveglianza o
> per l'analisi dei trend commerciali, utilizzerei lo stesso framework al
> quale sto lavorando.
Il mondo e' grande e' c'e' tanta gente capace su tutti i fronti.. c'e' parecchio lavoro da parte di una sfilza di persone molto capaci dietro ogni gioco (e non). E sono tutte persone che comprendono il concetto di framework.. infatti ogni casa di sviluppo ha uno o piu' frameworks (o usa soluzioni prefabbricate quali Unreal Engine, Unity, etc.).
Probabilmente sono in pochi ad avere un framework che integri OpenCV.. ma la complessita' che si puo' aggiungere ad un framework spazia molto in lungo ed in largo.
Per ogni feature che si ha.. c'e' sempre qualcosa in piu' di cui c'e' bisogno, o una estensione ottimizzazione che si rivela necessaria e che richiede uno sforzo addizionale.
Oltre al fatto che un framework per me e' veramente la punta dell'iceberg se si parla di realizzare un videogioco.
Un gioco di una complessita' modesta, richiede molto impegno su tanti altri fronti.. quali lo stabilire dei formati comuni ed un metodo di lavoro con gli artists (grafica, animazione, audio), level designers, gestione dell'interfaccia, gameplay (con qualche forma di AI), features di editing in-game o tramite editors esterni.
Sono belle rogne.. ed avere un framework e' una cosa importante, ma non e' il grosso del lavoro.. almeno secondo me.
mumble mumble
Davide
Gianpaolo Ingegneri
Jan 20, 2012, 8:09:43 AM1/20/12
to
> umm sinceramente il tuo discorso non mi convince.. il tuo vantaggio e'
> rispetto a chi ?
dipendere da altri, in generale.
> Il mondo e' grande e' c'e' tanta gente capace su tutti i fronti.. c'e'
> parecchio lavoro da parte di una sfilza di persone molto capaci dietro
> ogni gioco (e non). E sono tutte persone che comprendono il concetto di
> framework.. infatti ogni casa di sviluppo ha uno o piu' frameworks (o usa
> soluzioni prefabbricate quali Unreal Engine, Unity, etc.).
perplessità nei confronti del mio lavoro per cui non ti biasimo, anzi, sono
contento che sia così, perchè significa che sto facendo qualcosa di diverso.
Però ti invito a usare una logica molto semplice prima di giudicare
negativamente il mio lavoro. Quando dici che gli altri hanno il loro
framework dimostra che non esiste ancora un framework in grado di coprire le
caratteristiche più importanti a tal punto che le software house, in alcuni
casi, invece di usare un lavoro di partenza decidono di buttare giù tutto
per ricominciare da zero con un framework proprietario. E' praticamente lo
stesso che ho fatto io, ciò dunque non conferma e non nega la validità del
mio lavoro. Eppoi ti ci voglio a progettare un software di video
sorveglianza con Unreal Engine o Unity, non sono neppure gli esempi
migliori.
> Probabilmente sono in pochi ad avere un framework che integri OpenCV.. ma
> la complessita' che si puo' aggiungere ad un framework spazia molto in
> lungo ed in largo.
abbia integrazione OpenCV, OpenAL, Ogg Vorbis, DevIL, FreeType, OpenGL,
Assimp, Bullet, etc, programmabili con quattro righe di codice nella main.
Ti sorprenderai: non ne esiste uno. Nel mio caso potrei fare anche un
porting per DirectX (perchè ho gli abstraction layer) e spostarmi su Xbox
360 e su PSP3, oppure integrare facilmente Point Cloud Library e Kinect. Per
non parlare del valore che può avere in ambiente accademico, lo so per
esperienza diretta.
> Oltre al fatto che un framework per me e' veramente la punta dell'iceberg
> se si parla di realizzare un videogioco.
Un gioco di una complessita' modesta, richiede molto impegno su tanti altri
fronti.. quali lo stabilire dei formati comuni ed un metodo di lavoro con
gli artists (grafica, animazione, audio), level designers, gestione
dell'interfaccia, gameplay (con qualche forma di AI), features di editing
in-game o tramite editors esterni.
artistico di cui parli è decretato dalla bontà del progetto su cui fa
affidamento che non è affatto la punta dell'iceberg, ma la base di partenza.
Però come dicevo prima, sono punti di vista, perchè se tu hai trovato un
modo rapido per sviluppare cloni di outrun o di quake usando tot. framework
con la tua scaletta personale dei preferiti, ovviamente trattandosi di
riutilizzare il lavoro degli altri l'importanza che dai è quella della punta
dell'iceberg, ma per me è un discorso diverso. Per me lo sviluppo di giochi
è una parte marginale del mio percorso e probabilmente mi ci dedicherò quel
tanto che basta per quel minimo di diffusione iniziale, parallelamente allo
sviluppo di applicazioni per la computer grafica, visione artificiale,
elaborazione del suono, videosorveglianza, progettazione, montaggio video,
eccetera...
Davide Pasca
Jan 20, 2012, 5:01:32 PM1/20/12
to
On Friday, January 20, 2012 10:09:43 PM UTC+9, Gianpaolo Ingegneri wrote:
[...]
[...]
> Già, hai ragione, se fossi al posto tuo avrei gli stessi dubbi e le stesse
> perplessità nei confronti del mio lavoro per cui non ti biasimo, anzi, sono
> contento che sia così, perchè significa che sto facendo qualcosa di diverso.
> Però ti invito a usare una logica molto semplice prima di giudicare
> negativamente il mio lavoro. Quando dici che gli altri hanno il loro
> framework dimostra che non esiste ancora un framework in grado di coprire le
> caratteristiche più importanti a tal punto che le software house, in alcuni
Ma io mica volevo giudicare il tuo lavoro negativamente 8)
> perplessità nei confronti del mio lavoro per cui non ti biasimo, anzi, sono
> contento che sia così, perchè significa che sto facendo qualcosa di diverso.
> Però ti invito a usare una logica molto semplice prima di giudicare
> negativamente il mio lavoro. Quando dici che gli altri hanno il loro
> framework dimostra che non esiste ancora un framework in grado di coprire le
> caratteristiche più importanti a tal punto che le software house, in alcuni
Il fatto che non ci sia un framework comune per tutti e' una cosa naturale.
Con un code-base si arriva fino ad un certo punto e poi ci si ritrova davanti ad un cambio generazionale di metodi di sviluppo del software e soprattutto ad hardware diversi.
E' un ciclo inesorabile di ogni software o API.. che prima o poi cominciano a mostrare i segni del tempo.
Basta guardare la storia tortuosa di OpenGL che sotto certi aspetti ha perso terreno perche' non si e' evoluta cosi' come e' successo per Direct3D ..che ad ogni versione introduce parecchi cambiamenti e talvolta nuovi paradigmi.
Tutte cose che un layer sopra queste API in un modo o nell'altro deve esporre con i compromessi del caso.
> No, non sono pochi, non ne esiste neppure uno. Trovami un solo framework che
> abbia integrazione OpenCV, OpenAL, Ogg Vorbis, DevIL, FreeType, OpenGL,
> Assimp, Bullet, etc, programmabili con quattro righe di codice nella main.
Quanto un framework sia poi potente dipende da come si comporta "su strada" e sull'estensibilita' futura.
Hai menzionato la PS3.. ma la parte difficile della PS3 e' programmare i chip custom.
Su PS3 e' in voga usare CPU per rasterizzare e SPU per fare deferred shading "a mano". Questo tipo di customizzazzioni specifiche sono cose che fanno la differenza nel campo dei giochi.
Se il tuo framework dovesse essere portato su PS3, una delle prime necessita' sarebbe quella di ottimizzare il tutto per i limiti della GPU specifica si quella console. Ovvero il fill-rate relativamente basso e la complessita' aggiunta per ottenere buona performance quando si uploadano buffers di variabili uniformi (problema noto della GPU NVidia su PS3).
..questo e' solo un esempio sulla necessita' di customizzare (se non riscrivere parti) un framework.
Talvolta l'interfaccia stessa diventa inadeguata. Ad esempio per questioni di ottimizzazione si decide che bisogna accettare un nuovo tipo di formato di vertici per una mesh, oppure un sistema asincrono di upload di textures.. le possibilita' sono infinite.
> Ti sorprenderai: non ne esiste uno. Nel mio caso potrei fare anche un
> porting per DirectX (perchè ho gli abstraction layer) e spostarmi su Xbox
> 360 e su PSP3, oppure integrare facilmente Point Cloud Library e Kinect. Per
> non parlare del valore che può avere in ambiente accademico, lo so per
> esperienza diretta.
Diciamo che servirebbe qualche riscontro pratico per farsi 2 conti a posteriori.
> Stiamo parlando di cose diverse. Dal mio punto di vista, tutto il lavoro
> artistico di cui parli è decretato dalla bontà del progetto su cui fa
> affidamento che non è affatto la punta dell'iceberg, ma la base di partenza.
> Però come dicevo prima, sono punti di vista, perchè se tu hai trovato un
> modo rapido per sviluppare cloni di outrun o di quake usando tot. framework
> con la tua scaletta personale dei preferiti, ovviamente trattandosi di
> riutilizzare il lavoro degli altri l'importanza che dai è quella della punta
> dell'iceberg, ma per me è un discorso diverso. Per me lo sviluppo di giochi
Il mio lavoro principale e' sempre stato quello di sviluppo di sistema engine 3D in dipartimenti di R&D. Sono io il primo a programmare le cose a basso livello.
Il mio gioco Final Freeway somiglia ad Out Run ma programmazione e grafica sono completamente originali (visto che ci siamo, menziono anche Fractal Combat che abbiamo rilasciato qualche mese fa -> http://oyatsukai.com/fractal-combat )
Ma questo non e' il mio punto di vista ora.. quando dico che tutti hanno un framework, mi riferisco a tutto il mondo del game dev.
Lavoro nell'industria di video giochi da parecchio tempo ed il mio lavoro e' sempre stato intorno allo sviluppo di engines/frameworks. Quindi non avrei nessun' interesse a sminuire il valore di queste cose ..ma se devo essere onesto, realizzando un gioco di una certa complessita' un framework e' solo la base.
Spero che il mio intervento non appaia come un tentativo di sminuire il tuo lavoro, ma piuttosto per inquadrare lo scopo di un framework nel contesto di un gioco/applicazione 8)
Davide
Gianpaolo Ingegneri
Jan 31, 2012, 3:17:16 PM1/31/12
to
> Spero che il mio intervento non appaia come un tentativo di sminuire il
> tuo lavoro, ma piuttosto per inquadrare lo scopo di un framework nel
> contesto di un gioco/applicazione 8)
soprattutto in tempi moderni, ma quando ho iniziato questo framework come
cammino individuale, ricordo che tutto ciò di cui stiamo parlando adesso non
esisteva neppure (a quei tempi non esisteva neppure la ps3). Nel frattempo
sono usciti molti lavori che hanno a dir poco annientato tutta la miriade di
frameworks vari ed engine sviluppati da amatoriali ed affermato solo le
realtà più forti. Una delusione grossa ad esempio mi è arrivata dalla
consapevolezza che il mio framework in buona parte non ha alcun senso su
iPhone, perchè possiede già il suo framework ottimizzato per la piattaforma.
Come dici giustamente anche le versioni XBox e PS3 richiederebbero un
discreto lavoro di ottimizzazione, anche se in questo caso ci sarebbe molto
meno da lavorare e molto di più da guadagnare. Allo stato attuale, il mio
framework ha senso solo su pc e si propone come un concorrente di QT, ma non
solo. Probabilmente per rendermi compatibile con altre piattaforme dovrei
rivisitare molte parti e trasformare il framework in una serie di librerie,
ogniuna per la gestione di ogni requisito in particolare. Anche perchè, come
ho già detto, è una collezione piuttosto carina di algoritmi che non devo
più riprogrammare da capo. E' vero che ci sono molte librerie in giro che
fanno la qualunque, ma ho notato che in tutte quante c'è poca coerenza nello
stile di programmazione e c'è sempre da faticare parecchio. Ad esempio per
OpenAL ho dovuto fare un lavoro tremendo per aprire un suono da file ed
ascoltarlo in tempo reale, aggiornando allo stesso tempo le sorgenti così da
renderle coerenti con la traccia che andava letta ogni quarto di secondo.
Una fesseria ad esempio è che devi gestire una sorgente per ogni suono,
mentre la sorgente dovrebbe essere uno speaker nell'ambiente 3d che emette
suoni. Se vuoi implementare questo, devi gestire a manina le liste di suoni
con un thread che si preoccupa di aggiornare tutte le esecuzioni messe in
attesa, e non è implementato nativamente da OpenAL, stesso dicasi per
l'ascolto in tempo reale di Ogg Vorbis. In generale, ho sempre trovato delle
lacune importanti nei vari framework nella gestione coerente di collezioni
di oggetti e serializzazione. Una libreria che si avvicina parecchio al
concept del mio framework è CoreLibrary/CVML, sulla quale sono state
costruite diverse applicazioni di visione artificiale, tra cui c'è la
possibilità di trasmettere da un client ad un server degli oggetti con poche
righe di codice. Ovviamente anche questo ottimo progetto è stato
abbandonato, tuttavia includerò alcune funzionalità all'interno del mio
framework.
Davide Pasca
Feb 1, 2012, 2:59:14 PM2/1/12
to
On Wednesday, February 1, 2012 5:17:16 AM UTC+9, Gianpaolo Ingegneri wrote:
[...]
[...]
> realtà più forti. Una delusione grossa ad esempio mi è arrivata dalla
> consapevolezza che il mio framework in buona parte non ha alcun senso su
> iPhone, perchè possiede già il suo framework ottimizzato per la piattaforma.
Per iPhone c'e' un SDK ed un ambiente di sviluppo. Ma si puo' programmare a qualsiasi livello (o quasi).
> consapevolezza che il mio framework in buona parte non ha alcun senso su
> iPhone, perchè possiede già il suo framework ottimizzato per la piattaforma.
Ovvero, per le applicazioni con native look&feed e' chiaramente necessario usare la sua API per gestire la GUI e addirittura usare Objective-C.
Pero' si puo' tranquillamente mixare Objective-C/C++ con C/C++ (Obj-C e Obj-C++ sono dei superset di C e C++).
Nel caso dei giochi, specie multi-piattaforma, molti usano principalmente C++ con OpenGL e OpenAL.
Questo e' quello che faccio io.. e per questo con il tempo ho accumulato un framework che funziona anche su PC, dove faccio il grosso dello sviluppo. Mentre i target rimangono iOS e Android.
Quindi anche su iPhone c'e' spazio per frameworks ed engined alternativi.. infatti molti dei giochi famosi usano cocos2D e Box2D, Unity, UDK. Tutte soluzioni di terze parti.
> Una fesseria ad esempio è che devi gestire una sorgente per ogni suono,
> mentre la sorgente dovrebbe essere uno speaker nell'ambiente 3d che emette
> suoni. Se vuoi implementare questo, devi gestire a manina le liste di suoni
> con un thread che si preoccupa di aggiornare tutte le esecuzioni messe in
> attesa, e non è implementato nativamente da OpenAL, stesso dicasi per
> l'ascolto in tempo reale di Ogg Vorbis. In generale, ho sempre trovato delle
Riguardo allo streaming tipo Ogg Vorbis. Questa e' una di quelle cose che su iPhone faccio usando una libreria di sistema (comunque uso m4a o mp3), perche' le librerie di sistema sono particolarmente ottimizzate e usano hardware o instruction-set specifici per questo tipo di cose (dopo tutto un iPhone e' anche un iPod).
Quindi questo e' un caso dove per ragioni di performance uno tutto sommato potrebbe preferire usare una API di sistema per una piattaforma specifica.
mumble mumble
Davide
0 new messages