Gaming con Linux

[Mason]

Originariamente inviato da fek
Penso "'bin there done that"

Il mio primo motore 3d di un certo spessore parti' esattamente come un motore multipiattaforma, con supporto d3d e ogl, la prima versione fu sviluppata su BeOS, qualcuno magari si ricordera' del Peuck.
Dopo due anni mi accorsi che non era una buona idea

Un motore 3d moderno deve:

- essere leggero
- fare solo ed esclusivamente quello che l'applicazione che lo usa richiede
- essere facile da mantenere ed estendere

Solo cosi' si puo' sperare di avere un motore che costi poco e faccia quello che il gioco ha bisogno che faccia.
Un motore 3d multipiattaforma, generico, adatto a fare qualunque cosa, alla fine non fa piu' nulla di utile, diventa solo un ingestibile agglomerato di funzionalita' che costa tantissimo e non risolve il problema.

Se poi e' anche open source...

a parte che non mi ai guardato ode :P lo messo li apposta

il leggero e generico, dimmi un applicazione che deve essere pesante quando puo essere fatta leggera
sul estendibilita' non dipende dalla generalita' per un motore di rendering realtime, dipende dalla sua struttura logica e modulare, sono secondo me gli sviluppatori di applicazioni per grafica real time a dovere sottostare all interfaccia che l'engine esporta. posso concordare che ci posson esser diversi obbiettivi sul tipo di scena che l'engine deve sostenere che puo portare ad un ottimizzazione migliore, ma di solito sono parametri che possono essere scelti a compile time, se poi progettato bene puo avere un sistema di plugin per la collision detection, per la loro risposta fisica, ecc.
posso concordare che non avrai il massimo di engine real time, ma personalmente sacrificherei un 20 % di fps per avere un qualcosa di piu flessibile che un motore had hoc hardcoded,visto gli fps odierni, ma cmq questo e solo un punto di vista.

