Valve annuncia SteamOS

[TheKaneB]

• 

Beh si, sempre di compromesso si tratta, io mi scrivo un piccolo file per la bash lui fa il resto et voillà eccoti il game. Meglio sprecare 20 kb che 600 mega in più per installare un S.O.

Non c'è storia guarda
Scrivere un file in bash è peggio che fare due click. E DOSBox per i giochi di 25 anni fa pesa pochi mega, non 600 :p

[cdimauro]

• 

DOSBox è pure fuori dalla portata dell'utente medio. Molto meglio la soluzione presente da Windows 7, dove dalle proprietà dell'icona del software puoi scegliere il livello di compatibilità (API più altri dettagli). Oppure, sempre a partire da 7 e a partire dalla Pro (mi pare; non ricordo bene adesso) è possibile utilizzare VirtualPC in maniera trasparente.

Fermo restando che con software scritto bene dovrebbe funzionare tutto a prescindere, perché le API Win32 e le DirectX/3D sono decisamente stabili e retrocompatibili.

[Z80Fan]

• 

Le uniche API stabili in Linux son solo le syscall Unix, per il resto tutto é variabile, anche poiché essendo lui solo un kernel sopra ci costruiscono le più varie userland; non parliamo poi dalla volontà di NON inserire API e ABI stabili per driver.

Riguardo steam (son al cellulare quindi scrivo brevemente), dico quello che penso io: supporto questa iniziativa non tanto come una vittoria per Linux (anche se mi fa comodo così non devo riavviare per giocare a molti giochi), ma in generale per il distacco che i giochi avranno dalla piattaforma, passare attraverso librerie multipiattaforma (SDL, OpenGL) permetterà di farli girare su molti più OS che implementano le librerie, e per il resto è molto più semplice mimare a livello API un sistema Linux che Windows.

Un utente non sarà così obbligato alla scelta della piattaforma, e anche se alla fine Windows rimarrà al 95% d'uso, almeno i programmi saranno già predisposti per girare in altri sistemi (molto meno lavoro per creare un layer stile Wine).

[cdimauro]

• 

Questo SE i giochi saranno scritti usando quelle librerie anziché le ben più comode, diffuse, e redditizie DirectX. Ma lo credo poco probabile.

Riguardo alla loro implementazione su Linux, su Phoronix c'è un articolo sul porting delle DirectX 10 che è stato realizzato tempo fa da un italiano (se non ricordo male), che le elogia quale modello di semplicità sia d'uso che d'implementazione (appena 26mila righe di codice), oltre che prestazionali.

[Z80Fan]

• 

La semplicità di implementazione era relativa all'aggiungere un layer si nuova interfaccia sopra Gallium3D, che per progettazione è agnostico all'API grafica che ci gira sopra; per questo si è potuta fornire un'implementazione di Direct3D alle applicazioni.

Fatto sta che quel modulo è sempre stato sperimentale e mai è arrivato ad avere funzioni per far girare un gioco moderno, e anche se ci fosse riuscita, sarebbe rimasta al livello di prestazioni orrendo che hanno i driver open.

Discorso Direct3D vs. OpenGL: si possono perdere pagine e pagine di discussione senza arrivare a niente; alla fine le due sono molto diverse quanto molto simili, nel senso che hanno sintassi diverse per alla fine fare le stesse cose.

Dire che Direct3D è più comoda da programmare è ancora tutto da vedere (è pure difficile trovare buoni articoli di paragone, visto che quasi tutti parlano di "velocità" e non di "facilità di programmazione"); è vero che su OpenGL han fatto quel casino nella versione 3, dove han praticamente lasciato il passo a D3D, ma oggi le OGL 4 sono al pari di funzionalità con le D3D, spesso hanno avuto funzioni (tramite le estensioni) che le Direct3D han avuto dopo, ma sopratutto sono fornite dal driver e non dall'OS, il che vuol dire che, avendo il driver, anche un vecchio sistema diciamo con Windows XP può far girare un programma che usa OGL 4+, o se il gioco e il driver le supportano, usare estensioni proprietarie nVidia/AMD per avere un boost sull'hardware che le supporta e simulandole se non disponibili.

Altri punti a favore di OpenGL sono la disponibilità anche sulle piattaforme embedded (tipicamente tramite la versione ES, che dalle ultime versioni segue abbastanza bene la versione "grossa", tenendo però sempre fuori tutte le cose di compatibilità pre-OpenGL 2), e l'avere binding per tantissimi linguaggi di programmazione.

