MADS Engine, Dragonsphere, Rex Nebular, Return of the Phantom Opzioni

[Alpobemp]

Carissimi,
come alcuni di voi già sanno, è da qualche anno che mi incaponisco sulla traduzione di Dragonsphere, che per me è un grande capolavoro misconosciuto e sottovalutato, così come anche Rex Nebular, e un po' meno, Return of the Phantom.
Sia il primo che il secondo si ispirano a due grandi cicli della Sierra, King's Quest e Space Quest, e si collocano grossomodo come coevi di KQ V e SQ IV.
Insomma, per farla breve, qualcosa avevo ottenuto, ma di qualità tecnica assolutamente insufficiente, e che non reputo dignitoso pubblicare.
Sebbene il codice che ho sviluppato, per quanto primitivo e rozzo, possa allo stato attuale dell'arte tradurre dialoghi, descrizioni ed estrarre alcune risorse grafiche, non ricomprime i testi (o per meglio dire lo fa con compressione zero), ed è necessario entrare più nel merito del motore originario (MADS engine) per gestire meglio le risorse ed evitare qualunque possibilità che il testo tradotto possa causare un qualche overflow di memoria ed andare a sovrapporsi a regioni di codice. Allo stato attuale non vengono gestiti i caratteri speciali come le accentate e non si può fare molto per adattare all'italiano la "grammatica" che è basata sull'inglese, ma che in teoria è modificabile.
Di recente alcune persone interessate a tradurre Rex Nebular nelle loro lingue, un francese ed uno spagnolo, mi hanno contattato, anche su queste pagine, ma non potuto dare loro le risposte che si aspettavano.
Insomma, per andare al dunque, mi sono finalmente deciso di mettere da parte il mio solito vizio di lavorare da solo, e di lanciare un progetto che abbia come finalità la creazione di un ambiente integrato per modificare e tradurre un gioco basato sul motore MADS in un'altra lingua. Le premesse sono buone, credo, e ho diverso materiale e conoscenze che posso mettere a disposizione.
Prima di dare diffusione della cosa su altre pagine, preferisco parlarne qui che è il luogo che per me è di riferimento nella scena delle traduzioni amatoriali di ag (senza intenzione di aprire polemiche con chicchessia) e a cui devo molto (avere persone come DK, solo per citare chi conosco di più, è una vera ricchezza).
Servono programmatori esperti in C e assembler intel (soprattutto a 16 bit), sebbene il codice che ho finora sviluppato sia in Delphi (pessimo Delphi, per essere più esatti), e persone che abbiano conoscenze di algoritmi di compressione tipo il LZ77. Se si trovasse qualcuno che possedesse entrambe le competenze, sarebbe il massimo.

[Expert C and intel (mostly 16bit) assembly programmers are needed, although the code I have written until now is Delphi (actually a bad Delphi) and also people having knowledge of compression algorithms like LZ77 are needed. If anybody were skilled in both requirements, it would be great.]

Ciao,
Alberto

[TheRuler]

