Porting Autodesk Animator Pro di essere cross-platform

Question

un precedente questione rilevante da me è qui Reverse Engineering old paint programs

ho impostato la mia base operativa qui: http://animatorpro.org wiki in arrivo.

Ok, ora ho una base di codice MSDOS legacy di 300.000 legacy. È una specie di situazione di "stai attenta a ciò che desideri". Non sono un programmatore C esperto. Nemmeno io sono del tutto inesperto, ma a tutti gli effetti sono un noob alla lingua e in particolare alla complessità delle sue librerie. Sono particolarmente ignorante dei capricci delle differenze tra i programmi C scritti specificamente per MSDOS e programmi che sono multipiattaforma. Tuttavia ho studiato questa base di codice per più di un anno, e questo è quello che so su Animator Pro:

compilatori e gli strumenti utilizzati:

• Watcom compilatore C
• tcmake (fanno programma dal Turbo C)
• 386asm, un assemblatore specializzato per l'extender Phar Lap
• e, naturalmente, l'extender di Phar Lap stesso.
• una selezione di Dos oscuri utilità

Gran parte della compilation sembra essere guidata da file batch. Sebbene abbia ottenuto copie di tutti questi strumenti, non sono ancora riuscito a compilarlo. .. (Anche se ho compilato il suo fratello maggiore, Autodesk animatore originale

che ha un sistema di plugin che replica DLL prima DLL erano disponibili, sulla base di REX Il sistema di plugin gestisce:

• driver video (con una pletora di driver VESA inclusi)
• driver di ingresso (tra cui tavolette Wacom e tastiere)
• Strumenti di disegno
• inchiostri (come filtri di Photoshop, o metodi di fusione)
• scripting Addons (script essenzialmente compilati)
• I formati di file

Essa ha avuto un proprio interprete di script chiamato POCO, sulla base del C lingua- Il linguaggio di scripting ha abbastanza potere per fare praticamente tutte le cose che il sistema di plugin può do- Solo più lento.

Data questa informazione, questo è il mio piano di sviluppo. Si prega di criticare questo. Il codice sorgente è disponibile nel link qui sopra, quindi puoi facilmente, se sei così propenso, valutare da solo la situazione.

1. Compilare con gli strumenti originali.
2. Passa all'utilizzo di DJGPP e apporta le modifiche necessarie per farlo compilare, oltre all'assemblatore originale.
3. Includere la libreria "Gioco" Allegro.cc e passare il maggior numero possibile di funzionalità a quella libreria possibile-Forse semplicemente scrivendo nuovi video e driver di input che utilizzano l'API Allegro.Sto pensando ad Allegro piuttosto che a SDL perché: c'è una versione DOS di Allegro, e affascinante, una delle sue funzioni principali è la capacità di riprodurre il formato nativo FLIC di Animator Pro.
4. Spero che dopo 3 anni, avrò eliminato la maggior parte o tutti gli Assembler nel progetto. Dico speranzoso, perché è in un dialetto oscuro che non si assembla in nessun assemblatore libero moderno senza modifiche significative. Li ho provati tutti. Tutto ciò che è rimasto viene convertito in assemblare in NASM, o in codice C se posso definire la funzione effettiva dell'assemblatore.
5. Passa il dos extender da Phar Lap a HX Dos http://www.japheth.de/HX.html, che promette di replicare il maggior numero possibile di API WIN32. Quindi apportare tutte le necessarie modifiche al codice affinché funzioni.
6. Passare alla versione win32 di Allegro.cc, assumendo che la versione win32 possa essere eseguita su HXDos. Apporta ulteriori modifiche necessarie
7. Modifica il sistema di plugin per utilizzare una sorta di libreria di plugin standard multipiattaforma. Che cosa sarebbe, non ne ho idea. Forse puoi offrire qualche suggerimento? Ho parlato con lo sviluppatore che ha originariamente scritto il sistema di plugin, e ha detto che alcune delle cose che non è possibile sui sistemi operativi moderni a causa delle restrizioni di segmentazione. Non sono sicuro di cosa significhi, ma suppongo che significhi che tutti i plug-in dovranno essere riscritti quasi da zero.
8. Magicamente, ho fatto tutto quanto sopra, e possiamo provare a farlo funzionare in windows, osx e linux, mentre si tratta di altri problemi cross-platform come i nomi di file lunghi e cose a cui non ho pensato.

Qualcuno ha avuto un problema con tutto questo? Allegro è una buona scelta? se no, perché? cosa faresti riguardo a questo sistema di plugin? Cosa faresti diverso? Tutta questa cosa è sciocca, e dovrei semplicemente riscriverla da zero, usando l'originale come ispirazione? (a quanto pare sarebbe lo sviluppatore originale "Circa un mese" per farlo)

Una cosa che non ho trattato sopra è il sistema di testo/carattere. Non sei sicuro di cosa fare al riguardo, ma Animator Pro ha il suo formato personalizzato, ma è anche in grado di usare i font Postscript Type 1 e alcuni altri formati.

Answer 1

Spesso è molto difficile prendere una base di codice non banale esistente che non sia stata scritta pensando alla portabilità - ne parli alcuni - e quindi prova a renderla portabile. Ci saranno molti problemi in arrivo. Probabilmente è una buona idea iniziare da zero e riscrivere il codice usando il codice esistente solo come riferimento. Se si parte da zero, è possibile sfruttare la soluzione UI portatile esistente nel nuovo progetto come Qt.

Answer 2

La mia più grande preoccupazione per il tuo piano, in poche parole: il tuo approccio sembra essere quello di tentare di mantenere l'intera enorme cosa che funziona in ogni momento, modificando l'ambiente sempre più lontano dal DOS. Durante ogni modifica all'ambiente, ciò significa che avrete circa un miliardo di assunzioni sottili che potrebbero essersi spezzate in una volta, nessuna delle quali necessariamente comprendete ancora. Districarli tutti in una volta sarà incredibilmente doloroso.

Se stavo facendo il porto, il mio approccio sarebbe quello di disabilitare il maggior numero possibile di codice per far sì che SOMETHING funzioni in un ambiente moderno e riportare le parti online, un pezzo alla volta. Scrivi un semplice programma di test harness che carica un driver video e disegna alcune cose, e lo compila per DOS per assicurarti di aver capito l'interfaccia. Quindi scrivi un codice C che implementa la stessa interfaccia, ma con Allegro (o SDL o SFML) e fai in modo che quel programma funzioni sotto Windows o Linux. Quando l'output è diverso, hai un semplice caso di test da cui lavorare.

L'intero lavoro su questa porta sta sostituendo le implementazioni di varie interfacce e funzioni con quelle completamente nuove. Questo è un lavoro su cui il test unitario eccelle. Non scrivere alcun nuovo codice senza un test di qualche tipo eseguito sul vecchio codice sotto DOS! Rendi i tuoi potenziali problemi il più piccoli e semplici che puoi. Porta il codice assembly invece di riscriverlo solo se sei ragionevolmente sicuro che renderà il tuo lavoro più semplice (cioè, materiale algoritmico che compila bene con pochi aggiustamenti sotto NASM). Non mordere un pezzo più grande di quello che puoi comodamente inserire nel tuo cervello in una sola volta.

Io, per esempio, non vedo l'ora di vedere i tuoi progressi! Penso che quello che stai tentando di fare sia grandioso. Grazie per averlo fatto.

Answer 3

Hmmm - Potrei avvicinarmi scrivendo un "driver" video OpenGL. e le macchine di oggi sono abbastanza veloci con tonnellate di RAM che potresti fare tutti gli algoritmi specifici dei pixel della CPU principale in un buffer posteriore e funzionerebbe. Poiché il driver VGA "generico" ha appena mappato il buffer video su un puntatore, questo sarebbe un punto di partenza. C'era una modalità zoom nell'interfaccia utente in modo da poter guardare i pixel su un display ad alta risoluzione.