Infine aggiungo che la maggior parte degli engine moderni sono agnostici all'API usata sotto, visto che devono farlo girare su molti sistemi (DirectX per Windows/XBox, le librerie proprietarie Sony, quelle Nintendo etc...), e riguardo il "alla fine fanno le stesse cose" lo si dimostra proprio dal lavoro di Valve la quale ha messo insieme un sistema di conversione Direct3D->OpenGL (usato nelle sue conversioni come Portal e Left 4 Dead) che raggiunge prestazioni paragonabili al sistema nativo.


I grandi svantaggi di OpenGL secondo me primo è il dover eseguire il bind per fare operazioni su certi oggetti (anche se alcune cose venute dopo, tipo gli shader, prendono l'id dell'oggetto direttamente senza bisogno del bind), ma a quello ci si abitua (sopratutto se si racchiudono le chiamate in oggetti che eseguono i bind/unbind ripristinando lo stato); secondo, moltissimi tutorial OpenGL insegnano OpenGL 1.0, con tutte le chiamate "immediate" per passare i vertici e non citano minimamente le pratiche moderne ovvero i Vertex Buffer e gli shader.


Un tutorial che consiglio fortemente a chi vuole imparare la computer grafica in generale, e iniziare con OpenGL 3.3 in particolare, è questo:
http://www.arcsynthesis.org/gltut/
Oltre a spiegare le cose dal punto di vista geometrico, insegna direttamente il modo di fare "moderno" di OpenGL (che alla fine è lo stesso di Direct3D, cambiano solo i nomi e i comandi) invece che usare tutte le funzioni "legacy" inutili (anche se non approvo l'uso di FreeGLUT come libreria di interfaccia con l'OS; io consiglio sempre SDL che è facilissima da usare, permette di interagire con I/O e audio, e ha molte estensioni ad esempio per caricare immagini e renderizzare font).

[cdimauro]

• 

Sulla comodità delle DirectX rispetto alle OpenGL puoi trovare parecchio materiale dagli sviluppatori che le conoscono e hanno lavorato con entrambe. C'è anche un articolo di Francesco Carucci su Appunti Digitali.
Persino Carmack, un po' di tempo fa, le ha elogiate, quando in precedenza ha passato buona parte della sua vita a sputtanarle...

[Z80Fan]

• 

Sulla comodità delle DirectX rispetto alle OpenGL puoi trovare parecchio materiale dagli sviluppatori che le conoscono e hanno lavorato con entrambe.

Ma che (il materiale) è solo divulgativo e poco tecnico. Io mi fido anche ma non posso andare avanti di ipse dixit, se devo parlare a una persona perchè è meglio l'uno/l'altra devo avere degli esempi di codice effettivo.

C'è anche un articolo di Francesco Carucci su Appunti Digitali.

Immagino tu parli di questo:
http://www.appuntidigitali.it/2497/opengl-vs-direct3d-chi-ha-vinto/
...scritto proprio nel 2008, subito dopo l'uscita di OpenGL 3, ovvero la più grande delusione nella computer grafica.

Per chi non sapesse la storia, Khronos Group per OpenGL 3 aveva promesso un'API completamente nuova, tutta orientata agli oggetti e senza legacy del passato. Per 2-3 anni hanno tenuto un silenzio stampa, per poi uscire nel 2008 con quella che è correntemente OpenGL 3.0, che a differenza di quanto promesso era solo uno step evolutivo dal 2, senza la nuova interfaccia e mantenendo (anche se deprecate) tutte le funzioni legacy. Questa storia ha creato un grave danno per OpenGL, e ha permesso a Direct3D di progredire e prendere mercato.
Per fortuna dopo questo incidente son state riorganizzate le cose nel gruppo, e ora le OpenGL seguono e in alcuni casi anticipano Direct3D in funzionalità, anche se il danno pesa ancora.

Persino Carmack, un po' di tempo fa, le ha elogiate, quando in precedenza ha passato buona parte della sua vita a sputtanarle...

Questo perchè quando ha scritto il suo famoso rant, le Direct3D erano veramente orrende come API; a partire da DirectX 8 invece hanno cominciato a diventare competitive (ad esempio introducendo i Pixel e Vertex shader che in OpenGL c'erano già ma solo attraverso estensioni e non ancora finalizzati dall'ARB) e da li hanno preso piede con vari miglioramenti e innovazioni (mentre OGL era in bilico come detto prima).

[cdimauro]

• 

Purtroppo esempi non te ne posso fornire, perché non è il mio campo. Magari Antonio, che c'ha lavorato, ti saprà dire meglio. Comunque sono curioso quanto te di vedere un confronto, codice alla mano.

[devil78]

• 