sul fatto di fare un compito specifico in fondo il compito specifico e piu o meno uguale per molti videogames 3d:
il motore di quake e stato uno(a quanto ne so, e un po che non seguo la scena) tra i piu venduti, ha sempre mantenuto la stessa struttura estesa nel tempo (almeno a vederlo dall'esterno),e ha realizzato mod di macchine, engine per rts, avventure 3d, avventure strategiche a turni tipo ufo-unknown enemy.

capisco il tuo punto di vista in quanto preso da una posizione diversa sulla realta', pero guardando i partners dei vari progetti non mi sembrano cosi sottovalutati, poi che la realta' odierna nel gaming sia un altra concordo.

ps: Se poi e' anche open source... >>/dev/null :P

[FuocoNero]

Originariamente inviato da marcowave
Cmq anche Half Life 2 doveva essere multipiattaforma (a giudicare dalla leaked di un anno fa, che girava anche e meglio in OpenGL)
poi però è stato completato solo in D3D.. probabilmente hanno capito che stavano buttando via le loro forze per nulla..

uff.. sarebbe stato bello averlo anche per linux.. non dico che vorrei tutti i giochi per linux, ma quelli storici si e all'appello mancano solo HL, CS e seguiti

Diciamo che alla Valve non si sono sbattuti tantissimo, per fortuna neanche dopo un mese dal rilascio possiamo giocarci anche sotto Linux tramite Cedega

http://downloads.transgaming.com/fil...leasenotes.txt

[fek]

Originariamente inviato da Mason
posso concordare che ci posson esser diversi obbiettivi sul tipo di scena che l'engine deve sostenere che puo portare ad un ottimizzazione migliore, ma di solito sono parametri che possono essere scelti a compile time, se poi progettato bene puo avere un sistema di plugin per la collision detection, per la loro risposta fisica, ecc.

Sulla carta e' tutto bello e funziona, ma in pratica no
In un mondo ideale il software si progetta tutto prima e bene e poi basta scriverlo, un sistema di plugin e basta aggiungere la collision detection. E' tutto molto bello, ma poi c'e' il mondo reale.
E nel mondo reale i progetti possono essere incompleti, le specifiche possono cambiare, anzi cambiano, il game designer esce con una nuova feature che il motore non era stato progettato per supportare, il sistema di plugin magari contiene bug e va comunque supportato e testato. Nel mondo reale il codice non si scrive e non lo si tocca piu', ma va supportato per tutto l'arco del progetto.
Ed ogni linea di codice che scrivi e' potenziale sorgente di bug e costa.
E perche' dovrei avere un sistema di plugin splendido se poi mi basta scrivere la collision detection della quale ho bisogno "that just bloody works"?
E cosi' via posso fare decine di altri esempi.
E alla fine della fiera l'esperienza insegna che sulla carta e' tutto bello, ma nella realta' devi fare le cose nella maniera piu' semplice possibile, scrivere solo il codice che serve al gioco e scriverlo il piu' pulito possibile e non scrivere nulla di piu' che puo' potenzialmente andare storto (e ti assicuro che va storto).

Quella di progettare tutto prima e bene e' una vecchia dottrina dell'Ingegneria del Software. Purtroppo non funziona.

posso concordare che non avrai il massimo di engine real time, ma personalmente sacrificherei un 20 % di fps per avere un qualcosa di piu flessibile che un motore had hoc hardcoded,visto gli fps odierni, ma cmq questo e solo un punto di vista.

Il problema qui non e' il 20% di fps (no, comunque non li puoi sacrificare), il problema e' avere un motore 3d che fa quello che ti serve e che non costi una montagna di soldi e di tempo (Doom 3?).
E c'e' un altro problema, nel tempo che impieghi a scrivere il motore 3d "che pensa a tutto", il 3d in real time si e' evoluto e tutte le assunzioni che hai fatto all'inizio del progetto sono obsolete: puoi prendere il tuo motore e buttarlo. E' vecchio. E non puoi prevedere tutto "up front", non c'e' modo. Non potevi prevedere 5 anni fa che esattamente oggi tutta la pipeline grafica sarebbe passata agli fp16, oppure che le GPU sarebbero state lentissime a processare batch di poligoni e velocissime a processare i poligoni stessi, non c'era modo neppure di immaginarlo. Ed uno solo di questi piccoli cambiamenti ti stravolge tutta l'architettura. Butti e ricominci. Pero' hai perso 5 anni a progettare il motore 3d "che fa tutto". O che almeno ci provava.

sul fatto di fare un compito specifico in fondo il compito specifico e piu o meno uguale per molti videogames 3d:
il motore di quake e stato uno(a quanto ne so, e un po che non seguo la scena) tra i piu venduti, ha sempre mantenuto la stessa struttura estesa nel tempo (almeno a vederlo dall'esterno),e ha realizzato mod di macchine, engine per rts, avventure 3d, avventure strategiche a turni tipo ufo-unknown enemy.

Purtroppo no
Un motore 3d per un FPS ha necessita' completamente diverse da un motore 3d per un gioco come BW2.
Esempio banale: in BW2 io devo renderizzare tantissimi oggetti (migliaia), in Doom 3 devo processare pochi oggetti ma molto dettagliati. In BW2 posso zoomare da sopra le nuvole fino al viso di un personaggio. E la creatura ha necessita' completamente diverse da quelle di un oggetto normale.

Penserai che renderizzare molti oggetti non sia diverso da renderizzarne pochi, ma ti dico che la pipeline del motore e la sua architettura sono completamente diversi nei due casi. Doom 3 non ha bisogno di fare batching aggressivo e infatti non lo implementa, io ne ho bisogno ma non ho bisogno di gestire le stencil shadow.
Prova a scrivere un motore 3d che gestisca entrambe le necessita', ti aiuto, e quando abbiamo finito (se finiamo) sara' gia' uscito Black&White 4 con due motori 3d custom.

Ti parlo per esperienza, la pensavo esattamente come te all'inizio, ci ho provato, ho dovuto buttare tutto (ma almeno adesso so che la strada era sbagliata ).

[Mason]

a parte che mi parli come se avessi gia ragione in partenza e io fossi nel mondo delle favole e tu nella frontiera del 3d(che questo puo essere anche vero, ma cio non tolgie che la nostra distanza non sia cosi massiccia).

ti do ragione su b&w, ma b&w e un gioco molto particolare, per quello ha bisogno di un motore particolare, e su questo ti do ragione, cosi come penso alle routine per l' ia del gioco, che a quanto ricordo erano abbastanza avanzate a vederne il comportamento sul campo.
pero vendendo quello che c'e in giro come giochi mi sembra che le richieste siano piu allineate ad una media di engine, che tutto sommato non si differenzia molto l'uno dall'altro(i giochi di macchine son cosi diversi dai sparatutto o dalle avventure 3d?,e anche molti gestionali/rts non penso abbiano richieste cosi differenti), che poi mi parli di stencil e fp16 non posso che darti ragione che tutto si evolve, ma secondo te il motore di quake3(non parlo di programmabilita' degli shaders per doom3, e una cosa abbastanza recente per opengl e me, ed e maturata non da molto) e cosi differente da quello di quake2 e quake 1, non ti dico che non sia differente, ma _cosi_ differente da implicarne una riscrittura da 0,o da 20 o da 40 su una scala fino a 100?

e cmq il discorso dell'engine non ti dico che tu o la tua casa dovete farlo perche e meglio, volevo solo sapere come vedevi tecnicamente quei progetti, non voglio convertirti perche giustamente nel tuo campo sarebbe uno sforzo terribile sviluppare un motore piu generico per poi vederlo male adattarsi ad una situazione di gioco nuova o che e un macello inserire nella sua pipeline una nuova features, quindi per questo molto rischioso paragonato a quanto puo far guadagnare allo sviluppo(questo e palese dal tuo 20% non sacrificabile, quando per me andare a 100fps o 80 non cambia molto,50 40,ecc).

cmq ti ripeto che capisco e rispetto il tuo punto di vista, lo trovo giustissimo per la tua posizione e per il tuo lavoro, solo che non esiste solo latua realta'.

ode e usato in xsi per la simulazione dinamica per esempio, non parlo di cavoli fritti che volano in aria eh, sia ben inteso

[fek]

Originariamente inviato da Mason


a parte che mi parli come se avessi gia ragione in partenza e io fossi nel mondo delle favole e tu nella frontiera del 3d(che questo puo essere anche vero, ma cio non tolgie che la nostra distanza non sia cosi massiccia).

Non ho capito questo commento, lo ignoro.

pero vendendo quello che c'e in giro come giochi mi sembra che le richieste siano piu allineate ad una media di engine, che tutto sommato non si differenzia molto l'uno dall'altro(i giochi di macchine son cosi diversi dai sparatutto o dalle avventure 3d?,e anche molti gestionali/rts non penso abbiano richieste cosi differenti), che poi mi parli di stencil e fp16 non posso che darti ragione che tutto si evolve, ma secondo te il motore di quake3(non parlo di programmabilita' degli shaders per doom3, e una cosa abbastanza recente per opengl e me, ed e maturata non da molto) e cosi differente da quello di quake2 e quake 1, non ti dico che non sia differente, ma _cosi_ differente da implicarne una riscrittura da 0,o da 20 o da 40 su una scala fino a 100?

