Hier noch ein paar Patches:
Behobene Fehler (Bright-Eyes)
- Abstürze bei AE-Verlust im "3D-Modus"
Sonstiges
- Benutzung von Namen für einige globale Variablen für bessere Lesbarkeit (z.B. CURRENT_TOWN statt 0x2d63)
Der behobene Fehler war übrigens der besagte Fehler, welcher mir auf ARM aufgefallen ist.
Auf allen anderen Prozessoren (x86, x86_64, PPC) ist dieser Fehler auch aufgetreten.
Viel Vergnügen!
(10.10.2014, 16:25)Obi-Wahn schrieb: [ -> ]Auf die ARM-Version bin ich gespannt! Dann muss ich doch mal glatt den Raspberry Pi meines Vaters klauen! 
Wie weit wäre der Schritt dann noch zu einer Android-Version? 
Gute Frage! Gibt es denn hier im Forum potentielle NLT-Androidnutzer?
Eine Androidversion könnte man vermutlich relativ einfach bauen,
indem man den DOSBox-Quellcode in einem funktionierenden und quelloffenen DOSBox-Port (z.B. aDOSBox)
durch den Bright-Eyes Quellcode ersetzt und das ganze dann baut.
Ich habe gerade versucht aDOSBox mit dem aktuellen Andriod NDK zu bauen, aber das Bauen bricht leider ab.
Mir fehlt dafür allerdings die Zeit um eine Androidversion zu pflegen.
Interessenten bitte vortreten.
(10.10.2014, 16:25)Obi-Wahn schrieb: [ -> ]Was meinst du mit einem "eigenen" Compiler?
Aus Lizenzgründen darf ich doch keine Kopien verteilen.
Desshalb muss jeder Entwickler seine eigene Version vom "Borland C++ 3.1" Compiler besitzen,
wenn er diese Vergleichstests durchführen möchte.
Neue Version vom 17.10.2014!
Ich hätte da diverse Android-Geräte mit denen ich das ausprobieren könnte. Es wäre allerdings eher ne Spielerei als eine echte Anwendung.
Nein, nicht ganz. Es soll ähnlich laufen wie auf dem PC. Die aDosBox soll nur noch die Teile von Schick übernehmen, die von BrightEyes noch nicht ersetzt worden sind. Gerade auf den Android-Geräten, die noch nicht so viel Rechenleistung "über" haben, sollte sich da eine Geschwindigkeits- oder besser "Geschmeidigkeits-"Verbesserung zeigen.
(17.10.2014, 16:54)HenneNWH schrieb: [ -> ]Ich habe gerade versucht aDOSBox mit dem aktuellen Andriod NDK zu bauen, aber das Bauen bricht leider ab.
Vermutlich braucht man da noch die Android/ARM-Variante von SDL, oder? (Vielleicht das
hier?)
(18.10.2014, 11:53)Obi-Wahn schrieb: [ -> ]Nein, nicht ganz. Es soll ähnlich laufen wie auf dem PC. Die aDosBox soll nur noch die Teile von Schick übernehmen, die von BrightEyes noch nicht ersetzt worden sind. Gerade auf den Android-Geräten, die noch nicht so viel Rechenleistung "über" haben, sollte sich da eine Geschwindigkeits- oder besser "Geschmeidigkeits-"Verbesserung zeigen.
Genau so ist es.
(18.10.2014, 11:53)Obi-Wahn schrieb: [ -> ]Vermutlich braucht man da noch die Android/ARM-Variante von SDL, oder? (Vielleicht das hier?)
Das ist nicht nötig.
Bei aDOSBox sind alle benötigten Bibliotheken im Quellcode dabei, also auch SDL.
Das Android NDK baut den ganzen C++ Code in eine neue Bibliothek. (Habe jetzt Version 5b probiert, damit ging es.)
Diese Bibliothek wird dann von der JAVA-App, welche mit dem SDK gebaut wird aufgerufen.
An dieser Stelle hänge ich gerade fest.
Hi NLT-Freunde,
was machen denn die verschiedenen SW-Projekte? Sommer ist vorbei und Wetter wird ideal zum programmieren.
Bright-Eyes macht große Fortschritte:
Der Kampfmodus ist jetzt
vollständig nachgebaut.
Gerade bastle ich an ein paar Gebäuden von Phexcaer.
Ich teste Morgen meine Version nochmal und werde morgen wieder mal releasen.
Dann mit genaueren Infos.
Einige Neuigkeiten:
Wie schon im letzten Beitrag erwähnt:
das Kampfsystem läuft jetzt komplett auf dem Hostrechner.
Ersetzte Funktionen (Segmente sind komplett identisch)
- seg043: Kampfaktionen von Monstern ausführen
- seg042: Kampfaktionen von Helden ausführen
- seg032: Kampfsystem: Kampfrunde, gesamter Kampfablauf
- seg097: GUI Elemente: Textboxen, Popup-Menus
- seg028: Fileloader: Karten, NPCs, besondere Texturen, Dialoge, Kampfhintergründe
Ersetzte Funktionen
- seg070: Phexcaer: Fuhrhaus, Stadthaus, Spielhaus, Villa Gremob
Behobene Fehler (Bright-Eyes)
- Programmabbruch beim Öffenen von Schatztruhen
- Zauberanimationen in Kämpfen an der falschen Stelle
- Weitere BigEndian-Probleme (aber noch nicht alle)
Fehler aus dem Original
- Fehldeutung des Glücksspielergebnisses in Phexcaer
- Kaputter Dialog im Stadthaus
- Tippfehler in der "Saft, Kraft, Monstermacht" Meldung
Dokumentation:
- Doxygen-File (zum Erzeugen der Dokumentation)
- details.html (Übersicht über den Fortschritt der Bright-Eyes Entwicklung)
Was kommt als Nächstes?
- Check: Skripte zum Vergleichen der Binärdateien (erfordert eigenen Borland C++ 3.1 Compiler)
- Weitere Arbeiten an Phexcaer
Statistik:
- Es sind 762 von 1236 Funktionen sind nachgebaut (61,65%).
- Davon sind 702 identisch mit dem Originalcode.
Die Fortschrittsmessung anhand der Anzahl der Funktionen ist manchmal ein wenig irreführend.
Es gibt Funktionen, die in der SCHICKM.EXE sehr viel Platz wegnehmen.
Der Maschinencode für das Menu im Kampfsystem ist z.B. über 6KB groß (mehr als 1% der SCHICKM.EXE).
Andere Funktionen sind dagegen winzig.
Das macht sich auch in der Bearbeitungszeit bemerkbar.
Desshalb habe ich noch eine alternative Metrik zu Messen des Bright-Eyes Fortschritts,
welche die Größe des fertigen Maschienencodes ins Verhältnis zum Maschinencode in der SCHICKM.EXE setzt.
Der folgende Wert ist noch etwas kleiner als der Tatsächliche, da ich im Moment nur komplett fertige Segmente zähle:
Nach der Byte-Metrik ist der Code von SCHICK schon zu 71,91% fertig.
Das klingt doch schon viel besser.
Viel Spaß!
Henne, großartig! Wieviel Cycles brauchst Du mittlerweile? Oder anders: Wie wenige sind es noch?
@Wetzer:
3DM schläft z.Z.
Habe zwar einen kleinen OpenGL-Viewer geschrieben. Dabei sind mir aber noch ein paar Unstimmigkeiten aufgefallen. Die Face-Zuordnung stimmt nicht ganz. Was falsch ist, weiß ich aber noch nicht. Habe gerade auch -- trotz Winter
-- wenig Zeit dafür.
Schaue aber immer mal wieder rein. Hoffentlich kommt da bald der Heureka-Moment.
(20.11.2014, 11:27)Shihan schrieb: [ -> ]@Wetzer:
3DM schläft z.Z.
Habe zwar einen kleinen OpenGL-Viewer geschrieben. Dabei sind mir aber noch ein paar Unstimmigkeiten aufgefallen. Die Face-Zuordnung stimmt nicht ganz. Was falsch ist, weiß ich aber noch nicht. Habe gerade auch -- trotz Winter -- wenig Zeit dafür.
Schaue aber immer mal wieder rein. Hoffentlich kommt da bald der Heureka-Moment.
Sehr Schade.
Wäre es möglich, dass du deine bisherigen Arbeiten veröffentlichst, damit man darauf aufbauen kann?
Das lesbar machen ist ja eigentlich klassisches Refactoring. Hat sich schon mal jemand Gedanken darum gemacht, mit welchen Tools sich das unterstützen ließe? (z.B. Eclipse)
Damit könnte man ja eigentlich jetzt schon anfangen, oder?
(20.11.2014, 18:39)Obi-Wahn schrieb: [ -> ]Der Kampf funktioniert grundlegend. Angreifen, Magie usw... Mehr habe ich noch nicht getestet.
War never changes ... :d
(20.11.2014, 18:22)Wetzer schrieb: [ -> ]Sehr Schade.
Wäre es möglich, dass du deine bisherigen Arbeiten veröffentlichst, damit man darauf aufbauen kann?
Naja, außer dem Text in der Wiki und dem Viewer gibt es nichts, was ich da veröffentlichen könnte. Und der Viewer ist bisher so geschrieben, dass ich den nicht veröffentlichen möchte. Zu dreckig, um es mal anders zu sagen
Aber wie gesagt, ich denke, die Zeit kommt wieder.
(20.11.2014, 11:27)Shihan schrieb: [ -> ]Henne, großartig! Wieviel Cycles brauchst Du mittlerweile? Oder anders: Wie wenige sind es noch?
Also wenn man eine leicht verzögerte Startphase in Kauf nimmt,
in der DOSBox das CD-Image mountet und die SCHICKM.EXE startet,
kann man Schick mit 100 Cycles flüssig spielen.
(20.11.2014, 20:20)Rabenaas schrieb: [ -> ]Das lesbar machen ist ja eigentlich klassisches Refactoring. Hat sich schon mal jemand Gedanken darum gemacht, mit welchen Tools sich das unterstützen ließe? (z.B. Eclipse)
Damit könnte man ja eigentlich jetzt schon anfangen, oder?
Ich lese parallel die
Wikipedia Seite zu Refactoring.
Einige Änderungen können gemacht werden, andere noch nicht.
Was ist im Moment möglich:
- Lesen und nachvollziehen des Quelltextes
- Fehler im Original melden / beheben (als ORIGINAL_BUGFIX)
- Ändern der Symbolnamen von lokalen Variablen z.b. signed short l_di; signed short l1;
- Ändern der Symbolnamen von Funktionen z.B. void seg044_02a()
- Ersetzen von Adressen im Datensegment durch Präprozessorkonstanten z.B ds_readbs(0x2d67) => ds_readbs(CURRENT_TOWN)
- Schreiben von Doxygen-Kommentaren für Funktionen
- Ändern des alten Kommentarstils in Doxygen-Kommentare
Die Borland-C-Version des Quelltextes darf nicht in ihrer Funktionalität geändert werden,
da ich bei jedem Commit automatisch den Quellcode mit dem BCC kompiliere und prüfe ob dergleiche Binärcode rauskommt.
Ist das nicht der Fall wird der Commit nicht zugelassen.
Unit-Tests wären schön, aber ich hab noch keine Idee wie und womit diese umgesetzt werden können.
Einige Neuigkeiten zun Nikolaus
:
Der Code von der Spezialgebäude von Phexcaer ist komplett nachgebaut.
Ersetzte Funktionen (Segmente sind komplett identisch)
- seg070: Phexcaer Spezialgebäude 1/2
- seg071: Phexcaer Spezialgebäude 2/2
- seg073: Taverne: Gerüchte,
- seg120: Misc: Tollwutanfall, Spielinititalisierung, Game-Over-Screen, Starten von GEN.EXE
Ersetzte Funktionen
- seg050: Steigerung: Erhöhen von Zauberfertigkeiten im Fortgeschrittenenmodus
Behobene Fehler (Bright-Eyes)
- Falsche Speicherzugriffe beim Freigeben von EMS-Speicher (tritt nie auf)
Dokumentation:
- Aktualisierung details.html (Übersicht über den Fortschritt der Bright-Eyes Entwicklung)
Was kommt als Nächstes?
- Check: Skripte zum Vergleichen der Binärdateien (erfordert eigenen Borland C++ 3.1 Compiler)
Statistik:
- Es sind 774 von 1236 Funktionen sind nachgebaut (62,62%).
- Davon sind 716 identisch mit dem Originalcode.
- Byte-Metrik: 74,51% des Codes sind nachgebaut.
Anmerkungen zu Phexcaer:
Die vollständige Umsetzung dieser Stadt scheint dem frühen Releaseterm in zum Opfer gefallen zu sein.
Fragt man im Fuhrhaus oder im Spielhaus nach Alrik Derondan, so trifft man ihn in der nächsten Taverne in Phexcaer.
Im Gespräch mit Ihm führen die Antwortfolgen 1->3->1 oder 3->1 dazu, dass eine Variable im Spielstand gesetzt wird,
welche allerdings nirgendwoanders abgefragt wird.
Hier tritt somit das gleiche Problem auf, wie bei der Verabredung mit der Prostituierten.
Viel Spaß!
Bin gerade über eine interessante Bibliothek gestolpert. Was haltet ihr von der Idee, ein Backend für die DATs in
physicsfs zu schreiben?
Ja, Physicsfs...
Wenn ich dich recht verstehe, möchtest du (langfristig) die Lade-Routinen der 3 NLT-Teile durch Aufrufe von PhysicsFS ersetzen, so dass ich die Archivdateien auch ungepackt verwenden könnte? Geht durchaus, aber das ist eher etwas für den "dritten Schritt", nachdem die Spiele vollständig rückübersetzt und lesbar gemacht worden sind.
Was mich beim Schreiben von nltpack an den NLT-Archiven am meisten gestört hat ist, dass es durchgehend keine "echten" Archivformate sind - man kann jeweils nur bestimmte Dateien speichern. Für die SCHICK.DAT sind das genau die Dateien, die in der SCHICK.EXE am Ende stehen, für Schweif die Dateien aus der jeweiligen .FN, und Riva hat zwar theoretisch sogar Unterverzeichnisse, praktisch hingegen sind die Archive (bzw. der Code in der RIVA.EXE) recht empfindlich gegen eine solche "universelle" Nutzung. Daher hatte ich mich auch für das - zugegeben nicht besonders nutzerfreundliche - Bedienkonzept mit den .FN-Dateien entschieden.
EDIT: Ein PhysicsFS-Backend hätte, als Bibliothek verstanden, natürlich auch andere Einsatzmöglichkeiten: nutzerfreundliche Reimplementationen von nltpack, Nutzung in Editoren, Nachbau der NLT (statt RevEng), ...
(18.12.2014, 13:50)Hendrik schrieb: [ -> ]Wenn ich dich recht verstehe, möchtest du (langfristig) die Lade-Routinen der 3 NLT-Teile durch Aufrufe von PhysicsFS ersetzen,
Ja
(18.12.2014, 13:50)Hendrik schrieb: [ -> ]so dass ich die Archivdateien auch ungepackt verwenden könnte?
Jein, über PhysicsFS kann man ja (soweit ich das verstehe) z.B. auch auf Zips zugreifen. Insofern würde die Bibliothek u.a. den Zugriff auf die Ressourcen als Middleware vereinheitlichen und transparent machen. (Ent-)Packer, Editoren und Spiele könnten über den selben Code auf die Archive wie auf normale Verzeichnisse (und umgekehrt) zugreifen und bräuchten sich nicht mehr mit den Details auseinandersetzen.
(18.12.2014, 13:50)Hendrik schrieb: [ -> ]Geht durchaus, aber das ist eher etwas für den "dritten Schritt", nachdem die Spiele vollständig rückübersetzt und lesbar gemacht worden sind.
Stimmt.