Fermo restando che siamo andati un po' fuori traccia, sono favorevole a steam OS e machine, darò il mio contributo affinché il porting su Linux sia continuo (e credo che, se il suo OS sarà linux base d, di certo avrà un motivo in più per farlo) Sono sempre stato coinvolto a guerre religiose tra miglior OS in genere Windows vs Linux ma, stavolta, dirò solo ad ognuno il suo OS ma che i software siano multi OS perché, molto spesso, la scelta da e/o verso un OS all'altro è dato proprio dal software disponibile piuttosto che dalle peculiarità del sistema stesso. Questo discorso è un po' logico, perché esso, infatti, ha la funzione di far interagre l'uomo con la macchina. Mentre l'utente dovrebbe scegliere quale tipo di approccio preferisce ma, allo stato attuale, troppi sono i motivi, spesso legati al software, che obbligano la scelta verso un determinato OS.

[cdimauro]

• 

Scusa la rudezza, ma questo discorso è tutto fuorché logico, perché il software non lo scrivi tu, ma (tanti) altri, e ciò richiede tempo e/o risorse.
Dunque per un professionista è una questione meramente economica. Per cui se la comunità open source paga i costi dello sviluppo, sta tranquillo che difficilmente la software house si tirerà indietro.
Lo sviluppatore che programma per hobby, invece, dedica il suo tempo libero a ciò che, semplicemente, gli piace fare. Per cui se finora non s'è dedicato a Linux et similia dubito che lo farà in futuro perché evidentemente non lo reputa interessante. Poi è chiaro che può sempre cambiare idea, ma per farti un esempio, uno che ha assaggiato C# e, specialmente, .NET, è difficile che li abbandoni, a maggior ragione se è decisamente ben abituato da eccezionali strumenti di sviluppo come Visual Studio.
Detto in altri termini, per queste realtà non ci sono sufficienti motivazioni per supportare Linux & co..

[Z80Fan]

• 

Lo sviluppatore che programma per hobby, invece, dedica il suo tempo libero a ciò che, semplicemente, gli piace fare. Per cui se finora non s'è dedicato a Linux et similia dubito che lo farà in futuro perché evidentemente non lo reputa interessante.

Se parli di sviluppatori Indie, quasi la totalità dei giochi che è uscita di recente supporta anche MacOS e Linux, grazie appunto alle librerie multipiattaforma e agli engine che vengono portati; ad esempio di recente è stato portato Unity, e "automaticamente" alcuni giochi sono usciti per il pinguino, come Kerbal Space Program (che è scritto in C# tra l'altro).

[cdimauro]

• 

No, non mi riferivo agli indie, ma a chi sviluppa semplicemente per hobby.

Gli indie sono una categoria a sé, e se fanno uso di Unity non è certo per fare un favore a Linux o per amore verso di esso. Il supporto a Linux è puramente un "effetto collaterale" dovuto all'adozione di Unity. Tant'è che, tolti i giochi (Unity si usa per questo), siamo punto e da capo con le altre app mobile.

P.S. Sì, lo so, c'è Android. Ma le app girano ovunque, anche su Windows, ma... rimangono app mobile, appunto.

[devil78]

• 

Io parlavo di supporto e supportare significa, contribuire, suggerire, sviluppare, tradurre e acquistare un prodotto sia esso software o no. Quindi come l'utente Windows acquista (o scarica il legalmente) software di certo reca più danni di uno che, nel tempo libero, si preoccupa di sviluppare. Cmq il mio supporto significa che, se uscisse, ad esempio, uncharted su steam io acquisterei per linux. Per dare il mio contributo alla software house che ha lavorato su quel porting. Sempre di soldi si tratta. Personalmente non ho mai usato visual studio ne conosco la piattaforma .Net. Giacché non sono uno sviluppare non credo di avere competenza per discutere di questo. Posso solo dire che ho sviluppato qualcosa con Xcode e lo trovo semplice nonostante le mie capacità siano prossime allo zero. Per cui lascio la logica a chi appartiene ad alti ranghi di capacità intellettive. Io credo solo se gli utenti Linux acquistano allora lo sviluppo verso questo OS sarà una sua naturale conseguenza. Sia esso sviluppato con visual studio, eclipse o, semplicemente, emacs il problema per l'utilizzatore non sussiste.

[cdimauro]

• 

Certamente.
Ma se usi un Mac con OS X, e pure XCode, sei "leggermente" distante da Linux et similia...

[devil78]

• 

Uso anche linux, anzi, uso anche mac... visto che ho il dual boot e uso linux per tutto mac per foto video e musica. Su linux sviluppo con Gambas e QDevelop, piccoli esperimenti da autodidatta, nulla di che.