Un gioco di macchine:
- telecamera su un percorso piu' o meno fisso ad un'altezza piu' o meno fissa dal terreno
- i livelli di dettaglio possono essere precalcolati e ottimizzati
- scene esterne
- gli sfondi non hanno bisogno di alto dettaglio perche' non saranno mai raggiunti (non serve un landscape renderer)
- pochi modelli devono essere molto dettagliati (le macchine)
- il framerate non deve mai scendere sotto una certa soglia (60 fps normalmente)
- illuminazione e luci piu' o meno costanti
- sistema di ombre puo' essere molto semplificato e "ad hoc"

Un FPS:
- la telecamera non ha un percorso fisso, ma l'altezza e' piu' o meno costante
- scene indoor e outdoor e passaggio da uno all'altro caso
- a volte (ma non sempre) e' necessario un landscape renderer
- tutti gli oggetti devono essere molto dettagliati, ma in genere ci sono relativamente pochi oggetti nel mondo
- il modello di illuminazione dev'essere molto ricco e supportare luci dinamiche
- il sistema di ombre e' uno dei "visual clue" piu' importanti per posizionare gli oggetti nel mondo e con luci dinamiche dev'essere molto ricco e flessibile (vedi FarCry e Doom 3)
- il framerate e' relativamente secondario

Un avventura 3D:
- visuale in terza persona, il personaggio principale dev'essere molto dettagliato
- telecamera su percorsi molto piu' fissi di un fps, ma piu' variabili di un racing game
- il resto e' piu' o meno simile ad un FPS

Un RTS:
- moltissimi oggetti con relativamente pochi dettagli
- sistema di landscape necessario
- sistema di illuminazione quasi completamente dinamico (lightmap inusabili)
- il sistema di ombre non deve essere particolarmente dettagliato come in un FPS
- a seconda del gioco in particolare la telecamera puo' essere completamente libera (BW2) o totalmente fissa (WarCraft3)

Questo giusto per prendere quattro tipi di gioco che vanno per la maggiore, ti sembra che abbiano qualcosa in comune a parte il renderizzare oggetti 3d? No, ognuna di queste modalita' di gioco richiede un motore 3d completamente diverso per architettura. E ancora vuoi provare a scrivere il motore 3d "che fa tutto?"

