17.08.2014, 16:16
Vielen Dank! 
Manchmal lass ich mich von GIT doch noch austricksen.
Die fehlenden Dateien sind jetzt im Repo.
Ja, Shihan, der Code ist momentan sehr unleserlich, was viele Ursachen hat.
Der grobe Entwicklungsfahrplan hat 3 Stufen:
Zu Punkt 2:
Eine kleine Ursache ist, dass einige Funktionen und Variablen noch keine sinnvollen Namen haben.
Das liegt daran, dass ich mich im Moment aus Zeitgründen nicht damit auseinandersetzen möchte,
was jede einzelne Variable bedeutet, sondern lieber Programmcode erzeuge welcher 1:1 übereinstimmt.
Die sinnvolle Namensgebung, kann dann in Ruhe im Nachgang erledigt werden.
Die Hauptursache ist, dass sämtliche Speicherzugriffe auf globale Daten und dynamisch allokierten Speicher
mittels Funktionen oder Makros durchgeführt werden.
Das wird sich, bis der Code von wirklich allen Funktionen nachgebaut ist, auch nicht ändern.
Danach können alle Zugriffe auf die globalen Daten im Quellcode leserlich gemacht werden,
indem die entsprechenden Variablen angelegt, exportiert und vom ganzen Programm benutzt werden.
Zum Beispiel: aus diesem Code, welcher einfach einen 32bit Wert kopiert...
... wird später ...
Auch verschwindet das Konvertieren von Zeigern mit Real2Host(), welches einen Zeiger in RealMode-Addressierung,
in einen Zeiger für unsere Systeme umwandelt.
Bei dynamischem Speicher kann ähnlich verfahren werden wie bei Globalem,
wobei hier noch etwas behutsamer auf korrekte Endianess geachtet werden muss
wenn Daten aus Dateien eingelesen werden.
War die Auskunft hilfreich?
(17.08.2014, 10:45)Obi-Wahn schrieb: Unter Linux klappt das Bauen leider nicht:
Manchmal lass ich mich von GIT doch noch austricksen.
Die fehlenden Dateien sind jetzt im Repo.
(17.08.2014, 12:05)Shihan schrieb: Nur eine Frage hätte ich, nach einem Blick in den Code: Wie könnte ein mögliches, in der unbestimmten Zukunft liegendes Refaktoring aussehen? Ich blick' da nämlich überhaupt nicht durch
Ja, Shihan, der Code ist momentan sehr unleserlich, was viele Ursachen hat.
Der grobe Entwicklungsfahrplan hat 3 Stufen:
- Den Programmcode zu 100% nachbauen.
- Hilfskonstrukte für Speicherzugriffe durch normale Speicherzugriffe ersetzten, sinnvolle Benennung und Dokumentation
- Portierung der Ein-/Ausgabe auf SDL
Zu Punkt 2:
Eine kleine Ursache ist, dass einige Funktionen und Variablen noch keine sinnvollen Namen haben.
Das liegt daran, dass ich mich im Moment aus Zeitgründen nicht damit auseinandersetzen möchte,
was jede einzelne Variable bedeutet, sondern lieber Programmcode erzeuge welcher 1:1 übereinstimmt.
Die sinnvolle Namensgebung, kann dann in Ruhe im Nachgang erledigt werden.
Die Hauptursache ist, dass sämtliche Speicherzugriffe auf globale Daten und dynamisch allokierten Speicher
mittels Funktionen oder Makros durchgeführt werden.
Das wird sich, bis der Code von wirklich allen Funktionen nachgebaut ist, auch nicht ändern.
Danach können alle Zugriffe auf die globalen Daten im Quellcode leserlich gemacht werden,
indem die entsprechenden Variablen angelegt, exportiert und vom ganzen Programm benutzt werden.
Zum Beispiel: aus diesem Code, welcher einfach einen 32bit Wert kopiert...
Code:
ds_writed(SPELLUSER, ds_readd(ITEMUSER));Code:
spelluser = itemuser;Auch verschwindet das Konvertieren von Zeigern mit Real2Host(), welches einen Zeiger in RealMode-Addressierung,
in einen Zeiger für unsere Systeme umwandelt.
Bei dynamischem Speicher kann ähnlich verfahren werden wie bei Globalem,
wobei hier noch etwas behutsamer auf korrekte Endianess geachtet werden muss
wenn Daten aus Dateien eingelesen werden.
War die Auskunft hilfreich?