Reverse Engineering der NLT

[uxl]

Klasse, dass es weitergeht!

Ich selbst, habe jedoch ein keines Problemchen:

./configure CXX='g++' CXXFLAGS='-O1 -g'

   

[HenneNWH]

@arbosh, rabenaas:
Leider warnt der GCC nicht bei solchen Fehlern. Ich bin dem Problem aber schon auf der Spur.

EDIT: Nach ein paar Änderungen läuft Bright-Eyes mit Clang und GCC mit "-O2".
Ich habe den Commit eben gepusht, aber es kann an anderen Stellen im Spiel zu ähnlichen Fehlern kommen.
Meine Empfehlung vorerst: lieber auf die Optimierung verzichten.


@uxl:
Bei mir tritt der Fehler nicht auf.
Probier mal folgendes: füge folgende Zeile in seg000.cpp vor der ersten include-Zeile ein:

#include <time.h>


Gib bitte Bescheid ob es funktioniert.

[uxl]

Leider keine Besserung.

Ich habe die Ausgabe des Terminals in eine Textdatei gepackt, vielleicht helfen dir diese Angaben etwas weiter.

Ich verwende Mac OS X 10.11.6 mit Xcode v7.0 und den Paketen von MacPorts (zusätzlich installiert: autogen, autoconf, automake, libsdl, libsdl_sound)

@uxl:
Bei mir tritt der Fehler nicht auf.
Probier mal folgendes: füge folgende Zeile in seg000.cpp vor der ersten include-Zeile ein:

#include <time.h>

Gib bitte Bescheid ob es funktioniert.

[NewProggie]

Leider keine Besserung.

Ich habe die Ausgabe des Terminals in eine Textdatei gepackt, vielleicht helfen dir diese Angaben etwas weiter.

Ich verwende Mac OS X 10.11.6 mit Xcode v7.0 und den Paketen von MacPorts (zusätzlich installiert: autogen, autoconf, automake, libsdl, libsdl_sound)

@uxl:
Bei mir tritt der Fehler nicht auf.
Probier mal folgendes: füge folgende Zeile in seg000.cpp vor der ersten include-Zeile ein:

#include <time.h>

Gib bitte Bescheid ob es funktioniert.

Das eine Betriebssystem ist halt "POSIXer", als das andere :-) Probier mal das hier in der Datei einzufügen, in der der Fehler auftritt

Code:

#if !defined __timer_t_defined && \
((defined _TIME_H && defined __USE_POSIX199309) || defined __need_timer_t)
# define __timer_t_defined      1

# include <bits/types.h>

/* Timer ID returned by `timer_create'.  */
typedef __timer_t timer_t;

@Henne: Lohnt sich vielleicht das Projekt auch mal auf travis-ci (oder ähnlichem) automatisiert bauen zu lassen. Need a hand?

[HenneNWH]

Leider keine Besserung.

Ich habe die Ausgabe des Terminals in eine Textdatei gepackt, vielleicht helfen dir diese Angaben etwas weiter.

Ich verwende Mac OS X 10.11.6 mit Xcode v7.0 und den Paketen von MacPorts (zusätzlich installiert: autogen, autoconf, automake, libsdl, libsdl_sound)

Das eine Betriebssystem ist halt "POSIXer", als das andere :-) Probier mal das hier in der Datei einzufügen, in der der Fehler auftritt

Danke an NewProggie für den Hinweis. Der Fehler tritt allerdings bei time_t und nicht bei timer_t auf.
Hier ist mal der entsprechende Ausschnitt aus meiner time.h.
Probier den mal.

Code:

#if !defined __time_t_defined && (defined _TIME_H || defined __need_time_t)
# define __time_t_defined       1

# include <bits/types.h>

__BEGIN_NAMESPACE_STD
/* Returned by `time'.  */
typedef __time_t time_t;
__END_NAMESPACE_STD
#if defined __USE_POSIX || defined __USE_MISC || defined __USE_SVID
__USING_NAMESPACE_STD(time_t)
#endif

#endif /* time_t not defined and <time.h> or need time_t.  */
#undef  __need_time_t

@Henne: Lohnt sich vielleicht das Projekt auch mal auf travis-ci (oder ähnlichem) automatisiert bauen zu lassen. Need a hand?

Prinzipiell folge ich dem CI-Gedanken schon seit einiger Zeit:

• In meinem lokalen Repo werden mit dem Borland-Compiler bei jedem Commit alle Objekt-Dateien gebaut und geprüft,
  ob der Code mit dem aus der SCHICKM.EXE (v3.02) übereinstimmt.
  
• Auf meinem System muss auch jeder Commit gebaut werden können.
  
• In einer Windows-VM teste ich mit MSVC nur vor den Releases.
  

Das sind zur Zeit die wenigen wichtigen Kriterien auf die ich achte.

Treten Fehler bei den Testern auf, wie dieser Reisemodus-Optimierungs-Bug, kann ein CI-Server erstmal auch nicht helfen.
Der Fehler von uxl wäre gefunden worden, wenn der CI-Server auch für Mac bauen würde.

Generell bin ich dafür, aber in der aktuellen Phase halte ich das noch für verfrüht.
Wenn der Code nativ (in lesbarem C und ohne DOSBox) läuft, dann ist ein CI-Server ein Muss.
Halte deine Hand bereit!

P.S.: Wenn du es aber trotzdem probieren möchtest, würde ich mich über deine Erfahrungsberichte freuen.

[uxl]

Danke an NewProggie für den Hinweis. Der Fehler tritt allerdings bei time_t und nicht bei timer_t auf.
Hier ist mal der entsprechende Ausschnitt aus meiner time.h.
Probier den mal.

Unter den Dateien, die ich gestern von GitHub heruntergeladen habe, befindet sich keine Datei mit dem Namen time.h.
Ich finde nur /include/timer.h

[Borbaradwurm]

Unter den Dateien, die ich gestern von GitHub heruntergeladen habe, befindet sich keine Datei mit dem Namen time.h.

time.h ist ein Standard C Header und sollte im Lieferumfang eines jeden C Compilers enthalten sein.

[uxl]

time.h ist ein Standard C Header und sollte im Lieferumfang eines jeden C Compilers enthalten sein.

Nö, da lass ich mal lieber die Finger weg!


Ich hab's aber inzwischen anderweitig zum laufen bekommen.

Der Error verweist in der Datei seg000.h auf den Eintrag:

Code:

Bit32s bc_time(time_t*);

Dieser steht noch vor:

Code:

#include <TIME.H>

...daher habe ich diesen an den Anfang der Datei kopiert. Damit läuft make ohne Error durch.

   

[Obi-Wahn]

Mit der neusten Version gibt es unter Linux das Problem im Reisebildschirm nicht mehr.

[HenneNWH]

Nochmal ein kleines Release:

Es wurde ein Dungeon ersetzt - das Totenschiff.
Jetzt fehlen nur noch: Die Herberge, die Spinnenhöhle und die Orkhöhle.

Außerdem habe ich den Bugfix für den Reisemodus überarbeitet und an anderen Stellen angewandt.


Ersetzte Funktionen (Segmente sind komplett identisch):

• seg076: Dungeon: Totenschiff
  

Bugfix:

• Zeigerarithmetikprobleme: führte zu Abstürzen im Reisemodus
  
• Kompilieren auf Mac: time.h eingefügt
  

Original-Bugfix:

• Totenschiff: kaputter Text beim Öffnen der Rätselkiste (führte auf aktuellen Rechnern zum Absturz)
  

TODO-Liste:

• Dungeons (33 sehr kleine und 3 sehr lange Funktionen, insgesamt noch 36)
  
• Audio-CD Steuerung (11 Funktionen)
  

Statistik:

Es sind 1189 von 1237 Funktionen nachgebaut (96,12%).
Davon sind 1184 identisch mit dem Originalcode.
Nach Byte-Metrik sind schon 94,14% (korrigiert) fertig.


Viele Spaß beim Testen,
HenneNWH

Admin-Edit: Fehlerhaften Code-Tag korrigiert.

[Obi-Wahn]

Neue Version vom 10.12.2016!

Hier die Übersicht, die Henne erstellt hat: https://bright-eyes.obiwahn.de/Bright-Eyes/details.html

[Rabenaas]

Dann können wir ja Wetten abschließen, ob dieses Jahr noch die 100 geknackt wird.

[NRS]

seg076: Dungeon: Totenschiff

seg077

Totenschiff: kaputter Text beim Öffnen der Rätselkiste (führte auf aktuellen Rechnern zum Absturz)

Da fehlen aber noch die 10 AP, von denen im Textfenster die Rede ist.

[HenneNWH]