Rispondi a questa domanda: nel tuo motore 3d ci metti un landscape renderer o no? E su quale algoritmo lo basi? Ce ne sono almeno una decina tutti piu' o meno validi o perfettamente inutili a seconda dell'uso che se ne deve fare. Auguri

e cmq il discorso dell'engine non ti dico che tu o la tua casa dovete farlo perche e meglio, volevo solo sapere come vedevi tecnicamente quei progetti, non voglio convertirti perche giustamente nel tuo campo sarebbe uno sforzo terribile sviluppare un motore piu generico per poi vederlo male adattarsi ad una situazione di gioco nuova o che e un macello inserire nella sua pipeline una nuova features, quindi per questo molto rischioso paragonato a quanto puo far guadagnare allo sviluppo(questo e palese dal tuo 20% non sacrificabile, quando per me andare a 100fps o 80 non cambia molto,50 40,ecc).

Ti ho detto come vedo tecnicamente quei progetti: perfettamente inutili dal lato pratico, per lo sviluppo di un videogioco.

cmq ti ripeto che capisco e rispetto il tuo punto di vista, lo trovo giustissimo per la tua posizione e per il tuo lavoro, solo che non esiste solo latua realta'.

Ma allora non ho capito io: stiamo parlando di motori 3d per videogiochi oppure di rendering in realtime per una qualunque applicazione generica?

ode e usato in xsi per la simulazione dinamica per esempio, non parlo di cavoli fritti che volano in aria eh, sia ben inteso

E ripeto: io sto parlando solo di videogiochi che e' l'unica cosa che conosco

[fek]

Ho capito ora il commento.

Si', su questo argomento parlo come se avessi ragione in partenza per due motivi:

1) Ci sono gia' passato

2) Tutta l'industry si sta muovendo in questa direzione: letteralmente tutti i motori 3d nuovi di una certa caratura vengono riscritti quasi interamente da zero (Source e FarCry e PainKiller e Stalker) ad ogni ciclo di produzione e magari licenziati. L'unico motore 3d middleware sopravvissuto e' RenderWare che viene usato solo in produzioni tecnicamente poco evolute.

Questa e' semplicemente la realta' delle cose al giorno d'oggi. Nei videogiochi, ovviamente.

[Mason]

ok va bene ho capito

tecnicamente tu mi dici che queste cose sono inutili per un discorso di fondo che non condivido, non mi dimostri che un engine generico non vada bene, tu affermi che un engine specializzato e meglio, ma su questo non ho mai obbiettato.

le argomentazioni che mi dai sulla differenza dei vari tipi di giochi non le reputo sostanzialmente diverse, in quanto sacrificando un po di fps, cosa che oggi mi sembrano abbondare, ottieni una generalita' di riutilizzo, che per l'os e il fondamento.

cmq ci son persone che ci stanno passando, magari avranno piu fortuna dove tu hai ora vedi inutilita', forse e sbagliato, ma non e che mi convinci molto dicendo che tu hai capito che era sbagliato, sicuramente data la tua esperienza diciamo che mi metti una pulce nel orecchio, ma nulla piu.

io mi aspettavo qualcosa tipo:
la gestione del collision detecion non va bene perche il metodo numerico e instabile e degenera scalando.
il formato per l'animazione delle mesh e superato per oggigiorno si usa cippafritta e ariasecca per deformare le mesh.
ha una limitazione forte nel supporto ai linguaggi di shading perche unifica vari linguaggi quindi e un loro subset.

il fatto che i motori per i giochi :
la possibilita' di liberta di telecamera puo portare ad ottimizzazioni, senza queste ottimizzazioni quanto perdi? non puoi mettere delle matrici globali che ti fanno queste trasformazion di camera alla base del grafo di scena? quale altre ottimizzazioni ci sono possibili(ruotare il modno e come ruotare la camera no?, visto la relativita delle due entita'), sinceramente non so quanti gradi di liberta' lasci le api come ogl o dx per i lpunto di vista.
il percorso dipende da come sono immagzzinate le "mappe", nei giochi di guida non so che formato, ma per gli fps il bsp penso sia un mezzo standard, come gli md2/3 per le animazioni delle mesh, o sbaglio?
naturalmente per un gioco di guida su tracciato la struttura dati atta a contenere queste info non ha necessariamente bisogno di un bsp, ma un albero con un solo figlio e una lista, la lista non mi sembra cosi male per tenere le info di un gioco del genere, sei sicuro che non esista qualcosa di generico per immagazzinare i dati.
per la illuminazione ti posso dare ragione.

