Un piccolo passo per l'informatica, un grande passo per GM
- ball-man_3000
- Moderatore
- Messaggi: 1263
- Iscritto il: 26/08/2009, 13:42
- Specialità: Contare con le dita
- Uso: GM:Studio 2
- Località: Bologna
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
ma GM non ha il limitatore per gli FPS?
Quattro corde sono meglio
- civic71
- GMI Advanced
- Messaggi: 2210
- Iscritto il: 23/10/2003, 17:31
- Specialità: Risotto con zucchine
- Uso: GM:Studio 1.4 Pro
- Località: Jesolo (venezia)
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
Forte , sopratutto l'ombra che viene indirizzata anche sulla cassa
ball-man Spoiler : è favoloso
ball-man Spoiler : è favoloso
- gameplay_extreme
- GMI VIP
- Messaggi: 3824
- Iscritto il: 13/11/2010, 16:23
- Uso: GM:Studio 2
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
il limitatore lo imposti come vuoi (vedi variabile room_speed), poi c'è il caso in cui il codice viene portato avanti tutto in un ciclo, in quel caso il limitatore FPS non c'è propio...ball-man_3000 ha scritto:ma GM non ha il limitatore per gli FPS?
il problema più che il limitatore FPS è il limite di GM e il limite del PC...
clicca sul logo qui sopra per info e download riguardo ai miei software o per sapere come si crea un videogioco!
iscriviti qui gratuitamente a GMI !
Spoiler
-
- Admin
- Messaggi: 12355
- Iscritto il: 19/08/2009, 16:20
- Specialità: Programmazione 3D
- Uso: GM:Studio 2
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
Cavolo ma tenere il pc aggiornato non dovrebbe essere la cosa primaria da fare?mac12 ha scritto:ho scariato questo ed ora funziona!!!
Già, purtroppo gmstudio è perfino molto più lento di gm8.1 di base per ignote ragioni. E dire che una volta mi andava più veloce ma se non lo peggiorano non sono contentigameplay_extreme ha scritto:il problema più che il limitatore FPS è il limite di GM e il limite del PC...
Comunque credo che con le dovute precauzioni visti i risultati sia un'effetto applicabile in un gioco, chiaramente limitando il numero di luci che castano ombre e cose di questo tipo. Essendo totalmente realtime rende il tutto facilmente scalabile. Non sarà molto complesso fare impostazioni di qualità del gioco.
Certo aggiungendoci un soffitto e anch'esso che riceverà ombre gli fps caleranno in fretta ma i pc più cazzuti dovrebbero farcela. Come ho detto la maggior parte della colpa è la lentezza di GM. Basta considerare che una room vuota e finestra rimpicciolita al minimo(per azzerare il draw time) passiamo dai 2000 fps di gm8.1 ai 200-300 di gmstudio. Osceno
Mah, secondo me è più bello vederlo indirizzare su se stesso.civic71 ha scritto:Forte , sopratutto l'ombra che viene indirizzata anche sulla cassa
Ogni oggetto può castare ombre ed ogni oggetto può ricevere quelle di tutti gli altri oggetti(e pure se stesso)! Non ci sono limitazioni.
Comunque a te funziona? Provalo magari ti va, al contario di njine qua non uso chissà quali robe moderne e cazzute.
In futuro vedrò di fare qualcosa di più serio ma comunque leggero:
http://http.developer.nvidia.com/GPUGem ... _ch08.html
http://http.developer.nvidia.com/GPUGem ... ter17.html
Senza la nvidia con i suoi papers non so come farei <3
Time to feel, time to believe
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
- mac12
- Membro d'elite
- Messaggi: 1124
- Iscritto il: 18/09/2012, 17:32
- Specialità: programmazione
- Uso: GameMaker 8.1
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
ho formattato di recente.Jak ha scritto: Cavolo ma tenere il pc aggiornato non dovrebbe essere la cosa primaria da fare?
Spoiler
-
- Admin
- Messaggi: 12355
- Iscritto il: 19/08/2009, 16:20
- Specialità: Programmazione 3D
- Uso: GM:Studio 2
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
Dimenticavo che il discorso "pieno schermo" non è esatto visto che la schermata è ruotabile e si può fissare per terra quindi tutti i pixel renderizzati ricevono ombre.
Comunque mi va dai 90 ai 100 fps senza blur ed il risultato è comunque ottimo essendo la lightmap molto precisa.
Con 256x256 stranamente non cambia nulla, segno che il problema sta altrove.
Interessante anche scoprire che con gli oggetti che non ricevono ne luce ne ombre ne nulla pesa praticamente uguale.
Il solo disegno della maschera mi toglie 5-8 fps, brutta roba il fillrate.
...Interessante anche scoprire che il solo set/reset del target della surface della luce(solo quelle due funzioni) mi cava una decina di fps
E come window_set_caption sia altrettanto pesante
Ho due oggetti in totale e disabilitato completamente step e draw event di entrambi, poi verificato con room vuota con un solo oggetto che disegna gli fps e mi viene fuori un bellissimo 135 fps contro i buoni vecchi 800-900 fps con gm8.1 (room completamente visibile)
Bel lavoro yoyogames.
Quindi a parte questo il mio effetto in se non è particolarmente pesante, è GMStudio che diventa osceno ogni giorno di più.
Comunque mi va dai 90 ai 100 fps senza blur ed il risultato è comunque ottimo essendo la lightmap molto precisa.
Con 256x256 stranamente non cambia nulla, segno che il problema sta altrove.
Interessante anche scoprire che con gli oggetti che non ricevono ne luce ne ombre ne nulla pesa praticamente uguale.
Il solo disegno della maschera mi toglie 5-8 fps, brutta roba il fillrate.
...Interessante anche scoprire che il solo set/reset del target della surface della luce(solo quelle due funzioni) mi cava una decina di fps
E come window_set_caption sia altrettanto pesante
Ho due oggetti in totale e disabilitato completamente step e draw event di entrambi, poi verificato con room vuota con un solo oggetto che disegna gli fps e mi viene fuori un bellissimo 135 fps contro i buoni vecchi 800-900 fps con gm8.1 (room completamente visibile)
Bel lavoro yoyogames.
Quindi a parte questo il mio effetto in se non è particolarmente pesante, è GMStudio che diventa osceno ogni giorno di più.
Time to feel, time to believe
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
- Prometeo
- Membro d'elite
- Messaggi: 1258
- Iscritto il: 15/09/2010, 12:36
- Specialità: Grafico Progammatore
- Uso: GameMaker 8.1
- Località: Italia
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
ma è il mio lucertolone!!... è stupendo jak, complimenti.... appena posso ti faccio una versione del lucertolone più dettagliata come mi avevi chiesto, abbi pazienza.
Il dolore che i limiti delle cose c'impongono, cioè a dire il mal essere del desiderio non soddisfatto, il senso del non potere tutto, ci dà il sentimento e l'idea del tutto. Il limite diventa indizio. E la più larga via verso l'infinito è il dolore. [Niccolò Tommaseo]
-
- Admin
- Messaggi: 12355
- Iscritto il: 19/08/2009, 16:20
- Specialità: Programmazione 3D
- Uso: GM:Studio 2
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
Grazie! Aspettavo proprio un tuo commento, ed il fatto che sia corto e coinciso mi onora, visto quanto chiaccheri significa che non hai veramente nulla da ridire.
Questo è chiaramente solo il principio, ho altre cosucce in mente (SSAO) e non vedo l'ora di vederle tutte assieme.
Prenditi pure tutto il tempo che ti serve.
Questo è chiaramente solo il principio, ho altre cosucce in mente (SSAO) e non vedo l'ora di vederle tutte assieme.
Chiaro, il tuo lucertolone è presente in ogni mio progetto/test/quel che è. E' la mascotte ufficiale. Certo il modello così semplice senza animazioni nella sua posa semplice non è certo il migliore per provare effetti di questo tipo ma per ora mi accontento.Prometeo ha scritto:ma è il mio lucertolone!!...
Non vedo l'ora!Prometeo ha scritto:appena posso ti faccio una versione del lucertolone più dettagliata come mi avevi chiesto, abbi pazienza.
Prenditi pure tutto il tempo che ti serve.
Time to feel, time to believe
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
Re: Un piccolo passo per l'informatica, un grande passo per
Tipo l'orco di ogreJak ha scritto:Chiaro, il tuo lucertolone è presente in ogni mio progetto/test/quel che è. E' la mascotte ufficiale. Certo il modello così semplice senza animazioni nella sua posa semplice non è certo il migliore per provare effetti di questo tipo ma per ora mi accontento.Prometeo ha scritto:ma è il mio lucertolone!!...
-
- Admin
- Messaggi: 12355
- Iscritto il: 19/08/2009, 16:20
- Specialità: Programmazione 3D
- Uso: GM:Studio 2
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
E vai con l'ambient occlusion!
Stavolta però ho copia/incollato parecchio. Certo ho dovuto fare moltissimi aggiustamenti ma diciamo che buona parte del merito è anche di altri.
Nel fare ciò ho anche scoperto come migliorare la qualità della depthmap (meno errori nel calcolo della luce)
L'immagine che vedete sopra parte completamente bianca senza alcuna texture ne luce, non vedo l'ora di vederlo in una ambientazione reale con un po di blur per ridurre gli artefatti.
Chiaramente non è che sia magico dalla qualità immensa ed anche la compressione della depth su rgb non è certo d'aiuto. Qualche piccola sbavatura ci sarà sempre ma è comunque meglio di non avere nulla.
Per ora ho sfruttato la depth map della luce (ecco perchè non ci ho ancora aggiunto le texture) e questo effetto "assieme" alla luce mi gira intorno ai 60 fps e con tutti quei cubi disegnati (un centinaio) quindi è qualcosa di utilizzabile anche se pesante, l'ambient occlusion non l'ho MAI attivato in alcun gioco, non è certo l'effetto più leggero del mondo.
Questo è uno degli effetti che aumentano notevolmente la bellezza di una scena, un must.
Stavolta però ho copia/incollato parecchio. Certo ho dovuto fare moltissimi aggiustamenti ma diciamo che buona parte del merito è anche di altri.
Nel fare ciò ho anche scoperto come migliorare la qualità della depthmap (meno errori nel calcolo della luce)
L'immagine che vedete sopra parte completamente bianca senza alcuna texture ne luce, non vedo l'ora di vederlo in una ambientazione reale con un po di blur per ridurre gli artefatti.
Chiaramente non è che sia magico dalla qualità immensa ed anche la compressione della depth su rgb non è certo d'aiuto. Qualche piccola sbavatura ci sarà sempre ma è comunque meglio di non avere nulla.
Per ora ho sfruttato la depth map della luce (ecco perchè non ci ho ancora aggiunto le texture) e questo effetto "assieme" alla luce mi gira intorno ai 60 fps e con tutti quei cubi disegnati (un centinaio) quindi è qualcosa di utilizzabile anche se pesante, l'ambient occlusion non l'ho MAI attivato in alcun gioco, non è certo l'effetto più leggero del mondo.
Questo è uno degli effetti che aumentano notevolmente la bellezza di una scena, un must.
Time to feel, time to believe
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
- NoCode
- GMI VIP
- Messaggi: 3403
- Iscritto il: 01/09/2008, 8:08
- Specialità: Grafica e Musica
- Uso: GM:Studio 1.4 Pro
- Località: My houuuse... Where is my houuuuse?!?
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
Bisogna contare però che questa è una scena con pochi poligoni comunque, e che una scena reale di un gioco, comprese texture, intelligenze artificiali, ecc, risulterà molto meno prestante.
Forse con il Compiler qualche FPS lo guadagni con questo tipo di effetti, anche se non penso di molto.
Bisogna solo sperare che migliorino le prestazioni di Game Maker in futuro, perchè con queste cose ci si può fare un gioco serio.
Forse con il Compiler qualche FPS lo guadagni con questo tipo di effetti, anche se non penso di molto.
Bisogna solo sperare che migliorino le prestazioni di Game Maker in futuro, perchè con queste cose ci si può fare un gioco serio.
- civic71
- GMI Advanced
- Messaggi: 2210
- Iscritto il: 23/10/2003, 17:31
- Specialità: Risotto con zucchine
- Uso: GM:Studio 1.4 Pro
- Località: Jesolo (venezia)
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
No , pur avendolo provato anche in un altro pc più recente con seven. stesso fatal errore di mac12 :Comunque a te funziona? Provalo magari ti va,
___________________________________________
############################################################################################
FATAL ERROR in Vertex Shader compilation
ShaderName: depth_shader
D3DXCompile failed - result
at gml_Object_light_Draw_0
############################################################################################
- mac12
- Membro d'elite
- Messaggi: 1124
- Iscritto il: 18/09/2012, 17:32
- Specialità: programmazione
- Uso: GameMaker 8.1
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
hai provato ad installare questo:http://www.microsoft.com/it-it/download ... aspx?id=35?
Spoiler
-
- Admin
- Messaggi: 12355
- Iscritto il: 19/08/2009, 16:20
- Specialità: Programmazione 3D
- Uso: GM:Studio 2
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
Ho scoperto sulla mia pelle che GM è rallentato non solo "in generale" ma anche come scrittura di codice.
Provando a fare una scena con una luce con un migliaio di cubi mi cala vertiginosamente a 7 fps.
Il problema sta sopratutto nella moltiplicazione delle matrici e conversione matrice/array.
Certo è vero che fare due moltiplicazioni tra matrici per ognuno dei 1000 oggetti non è il massimo della velocità ma speravo qualcosina in più...
Mi toccherà quindi convertire, o perlomeno portare in parallelo, tutta la gestione con le ds_grid ad una che utilizza solamente ed esclusivamente array per succhiare ogni millesimo di prestazioni. Anche il codice sarà molto meno leggibile visto che dovrò usare un'array monodimensionale anzichè bidimensionale per risparmiare le conversioni.
Per ora ho comunque risolto lasciando separate la world_matrix dalla viewprojection in modo da non effettuare mai alcuna moltiplicazione e/o conversione e permette anche di fondere una proiezione fatta con la mia lib ad una world_matrix fatta usando le classiche d3d_transform.
Al contrario di quanto dovrebbe essere e di quanto ha detto lo stesso mark overmars in alcuni post sul forum yoyogames lasciare fare allo shader è nettamente più veloce di farlo fare a GM
Tanto bisognava comunque passare la world matrix separata per le normali.
Per ora non da problemi di prestazioni quindi eccetto la potenza della scheda video e 1000 modelli disegnati che non sono pochi, è comunque preoccupante pensare alle animazioni per il quale vengono svolti parecchi calcoli delle matrici e non dimentichiamoci anche che ogni oggetto che si muove può richiedere una o più trasformazioni e conseguente moltiplicazione. Insomma bisognerà andarci abbastanza cauti, ma in fondo è GM, c'era da aspettarselo.
Con tutti i modelli statici e quindi quasi nessun peso lato matrici/passaggio di esse allo shader (pesa poco) mi viene fuori 30 fps con due luci disegnate in multipass (quindi modelli disegnati una volta in entrambe le luci e una volta per luci per riceverle quindi disegno in totale 1002 modelli per 4 volte, non è pochissimo ed ho la scheda video decisamente lenta) con ombre blurrate.
30 fps in un test abbastanza pesante come questo significa che è possibile applicarlo in un gioco a patto di avere un buon pc e stare molto attenti con le prestazioni.
Con un modello unico quindi disegnandone 3 in totale (per 4 volte) mi fa 35 fps. E' chiaro che con il single pass le prestazioni saliranno e più tardi proverò a farlo se GM lo permette e non mette solite cagate tipo limite di istruzioni.
Se abbasso la risoluzione delle luci a 256x256 è comunque utilizzabile con una qualità decente e mi sale tutto a 50 fps.
Alla fine è sempre la solita storia, stiamo parlando di GM, gli shaders che ho fatto sono abbastanza leggeri e seguono praticamente 1:1 come si fa nella realtà. Purtroppo la lentezza innata di gmstudio e la mia scheda video non permettono di pompare molto di più ma è comunque qualcosa di utilizzabile anche se su computer di fascia più alta rispetto a quello che comunemente si userebbe per una grafica simile.
Se in futuro sistemeranno il compiler dandogli finalmente delle prestazioni base decenti (come ho già detto room vuota mi fa 150 fps contro gli 800 di gm8.1) credo che saranno effetti utilizzabili in un gioco completo senza troppi problemi.
EDIT: Nocche va intorno ai 750-800 fps!!!! Non ho idea di come faccia, anche perchè ha una cpu peggiore della mia pur avendo una gpu nettamente migliore.
I rallentamenti di gmstudio non hanno proprio senso... mah. Fatto sta che 750 fps credo che "potrebbero" essere utilizzabili in un gioco.
Ancora non si spiega come mai un'effetto più pesante gli vada meglio di uno meno pesante(la vecchia versione faceva 200fps), è possibile che il window set caption faccia macello quando si raggiunge un numero elevato di fps mentre nel caso di scheda video ciofecosa come la mia non ha fatto molta differenza.
Provando a fare una scena con una luce con un migliaio di cubi mi cala vertiginosamente a 7 fps.
Il problema sta sopratutto nella moltiplicazione delle matrici e conversione matrice/array.
Certo è vero che fare due moltiplicazioni tra matrici per ognuno dei 1000 oggetti non è il massimo della velocità ma speravo qualcosina in più...
Mi toccherà quindi convertire, o perlomeno portare in parallelo, tutta la gestione con le ds_grid ad una che utilizza solamente ed esclusivamente array per succhiare ogni millesimo di prestazioni. Anche il codice sarà molto meno leggibile visto che dovrò usare un'array monodimensionale anzichè bidimensionale per risparmiare le conversioni.
Per ora ho comunque risolto lasciando separate la world_matrix dalla viewprojection in modo da non effettuare mai alcuna moltiplicazione e/o conversione e permette anche di fondere una proiezione fatta con la mia lib ad una world_matrix fatta usando le classiche d3d_transform.
Al contrario di quanto dovrebbe essere e di quanto ha detto lo stesso mark overmars in alcuni post sul forum yoyogames lasciare fare allo shader è nettamente più veloce di farlo fare a GM
Tanto bisognava comunque passare la world matrix separata per le normali.
Per ora non da problemi di prestazioni quindi eccetto la potenza della scheda video e 1000 modelli disegnati che non sono pochi, è comunque preoccupante pensare alle animazioni per il quale vengono svolti parecchi calcoli delle matrici e non dimentichiamoci anche che ogni oggetto che si muove può richiedere una o più trasformazioni e conseguente moltiplicazione. Insomma bisognerà andarci abbastanza cauti, ma in fondo è GM, c'era da aspettarselo.
Con tutti i modelli statici e quindi quasi nessun peso lato matrici/passaggio di esse allo shader (pesa poco) mi viene fuori 30 fps con due luci disegnate in multipass (quindi modelli disegnati una volta in entrambe le luci e una volta per luci per riceverle quindi disegno in totale 1002 modelli per 4 volte, non è pochissimo ed ho la scheda video decisamente lenta) con ombre blurrate.
30 fps in un test abbastanza pesante come questo significa che è possibile applicarlo in un gioco a patto di avere un buon pc e stare molto attenti con le prestazioni.
Con un modello unico quindi disegnandone 3 in totale (per 4 volte) mi fa 35 fps. E' chiaro che con il single pass le prestazioni saliranno e più tardi proverò a farlo se GM lo permette e non mette solite cagate tipo limite di istruzioni.
Se abbasso la risoluzione delle luci a 256x256 è comunque utilizzabile con una qualità decente e mi sale tutto a 50 fps.
Alla fine è sempre la solita storia, stiamo parlando di GM, gli shaders che ho fatto sono abbastanza leggeri e seguono praticamente 1:1 come si fa nella realtà. Purtroppo la lentezza innata di gmstudio e la mia scheda video non permettono di pompare molto di più ma è comunque qualcosa di utilizzabile anche se su computer di fascia più alta rispetto a quello che comunemente si userebbe per una grafica simile.
Se in futuro sistemeranno il compiler dandogli finalmente delle prestazioni base decenti (come ho già detto room vuota mi fa 150 fps contro gli 800 di gm8.1) credo che saranno effetti utilizzabili in un gioco completo senza troppi problemi.
EDIT: Nocche va intorno ai 750-800 fps!!!! Non ho idea di come faccia, anche perchè ha una cpu peggiore della mia pur avendo una gpu nettamente migliore.
I rallentamenti di gmstudio non hanno proprio senso... mah. Fatto sta che 750 fps credo che "potrebbero" essere utilizzabili in un gioco.
Ancora non si spiega come mai un'effetto più pesante gli vada meglio di uno meno pesante(la vecchia versione faceva 200fps), è possibile che il window set caption faccia macello quando si raggiunge un numero elevato di fps mentre nel caso di scheda video ciofecosa come la mia non ha fatto molta differenza.
Time to feel, time to believe
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
-
- Admin
- Messaggi: 12355
- Iscritto il: 19/08/2009, 16:20
- Specialità: Programmazione 3D
- Uso: GM:Studio 2
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
Ho fatto un test come si deve con la possibilità di scegliere qualche modalità:
https://drive.google.com/file/d/0B62O2v ... sp=sharing
Spazio: si sceglie se usare il multipass o il singlepass
Invio: attiva/disattiva la depth prepass
Control: attiva/disattiva il gamma correction.
Passiamo quindi a spiegazioni un po più tecniche.
L'esempio disegna solo 3 modelli, il lucertolone, il pavimento e le casse (tutte le casse racchiuse in un modello unico e generate casualmente, per la precisione sono 100) per limitare il più possibile le draw calls che hanno il loro peso, in effetti potevo sforzare un po di più ad almeno una 50a ma per concentrare il test sulla qualità degli shaders ho preferito limitarle il più possibile.
Le luci sono anch'esse 3, non impostabili e con ombre morbide. La qualità delle ombre morbide è quelle che è ma con qualche calcolo accurato si può ottenere più qualità a praticamente lo stesso peso.
Le luci sono una giallo-panna una rossa ed una blu.
Il gamma correction è un calcolo particolare piuttosto leggero che permette di risolvere un bug nella colorazione degli schermi dando un colore più naturale e realistico. Essendo leggero e semplice da implementare l'ho sempre usato nei vari test, ora l'ho messo selezionabile per mostrare l'uguaglianza con il multipass dell'algoritmo singlepass.
Il gamma correction è applicabile anche usando il multipass ma SOLO usando una surface di supporto e si perderebbe in qualità dei colori, forse con un leggero noise si potrebbe migliorare l'effetto ma è comunque una cosa pesante e che eviterei di fare con game maker. Una buona cosa sarebbe da integrarlo assieme a qualche effetto che necessita di usare surface di supporto che appesentirebbe comunque il tutto.
Il singlepass disegna tutte e tre le luci disegnando una sola volta un modello, il multipass disegna il modello una volta per ogni luce in bm_add. Per via delle limitazioni dei colori il singlepass è leggermente più bello e preciso ma parliamo comunque di poca differenza.
Il prepass è un draw aggiuntivo di tuta la scena, questo draw ha i colori completamente disabilitati e tutto ciò che fa è scrivere il depth buffer. In pratica a basso livello ogni pixel viene disegnato solo dopo aver controllato la sua profondità sullo schermo. Se un determinato pixel scopre di essere nascosto non viene disegnato. Il problema è riguardante l'ordine di disegno, se prima disegniamo un'oggetto che sta molto vicino alal telecamera e poi ne disegniamo uno nascosto, i pixel di quest'ultimo rileveranno il primo oggetto e non verranno disegnati, viceversa se prima disegniamo l'oggetto lontano e poi disegniamo l'oggetto vicino verranno disegnati entrambi e ciò è ovviamente una perdita di prestazioni. Un sistema abbastanza comune è quello di disegnare prima gli oggetti vicini alla telecamera ma essendo questi di forme e dimensioni diverse e GM molto lento è un sistema difficile da applicare e non sempre affidabile. Il prepass disegna tutti gli oggetti in scena (in maniera più veloce del solito visto che non disegna i colori) riempiendo il depth buffer, in questo modo quando si andrà a disegnare successivamente non si saranno pixel sprecati e vengono disegnati solo quelli davanti a tutti.
Chiaramente è una tecnica che bisogna usare in base alla situazione, alla fine disegna comunque qualcosa e ci sono varie chiamate a disegno. Nel caso di scene molto complesse tipo con elevata vegetazione può essere utile, viceversa se sono abbastanza semplici è più conveniente fare depth sorting.
In questo caso l'ho aggiunto per vedere se era conveniente usarlo in una scena in cui si disegno oggetti senza un'ordine preciso e a quanto pare è molto utile. Ma come al solito dipende dalle varie situazioni, se disegno i cubi prima del pavimento le prestazioni sono molto simili ma non sempre è qualcosa di facilmente applicabile con game maker.
Nel caso del multipass le prestazioni non variano di molto in quanto la prima luce fa anche da prepass per le successive.
Purtroppo fino ad opengl 4.2 non è possibile impostare che la depth venga calcolata prima di eseguire il pixel shader quindi le prestazioni non aumenteranno moltissimo. Dovrò provare a fare un deferred shader.
Idem per gli if, anche se esistono essi non porteranno ad alcun miglioramento in fatto di prestazioni a quanto pare
A me l'esempio va a circa 30 fps. Purtroppo non è molto ma come al solito ripeto che il mio pc fa abbastanza schifo, nocode invece ha ben 600 fps.
Ancora non sono riuscito a capire come mai singlepass e multipass non hanno praticamente alcuna differenza di prestazioni, ogni tanto si nota un leggerissimo vantaggio da parte di uno ed altre volte da parte dell'altro. Stessa cosa capita a nocode.
Ogni tecnica ha i suoi vantaggi, nel primo caso possiamo avere più prestazioni e qualità (ed il gamma correction) mentre nel secondo possiamo avere un numero praticamente illimitato di luci, altro contro del singlepass è che, a meno di creare più shaders, non si può selezionare il numero di luci. E' anche vero che creare molti shaders per le varie impostazioni non è un'idea da buttare via.
Siccome GMstudio usa dx9 penso che per il numero di luci non sia comunque troppo problematico, forse un 4-8 luci si riescono ad ottenere. 8 luci in genere bastano ed avanzano, considerate che ogni oggetto può avere le sue 4 luci personali, quelle più vicine, non è obbligatorio usare le stesse per tutti gli oggetti.
E' quindi utilizzabile tutto questo sistema? Penso proprio di sì, togliendo le ombre morbide ed abbassando la qualità delle luci a 256x256 la qualità non è delle migliori ma utilizzabile e vado a ben 70 fps con il singlepass e 45 con il multipass. A quanto pare quando l'effetto non è particolarmente pesante il fillrate si fa sentire quindi il multipass diventa abbastanza pesante, motivo in più per usare il singlepass.
Calcolate che alla fine se riesco a far andare l'esempio qualcosa ad almeno 20 fps sul mio pc significa che sarà utilizzabile dalla stragrande maggioranza delle persone. Quasi tutti i giochi attuali mi vanno sotto questa soglia anche a grafica minima.
Ancora non ho aggiunto l'ambient occlusion ma vedrò di aggiungerlo assieme a dei test di deferred shading.
Ecco un'inutile screenshot:
https://drive.google.com/file/d/0B62O2v ... sp=sharing
Spazio: si sceglie se usare il multipass o il singlepass
Invio: attiva/disattiva la depth prepass
Control: attiva/disattiva il gamma correction.
Passiamo quindi a spiegazioni un po più tecniche.
L'esempio disegna solo 3 modelli, il lucertolone, il pavimento e le casse (tutte le casse racchiuse in un modello unico e generate casualmente, per la precisione sono 100) per limitare il più possibile le draw calls che hanno il loro peso, in effetti potevo sforzare un po di più ad almeno una 50a ma per concentrare il test sulla qualità degli shaders ho preferito limitarle il più possibile.
Le luci sono anch'esse 3, non impostabili e con ombre morbide. La qualità delle ombre morbide è quelle che è ma con qualche calcolo accurato si può ottenere più qualità a praticamente lo stesso peso.
Le luci sono una giallo-panna una rossa ed una blu.
Il gamma correction è un calcolo particolare piuttosto leggero che permette di risolvere un bug nella colorazione degli schermi dando un colore più naturale e realistico. Essendo leggero e semplice da implementare l'ho sempre usato nei vari test, ora l'ho messo selezionabile per mostrare l'uguaglianza con il multipass dell'algoritmo singlepass.
Il gamma correction è applicabile anche usando il multipass ma SOLO usando una surface di supporto e si perderebbe in qualità dei colori, forse con un leggero noise si potrebbe migliorare l'effetto ma è comunque una cosa pesante e che eviterei di fare con game maker. Una buona cosa sarebbe da integrarlo assieme a qualche effetto che necessita di usare surface di supporto che appesentirebbe comunque il tutto.
Il singlepass disegna tutte e tre le luci disegnando una sola volta un modello, il multipass disegna il modello una volta per ogni luce in bm_add. Per via delle limitazioni dei colori il singlepass è leggermente più bello e preciso ma parliamo comunque di poca differenza.
Il prepass è un draw aggiuntivo di tuta la scena, questo draw ha i colori completamente disabilitati e tutto ciò che fa è scrivere il depth buffer. In pratica a basso livello ogni pixel viene disegnato solo dopo aver controllato la sua profondità sullo schermo. Se un determinato pixel scopre di essere nascosto non viene disegnato. Il problema è riguardante l'ordine di disegno, se prima disegniamo un'oggetto che sta molto vicino alal telecamera e poi ne disegniamo uno nascosto, i pixel di quest'ultimo rileveranno il primo oggetto e non verranno disegnati, viceversa se prima disegniamo l'oggetto lontano e poi disegniamo l'oggetto vicino verranno disegnati entrambi e ciò è ovviamente una perdita di prestazioni. Un sistema abbastanza comune è quello di disegnare prima gli oggetti vicini alla telecamera ma essendo questi di forme e dimensioni diverse e GM molto lento è un sistema difficile da applicare e non sempre affidabile. Il prepass disegna tutti gli oggetti in scena (in maniera più veloce del solito visto che non disegna i colori) riempiendo il depth buffer, in questo modo quando si andrà a disegnare successivamente non si saranno pixel sprecati e vengono disegnati solo quelli davanti a tutti.
Chiaramente è una tecnica che bisogna usare in base alla situazione, alla fine disegna comunque qualcosa e ci sono varie chiamate a disegno. Nel caso di scene molto complesse tipo con elevata vegetazione può essere utile, viceversa se sono abbastanza semplici è più conveniente fare depth sorting.
In questo caso l'ho aggiunto per vedere se era conveniente usarlo in una scena in cui si disegno oggetti senza un'ordine preciso e a quanto pare è molto utile. Ma come al solito dipende dalle varie situazioni, se disegno i cubi prima del pavimento le prestazioni sono molto simili ma non sempre è qualcosa di facilmente applicabile con game maker.
Nel caso del multipass le prestazioni non variano di molto in quanto la prima luce fa anche da prepass per le successive.
Purtroppo fino ad opengl 4.2 non è possibile impostare che la depth venga calcolata prima di eseguire il pixel shader quindi le prestazioni non aumenteranno moltissimo. Dovrò provare a fare un deferred shader.
Idem per gli if, anche se esistono essi non porteranno ad alcun miglioramento in fatto di prestazioni a quanto pare
A me l'esempio va a circa 30 fps. Purtroppo non è molto ma come al solito ripeto che il mio pc fa abbastanza schifo, nocode invece ha ben 600 fps.
Ancora non sono riuscito a capire come mai singlepass e multipass non hanno praticamente alcuna differenza di prestazioni, ogni tanto si nota un leggerissimo vantaggio da parte di uno ed altre volte da parte dell'altro. Stessa cosa capita a nocode.
Ogni tecnica ha i suoi vantaggi, nel primo caso possiamo avere più prestazioni e qualità (ed il gamma correction) mentre nel secondo possiamo avere un numero praticamente illimitato di luci, altro contro del singlepass è che, a meno di creare più shaders, non si può selezionare il numero di luci. E' anche vero che creare molti shaders per le varie impostazioni non è un'idea da buttare via.
Siccome GMstudio usa dx9 penso che per il numero di luci non sia comunque troppo problematico, forse un 4-8 luci si riescono ad ottenere. 8 luci in genere bastano ed avanzano, considerate che ogni oggetto può avere le sue 4 luci personali, quelle più vicine, non è obbligatorio usare le stesse per tutti gli oggetti.
E' quindi utilizzabile tutto questo sistema? Penso proprio di sì, togliendo le ombre morbide ed abbassando la qualità delle luci a 256x256 la qualità non è delle migliori ma utilizzabile e vado a ben 70 fps con il singlepass e 45 con il multipass. A quanto pare quando l'effetto non è particolarmente pesante il fillrate si fa sentire quindi il multipass diventa abbastanza pesante, motivo in più per usare il singlepass.
Calcolate che alla fine se riesco a far andare l'esempio qualcosa ad almeno 20 fps sul mio pc significa che sarà utilizzabile dalla stragrande maggioranza delle persone. Quasi tutti i giochi attuali mi vanno sotto questa soglia anche a grafica minima.
Ancora non ho aggiunto l'ambient occlusion ma vedrò di aggiungerlo assieme a dei test di deferred shading.
Ecco un'inutile screenshot:
Time to feel, time to believe
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
- civic71
- GMI Advanced
- Messaggi: 2210
- Iscritto il: 23/10/2003, 17:31
- Specialità: Risotto con zucchine
- Uso: GM:Studio 1.4 Pro
- Località: Jesolo (venezia)
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
Tutto molto interessante .
Ma se lo scopo è quello di migliorare le prestazioni , mi chiedo come un tale calcolo della depth dei pixel non sia anch'esso pesante.
Gli screenshot non sono mai inutili
Ma se lo scopo è quello di migliorare le prestazioni , mi chiedo come un tale calcolo della depth dei pixel non sia anch'esso pesante.
Gli screenshot non sono mai inutili
-
- Admin
- Messaggi: 12355
- Iscritto il: 19/08/2009, 16:20
- Specialità: Programmazione 3D
- Uso: GM:Studio 2
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
E' probabilmente una delle cose più leggere, alla fine la matrice di trasformazione è sempre quella, cambia solo che anzichè outputtare il colore della texture outputto la posizione con qualche calcolo per aggiustare il range. Vedrò di migliorarla in qualità comunque, ho una mezza ideuccia che risparmia un po di calcoli ora inutili...civic71 ha scritto:mi chiedo come un tale calcolo della depth dei pixel non sia anch'esso pesante.
Gran parte del peso è dovuto al multitexture e sopratutto al blur. Un'ombra blurrata oltre a prelevare il pixel della texture diffusa (leggere una texture è un'operazione abbastanza lenta) attualmente prende 8 campioni dalla lightmap, è un po come avere 9 texture tutte assieme. Con 3 luci è come averne 25. Oltre ovviamente a tutte le conversioni, i controlli di range e tutto.
Ottimizzerò al meglio ma un limite cè sempre, texture read e fillrate sono una delle cose peggiori nelle vecchie schede come la mia.
Time to feel, time to believe
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
Dare to see what may come of our future
Lift your head, broaden your gaze
Speak your mind and your thoughts they will follow you
- enick
- GMI VIP
- Messaggi: 3749
- Iscritto il: 26/06/2011, 19:34
- Specialità: 39dll e 3D
- Località: Sardegna
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
eE' sempre un piacere vederti lavorare jak Complimenti
- doom13
- Moderatore
- Messaggi: 2093
- Iscritto il: 31/08/2012, 15:40
- Specialità: Programmazione
- Uso: GM:Studio 2
- Contatta:
Re: Un piccolo passo per l'informatica, un grande passo per
Jakke ma mica mi presteresti il progetto che hai pubblicato? Vorrei mettere ste benedette ombre nel gioco che sto facendo. Almeno tutto sto lavoro non va buttato
Spoiler
"Things get hard sometimes guys... But remember, dicks get hard too, but they don't stay hard forever. Don't give up!"
Chi c’è in linea
Visitano il forum: Nessuno e 4 ospiti