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

EDIT: Link to the new alpo's host:

http://www.pompons.net/Files/DrawFontMADS.html
http://www.pompons.net/Files/DrawFontMADS.exe
http://www.pompons.net/alpobemp/index.php/mads-engine/
http://www.pompons.net/Files/extracthag.exe

External resource:
https://github.com/institution/mpskit

[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