vabbe ma cmq non guardi quello che ti ho detto, che son 3 cose diverse
uno e un motore per giochi(ed effetivamente e poco usato)
uno e un motore di rendering realtime con supporto ai linguaggi di shading,opzionale collsiion detection e dinamica basato su ode e animazione scheletriche tramite cal3d.
uno e un motore per la dinamica realtime.

sul engine vero e puro posso anche darti un po ragione, o per lo meno capisco i ltuo punto di vista in quanto sei nel settore avanzato, che generico non e che sia il massimo(come prima non ti dico lo stato del arte in questo preciso istante, ma cmq usabile per progettini come quelli di renderware diciamo), ma oltre quello non mi sembra che guardi.

[fek]

Originariamente inviato da Mason
tecnicamente tu mi dici che queste cose sono inutili per un discorso di fondo che non condivido, non mi dimostri che un engine generico non vada bene, tu affermi che un engine specializzato e meglio, ma su questo non ho mai obbiettato.

Qual e' il discorso di fondo che non condividi? Il fatto che il software dovrebbe fare solo cio' che risolve il problema e nulla di piu'?
Questo e' un discorso piu' generico che non si applica solo ai motori 3d, ma a tutto lo sviluppo in generale: Agile development e XP programming sono due paradigmi di sviluppo che esplorano queste problematiche. Si puo' riassumere in "Just write something that does bloody work".

le argomentazioni che mi dai sulla differenza dei vari tipi di giochi non le reputo sostanzialmente diverse, in quanto sacrificando un po di fps, cosa che oggi mi sembrano abbondare, ottieni una generalita' di riutilizzo, che per l'os e il fondamento.

Perche' tu vedi solo il costo in termini di fps e lo quantifichi in maniera un po superficiale, se mi permetti. Ma il costo non e' solo quello.
Facciamo qualche esempio pero', per capirci: se uso il motore 3d di Doom 3 per far girare BW2, mi gira a 2fps. Non perche' il motore di Doom 3 sia scarso, ma perche' non risolve il mio problema, ne risolve un altro. Se scrivo un motore (che, ripeto, ha un'architettura totalmente diversa) per risolvere il mio problema, ho la speranza di far girare il gioco a 60fps. Non e' una manciata di fps, e' la differenza fra un gioco giocabile ed un gioco che viene cancellato.

Ma gli fps non sono il solo costo. Tu mi puoi obiettare: allora scrivo un motore abbastanza generico da includere entrambe le architetture e poi lo uso sia per FPS sia per BW2, magari pagando la genericita' in termini di pochi fps.
Non funziona. Non paghi la genericita' in termini di pochi fps, la paghi in termini di mesi uomo passati a supportare un intero sistema che potrebbe gestire anche un fps ma che a me non serve per BW2. Pago per qualcosa che non uso. Capisci che e' pura follia. E' per questo che i motori 3d generici non sono una buona idea: costano troppo.
E se questa argomentazione ancora non ti convince, l'ultima domanda dovrebbe chiarire ogni dubbio: quanti motori 3d conosci che hanno resistito 10 anni e sono ancora usati in qualche gioco al giorno d'oggi? Zero.

io mi aspettavo qualcosa tipo:
la gestione del collision detecion non va bene perche il metodo numerico e instabile e degenera scalando.
il formato per l'animazione delle mesh e superato per oggigiorno si usa cippafritta e ariasecca per deformare le mesh.
ha una limitazione forte nel supporto ai linguaggi di shading perche unifica vari linguaggi quindi e un loro subset.

Come ho cercato di illustrarti, non e' solo una questione di formati, ma dell'intera architettura del motore 3d: fare HDR, ad esempio, presuppone toccare ogni riga di codice che porta il modello dal grafico allo schermo. Secondo te perche' HL2 lo ha abbandonato?

la possibilita' di liberta di telecamera puo portare ad ottimizzazioni, senza queste ottimizzazioni quanto perdi? non puoi mettere delle matrici globali che ti fanno queste trasformazion di camera alla base del grafo di scena? quale altre ottimizzazioni ci sono possibili(ruotare il modno e come ruotare la camera no?, visto la relativita delle due entita'), sinceramente non so quanti gradi di liberta' lasci le api come ogl o dx per i lpunto di vista.

