ArsLudica.org Forum
Cogitare => Officina Creandi => Topic aperto da: Ziggybee - Febbraio 10, 2009, 18:28:20
-
Io non ho mai usato XNA Sad Al fondo c'e' DX. giusto?
E' una versione ulteriormente semplificata delle vecchie implementazioni ad oggetti di DX dei tempi andati. Su di essa poi sono stati introdotti di pattern architetturali standard ed ottimizzati per gestire rendering, multithreading, Live!, calcoli vettoriali, mesh, animazioni, pipeline grafiche programmabili, shader, xact, etc. Insomma, la solita roba di base.
Dulcis in fundo, c'è pure una pipeline dinamica e programmabile per gestire i content di gioco, con la possibilità di scrivere exporter ed importer, nonché di "scalare" i contenuti in base al target di release prescelto (es: downscale di texture e modelli (utilizzando i LOD, ad esempio) per deployare su Zune. La pipeline va molto oltre il content management diventando uno strumento di configurazione per qualsiasi cosa esista in codice e sia parametrizzabile (abbia delle proprietà get/set da manipolare). Esempio pratico: puoi gestirci l'intera timeline di uno shmup, con definizione di ondate, pattern degli avversari, etc...
Prossimamente la pipeline dinamica verrà estesa integreranno anche Silverlight/XAML (una versione moderna di Flash con supporto ad una sintassi a componenti XML-like dichiarativa) per la realizzazione di GUI graficamente e funzionalmente complesse senza bisogno di smazzarsi decine di migliaia di righe di codice, con relativo debug.
Su Windows è già possibile farlo.
Alcuni sono convinti che sia un semplice wrapper stile DX Managed, invece sono interfacce Managed che mappano API native, senza overhead. Altri sostengono che sia una versione semplificata di DX perché hanno tolto tutte le API non legate al gaming (mancano quasi tutte le modalità di rendering tipiche del CAD). Poi ci sono delle funzionalità aggiuntive, che per un programmatore C++ sembrano miracolose ma che sono semplicemente feature di base di .NET.
Ovviamente tutto questo lo si può lasciare Managed (ormai l'overhead è quasi nullo e l'ottimizzazione adattativa di .NET spesso rende meglio sui loop di gioco molto complessi di quanto non faccia un'ottimizzazione nativa automatica), oppure precompilare in nativo ahead of time prima di fare il publish del pacchetto (XBOX/Zune) o al momento dell'installazione (Windows).
-
Per smanettarci serve questo:
Visual C# Express 2008 (dovrebbe funzionare anche con Visual C++ Express 2008 ma supporta solo modalità Managed, col C# la programmazione è più naturale, essendo la sintassi di riferimento per tutto .NET)
E poi l'XNA Game Studio 3, un plug in del Visual Studio, che trovi qui:
http://www.microsoft.com/downloads/details.aspx?familyid=7D70D6ED-1EDD-4852-9883-9A33C0AD8FEE&displaylang=en
Per reference implementation (prototipi di gioco di riferimento, non tutti aggiornati all'ultima versione) e tutorial vari, puoi far rierimento al creator's club di Microsoft.
http://creators.xna.com
-
Fico :D
Curiosita': funziona anche con visual studio 2008 full? immagino di si :)
Stasera me lo scarico e ci faccio space invaders, che e' il mio gioco di test per tutto :D
L'ho fatto pure con l'engine di codemasters per imparare ad usarlo :D
-
Si funziona anche col 2008 ma io per XNA preferisco l'Express per via della leggerezza maggiore, visto che tanto il 90% del resto delle feature diventa inutile.
Ho scoperto che c'è uno shmup stile Galaga nei tutorial (guarda la guida nella sezione extended tutorial).
Affiancato al Curve Editor che scarichi da creator's club (in pratica una GUI per interagire con l'oggetto Curve di XNA che fa le interpolazioni di Bezier) mi ha dato una dritta non da poco per quel problema che avevo per la creazione dei pattern di movimento.
Se ti servono un po' di mesh di prova c'è un paccone di quelli di dark basic con un bel po' di asset che può essere scaricato dal sito di Visual Studio Express (vai nella sezione gaming).
Sullo stesso sito c'è anche la versione free di quel prodotto commerciale che genera le texture proceduralmente con una GUI simile a quella per generare gli effetti audio digitali nei software di sintesi sonora. Veramente figo!
-
In questi giorni sto guardicchiando i tutorial di XNA presenti sul sito. Un po' prolissi (11 minuti per copiare dei file :D) però intravedo le potenzialità.
Se qualcuno qui l'ha già usato, vorrei capire se è possibile fare questo:
- vorrei poter controllare la pipeline per fare una prepassata con solo Z-Buffer, una con le normali ed una con il colore, per fare un po' di effetti interessanti (particelle finto volumetriche, deferred lighting e così via). Si ha un controllo del genere sulla sua pipeline?
- Ho cercato un engine per la fisica, ma non ho trovato molto, a parte un wrapper di physics non ufficiale e una versione di Newton physics solo per Windows.
qualcuno sa se ci sono degli engine fisici compatibili con XNA?
- Esiste qualcosa per le GUI? Qualcosa di semplice e solido? Non voglio perderci troppo tempo.
- Se faccio delle cose in mutithreading usando le robe di .NET, su X360 userà correttamente i core, non saturando quello su cui gira il sistema operativo? Posso avere controllo a basso livello su questo lato?
- Se volessi fare dello streaming di dati, avrei bisogno di preallocare dei buffer, con controllo preciso della loro dimensione per la gestione del caso peggiore. Ho un controllo approfondito sulla memoria con .NET oppure è assolutamente impredicibile come in Java?
Grazie a chi risponderà :D (che mi sa che sarà z.e.r.o. :D)
-
Ok prima delusione: caricando un modello3d ti carica anche le texture.
Questo apre un mondo intero di problemi pazzeschi, che da anni ed anni sono stati risolti mettendo i materiali fuori dalle mesh.
-
Avevo trovato una sfilza di motivi per non usare xna per studiare, ma me li sono dimenticati tutti :D
-
Avevo trovato una sfilza di motivi per non usare xna per studiare, ma me li sono dimenticati tutti :D
Questa cosa delle texture me l'ha fatto accantonare completamente. Domani vedo si può evitare il caricamento delle texture.
-
Iniziamo dalle cose semplici.
Presumo che tu sappia come funziona il threading della 360, faccio lo stesso una intro per gli altri.
X360 ha 3 core, ognuno supporta 2 thread hardware., quindi il core 0 gestisce i thread 0 e 1, il core 1 i thread 2 e 3 e così via.
XNA riserva i thread 0 e 2 per sé (rendering pipeline ed il resto, grosso modo), gli altri 4 thread sono ad uso e consumo esclusivo del gioco. Il gioco parte sempre dal thread 1.
L'allocazione sui thread hardware rimanenti è fatta in round robin, quindi se uno ha meno di 4 task in esecuzione parallela può contare sempre sul fatto che ognuno di essi viaggi su un thread dedicato, senza troppi problemi.
Se devi fare cose strane, puoi gestire i thread manualmente, settando la loro ProcessorAffinity manualmente.
Se fai pooling, devi considerare alcune cose (che sicuramente sai), come il fatto che, non appena un thread va in cache miss, la X360 switcha thread, sperando che ci sia qualcosa di utile da fare altrove, mentre il core che ha missato fa il fetch.
-
Ok prima delusione: caricando un modello3d ti carica anche le texture.
Questo apre un mondo intero di problemi pazzeschi, che da anni ed anni sono stati risolti mettendo i materiali fuori dalle mesh.
Le texture le puoi caricare anche manualmente. E' l'importer di default che carica tutto insieme. Sul manuale ci sono anche i tutorial per caricare texture manualmente.
-
Ok prima delusione: caricando un modello3d ti carica anche le texture.
Questo apre un mondo intero di problemi pazzeschi, che da anni ed anni sono stati risolti mettendo i materiali fuori dalle mesh.
Le texture le puoi caricare anche manualmente. E' l'importer di default che carica tutto insieme. Sul manuale ci sono anche i tutorial per caricare texture manualmente.
Sono un pochino più contento. Mi puoi indicare i tutorial? :)
-
- vorrei poter controllare la pipeline per fare una prepassata con solo Z-Buffer, una con le normali ed una con il colore, per fare un po' di effetti interessanti (particelle finto volumetriche, deferred lighting e così via). Si ha un controllo del genere sulla sua pipeline?
Non sono un espertone di grafica 3d spinta, quindi non so se c'è tutto quello che cerchi, ma con XNA la pipeline la controlli tramite gli Effect che carichi ed invochi quando fai il rendering. Gli effect sono una commistione di classi e shader. Fossi in te inizierei da li e mi definirei uno o più effect che facciano ciò che vuoi.
- Ho cercato un engine per la fisica, ma non ho trovato molto, a parte un wrapper di physics non ufficiale e una versione di Newton physics solo per Windows. qualcuno sa se ci sono degli engine fisici compatibili con XNA?
Io ho giochicchiato con questa, è il port di Bullet per XNA:
http://www.codeplex.com/xnadevru/Wiki/View.aspx?title=Managed%20Bullet%20Physics%20Library&referringTitle=Home
Bullet è una libreria fisica che viene usata anche per giochi commerciali
Questa è una libreria che supporta la soft body:
http://walaber.com/index.php?action=showitem&id=16
Tempo fa mi hanno suggerito anche questa, ma non l'ho nemmeno aperta per guardarla:
http://www.bepu-games.com/BEPUphysics/
Questa invece è ancora in embrione:
http://www.codeplex.com/JigLibX
- Esiste qualcosa per le GUI? Qualcosa di semplice e solido? Non voglio perderci troppo tempo.
Dipende dalla GUI, molti elementi di base (menù, schermate di configurazione, HUD, pannelli di debug) sono definiti nelle reference implementation, se vuoi qualcosa di più complesso ci sono diverse librerie che supportano windowing e immediate mode, ma sono tutte, IMHO, troppo complesse o verbose. Se è per tool & roba simile, sappi che su windows puoi abilitare XNA nei contesti grafici di WPF, creando GUI flash-like che supportano databinding (associare proprietà degli oggetti a stati o elementi della GUI) integrate con i motori 3D XNA. Dalla prossima versione dovrebbe essere possibile anche per 360, visto che WPF Mobile è imminente.
- Se volessi fare dello streaming di dati, avrei bisogno di preallocare dei buffer, con controllo preciso della loro dimensione per la gestione del caso peggiore. Ho un controllo approfondito sulla memoria con .NET oppure è assolutamente impredicibile come in Java?
Che intendi per controllo approfondito? Che intendi per impredicibile come Java?
-
Ti volevo mandare delle presentazioni ma sono IMMENSE, fortunatamente stanno quasi tutte qui:
http://msdn.microsoft.com/en-us/xna/aa937787.aspx
Ci sono un sacco di risposte ai tuoi interrogativi sulla gestione della memoria, guarda in basso, le presentazioni del 2006.
Per le texture sto verificando una cosa, la soluzione dovrebbe essere banale.
-
Per controllo approfondito intendo:
alloco questo buffer che conterrà al massimo N mesh grandi al massimo N Kb (tra index e vertex buffer).
Quando carico la mesh, la carico in quei buffer.
Immagino che in qualche modo di possa, ma però ho un terribile dubbio.
Il tutto mi suona un po' come "se vuoi fare le figate, devi farti tutto da te e non usare niente di quello che c'è già".
-
Guardati bene il capitolo Content Pipeline, c'è tutto quello che serve per capire come funziona il caricamento degli asset e come intervenire sul processing dei contenuti e dello streaming.
Il tuo problema è che XNA preottimizza tutti i content. Utilizzando il ModelContentProcessor di default, non puoi fare a meno di caricare anche le texture, visto che il sistema ottimizza lo streaming in quel modo.
Ma si può cambiare.
Scriviti un ContentProcessor custom che derivi dal ModelContentProcessor. In realtà non devi fare quasi nulla, tranne customizzarti il metodo processmaterials, per non mettere una ExternalReference alla texture. In questo modo XNA non la caricherà da sola, ma caricherà solo le informazioni dei materiali (sempre se ti servono).
I processor si chiamano in cascata per ogni content associato a quello che stai caricando, quindi ti puoi sbizzarrire.
Per le Texture, ti basta utilizzare il content processor di default, che ti instanzia una Texture2D o Texture3D a seconda delle tue necessità e quando ti serve.
In questo modo ti puoi gestire le texture, gli effetti e le tecniche manualmente durante il rendering.
-
Per controllo approfondito intendo:
alloco questo buffer che conterrà al massimo N mesh grandi al massimo N Kb (tra index e vertex buffer).
Quando carico la mesh, la carico in quei buffer.
Immagino che in qualche modo di possa, ma però ho un terribile dubbio.
Il tutto mi suona un po' come "se vuoi fare le figate, devi farti tutto da te e non usare niente di quello che c'è già".
Le mesh sono statiche o dinamiche?
-
Per controllo approfondito intendo:
alloco questo buffer che conterrà al massimo N mesh grandi al massimo N Kb (tra index e vertex buffer).
Quando carico la mesh, la carico in quei buffer.
Immagino che in qualche modo di possa, ma però ho un terribile dubbio.
Il tutto mi suona un po' come "se vuoi fare le figate, devi farti tutto da te e non usare niente di quello che c'è già".
Le mesh sono statiche o dinamiche?
Intendi dire se il vertex buffer cambia durante l'esecuzione del programma? Se è così, no :)
-
Mi pare di capire che le dimensioni massime sono note a priori, o no?
Fatti una ArrayList di N Mesh, al limite estendila per gestire il riuso delle istanze, così non incasini il garbage collector e non chiami proprio l'allocatore della 360 :)
In pratica io ho un allocatore (scritto coi generics) che mi gestisce buffer di N oggetti arbitrari. All'inizio mi prealloca le N istanze, da quel momento in poi quando me ne serve una, la chiedo a lui, quando una non mi serve più la dò a lui, così me la tiene in caldo sino a che non mi riserve. Utile quando hai migliaia di proiettili da gestire con relative geometrie. :)
Se ho finito gli N oggetti a disposizione me lo dice così mi regolo.
Ma è un terrain engine per caso?
-
Mi pare di capire che le dimensioni massime sono note a priori, o no?
Fatti una ArrayList di N Mesh, al limite estendila per gestire il riuso delle istanze, così non incasini il garbage collector e non chiami proprio l'allocatore della 360 :)
In pratica io ho un allocatore (scritto coi generics) che mi gestisce buffer di N oggetti arbitrari. All'inizio mi prealloca le N istanze, da quel momento in poi quando me ne serve una, la chiedo a lui, quando una non mi serve più la dò a lui, così me la tiene in caldo sino a che non mi riserve. Utile quando hai migliaia di proiettili da gestire con relative geometrie. :)
Se ho finito gli N oggetti a disposizione me lo dice così mi regolo.
Ma è un terrain engine per caso?
Ok, quindi si può.
No, niente terrain engine :D Non ho idea di quello che voglio fare, sto solo cercando di capire quali limiti il sistema mi imporrà :D
-
Io uso questa regola aurea che sovrastima abbastanza: per 50MB/s di traffico in oggetti (gestiti senza alcuna pre-ottimizzazione delle allocazioni) un GC non gestito crea circa 500Kb di overhead per la gestione dell'heap (oggetti temporanei, reference counter, tabelle dei cicli di vita, etc etc).
Io non mi sono mai fatto troppi problemi perché sono molto lontano dal saturare la memoria della 360 ma se usi quel margine di prudenza, considerando pure che ogni oggetto che utilizzi lo ricrei nell'heap ad ogni ciclo, sicuramente ci stai dentro.
Cmq ti ricordo che puoi andare in debug da visual studio tramite ethernet sulla 360, quindi puoi vedere chiaramente quanto overhead viene generato dal tuo engine nell'ambiente di esecuzione di .NET, nonché profilare.
-
http://creators.xna.com/it-IT/sample/normalmapping
???
Ma stiamo scherzando? Apriamo il file e guardiamo che casino mostruoso bisogna fare per programmare la pipeline.
Inconcepibile.
Siamo pure in un linguaggio al alto livello.
Fare un materiale nuovo dovrebbe essere una banalità, qui invece è un casino mostruoso.
Ma perfavore.
-
Ma ti riferisci ai processor?
Quello è un pezzo della content pipeline, se vuoi implementare il normal mapping SENZA predisporre i contenuti per uno streaming ottimizzato e multipiattaforma, integrato con visual studio non c'è bisogno di tutto quel casino, ti carichi geometrie, texture e modelli e poi ti implementi tutto a mano, con dei loading time di 4-5 ore :)
-
Ma ti riferisci ai processor?
Quello è un pezzo della content pipeline, se vuoi implementare il normal mapping SENZA predisporre i contenuti per uno streaming ottimizzato e multipiattaforma, non c'è bisogno di tutto quel casino.
Mi sa che non hai mai visto come si fa questa roba nei gochi fatti coi i sistemi normali :D
Se voglio fare il normalmapping con neon, in tre minuti faccio il normal mapping ottimizzato per tre piattaforme.
Ed è in C++.
Qui invece per fare il normal mapping devo fare un macello per farlo andare ottimizzato solo su due.
Mi aspettavo che tutto sto .NET, con le sue promesse, non mi facesse fare PIU' lavoro di quanto non sia richiesto da un sistema che lavora in C++.
-
cmq penso che quello sia un esempio vecchio (tipo per 1.0 o 2.0), io faccio così:
namespace NormalMappingProcessor
{
[ContentProcessor(DisplayName = "Model - ShipGame Normal Mapping")]
public class NormalMappingModelProcessor : ModelProcessor
{
public const string TextureMapKey = "Texture";
public const string NormalMapKey = "Bump0";
public const string SpecularMapKey = "Specular0";
public const string GlowMapKey = "Emissive0";
public override ModelContent Process(NodeContent input,
ContentProcessorContext context)
{
if (input == null)
{
throw new ArgumentNullException("input");
}
PreprocessSceneHierarchy(input);
return base.Process(input, context);
}
private void PreprocessSceneHierarchy(NodeContent input)
{
MeshContent mesh = input as MeshContent;
if (mesh != null)
{
MeshHelper.CalculateTangentFrames(mesh,
VertexChannelNames.TextureCoordinate(0),
VertexChannelNames.Tangent(0),
VertexChannelNames.Binormal(0));
foreach (GeometryContent geometry in mesh.Geometry)
{
if (false == geometry.Material.Textures.ContainsKey(TextureMapKey))
geometry.Material.Textures.Add(TextureMapKey,
new ExternalReference<TextureContent>(
"null_color.tga"));
if (false == geometry.Material.Textures.ContainsKey(NormalMapKey))
geometry.Material.Textures.Add(NormalMapKey,
new ExternalReference<TextureContent>(
"null_normal.tga"));
if (false == geometry.Material.Textures.ContainsKey(SpecularMapKey))
geometry.Material.Textures.Add(SpecularMapKey,
new ExternalReference<TextureContent>(
"null_specular.tga"));
if (false == geometry.Material.Textures.ContainsKey(GlowMapKey))
geometry.Material.Textures.Add(GlowMapKey,
new ExternalReference<TextureContent>(
"null_glow.tga"));
}
}
foreach (NodeContent child in input.Children)
{
PreprocessSceneHierarchy(child);
}
}
static IList<string> acceptableVertexChannelNames =
new string[]
{
VertexChannelNames.TextureCoordinate(0),
VertexChannelNames.Normal(0),
VertexChannelNames.Binormal(0),
VertexChannelNames.Tangent(0)
};
protected override void ProcessVertexChannel(GeometryContent geometry,
int vertexChannelIndex, ContentProcessorContext context)
{
String vertexChannelName =
geometry.Vertices.Channels[vertexChannelIndex].Name;
// if this vertex channel has an acceptable names, process it as normal.
if (acceptableVertexChannelNames.Contains(vertexChannelName))
{
base.ProcessVertexChannel(geometry, vertexChannelIndex, context);
}
// otherwise, remove it from the vertex channels; it's just extra data
// we don't need.
else
{
geometry.Vertices.Channels.Remove(vertexChannelName);
}
}
protected override MaterialContent ConvertMaterial(MaterialContent material,
ContentProcessorContext context)
{
EffectMaterialContent normalMappingMaterial = new EffectMaterialContent();
normalMappingMaterial.Effect = new ExternalReference<EffectContent>
("shaders/NormalMapping.fx");
foreach (KeyValuePair<String, ExternalReference<TextureContent>> texture
in material.Textures)
{
normalMappingMaterial.Textures.Add(texture.Key, texture.Value);
}
return context.Convert<MaterialContent, MaterialContent>
(normalMappingMaterial, typeof(MaterialProcessor).Name);
}
}
}
-
Ma cos'è sta roba??
protected override void ProcessVertexChannel(GeometryContent geometry,
int vertexChannelIndex, ContentProcessorContext context)
{
String vertexChannelName =
geometry.Vertices.Channels[vertexChannelIndex].Name;
// if this vertex channel has an acceptable names, process it as normal.
if (acceptableVertexChannelNames.Contains(vertexChannelName))
{
base.ProcessVertexChannel(geometry, vertexChannelIndex, context);
}
// otherwise, remove it from the vertex channels; it's just extra data
// we don't need.
else
{
geometry.Vertices.Channels.Remove(vertexChannelName);
}
}
Cosa fa questo codice? Perchè serve? E perchè serve nel progetto del gioco?
Questa roba deve stare fuori! Cos'è questo mischiare creazione di asset col gioco?
-
Ma cos'è sta roba??
protected override void ProcessVertexChannel(GeometryContent geometry,
int vertexChannelIndex, ContentProcessorContext context)
{
String vertexChannelName =
geometry.Vertices.Channels[vertexChannelIndex].Name;
// if this vertex channel has an acceptable names, process it as normal.
if (acceptableVertexChannelNames.Contains(vertexChannelName))
{
base.ProcessVertexChannel(geometry, vertexChannelIndex, context);
}
// otherwise, remove it from the vertex channels; it's just extra data
// we don't need.
else
{
geometry.Vertices.Channels.Remove(vertexChannelName);
}
}
Cosa fa questo codice? Perchè serve? E perchè serve nel progetto del gioco?
Questa roba deve stare fuori! Cos'è questo mischiare creazione di asset col gioco?
E' proprio per evitare di avere decine di developer ognuno con la sua parrocchia, limitare i costi e snellire i tempi di gestione di tutto il processo di sviluppo.
Comunque la gestione dei processor non riguarda il programmatore grafico. Se avessi letto la documentazione lo sapresti.
Quello che hai visto tu è un ESEMPIO. Nei progetti veri, come nelle reference implementation quel codice se ne sta nella sua assembly di gestione degli asset (scritta una volta e poi dimenticata per sempre). L'esempio ti spiega come fare ma non è che tu lo devi per forza rifare. Se ragioni su questa logica, dovresti metterti a leggere tutti i sorgenti di .NET, visto che te li corredano :)
Cmq al programmatore non frega una ceppa. Al grafico nemmeno.
Può sembrare verboso, specie se lo paragoni ad un middleware, eppure di giochi per 360 basati su XNA ne sono già usciti parecchi (parlo di quelli XBLA, non Community) e stimati professionisti finiscono un progetto in pochi mesi con staff piccolissimi e molto più agili ed economici di quelli con utilizzo di tecnologie più datate.
-
Non lo metto in dubbio: Sai bene quanti giochi hanno fatto con Renderware e renderware era una vera merda.
Questa è solo la nuova merda obbligatoria per fare giochi per il marketplace. Più lo guardo più mi disgusta.
Anche la faccenda degli attributi. Che vergogna.
-
Ma cos'è sta roba??
protected override void ProcessVertexChannel(GeometryContent geometry,
int vertexChannelIndex, ContentProcessorContext context)
{
String vertexChannelName =
geometry.Vertices.Channels[vertexChannelIndex].Name;
// if this vertex channel has an acceptable names, process it as normal.
if (acceptableVertexChannelNames.Contains(vertexChannelName))
{
base.ProcessVertexChannel(geometry, vertexChannelIndex, context);
}
// otherwise, remove it from the vertex channels; it's just extra data
// we don't need.
else
{
geometry.Vertices.Channels.Remove(vertexChannelName);
}
}
Cosa fa questo codice? Perchè serve? E perchè serve nel progetto del gioco?
Questa roba deve stare fuori! Cos'è questo mischiare creazione di asset col gioco?
E' proprio per evitare di avere decine di developer ognuno con la sua parrocchia, limitare i costi e snellire i tempi di gestione di tutto il processo di sviluppo.
Comunque la gestione dei processor non riguarda il programmatore grafico.
Infatti qui in casa mia in questo momento siamo in dieci programmatori che vorrebbero fare un giochino, ognuno con la sua specializzazione.
-
Non lo metto in dubbio: Sai bene quanti giochi hanno fatto con Renderware e renderware era una vera merda.
Questa è solo la nuova merda obbligatoria per fare giochi per il marketplace. Più lo guardo più mi disgusta.
Anche la faccenda degli attributi. Che vergogna.
Aho, se non ti piace pazienza :)
Attributi?
-
Lezione 18, attributi:
http://www.softsteel.co.uk/tutorials/cSharp/lesson18.html
Usati estensivamente nell'esempio di cui sopra.
-
Ma cos'è sta roba??
protected override void ProcessVertexChannel(GeometryContent geometry,
int vertexChannelIndex, ContentProcessorContext context)
{
String vertexChannelName =
geometry.Vertices.Channels[vertexChannelIndex].Name;
// if this vertex channel has an acceptable names, process it as normal.
if (acceptableVertexChannelNames.Contains(vertexChannelName))
{
base.ProcessVertexChannel(geometry, vertexChannelIndex, context);
}
// otherwise, remove it from the vertex channels; it's just extra data
// we don't need.
else
{
geometry.Vertices.Channels.Remove(vertexChannelName);
}
}
Cosa fa questo codice? Perchè serve? E perchè serve nel progetto del gioco?
Questa roba deve stare fuori! Cos'è questo mischiare creazione di asset col gioco?
E' proprio per evitare di avere decine di developer ognuno con la sua parrocchia, limitare i costi e snellire i tempi di gestione di tutto il processo di sviluppo.
Comunque la gestione dei processor non riguarda il programmatore grafico.
Infatti qui in casa mia in questo momento siamo in dieci programmatori che vorrebbero fare un giochino, ognuno con la sua specializzazione.
Boh, cmq renditi conto che stai criticando qualcosa che va ben oltre il semplice "carico un modello per fare normal mapping".
-
Sto criticando qualcosa che per fare una banalità richiede paginate di codice.
Probabilmente se mi chiedessi di farlo in C++ da zero con DX, il listato sarebbe più breve.
Sto criticando qualcosa che è esattamente come Renderware: una merda pazzesca, ma bisogna usarlo per forza, perchè è così punto e stop.
Gli concedo ancora esattamente 8 ore del mio tempo, solamente perchè a te piace tanto e quindi qualcosa di buono ci deve essere per forza.
-
Benvenuto nel ventesimo secolo, le annotazioni, le lambda operations e l'AOP sono diventate la norma nei linguaggi ad oggetti moderni.
L'attributo serve per definire i parametri necessari al Visual Studio, visto che il processor è un plug in di Visual Studio e MSBuild.
In pratica l'attributo stà la per dire a VS (o ad un'altro software) che il tuo binario ha dei metodi che possono essere agganciati per fare qualcosa di specifico. E' utile, come nel caso dei processor, per sviluppare plugin per gli IDE o le applicazioni, dove i metodi sono in grado di autodefinirsi e descriversi per essere integrati in altri ambienti.
Ad esempio se hai una struttura dati di un salvataggio e vuoi poterla serializzare in XML ma per motivi tuoi hai necessità di cambiare l'associazione di alcune proprietù dell'oggetto in elementi piuttosto che attributi dell'XML con due annotazioni lo fai, senza dover riscrivere la classe o gestire la serializzazione manualmente. E' il serializzatore che esplora gli oggetti a sapere come regolarsi quando incontra un'annotazione.
La cosa che non vedi mai negli esempio, ma che sarebbe la norma è che gli attributi non dovrebbero mai essere nel Main code del tuo oggetto ma in una classe parziale (un'aspetto, se preferisci) scritta apposta per essere configurabile indipendentemente dal resto: in questo modo hai dei repository per intervenire sui metadati degli oggetti, senza necessariamente intervenire sull'implementazione.
-
Capiamoci bene: questo listato
#region File Description
//-----------------------------------------------------------------------------
// NormalMappingEffect.cs
//
// Microsoft XNA Community Game Platform
// Copyright (C) Microsoft Corporation. All rights reserved.
//-----------------------------------------------------------------------------
#endregion
#region Using Statements
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;
#endregion
namespace NormalMappingEffect
{
/// <summary>
/// Sample shows how to render a model using a custom effect.
/// </summary>
public class NormalMappingEffectGame : Microsoft.Xna.Framework.Game
{
#region Fields
GraphicsDeviceManager graphics;
KeyboardState lastKeyboardState = new KeyboardState();
GamePadState lastGamePadState = new GamePadState();
KeyboardState currentKeyboardState = new KeyboardState();
GamePadState currentGamePadState = new GamePadState();
Model model;
// the next 4 fields are inputs to the normal mapping effect, and will be set
// at load time. change these to change the light properties to modify
// the appearance of the model.
Vector4 lightColor = new Vector4(1, 1, 1, 1);
Vector4 ambientLightColor = new Vector4(.2f, .2f, .2f, 1);
float shininess = .3f;
float specularPower = 4.0f;
// the sample arc ball camera values
float cameraArc = 0;
float cameraRotation = 45;
float cameraDistance = 1500;
// the light rotates around the origin using these 3 constants. the light
// position is set in the draw function.
const float LightHeight = 600;
const float LightRotationRadius = 800;
const float LightRotationSpeed = .5f;
bool rotateLight = true;
float lightRotation;
#endregion
#region Initialization
public NormalMappingEffectGame()
{
Content.RootDirectory = "Content";
graphics = new GraphicsDeviceManager(this);
graphics.PreferredBackBufferWidth = 853;
graphics.PreferredBackBufferHeight = 480;
graphics.MinimumPixelShaderProfile = ShaderProfile.PS_2_0;
}
/// <summary>
/// Load your graphics content.
/// </summary>
protected override void LoadContent()
{
model = Content.Load<Model>("lizard");
foreach (ModelMesh mesh in model.Meshes)
{
foreach (Effect effect in mesh.Effects)
{
effect.Parameters["LightColor"].SetValue(lightColor);
effect.Parameters["AmbientLightColor"].SetValue
(ambientLightColor);
effect.Parameters["Shininess"].SetValue(shininess);
effect.Parameters["SpecularPower"].SetValue(specularPower);
}
}
}
#endregion
#region Update and Draw
/// <summary>
/// Allows the game to run logic.
/// </summary>
protected override void Update(GameTime gameTime)
{
HandleInput();
UpdateCamera(gameTime);
// Turn on the rotating light
if ((currentGamePadState.Buttons.A == ButtonState.Pressed &&
lastGamePadState.Buttons.A != ButtonState.Pressed) ||
(currentKeyboardState.IsKeyUp(Keys.Space) &&
lastKeyboardState.IsKeyDown(Keys.Space)))
{
rotateLight = !rotateLight;
}
base.Update(gameTime);
}
/// <summary>
/// This is called when the game should draw itself.
/// </summary>
protected override void Draw(GameTime gameTime)
{
GraphicsDevice device = graphics.GraphicsDevice;
device.Clear(Color.CornflowerBlue);
float aspectRatio = (float)device.Viewport.Width /
(float)device.Viewport.Height;
// Compute camera matrices.
Matrix unrotatedView = Matrix.CreateLookAt(
new Vector3(0, 0, -cameraDistance), Vector3.Zero, Vector3.Up);
Matrix view = Matrix.CreateRotationY(MathHelper.ToRadians(cameraRotation)) *
Matrix.CreateRotationX(MathHelper.ToRadians(cameraArc)) *
unrotatedView;
Matrix projection = Matrix.CreatePerspectiveFieldOfView(MathHelper.PiOver4,
aspectRatio,
1,
10000);
if (rotateLight)
{
lightRotation +=
(float)gameTime.ElapsedRealTime.TotalSeconds * LightRotationSpeed;
}
Matrix lightRotationMatrix = Matrix.CreateRotationY(lightRotation);
Vector3 lightPosition = new Vector3(LightRotationRadius, LightHeight, 0);
lightPosition = Vector3.Transform(lightPosition, lightRotationMatrix);
// Draw the model.
Matrix[] transforms = new Matrix[model.Bones.Count];
model.CopyAbsoluteBoneTransformsTo(transforms);
foreach (ModelMesh mesh in model.Meshes)
{
foreach (Effect effect in mesh.Effects)
{
Matrix world = transforms[mesh.ParentBone.Index];
effect.Parameters["World"].SetValue(world);
effect.Parameters["View"].SetValue(view);
effect.Parameters["Projection"].SetValue(projection);
effect.Parameters["LightPosition"].SetValue(lightPosition);
}
mesh.Draw();
}
base.Draw(gameTime);
}
#endregion
#region Handle Input
/// <summary>
/// Handles input for quitting the game.
/// </summary>
private void HandleInput()
{
lastKeyboardState = currentKeyboardState;
lastGamePadState = currentGamePadState;
currentKeyboardState = Keyboard.GetState();
currentGamePadState = GamePad.GetState(PlayerIndex.One);
// Check for exit.
if (currentKeyboardState.IsKeyDown(Keys.Escape) ||
currentGamePadState.Buttons.Back == ButtonState.Pressed)
{
Exit();
}
}
/// <summary>
/// Handles camera input.
/// </summary>
private void UpdateCamera(GameTime gameTime)
{
float time = (float)gameTime.ElapsedGameTime.TotalMilliseconds;
// Check for input to rotate the camera up and down around the model.
if (currentKeyboardState.IsKeyDown(Keys.Up) ||
currentKeyboardState.IsKeyDown(Keys.W))
{
cameraArc += time * 0.1f;
}
if (currentKeyboardState.IsKeyDown(Keys.Down) ||
currentKeyboardState.IsKeyDown(Keys.S))
{
cameraArc -= time * 0.1f;
}
cameraArc += currentGamePadState.ThumbSticks.Right.Y * time * 0.25f;
// Limit the arc movement.
if (cameraArc > 90.0f)
cameraArc = 90.0f;
else if (cameraArc < -90.0f)
cameraArc = -90.0f;
// Check for input to rotate the camera around the model.
if (currentKeyboardState.IsKeyDown(Keys.Right) ||
currentKeyboardState.IsKeyDown(Keys.D))
{
cameraRotation += time * 0.1f;
}
if (currentKeyboardState.IsKeyDown(Keys.Left) ||
currentKeyboardState.IsKeyDown(Keys.A))
{
cameraRotation -= time * 0.1f;
}
cameraRotation += currentGamePadState.ThumbSticks.Right.X * time * 0.25f;
// Check for input to zoom camera in and out.
if (currentKeyboardState.IsKeyDown(Keys.Z))
cameraDistance += time * 0.5f;
if (currentKeyboardState.IsKeyDown(Keys.X))
cameraDistance -= time * 0.5f;
cameraDistance += currentGamePadState.Triggers.Left * time;
cameraDistance -= currentGamePadState.Triggers.Right * time;
// Limit the camera distance.
if (cameraDistance > 5000.0f)
cameraDistance = 5000.0f;
else if (cameraDistance < 350.0f)
cameraDistance = 350.0f;
if (currentGamePadState.Buttons.RightStick == ButtonState.Pressed ||
currentKeyboardState.IsKeyDown(Keys.R))
{
cameraArc = 0;
cameraRotation = 45;
cameraDistance = 1500;
}
}
#endregion
}
#region Entry Point
/// <summary>
/// The main entry point for the application.
/// </summary>
static class Program
{
static void Main()
{
using (NormalMappingEffectGame game = new NormalMappingEffectGame())
{
game.Run();
}
}
}
#endregion
}
E' buono. E' quello che mi aspetto da un framework.
Ma.
Il materiale "normal mapping" chi gliel'ha assegnato alla lucertola? E i multimaterial? Ovviamente gestiti dal loop sui materiali. Chi viene prima? Come si chiamano? Come setto le trasformazioni ad ognuno? Lo posso fare?
Tutto l'assegnamento è fatto in quel codice inguardabile presente nell'altro progetto? Così sembra. Chi lo chiama? Esiste da qualche parte un binding? Perchè è tutto nascosto?
Quella lucertola da dove arriva? Da max? Da Maya? chi ha fatto quell'fbx? Che materiale gli ha assegnato?
Non potevano fare un exporter per il loro formato? Con dentro le mesh, le texture fuori ed i materiali fuori? Perchè usare formati vecchi e brutti per poi farli convertire da visual studio in qualcosa di ignoto?
-
Sto criticando qualcosa che per fare una banalità richiede paginate di codice.
Probabilmente se mi chiedessi di farlo in C++ da zero con DX, il listato sarebbe più breve.
Sto criticando qualcosa che è esattamente come Renderware: una merda pazzesca, ma bisogna usarlo per forza, perchè è così punto e stop.
Gli concedo ancora esattamente 8 ore del mio tempo, solamente perchè a te piace tanto e quindi qualcosa di buono ci deve essere per forza.
Io mi ci trovo bene, ma devi pure considerare che ho familiarità con C# e tutte le caratteristiche della programmazione ad oggetti di nuova generazione, che con .NET 3 hanno dato filo da torcere ad un sacco di gente (io ancora non faccio mio il lambda code ma sto imparando :P).
E non sono uno che programma con la scopa al culo, in .NET dichiaro proprietà solo se hanno una ragione di esistere, visto che a livello di integrazione col resto del codice non c'è differenza tra una proprietà get/set o un membro pubblico.
Se leggi la mia recensione che passò su Slashdot di XNA 1.0 anche io dicevo che era una deludente merda pazzesca.
-
Lo che ti ci trovi bene: non fai che parlarne bene :D
Ma io qui non vedo un ambiente professionale. Vedo un ambiente per giocare. Che se voi farci qualcosa di serio puoi usare sì e no l'1% delle sue funzionalità e riscriverti tutto il resto.
Ah: le funzioni lambda ci sono da anni in Boost, in C++ :D Così come un po' tutto quello che c'è di nuovi nei nuovi linguaggi.
Semplicemente nei nuovi linguaggi è tutto più simile alla teoria, quindi dovrebbe essere tutto più facile.
In Python E' tutto più facile. Qui mi sembra che è tutto bello finchè non ci devi lavorare :D
-
E' buono. E' quello che mi aspetto da un framework.
Ma.
Il materiale "normal mapping" chi gliel'ha assegnato alla lucertola? E i multimaterial? Ovviamente gestiti dal loop sui materiali. Chi viene prima? Come si chiamano? Come setto le trasformazioni ad ognuno? Lo posso fare?
Si leggiti i manuali, lo puoi fare. Solo che, purtroppo, essendo qualcosa di totalmente nuovo parti completamente svantaggiato, ci sono passato pure io, che, tra parentesi, ho sempre preferito le API DX in C a quelle in C++.
Tutto l'assegnamento è fatto in quel codice inguardabile presente nell'altro progetto? Così sembra. Chi lo chiama? Esiste da qualche parte un binding? Perchè è tutto nascosto?
Lo chiama Visual Studio quando compili (leggiti il manuale). Quando lanci il build, XNA prende i content sviluppati dai grafici e tramite il collante degli importer e dei processor crea il suo formato proprietario intermedio, ottimizzato a seconda della piattaforma, a partire a formati brutti e vecchi perché spesso sono quelli che la gente sa usare. Per esempio, alcuni processor sono parametrizzabili.
Tu dirai perché? Perché così è possibile cambiare il texture format che utilizzi senza dover toccare minimanente il codice, oppure sostituire il modo in cui la geometria o i lod sono creati senza dover rifare i modelli o mettere mano al codice di rendering.
Una cosa che mi hai fatto notare tu è proprio quella delle texture, un flag per lasciare al codice la gestione delle texture non sarebbe stato male.
Quella lucertola da dove arriva? Da max? Da Maya? chi ha fatto quell'fbx? Che materiale gli ha assegnato?
E' fatto così perché a chi scrive il codice non deve interessare da dove arriva la lucertola o di come sono stati gestiti i materiali sull'editor 3D.
Non potevano fare un exporter per il loro formato? Con dentro le mesh, le texture fuori ed i materiali fuori? Perchè usare formati vecchi e brutti per poi farli convertire da visual studio in qualcosa di ignoto?
E' quello che stavi criticando tu! E' il formato proprietario che però non lo devi integrare DENTRO i tool di grafica ma solo dentro la pipeline di build management del gioco. Così non hai bisogno di skill specialistiche.
Ad esempio nel mio caso i punti da cui i modelli sparano sono dei quad con una normale, messi nell'editor, con dei nomi appositi.
Piuttosto che farmi un plugin per Blender (non lo so fare) mi sono fatto un importer che mi tira fuori quei quad dalle geometrie (che arrivano pulite al processor) e mi genera un piccolo XML con le serializzazioni delle istanza dei BulletGenerator che mi servivano per quel modello comprensive di tutte le matrici di trasformazione necessarie.
L'XML è incompleto: perché tranne le informazioni geometriche, mancano i parametri sul tipo di sparo, che posso mettere io a mano, visto che il rognoso è parametrizzare le matrici di trasformazione rispetto al centro del modello e tutto il resto è tuning di game design.
L'XML gerato non c'è nemmeno bisogno che lo processo con un Processor, posso deserializzarlo passando direttamente dal ContentManager di XNA. Una volta sicuro, potrò rendere tutto serializzato in binario, così anche l'overhead del parsing non ci sarà, a costo zero, switchando un parametrino.
-
Ok, dove stanno questi magici manuali? :D
Ah:
E' fatto così perché a chi scrive il codice non deve interessare da dove arriva la lucertola o di come sono stati gestiti i materiali sull'editor 3D.
MAGARI no, ma almeno mi piacerebbe sapere che materiali sono.
-
Ma io qui non vedo un ambiente professionale. Vedo un ambiente per giocare. Che se voi farci qualcosa di serio puoi usare sì e no l'1% delle sue funzionalità e riscriverti tutto il resto.
Tieniti forte, XNA non sarà mai un middleware. E' una libreria di base, è ovvio che per fare cose avanzate devi scriverti i componenti, il favore che ti fà è renderli più vicini al tuo ambiente di sviluppo e più lontani dai tool accessori, così ti puoi creare delle librerie di componenti a lungo termine. In realtà Microsoft pare contare molto sul successo riscosso per farle diventare le API ufficiali per programmare nelle varie implementazioni di DX future e spingere di più su .NET nel ludico...
Per il resto mi è comprensibile il disagio. Cmq prenditi un po' di tempo per leggerti almeno la parte che introduce bene l'architettura e le pipeline di Update e Rendering, ci sono passato pure io e devo dire che nonostante molte tecniche sono piuttosto comuni negli scenegraph basati su compilazione JIT c'era troppa nuova carne al fuoco per farci un'hands-on da subito.
-
Ma io qui non vedo un ambiente professionale. Vedo un ambiente per giocare. Che se voi farci qualcosa di serio puoi usare sì e no l'1% delle sue funzionalità e riscriverti tutto il resto.
Tieniti forte, XNA non sarà mai un middleware.
Peccato che sia presentato come un supremo framework nel quale devi fare poco o niente e spunta il gioco :D A me sembra una versione di directx più semplice ma in fondo meno usabile.
Se voglio fare qualcosa con DirectX, lo faccio con directX, non con questa cosa qui.
Ah: dove sono sti magici manuali? :D
-
Ok, dove stanno questi magici manuali? :D
Dentro l'help del Visual Studio, c'è un libro nuovo che si chiama, neanche troppo metafisicamente, XNA Game Studio 3.0. Neanche a farlo apposta, la programming guide, dopo un'introduzione genrica inizia proprio con.... LA CONTENT PIPELINE!!!!!! ;D
Che comunque ha mandato TUTTI al manicomio.
Ritienito fortunato (per ora) a non dovere fare interfacce con WPF e XAML, se vedi come integrare Expression Design, Espression Blend e Visual Studio in tre flussi di lavoro paralleli, scorrelati ma al tempo stesso correlati a te va in meltdown il cervello!
Non c'è verso di capirlo tutto e subito!
-
Ok, dove stanno questi magici manuali? :D
Dentro l'help del Visual Studio, c'è un libro nuovo che si chiama, neanche troppo metafisicamente, XNA Game Studio 3.0. Neanche a farlo apposta, la programming guide, dopo un'introduzione genrica inizia proprio con.... LA CONTENT PIPELINE!!!!!! ;D
Ok, almeno questo non è senza senso :D
Me lo leggo un po' vedo se riesco a dissipare questa sensazione di "merda come Renderware" :D
-
Io lavoreri di più all'attitudine al cambiamento.
Ma renderware fa davvero così schifo? Mi posso documentare in merito? Come può il motore dietro il racing game più bello (e pare pure con dei porting pc della madonna) del cosmo essere così brutto?
Mi riferisco a Burnout Paradise, eh!
-
Io lavoreri di più all'attitudine al cambiamento.
Ma renderware fa davvero così schifo? Mi posso documentare in merito? Come può il motore dietro il racing game più bello (e pare pure con dei porting pc della madonna) del cosmo essere così brutto?
Mi riferisco a Burnout Paradise, eh!
In renderware che usa criterion non ha NIENTE a che vedere con quello che vende. Ecco come fa :D
Non ho problemi al cambiamento: non hai idea di quanti linguaggi ho usato e uso.
Ultimamente lavoro tanto con Python , ma in passato ho guadagnato soldi lavorando in VB6, in Java, in Avenue (Arcview) e, ultimo ma non meno importante, javascript :D
E' che qui mi sembra che si vuole essere allegri ed amichevoli, ma in realtà si è ben più complessi dei linguaggi a cui non si vuole somigliare perchè sono troppo complessi :D
-
LOL
-
Cmq continua a farmi sapere, non sia mai che alla fine mi convinco sia una merda pure io :)
Già sono depresso per via di una ristrutturazione forzata che mi terrà lontano da casa diversi mesi (tipo 4-5), ritardando gli sviluppi dello shmup, mettici pure che mi rendo conto che il tool è una merda... Non mi resta che il suicidio. Se non altro muoio contento sapendo che anche tu utlizzi una R4.
-
Ah, prima che diventi di nuovo viola, Microsoft continua la tradizione degli esempi del menga: gran parte di essi hanno rendering e logica nella stessa classe, presumo per rendere più sintetica l'esposizione.
Nulla vieta di separare i due layer, anzi, IMHO è consigliabile avere dei GameComponent che fanno l'update e dei GameComponent che fanno solo rendering, specie se si vogliono usare i 4 thread hardware a disposizione efficientemente.
-
Ah, prima che diventi di nuovo viola, Microsoft continua la tradizione degli esempi del menga: gran parte di essi hanno rendering e logica nella stessa classe, presumo per rendere più sintetica l'esposizione.
Che vergogna :D
Pero' vabbe' anche gli esempi DX sono cosi'.
In realta' non mi sto minimamente preoccupando dell'X360 :D Se faccio qualcosa con quella, non concepisco altro che l'SDK.
-
Ma io qui non vedo un ambiente professionale. Vedo un ambiente per giocare. Che se voi farci qualcosa di serio puoi usare sì e no l'1% delle sue funzionalità e riscriverti tutto il resto.
Tieniti forte, XNA non sarà mai un middleware.
Peccato che sia presentato come un supremo framework nel quale devi fare poco o niente e spunta il gioco :D A me sembra una versione di directx più semplice ma in fondo meno usabile.
Se voglio fare qualcosa con DirectX, lo faccio con directX, non con questa cosa qui.
Ah: dove sono sti magici manuali? :D
Ale, il concetto "piu' semplice ma in fondo meno usabile" viene definito "astrazione" e sappiamo tutti e due come va.
Se hai 100 istruzioni da eseguire puoi fare 100 funzioni da una istruzione, 10 funzioni da 10 istruzioni, o una sola funzione che ne raggruppi 100. La prima soluzione e' la meno astratta, l'ultima la piu' astratta.
Il problema con l'astrazione e' che piu' astrai, e piu' codice compatti in una sezione monolitica.
Il punto e' che essendo monolitica, se devi compiere solo meta' delle operazioni, beh, non puoi.
O tutto o niente - c'e' una sola funzione, per cui o chiami quella o non ne chiami nessuna.
Il pregio dell'astrazione e' che semplifica e abbrevia il lavoro del programmatore per le cose piu' comuni.
Il prezzo da pagare e' un controllo minore sul codice - e' vero che lo scrive sempre il programmatore, ma costringe a lavorare con "blocchi monolitici prefabbricati" meno controllabili. Cioe': se esci dal seminato sei fottuto =D
Detto questo, XNA e' un framework che possiede un livello di astrazione molto alto. Per questo e' mirato a hobbysti.
E non e' nemmeno sbagliato presentarlo come "un supremo framework nel quale devi fare poco o niente e spunta il gioco", perche' e' vero.
E' che non spunta "il tuo gioco". Spunta "il suo", fatto con delle sue regole e un suo modo di fare, pensare e organizzare dati e lavoro e tutto, che derivano da blocchi prefabbricati meno customizzabili.
Detto questo, se non ti sta bene (e vedo che non ti sta bene) il livello di astrazione che offre XNA, allora ci sono DirectX e l'XDK, che guardacaso sono mirati "a chi vuole fare qualcosa di serio", e guardacaso sempre da MS.
-
si' ma siccome tutti ne parlavano bene ero curioso :D