GameMaker Italia Forum

Sla, penso ad un futuro gioco sviluppato con la tua dll e distribuito a un analfabeta informatico...
In VC++ non è possibile forzare l'inclusione delle DLL indispensabili per il runtime nella tua dll prodotta,
in modo da rendere semplice al massimo la distribuzione (e rinunciare ovviamente ad uno dei massimi
vantaggi delle dll, cioè evitare di avere codice compilato doppio sul proprio pc...)?

Bè baron, a parte che non mi pare si possa fare esiste apposta il meccanismo delle gex per evitare di avere troppi file sottomano (due dll al posto di una, che fatica ) che tra l'altro cè scritto esplicitamente nel manuale di game maker che le funzioni per le dll ci sono solo per questioni di retrocompatibilità. Personalmente non lo trovo un grosso problema. Mi domando come mai con ogre nessuno si è lamentato del grande numero di dll presenti

BaronVsCorsar ha scritto:e rinunciare ovviamente ad uno dei massimi
vantaggi delle dll, cioè evitare di avere codice compilato doppio sul proprio pc

Non ho capito cosa intendi

Tanto per la cronaca, i giochi commerciali hanno decine di DLL, però è veramente poco professionale distribuire la mia SlaD3D.dll insieme ad altre..
Vedrò cosa posso fare con VC.
Il problema è che non posso exportare se non da VC++, quando uso il DirectX SDK

Potresti fare come fanno le GEX, cioè che l'altra DLL viene salvata nella tua DLL ed estratta quando serve

Potrei, ma non voglio che ci siano file secondari visibili..

La estrai su %temp% o su %appdata% o con tmpfile()...

problema risolto, sono riuscito a compilare con code blocks.

Nix ha scritto:Potresti fare come fanno le GEX, cioè che l'altra DLL viene salvata nella tua DLL ed estratta quando serve

ma no, così è davvero barbaro...

io intendevo compilare la dll runtime del VC++ limitatamente a quanto necessario alla SlascioSuperd3dMegaPackDLL.dll.
Senza avere ridondanza al 100%, ma includendo il minimo indispensabile.

Per intenderci (@ sla): linkare il numero minimo indispensabile di ".o" necessari nella tua dll... ammesso che le runtime dll di VC++ siano compilabili o siano fornite a livello di sorgente (o almeno oggetti) e non già precompilate in dll
Vabbè, giusto per curiosità: con codeblock a che livello hai realizzato la fusione? C'è l'intera dll o un sottoinsieme?

@jak: il problema non era avere più dll, era essere sicuri di fornire all'utente informaticamente analfabeta tutte le dll che erano necessarie, a prescindere da cosa aveva installato sul suo pc. Non semplicemente supponendo che quelle eventualmente mancanti se le andasse a cercare lui...

@jak2: le dll hanno davvero senso solo quando sono "installate" nel sistema operativo, e non distribuite insieme all'eseguibile.
In questo modo se più di un programma necessità della stessa dll non avrò due copie di quel file sul pc, ma solo una. Entrambi i programmi accedono fisicamente alla stessa dll (inteso come file) et voilà. Pensa solo se per ogni gioco ti dovessi copiare un DirectX dedicato per lui!
Ovviamente distribuire le dll con un eseguibile fa totalmente perdere questo enorme vantaggio.
Tecnicamente, se la dll è distribuita insieme all'eseguibile, sarebbe più vantaggioso compilare l'eseguibile integrando al suo interno il contenuto della dll.
Con GM questo non è possibile, e si fa di necessità virtù.
(notare che ai tempi dei SO semplici le dll non esistevano perchè non c'era motivo: una cosa concettualmente simile la si faceva all'atto del linking con i file-oggetto).
Non a caso il runtime del VC++ esiste anche in versione installabile, e se ti installi solo quello non hai più questi problemi.
Questo è il metodo "informaticamente" intelligente di mettersi quelle DLL sul proprio pc, purtroppo è anche quello più complicato e che richiede maggiori conoscenze... quindi via di distribuzione di file dll (oppure di compilazione "integrata").
E' più chiaro?

Ora sei stato chiarissimo.

BaronVsCorsar ha scritto:Non a caso il runtime del VC++ esiste anche in versione installabile, e se ti installi solo quello non hai più questi problemi.

Questa roba purtroppo non l'ho mai capita. Con i redistributable del runtime vc++ ti aggiungono tutto al sistema tranne quella dll mentre installando vc++ si. Questo non sarebbe un problema se quella dll non fosse assolutamente necessaria per far funzionare una qualsivoglia cosa fatta con vc++(e non cè il sorgente purtroppo)
Proprio non capisco come mai

Non sono mai riuscito a trovare il runtime come sorgente..
Per quanto riguarda codeblocks, sono riuscito a metterci tutta la dll. Da alcuni errori stupidi e facilmente sistemabili. Continuerò a sviluppare la DLL in VC++ per comodità (intellisense),e, solo al momento della compilazione, la trasferirò su C::B.

Super_Slascio ha scritto:Continuerò a sviluppare la DLL in VC++ per comodità (intellisense)

Anche C::B ha l'intellisense (con Ctrl+Space) (configurabile da Settings/Editor/Code-completion and symbols blablabla), e poi è open source e GCC (se stai usando quello) compila per più piattaforme

modelli OBJ...

Super_Slascio ha scritto:modelli OBJ...

i modelli da sketchup vengono importati e texturizzati perfettamente ?

Quello non è texturato, è solo colorato..
comunque sì.
Devi avere sketchup pro per poter exportare in obj.

Super_Slascio ha scritto:Quello non è texturato, è solo colorato..
comunque sì.
Devi avere sketchup pro per poter exportare in obj.

Alcuni importer obj che ho testato richiedevano texture uvmappata, questo sarà come il tuo vecchio importer 3ds ? cioe ogni texture è un materiale è il file obj ha le informazioni relative alle texture??

PS: potrei aver detto una serie di minchiate

Non c'entra niente con l'importer 3ds. Quello lo avevo dovuto adattare al sistema d3d di game maker.
Non esiste la richiesta di texture uv-mappate!
Puoi uv-mappare (cioè cambiare i valori u,v ai vertici del modello) un obj per facilitare il lavoro di creazione della texture, ma lo fa già Sketchup nel momento in cui exporta con i materiali che definisci te (anche per questo è comodo sketchup: puoi texturare cliccando sui poligoni stessi!).

Per game maker c'è un importer di obj (veramente schifoso), che è mosaic light.
Questo non carica il file .mtl (material lib) che generalmente sta insieme al suo .obj. Inoltre, visto che gm può dare 1 sola texture ad ogni modello (non supporta materiali), c'è bisogno di creare una unica texture per tutto l'obj. Da qui nasce la necessità di uv mappare nuovamente l'obj (con programmi come UV mapper), per creare una texture unica.

Sketchup exporta bene l'obj con il suo mtl, ci mette le sue UV e le sue texture.
Il mio importer lo legge esattamente come va letto, perciò è in grado, come hai visto, di renderizzarlo perfettamente.

Scritto un po velocemente, spero di essere stato chiaro.

chiarissimo GRAZIE

Che figata

http://www.megaupload.com/?d=CH8GKIWK
Guardate un po come vi gira. Estraete tutta la cartella e avviate l'exe

Xeryan ha scritto:comunque noto rallentamenti nella rotazione

Idem con patate. E sempre con lo stesso tempismo giusto?