Nella maggior parte dei casi la differenza fra l'avere quelle ottimizzazioni specifiche e non averle e' pari anche ad un ordine di grandezza.
Altro esempio tratto dalla mia esperienza: avevamo un model engine in BW2 un anno fa, il gioco girava a meno di 10fps di media (da 5 a 10), lo abbiamo riscritto con un'architettura fortmente orientata al batching ed ora gira da 50 a 100 fps... Si parla di un'ordine di grandezza secco.

il percorso dipende da come sono immagzzinate le "mappe", nei giochi di guida non so che formato, ma per gli fps il bsp penso sia un mezzo standard, come gli md2/3 per le animazioni delle mesh, o sbaglio?

Tutti usano formati proprietari customizzati per le proprie necessita'. Solo in BW2 ho scritto tre formati dei modelli diversi.

sul engine vero e puro posso anche darti un po ragione, o per lo meno capisco i ltuo punto di vista in quanto sei nel settore avanzato, che generico non e che sia il massimo(come prima non ti dico lo stato del arte in questo preciso istante, ma cmq usabile per progettini come quelli di renderware diciamo), ma oltre quello non mi sembra che guardi.

Ma come ti ho detto io guardo solo ai motori 3d per videogiochi, del resto non parlo perche' non lo conosco. Ovvio che non guardo oltre quello

Comunque e' una discussione davvero interessante.

[Banus]

Originariamente inviato da Mason
tecnicamente tu mi dici che queste cose sono inutili per un discorso di fondo che non condivido, non mi dimostri che un engine generico non vada bene, tu affermi che un engine specializzato e meglio, ma su questo non ho mai obbiettato.

Mi intrometto.
Fek non ti vuole dimostrare che un motore generico non vada bene, o sia necessariamente molto più inefficiente. Ti sta dicendo che è antieconomico e porta via un sacco di tempo.
Un investimento del genere ha senso se poi porta a maggiori profitti, cioè se il motore può essere riutilizzato più volte. Ma in un mercato nel quale il costo medio di sviluppo di un titolo continua a salire e in un settore dove ogni 2-3 anni cambia di molto lo scenario tecnologico, è difficile il riuso, e molto probabile invece trovarsi con un motore vecchio.
Prendendo come esempio un motore sfruttatissimo come quello di Quake 3, avrai letto i commenti di chi si lamentava della difficoltà di Medal of Honor o Call of Duty a gestire grandi spazi aperti, anche con sistemi potenti. Questo perchè quando il motore è nato queste esigenze non c'erano.

[Mason]

capisco che bw, visto che gestisce una cifra di oggetti, scalando i llivello di dettagli dal mondo alla faccia del singol osia un gioco particolare, e fin li ci sono, capisco che mettendoci un qualsivoglia altro motore faccia delle foto in sequenza piuttosto che un animazione, visto che cmq ora che prende gli oggetti da renderizzare ci mette 30 anni.
capisco che sia non redditizzio svilupparlo all'interno di una casa per software gaming come prima ho detto.
il discorso di fondo che non condividiamo e: se non vende non ne vale la pena, al di la della passione o cmq della curiosita di farlo giusto per farlo, non per affermarsi e venderlo.

cippalippa io volevo sapere solo tecnicamente, non finanziariamente, come vedevi quei progetti, mi andava anche bene un non li conosco, non me ne frega, il tempo che non programmo vado a gnocche,ma mi sposti il discorso come se io volessi che tutti usasessero questi tool o librerie di cui ti ho chieste un parere.

io so benissimo che questa generalita' si paga a livello di tempo umano, infatti non ti parlo di venderla, ne di prendere un motore commerciale per il gioco della barbie e metterlo sul simulatore di volo, o prendere un motore specifico e pensare che si adatti a tutto o molto.

beh 10 anni sono una cifra non indifferente nella grafivca ludica dopo 3dfx,m considerando che nvidia aghli inizi voleva radopiare la potenza delle gpu ogni 6 mesi mi pare.
ora non so come si implementi hdr, tu ste cose le vedi tutti i giorni, io posso sapere la base teorica sotto, pero te l;ho detto anche prima che farlo all'interno di un prodotto software, sopratutto videogames, con ritmi e tempi stretti da mantenere, possa essere anche molto savntaggioso, ma per un progetto, che diciamo se vuoi, "dilettantistico" un architettura della pipeline del motore (grafico, di gioco) generica ed estendibile penso che possa portare ad un prodotto cmq valido per un ambiente di tipo universitario, "piccolo gioco fatto in casa", piccolo prodotto commerciale,o cmq non da scontrarsi con eticchette che fanno quello dalla mattina alla sera.

