22.08.2015, 21:26
(30.07.2015, 18:02)adtbm schrieb: Nachdem ich dann raus in den Tempel bin, zum speichern und den Spielstand wieder
neu geladen habe, hat wieder ein Held gefehlt...
Im Moment arbeite ich an einer Lösung für diesen Bug und möchte meine Erkenntnisse loswerden:
Der Bug tritt beim speichern auf, aber nicht immer.
Die für diesen Bug beim speichern wichtigen Schritte sind:
- Alle aktiven Helden werden im TEMP-Verzeichnis gespeichert.
- Der komplette Spielstand wird gespeichert.
- Alle CHR-Dateien im TEMP-Verzeichnis werden an den Spielstand angehängt.
Welche CHR-Dateien das sind wird mit den Funktionen findfirst("TEMP\\*.CHR", &blk, 0) und findnext(&blk) ermittelt.
Das Problem ist nun, dass einige CHR-Dateien manchmal (noch) nicht im TEMP-Verzeichnis angekommen sind, und findnext() sie nicht findet was dazu führt, dass diese Helden nicht im Spielstand landen.
Ich habe einiges ausprobiert (fflush(), flushall(), sync(), warten) aber war damit leider erfolglos.
Aktuell habe ich den Laufwerkscache von DOSBox (dos/drive_cache.cpp) unter Verdacht,
welcher die Datei- und Verzeichnisnamen speichert um Laufwerkszugriffe zu vermeiden.
Dort stöbere ich gerade herum und lese mich in den Code ein.
...ah, in der Entwicklerversion von DOSBox wurde nach v0.74 nochmal an drive_cache.cpp herumgeschraubt...
(02.08.2015, 20:56)tommy schrieb: Naja auf jeden Fall hab ich mir gerade ein paar Zeilen code angesehen und ich muss dochmal ein wenig meckern Du hast eindeutig noch unter jemanden gelernt, der mit alten C kompilern zu tun hatte. Dieses deklarieren von Variablen am Funktionsanfang ohne sie unmittelbar zu definieren hat unter neueren C compilern (neuer als ANSI-C (C89/C90)) nichts und in C++ noch viel weniger zu suchen!!!
Ich habe schon zu oft gesehen, dass im nachhinein code geändert wurde und deswege in einer besonderen if/switch Anweisung eine bestimmte Variable nicht mehr initialisiert wurde, womit es ein bischen Glückssache wurde, dass im Speicher zufällig ein halbwegs passender Wert drin stand...Auf jeden Fall ist es eine schlechte Angewonheit, die man sich schnellsten Abgewöhnen sollte
Danke sowohl für das Lob als auch die Kritik.
Im Moment ist meine Hauptpriorität den Borland C++ 3.1 Compiler (von 1992) dazu zu bringen genau den gleichen Binärcode wie er in der SCHICKM.EXE ist auszugeben. Das bedeutet, dass ich auch so programmieren muss wie die ATTIC-Programmier es damals getan haben.
Bei SCHICK war das einzige was mit C++ etwas zu tun hatte die Dateiendungen *.cpp
(*.c erzeugt in seltenen Fällen leicht anderen Code).
Der Programmcode wurde ausschließlich in C, inline Assembler(BASM) und Assembler geschrieben.
Aber um auf deine Frage zu Antworten: ich hatte meine erste Begegnung mit C 1998 (Borland Turbo C ???) und habe das so gelernt.
In meinem Studium (2011) wurden wir in "Algorithmen und Programmierung" aber trotzdem dazu angehalten "ANSI-C" zu programmieren, da es für manche Plattformen nichts anderes gibt.