Totenschiff: kaputter Text beim Öffnen der Rätselkiste (führte auf aktuellen Rechnern zum Absturz)

Da fehlen aber noch die 10 AP, von denen im Textfenster die Rede ist.

Aufgefallen ist mir das schon, aber diese Kiste ist ein Spezialfall:
In jeder Schatzkiste können auch, neben den Gegenständen, noch Geld, Rationen und AP sein.
Bei dieser Kiste stehen die 10 AP tatsächlich in der Beschreibung der Kiste drin, nur werden sie nicht angerechnet.

[Shihan]

Hey ihr lieben Leute!

Habe doch mal etwas weiter gebastelt. Und weil es gerade so einen Spaß macht, muss ich euch daran teilhaben lassen


Da ich mittlerweile die Geduld verloren habe und das 3DM-Format jetzt endlich knacken will, habe ich mir ein neues Programm geschrieben, mit dem ich im Format nach Zusammenhängen suchen kann. Habe die Infos aus dem Wiki alle darin verarbeitet. Herausgekommen ist einiges, aber leider noch keine Geometrie. Das ist aber mein nächster Schritt. Immerhin bin ich jetzt in der Lage, aus PIX-Dateien (danke an Borbaradwurm für die Infos) und den dazugehörigen Paletten OpenGL-Texturen zu basteln. Die kann man sich dann auch ansehen. Nächster Schritt ist eine Anzeige der Faces. Drückt mir die Daumen, wenn alles gut läuft haben die dann auch die richtigen Texturen.

Mal ein Screenshot:




Das Programm basiert auf einer Software, die ich im beruflichen Umfeld gebastelt habe. Deshalb kann ich das Ding zum jetzigen Zeitpunkt nicht open-source stellen, sorry
Aber das werde ich klären und -- sollte da was möglich sein -- dann auch zur Verfügung stellen!
Falls es jemanden interessiert: Das Ding nutzt die ImGui! Ein absolut geiles Teil!




Damit ihr mal eine Meldung von mir habt, was gerade so passiert

[Obi-Wahn]

@Shilan: Schön, dass auch bei Riva Fortschritte zu erkennen sind!

@Henne: Im Moment wird jeweils eine 32bit-Version von Bright-Eyes gebaut, oder? Welche Vorteile würde eine 64bit-Version eigentlich bringen? Keine sichtbaren Vorteile, oder?

[HenneNWH]

@Henne: Im Moment wird jeweils eine 32bit-Version von Bright-Eyes gebaut, oder? Welche Vorteile würde eine 64bit-Version eigentlich bringen? Keine sichtbaren Vorteile, oder?

Kurze Antwort: Nein.

Mehr als 4GB RAM wird die DOSBox nicht brauchen. Die 8 zusätzlichen CPU-Register bringen vielleicht einen kleinen Geschwindigkeitsvorteil, aber das ist den Aufwand nicht wert.

[HenneNWH]

Die Überprüfung nach der eingelegten CD bei SCHICK kann abgeschaltet werden. Wie das geht?

Bei starten der SCHICKM.EXE kann ein Parameter übergeben werden.
Beispiel:

• SCHICKM.EXE +/:[[mmz}
  
• SCHICKM.EXE !55AISjuv
  
• SCHICKM.EXE Wagiimnrs
  

Groß- und Kleinschreibung sind wichtig, die Reihenfolge kann verändert werden.
Jedes Zeichen des Parameters wird als Zahl repräsentiert.
Es wird das Produkt aus diesen Zahlenwerten gebildet und im Speicher hinterlegt.
Wenn das Produkt den Wert 0x682772E4 hat, wird angenommen es läge die richtige CD im Laufwerk.

SCHICK fordert aber trotzdem, dass ein CD-Laufwerk vorhanden ist, in diesem muss dann aber nicht die SCHICK-CD liegen.

[Obi-Wahn]

Danke für die Erklärungen! Hatte ich mir aber schon fast gedacht, dass 64bit keinen Sinn macht. Die Erläuterungen zur CD habe ich jetzt noch nicht ganz verstanden. Kann ich jetzt mit dem entsprechenden Startbefehl Schick ohne CD spielen?

Es gibt neue Änderungen im Git-Repo, aber noch kein Changelog hier. Kann ich einen neuen Build bauen?

[Rabenaas]

Mit einer 64bit-Version könnte man sich aber in Zukunft uU das 32bit-Subsystem ganz sparen. Mach für mich aber gerade eh keinen Unterschied.