e poi sempre con sto bw, scusa ma secondo te il tuo gioco non si distingue da molti altri titoli? in che categoria lo fai rientrare?
almeno passami che il vostro game ha richieste particolari perche e un gioco particolare,no?

cmq forse ho sbagliato a chiederti un parare, non perche non penso che tu abbia le conoscenze tecniche per l analisi, ma per non conoscenza dei pacchetti,o sbaglio?

scusa se non ti quoto e magari il discorso e abbastanza frammentato.

si discussione interessante cmq, ma non ottengo le risposte che chiedevo

ps non c'e astio da parte mia, visto che non rileggo tutto se trovi qualcosa che ti da fastidio sappi che non e volontario, al max un "fan cool" risolve tutto no?

[bgpop]

Se ho capito bene il discorso, la filosofia di Mason sulla generalizzazione potrebbe essere valida in un ambito, quello delle console, dove il progresso è più statico, e soprattutto a "sbalzi"? (Un motore valido per tutto, limitatamente a quella console).

[fek]

Originariamente inviato da Banus
Mi intrometto.
Fek non ti vuole dimostrare che un motore generico non vada bene, o sia necessariamente molto più inefficiente. Ti sta dicendo che è antieconomico e porta via un sacco di tempo.
Un investimento del genere ha senso se poi porta a maggiori profitti, cioè se il motore può essere riutilizzato più volte. Ma in un mercato nel quale il costo medio di sviluppo di un titolo continua a salire e in un settore dove ogni 2-3 anni cambia di molto lo scenario tecnologico, è difficile il riuso, e molto probabile invece trovarsi con un motore vecchio.
Prendendo come esempio un motore sfruttatissimo come quello di Quake 3, avrai letto i commenti di chi si lamentava della difficoltà di Medal of Honor o Call of Duty a gestire grandi spazi aperti, anche con sistemi potenti. Questo perchè quando il motore è nato queste esigenze non c'erano.

Odio quando cerco di spiegare qualcosa per due pagine e poi arriva qualcuno che con un breve post chiarisce tutto il concetto molto meglio di me

[fek]

Originariamente inviato da Mason

ps non c'e astio da parte mia, visto che non rileggo tutto se trovi qualcosa che ti da fastidio sappi che non e volontario, al max un "fan cool" risolve tutto no?

Tranquillo, non ho trovato assolutamente nulla che mi abbia dato fastidio

[joe4th]

Originariamente inviato da ^TiGeRShArK^
...Avete provato a dare uno sguardo alla sign di fek????
no perchè se lo fate vi accrogerete ke PROBABILMENTE qualcosina in più di voi in quest'ambito la conosce per esperienza diretta......

E cmq già x me sarebbe bastato il motivo commerciale, senza tirare in ballo quello tecnico...
Linux è nato x un utenza professionale, non certo x ki si mette a fare giokini....

Non centra assolutamente nulla. Il fatto che fek conosca OpenGL
e DirectX non significa che debba anche la realtà Linux piu'
di tanti altri. Inoltre nella tua affermazione ci sono delle contraddizioni:
la prima e' che affermi che "Linux è nato per un
utenza professionale", questo non centra nulla,
visto che Linux e' nato come clone Minix perché a Linus
piaceva così. Ovvero non è nato un funzione di un mercato
o di un'utenza che è arrivata dopo. Secondo, quello che si
usa per i giochini su Linux, ovvero l'OpenGL, esisteva ed
esiste a prescindere da Linux.
Terzo dimentichi che i giochini non sono solo 3D. Ci sono
dei bellissimi giochi che utilizzano le librerie SDL. Onore a Sam
Latinga.
Quarto. dimentichi che Linux e' solo il kernel. Quando si
parla di desktop, si parla di applicativi che girano
sotto il kernel Linux: ovvero X.org, KDE, Gnome, OpenGL e i cloni free come
Mesa3D. E tali elementi esistono e continuano a funzionare
anche se sostituisci il kernel Linux con uno FreeBSD, OpenBSD, etc.
Infine dire che meglio relegare linux nella fascia server, perché quello è il suo
posto, mi sembra la solita affermazione qualunquista...

[Banus]

Originariamente inviato da fek
Odio quando cerco di spiegare qualcosa per due pagine e poi arriva qualcuno che con un breve post chiarisce tutto il concetto molto meglio di me

E' dal liceo che me lo dicono
Sono troppo sintetico

[Vifani]