Ho visto che tempo addietro (il tuo post e' del 2007) hai lanciato il sasso sul forum ScummVM. E' qualche anno che e' in progress, anche se allo stato embrionale, ma Rex nebular viene riconosciuto ed avviato dalla svn di scummVM. Magari ho detto una vaccata che sapevi gia', magari puo' essere utile.
Dreammaster, un utente scummvm, sta portando avanti un progetto che potrebbe interessarti.

[Tsam]

Caro Alpo, al di là dell'ovvio supporto per una persona che porta avanti progetti del genere, considerami eventualmente disponibile per quello che può essere il lavoro da manovalanza spicciola (se dovesse essercene) essendo molto indietro a livello di programmazione.

Ciao
tsam

[The Ancient One]

Come sai non posso aiutarti, però quando ci incontriamo posso stimolare le tue capacità informatiche con copiose quantità di vino rosso!

DK lo hai sicuramente già sentito.
Se vuoi un consiglio, prova a contattare anche Gufino. Con Phantasmagoria 2 ha dimostrato di saperci fare, eccome.

[Alpobemp]

Come sai non posso aiutarti, però quando ci incontriamo posso stimolare le tue capacità informatiche con copiose quantità di vino rosso!

Prepara il bicarbonato.
Per intanto, permettimi di segnalare la call-up per i riservisti:
http://www.icgag.it/alpobemp/?p=151

DK lo hai sicuramente già sentito.
Se vuoi un consiglio, prova a contattare anche Gufino. Con Phantasmagoria 2 ha dimostrato di saperci fare, eccome.

No, non ho sentito nessuno a parte chi sapevo per certo che avesse competenze specifiche di assembler x86 16bit (come sai, parlare di assembler genericamente non ha senso, essendo l'assembler un linguaggio con istruzioni direttamente legate alla struttura fisica del processore specifico di ciascuna macchina (pur essendo il kernel delle istruzioni principali comune, ciononostante registri, funzioni di librerie e interrupt possono differire astronomicamente tra un assembler per pentium ed uno per amiga, ad esempio).

Per rispondere a The Ruler, purtroppo Dreammaster non lascia a disposizione alcun riferimento di una email, ed io non uso da anni irc (ho usato mirc per qualche anno, ed ha effetti devastanti sull'ottimizzazione del tempo). Ciononostante, mi piacerebbe poterlo contattare, se hai modo digli senz'altro di scrivermi.

Ciao,
Alberto


Messaggio modificato da Alpobemp il 19 Nov 2010, 16:40

[The Ancient One]

Ragfox ha messo la news in prima pagina.
Speriamo bene!


PS
A lunedì!

[TheRuler]

Mi sono loggato sulla webchat (http://webchat.freenode.net/# canale scummvm), senza usare mirc, e ho trovato molta bella gente (lordhoto e drMcCoy) che mi ha suggerito di provare verso le 7:00 - 8:00 UTC (dreammaster è australiano), oppure di mandargli un pm direttamente sul forum di scummvm.


edit: ho verificato sul suo profilo, e una mail c'è: paul_whyzero at hotmail.com

mi dispiace non poter fare di più.

[redice]

molto velocemente:
conosco bene l'assembly x86 proc intel e il C, ma non ho tempo per imbarcarmi in un progetto di grosse dimensioni. Ho letto che hai scritto questo:

In realtà ci sarebbe la soluzione, che ho in parte recuperato contattando fonti alternative, ma serve una persona esperta di assembler x86 a 16bit. Si tratta di tradurre codice sviluppato con strumenti, assemblatori e compilatori commerciali dei primi anni ’90 orami desueti. Forse converrrebbe tradurre tutto in codice a 32bit. Se poi l’eventuale esperto Assembly unisse la propria esperienza con un programmatore Microsoft C 16bit, sarebbe il massimo

Quindi se non c'è niente da mettersi a disassemblare e debuggare ma si tratta solo di convertire da asmx86 a C 32 bit forse posso provare ad aiutarti (dipende dalla vastità del progetto)

edit: ovviamente un altro fattore importante è chi ci sta già lavorando: se ad esempio si è appurato che il team dello scummvm ha preso sotto mano questo progetto non consiglierei a nessuno di perderci tempo, ci penseranno loro

Messaggio modificato da redice il 20 Nov 2010, 00:43

[The Ancient One]

Redice, continui a stupirmi!

[The Ancient One]

Redice, continui a stupirmi!

[Alpobemp]

molto velocemente:
conosco bene l'assembly x86 proc intel e il C, ma non ho tempo per imbarcarmi in un progetto di grosse dimensioni. Ho letto che hai scritto questo:

In realtà ci sarebbe la soluzione, che ho in parte recuperato contattando fonti alternative, ma serve una persona esperta di assembler x86 a 16bit. Si tratta di tradurre codice sviluppato con strumenti, assemblatori e compilatori commerciali dei primi anni ’90 orami desueti. Forse converrrebbe tradurre tutto in codice a 32bit. Se poi l’eventuale esperto Assembly unisse la propria esperienza con un programmatore Microsoft C 16bit, sarebbe il massimo

Quindi se non c'è niente da mettersi a disassemblare e debuggare ma si tratta solo di convertire da asmx86 a C 32 bit forse posso provare ad aiutarti (dipende dalla vastità del progetto)

Ti contatto domani.

edit: ovviamente un altro fattore importante è chi ci sta già lavorando: se ad esempio si è appurato che il team dello scummvm ha preso sotto mano questo progetto non consiglierei a nessuno di perderci tempo, ci penseranno loro

Lo Scummvm, intendiamoci, sono brave e meritorie persone, ma dubito che glieni freghi qualche cosa di sviluppare un tool per editare testi, piuttosto che interpretare risorse a 16bit e farle eseguire sotto win32bit. Può sembrare cavilloso, ma sono due cose assai differenti. E' come chiedere ad un carburatorista di riverniciare un'automobile.

Ciao,
Alberto

Messaggio modificato da Alpobemp il 23 Nov 2010, 23:47

[Alpobemp]

molto velocemente:

Quindi se non c'è niente da mettersi a disassemblare e debuggare ma si tratta solo di convertire da asmx86 a C 32 bit forse posso provare ad aiutarti (dipende dalla vastità del progetto)

Ti contatto domani.

Diciamo stanotte, va'...

Ciao,
Alberto

[redice]

Resto in attesa, usa pure i pm del forum

[Alpobemp]

Ho sviluppato un piccolo programma che estrae dai file di risorse delle avventure grafiche della Microprose di cui parlavo qualche giorno fa, tutti i file “significativi”; quello per cui dovrebbe interessare i pochi interessati, è che può decomprimere i file contenenti i testi e alcune parti grafiche. E’ tutt’altro che perfetto, e credo che sia un po’ “buggoso”, per esempio estrae anche quando non dovrebbe il file “credits.txr”, e dovrebbe essere un po’ rivisto, ma funziona. Se qualcuno in giro vuole iniziare a tradurre una delle avventure Microprose in attesa che si riesca a sviluppare un tool che inserisca i testi tradotti nei file delle risorse, beh, diciamo che non lo biasimo.

Potete scaricare da qui extracthag.exe, l’eseguibile del programma. Funziona in modo abbastanza intuitivo. Innanzitutto è un programma “console”, nel senso che deve essere lanciato da prompt dei comandi. Si applica ad un file *.HAG, anche se io l’ho testato solo con il tipico GLOBAL.HAG, che è quello che di solito contiene tutti le descrizioni.

Spero che così facendo salti più facilmente fuori qualche collaboratore per lavorare sull’algoritmo di compressione.

Buon divertimento.

I have developed a little program to extract all the “significant” files from Microprose adventure games resource files I was speaking about some days ago; the reason for it should be interesting for the few interested into, is that it can decompress files containing text and some graphics. It is far from being perfect, and I think it is a bit “buggy”, for instance it extracts “credits.txr” file even when it shouldn’t, and it should to be revisited, but it works, all in all. If anybody out there wants to begin to translate a Microprose adventure game waiting for a tool that can insert translated texts back into resource files, well, he’s welcome.

You can download the program executable from here: extracthag.exe. It works in a pretty intuitive way. First of all it is a console application, this means that it must to be launched from the command prompt. It should be launched on a *.HAG file, even if I tested it just with the usual GLOBAL.HAG, the file containing all the descriptions and captions.

I hope this could help finding someone that can work on the compression algorithm.

Enjoy.

[TheRuler]

Alpo,

[Ragfox]

:bow:

[The Ancient One]

Rinnovo i miei complimenti!

[peres]

Ho sviluppato un piccolo programma che estrae dai file di risorse delle avventure grafiche della Microprose di cui parlavo qualche giorno fa, tutti i file “significativi”; quello per cui dovrebbe interessare i pochi interessati, è che può decomprimere i file contenenti i testi e alcune parti grafiche. E’ tutt’altro che perfetto, e credo che sia un po’ “buggoso”, per esempio estrae anche quando non dovrebbe il file “credits.txr”, e dovrebbe essere un po’ rivisto, ma funziona. Se qualcuno in giro vuole iniziare a tradurre una delle avventure Microprose in attesa che si riesca a sviluppare un tool che inserisca i testi tradotti nei file delle risorse, beh, diciamo che non lo biasimo.

Potete scaricare da qui extracthag.exe, l’eseguibile del programma. Funziona in modo abbastanza intuitivo. Innanzitutto è un programma “console”, nel senso che deve essere lanciato da prompt dei comandi. Si applica ad un file *.HAG, anche se io l’ho testato solo con il tipico GLOBAL.HAG, che è quello che di solito contiene tutti le descrizioni.

Spero che così facendo salti più facilmente fuori qualche collaboratore per lavorare sull’algoritmo di compressione.

Buon divertimento.

Se davvero cerchi qualcuno che ti aiuti dovresti mettere un link al sorgente della tua utility.

peres

[Alpobemp]

Ho sviluppato un piccolo programma che estrae dai file di risorse delle avventure grafiche della Microprose di cui parlavo qualche giorno fa, tutti i file “significativi”; quello per cui dovrebbe interessare i pochi interessati, è che può decomprimere i file contenenti i testi e alcune parti grafiche. E’ tutt’altro che perfetto, e credo che sia un po’ “buggoso”, per esempio estrae anche quando non dovrebbe il file “credits.txr”, e dovrebbe essere un po’ rivisto, ma funziona. Se qualcuno in giro vuole iniziare a tradurre una delle avventure Microprose in attesa che si riesca a sviluppare un tool che inserisca i testi tradotti nei file delle risorse, beh, diciamo che non lo biasimo.

Potete scaricare da qui extracthag.exe, l’eseguibile del programma. Funziona in modo abbastanza intuitivo. Innanzitutto è un programma “console”, nel senso che deve essere lanciato da prompt dei comandi. Si applica ad un file *.HAG, anche se io l’ho testato solo con il tipico GLOBAL.HAG, che è quello che di solito contiene tutti le descrizioni.

Spero che così facendo salti più facilmente fuori qualche collaboratore per lavorare sull’algoritmo di compressione.

Buon divertimento.

Se davvero cerchi qualcuno che ti aiuti dovresti mettere un link al sorgente della tua utility.

peres

A chi finora mi ha contattato rendendosi disponibile a contribuire al progetto, non ho lesinato informazioni e anche sorgenti.

Vuoi poi che te la dica tutta?
Mi vergogno un po' dei miei sorgenti che, pur funzionando e producendo in output quello che devono fare, sono vermanete scritti coi piedi, di getto, per arrivare velocemente all'obiettivo, e che poi finisco per non documentare (finendo per dovere passare i pomeriggi a rileggerli per capirci qualche cosa io stesso, quando li riprendo in mano); sto comunque pubblicando alla spicciolata un po' di documentazione della struttura delle risorse del gioco sul blog i cui riferimenti trovi in calce.

Paradossalmente il problema, infatti, non è capire come sono fatte, anzi, sono abbastanza ormai definite, piuttosto serve riscrivere in 32bit (e farla funzionare) la routine assembler che gestisce la compressione dei dati. Tutte le risorse, grafiche, audio, e, quel che più importa ai nostri fini, testuali, sono compresse. La routine di decompressione, invece, è già nota, mentre la sua inversa è oggetto di copyright (è ricavata da un algoritmo di Fabrice Bellard, creatore di LZEXE, un programma di compressione di eseguibili (praticamente il file compresso era un eseguibile che, lanciato, si decomprimeva in runtime ed eseguiva il programma decompresso senza lasciare traccia sul disco fisso; un problema frequente, quello dello spazio, quando gli hard disk misuravano al più 40MB)).
Interpellato, Fabrice Bellard ha gentilmente declinato la richiesta di mettere a disposizione la routine, proprio perché in copyright alla PKWARE.
Ad ogni modo, sono riuscito lo stesso ad entrare in possesso della routine di compressione del motore MADS, che però, per i motivi già detti, non ho intenzione di divulgare ai quattro venti, per rispettare la volontà di chi detiene i diritti (non farei carriera in wikileaks, lo so).

Tu conosci assembler intel 16bit o delphi?

Ciao,
Alberto

[Alpobemp]

-

capisco...

Ciao,
Alberto

[peres]

Capita qualche volta di non saper come cancellare un post sbagliato e di rimediare alla bell'e meglio. (se un moderatore puo' togliere il mio post precedente grazie)

Tu conosci assembler intel 16bit o delphi?

Una certa pratica col primo ce l'ho.

----------------------------------

Vorrei chiederti cosa intendi con la seguente:

è necessario entrare più nel merito del motore originario (MADS engine) per gestire meglio le risorse ed evitare qualunque possibilità che il testo tradotto possa causare un qualche overflow di memoria ed andare a sovrapporsi a regioni di codice.

Non capisco perche' temi che il testo vada a sovrascrivere codice eseguibile visto i file HAG che modifichi sono risorse esterne. Se il problema di "entrare nel merito del motore" sono le eventuali maggiori dimensioni del testo tradotto, allora prova a dare un'occhiata al codice di gestione dei file HAG in ScummVM: dovrebbe essere un buon punto di partenza.

----------------------------------

Riguardo la routine di compressione del testo ho sentito dreammaster, che ha scritto la classe FabDecompressor in ScummVM (come pure il codice HAG di cui sopra). Non che sperassi avesse scritto un compressore senza motivo, comunque sempre meglio chiedere prima.

In un post precedente dici di aver gia' del codice a compressione zero - che dal codice di FabDecompressor dovrebbe in realta' espandere i file del 12%-13%. Mi chiedevo se, visto che in fondo stai solo a (non) ricomprimere del testo, la differenza sia cosi' grande in termini assoluti da giustificare lo sforzo di riscrivere la routine di compressione.

peres

[Alpobemp]

Capita qualche volta di non saper come cancellare un post sbagliato e di rimediare alla bell'e meglio. (se un moderatore puo' togliere il mio post precedente grazie)

Tu conosci assembler intel 16bit o delphi?

Una certa pratica col primo ce l'ho.

----------------------------------

Vorrei chiederti cosa intendi con la seguente:

è necessario entrare più nel merito del motore originario (MADS engine) per gestire meglio le risorse ed evitare qualunque possibilità che il testo tradotto possa causare un qualche overflow di memoria ed andare a sovrapporsi a regioni di codice.

Non capisco perche' temi che il testo vada a sovrascrivere codice eseguibile visto i file HAG che modifichi sono risorse esterne. Se il problema di "entrare nel merito del motore" sono le eventuali maggiori dimensioni del testo tradotto, allora prova a dare un'occhiata al codice di gestione dei file HAG in ScummVM: dovrebbe essere un buon punto di partenza.

Sono risorse esterne, sì, ma vengono scompattate e caricate a runtime.
In effetti le mie perplessità sono proprio legate a non sapere "di quanto mi posso "allargare" con la dimensione del testo tradotto"? E sapere come è strutturato un file HAG non mi serve, proprio per il ragionamento che tu giustamente porti, a niente (è un problema di sapere in quali buffer o variabili (e di quali dimensioni) il programma "parcheggia" il testo. (Per entrare nel tecnico: carica il testo di una stanza tutto insieme in un buffer di memoria per poterlo accedere più velocemente? e quanto è grande questo buffer? e domande del genere.)
E questo, ne convengo con te, è un tipo di problema che esula completamente dal tentativo di tradurre la routine di compressione in codice 32bit .

----------------------------------

Riguardo la routine di compressione del testo ho sentito dreammaster, che ha scritto la classe FabDecompressor in ScummVM (come pure il codice HAG di cui sopra). Non che sperassi avesse scritto un compressore senza motivo, comunque sempre meglio chiedere prima.

grazie dell'interessamento.

In un post precedente dici di aver gia' del codice a compressione zero - che dal codice di FabDecompressor dovrebbe in realta' espandere i file del 12%-13%. Mi chiedevo se, visto che in fondo stai solo a (non) ricomprimere del testo, la differenza sia cosi' grande in termini assoluti da giustificare lo sforzo di riscrivere la routine di compressione.

peres

Non sono per niente convinto che funzioni con altre risorse, come quelle grafiche.
In fondo il "mio" algoritmo a compressione zero consiste semplicemente nello scrivere il file "compresso" in pacchetti di 16 byte in chiaro, anteponendo ovviamente la word xFFFF che il decompressore interpreta esattamente in questo modo, ricopiando in output i 16 byte seguenti. La coda finale del file, che ovviamente va da 0 a 15 byte, la gestisco un po' a cavolo ed empiricamente, aggiungendo "case of" il numero di byte rimasti, delle code di caratteri predeterminate facendo delle prove con delle frasi di lunghezza da 1 a 15. Come puoi capire è una "pezza".

Ciao,
Alberto

[peres]

In effetti le mie perplessità sono proprio legate a non sapere "di quanto mi posso "allargare" con la dimensione del testo tradotto"?

In ScummVM i buffer sono allocati in funzione della dimensione delle risorse, quindi l'unico limite e' la memoria disponibile nel sistema. Lo puoi verificare nel codice (verso la riga 60 di /engines/m4/compression.cpp).

----------------

E sapere come è strutturato un file HAG non mi serve, proprio per il ragionamento che tu giustamente porti, a niente (è un problema di sapere in quali buffer o variabili (e di quali dimensioni) il programma "parcheggia" il testo.

Se hai capito in questo modo allora non mi sono spiegato a dovere. Come dicevo sopra non sono i buffer in memoria quelli di cui ti devi preoccupare: piuttosto devi ricostruire correttamente l'indice del file HAG, perche' e' da questo che si calcolano le dimensioni dei buffer. Dal codice per la lettura dei file HAG di ScummVM (stesso sorgente di prima) si capisce che la cosa non e' particolarmente difficile.

Sempre analizzando lo stesso file di cui sopra, si capisce che le risorse non devono essere per forza compresse: basta scrivere nell'indice che il file ha le stesse dimensioni prima e dopo la compressione. Questo dovrebbe essere ancora piu' semplice della compressione zero.

----------------

Non sono per niente convinto che funzioni con altre risorse, come quelle grafiche.

E perche' il decompressore dovrebbe rifiutare uno stream LZSS valido? Nel codice non ho visto nessuna routine che giudichi la qualita' della compressione.


peres

[Alpobemp]

In effetti le mie perplessità sono proprio legate a non sapere "di quanto mi posso "allargare" con la dimensione del testo tradotto"?

In ScummVM i buffer sono allocati in funzione della dimensione delle risorse, quindi l'unico limite e' la memoria disponibile nel sistema. Lo puoi verificare nel codice (verso la riga 60 di /engines/m4/compression.cpp).

----------------

E sapere come è strutturato un file HAG non mi serve, proprio per il ragionamento che tu giustamente porti, a niente (è un problema di sapere in quali buffer o variabili (e di quali dimensioni) il programma "parcheggia" il testo.

Se hai capito in questo modo allora non mi sono spiegato a dovere. Come dicevo sopra non sono i buffer in memoria quelli di cui ti devi preoccupare: piuttosto devi ricostruire correttamente l'indice del file HAG, perche' e' da questo che si calcolano le dimensioni dei buffer. Dal codice per la lettura dei file HAG di ScummVM (stesso sorgente di prima) si capisce che la cosa non e' particolarmente difficile.

Sempre analizzando lo stesso file di cui sopra, si capisce che le risorse non devono essere per forza compresse: basta scrivere nell'indice che il file ha le stesse dimensioni prima e dopo la compressione. Questo dovrebbe essere ancora piu' semplice della compressione zero.

----------------

Non sono per niente convinto che funzioni con altre risorse, come quelle grafiche.

E perche' il decompressore dovrebbe rifiutare uno stream LZSS valido? Nel codice non ho visto nessuna routine che giudichi la qualita' della compressione.


peres

I tuoi argomenti in linea di principio sono validi, ma permettimi di essere comunque scettico sulla resa finale.
In prima battuta, né il motore MADS (quello di Dragonsphere, Rex Nebular, Return of the phantom) sono attualmente elencati nella lista di compatibilità, né la sua successiva evoluzione (una volta dismesso il gruppo interno di sviluppo Microprose) di Orion Burger e Riddle of Master Lu viene citata: segno che qualche magagna ci deve essere, ritengo.
In secondo luogo, il testo decompresso delle frasi rivela che c'è un qualche dimensionamento fisso delle finestre dove viene emesso il testo a video, quindi l'allocazione delle risorse non è sempre dinamica (e questo aspetto come anche altri, come l'episodio, che per fortuna è stato unico, di una frase tradotta che non veniva fatta apparire a video; una volta "accorciata", il fenomeno è scomparso) e questo basta a non farmi sentire sicuro a rilasciare il tool (più uno scaffolding che un tool come si deve) al libero uso.
Secondo te, se reprimessi il pudore e ne pubblicassi i sorgenti e l'eseguibile, avrei più largo seguito sul progetto, non è così?

Ciao,
Alberto

[Micartu]

Forse potreste provare a presentare queste ultime argomentazioni sotto forma di domanda agli sviluppatori dello scummvm, potrebbe aiutarvi a sborgliare la magagna.