Il punto di vista di fek è assolutamente condivisibile. E' ovvio che lui, dall'alto della sua esperienza di una software house di un certo livello, tenda ad avere una visione diciamo... prettamente realistica, dove per realistica intendo, ovviamente, legata al rapporto prezzo-benefici. Alla fine una software house deve innanzitutto far quadrare il bilancio ed è del tutto ovvio che le scelte vengano effettuate principalmente tenendo conto di questo fattore.

Personalmente un motore grafico "generico" penso che sia assolutamente impossibile da realizzare in maniera decente per qualsiasi tipo di utilizzo. Bene o male all'inizio della progettazione si deve decidere se deve essere orientato ad un FPS o ad un RTS/RPG. Gli approcci al rendering, alla gestione della scena e, soprattutto, alle ottimizzazioni sono radicalmente diversi. Il BSP usato nei motori di Quake è solo un esempio, forse un po vecchio diciamo, però un sistema a portali è alla base di un FPS indoor, mentre magari un RTS si concentra massicciamente su un sistema di partizionamento dello spazio (Quadtree, octree, k-tree, ecc...), sulla gestione dinamica del livello di dettaglio e sul view frustrum culling.

[share_it]

linux vince su windoes per velocità del kernel e forse anche del sistema grafico.
Quando è svantaggiato dipende da driver proprietari fatti peggio e giochi ottimizzati per win. Come al solito i problemi di linux sul fronte desktop dipendono da microsoft e dal suo monopolio

[cdimauro]

Originariamente inviato da Mason
... vabbe, questa e' assurda, se vai agli estremi e' sempre assurdo:

perche sviluppare un altro so se c'e' gia windows, perche' differenziare i gusti quando la trattazione di dati distribuiti uniformente e la piu semplice?

cmq penso che siano liberi di commercializzare un prodotto che offre un certo supporto, io son libero di comprarlo o no, io non richiedo a loro di supportare il tuo porc-os o meno, prendo una scheda che lo supporta.

Bene, e allora non ti lamentare dopo averla comprata che manca il supporto per Linux: ci pensavi prima.

E' chiaro che il mio messaggio è provocatorio ed estremista quanto quello che ho quotato, ma con ciò volevo mettere in risalto un concetto fondamentale: prima di scrivere bisognerebbe avere il buon senso di pensare a cosa si sta scrivendo.

certo sbandierare dei driver per linux (e visto la casa produttrice si pensa al 3d quando si compra una scheda del genere) e quantomeno una pubblicita' di cattivo gusto da parte loro, su questo concordi?

Bisogna anche vedere cosa ci fai con la scheda grafica: attualmente ho una 9200SE a lavoro e ti posso assicurare che funziona benissimo così.

[cdimauro]

Originariamente inviato da share_it
linux vince su windoes per velocità del kernel e forse anche del sistema grafico.

Bisogna vedere qual è il target di riferimento.

Quando è svantaggiato dipende da driver proprietari fatti peggio e giochi ottimizzati per win.

Mi sembra una soluzione un po' troppo facilona quella di dare la colpa agli altri: chi ti assicura che i driver il software non sono già "ottimizzati" anche per Linux? Mi sembra che nVidia abbia fatto un ottimo lavoro coi suoi driver binari, e questa recensione l'ha messo in luce...

Come al solito i problemi di linux sul fronte desktop dipendono da microsoft e dal suo monopolio

Com'è che quando si parla di MS si debba inevitabilmente tirare fuori questa storia del monopolio?
Ti ha costretto a comprare Windows? No? E allora mi spiace, ma hai detto una grandissima cazzata che non fa altro che alimentare queste leggende metropolitane.

Invece di perdere tempo a gettare merda su MS e i suoi prodotti, rimboccati le maniche, aiuta la comunità open source e fa in modo che Linux diventi una VALIDA ALTERNATIVA a Windows anche nell'ambito desktop.

[darkbasic]

IMHO creare un motore troppo generico è molto costoso (sia in termini di tempo che di $) e poco conveniente, sopratutto in luce del fatto che si otterrà un motore poco performante e con una serie di features inutili per ogni categoria di giochi. Per quanto riguarda la scelta fra opengl e direct3d, invece, non ho nè conoscenze nè esperienza sufficienti per fare affermazioni come "d3d è meglio di ogl perchè perchè mi basta scrivere metà del codice", però IMHO i giochi multipiattaforma sviluppati in ogl sono da considerare anche come un investimento nel lungo periodo, visto che sono gli unici giochi che "girano" su OS non M$. Chi è che utilizza linux e non ha giochi come UT, RTCW, NWN, Quake?

P.S. discussione molto interessante