(16.04.2025, 09:13)siebenstreich schrieb: Ich bin sprachlos.
Wie erfolgt die Grafikausgabe jetzt eigentlich, vom technischen Standpunkt aus, steckt da die SDL-Bibliothek dahinter?
Großartig auch die Demonstration ausgehend von der Bash-Kommandozeile. Da fühle ich mich zu Hause.
Bitte weitermachen!! Wenn du denkst, dass es so weit ist, dass ich helfen könnte, gib Bescheid.
Noch eine Frage: Worin besteht der Vorteil von clang gegenüber gcc?
Henne verwendet die SDL2 in dem Repository, ja. Ich kann nicht für ihn sprechen, aber Clang und GCC produzieren das gleiche Binary. Von daher ist es vermutlich einfach nur cool, je mehr Compiler tatsächlich unterstützt werden.
Bist du wirklich sicher, dass der gcc und clang denselben Byte-Code erzeugen?
Meine Frage kommt daher, dass Henne in der TODO schreibt: "compile with GCC/Clang.linking with Clang"
Daraus hätte ich geschlossen, dass Clang zumindest beim Linken einen Vorteil mitbringt.
16.04.2025, 14:08 (Dieser Beitrag wurde zuletzt bearbeitet: 16.04.2025, 14:10 von HenneNWH.)
Whoa, hier geht's wiedermal zur Sache.
Da geb ich gleich mal ein paar Infos zu den Compilern:
GCC ist der Standard-Compiler, welcher in der freien Softwarewelt seit Jahren benutzt wird.
Clang wurde vor einigen Jahren von Apple auf den Markt geworfen, wirkt etwas sauberer designt und es gibt viele Tools, Warnungen und Fehlermeldungen.
Beide Compiler erzeugen unterschiedlichen Bytecode und Clang hat den Ruf schnellere Software zu erzeugen als der GCC.
Um Performance geht's hierbei allerdings nicht, sondern um möglichst flexiblen Quellcode.
Den von mir rekonstruierten Quellcode konnte ich mit beiden Compilern erfolgreich übersetzen.
Da ich allerdings "Was sehen" wollte habe ich vor 4 Tagen einen Speicherbereich von 320x200 Pixeln eingefügt,
welcher den Speicher einer VGA-Karte repräsentiert (siehe Commit e1c1824 Zeile 7306 in g105_seg002.c).
Diesen habe ich wenige Studen später in der GCC/Clang-Welt nutzbar gemacht (siehe Commit 52092e8).
Die Umsetzung ist einfach: Fenster, Renderer und Textur erzeugen, Farbpaletten anpassen und den Inhalt des Speicherbereichs in die Textur übertragen und rendern.
Bei jedem Aufruf in die Grafikroutinen wird am Ende der Inhalt des Fensters aktualisiert.
Ein unschöner Nebeneffekt dieser Änderung war, dass bisher die SDL2 Bibliothek mit Code vom GCC nicht gelinkt werden konnte. Das habe ich eben behoben.
(Im Makefile "CC=clang" durch "CC=gcc" ersetzen 'make' aufrufen und 'g105de_gcc' starten.)
Prinzipiell bin ich dafür beide Compiler in der Zukunft zu benutzen, da beide jeweils ihre Vorteile haben.
GCC unterstützt sehr viele Prozessorarchitekturen (x86, x86_64, ARM, MIPS, ...) und auch Windows (32- und 64-Bit).
Clang sicherlich auch, aber das findet sich.
Beide Compiler sind von der Benutzung sehr ähnlich und ja: Ich finde es erstmal cool mehrere Compiler benutzen zu können.
Was die Zukunft bringt wird sich zeigen.
Aktuell entwickle ich einen Test für Phase 2+3, welcher beide EXE-Dateien auf Ähnlichkeit prüft.
Grund ist, dass in den vom BCC erzeugten Objektdateien die Speicheradressen von absolut zu relativ gewechselt sind und somit mit meiner bisherigen Testroutine sehr viele Unterschiede angezeigt werden.
Die GEN.EXE welche ich (noch lokal) bei mir erzeuge, hat weitestgehend denselben Binärcode (inkl. Speicheradressen) wie das Original (272/52336 also ca. 0,52 % vom Code sind aktuell unterschiedlich, Speicherbereiche habe dasselbe Layout, aber noch eine immense Größendifferenz).
Unterschiede im Code haben dieselbe Funktionalität oder werden von mir noch soweit untersucht, dass ich sie entsprechend anpasse, falls es möglich ist.
Prinzipiell sehe ich es so, dass der BCC die Vergangenheit abdeckt und auch ältere Versionen der GEN.EXE leicht aus dem von mir erstellten Code erzeugt werden können.
Die GCC/Clang-Welt deckt die zukünftige Entwicklung ab.
Dort wird es in der Zukunft noch eine Aufspaltung geben.
(17.04.2025, 15:28)HenneNWH schrieb: @NewProggie: Ich war selbst überrascht, aber du hast in diesem Fall Recht:
Auf meinem System erzeugen GCC-12.2.0 und Clang-19.1.4 tatsächlich dasselbe Binary.
Das von Clang-14.0.6 ist anders. Das hatte ich nicht erwartet.
Clang und GCC sind in jeweils älteren/neueren Versionen tatsächlich ABI kompatibel (sofern die gleiche std lib und flags beim Kompilieren verwendet werden). Die 14er Version ist schon ein paar Jahre älter als GCC 12, daher sind Unterschiede beim alignment oder padding oder generell Optimierungen des Assemblies durchaus zu erwarten.
Gestern, 10:08 (Dieser Beitrag wurde zuletzt bearbeitet: Gestern, 10:13 von siebenstreich.)
Vielen Dank für eure Erklärungen zu gcc und clang. Das BrightEyes-Projekt ist schon allein deswegen gut, weil es mein mitunter aus den 90ern stammendes technisches Wissen auf einen aktuellen Stand bringt.
(16.04.2025, 14:08)HenneNWH schrieb: Prinzipiell bin ich dafür beide Compiler in der Zukunft zu benutzen, da beide jeweils ihre Vorteile haben.
GCC unterstützt sehr viele Prozessorarchitekturen (x86, x86_64, ARM, MIPS, ...) und auch Windows (32- und 64-Bit).
Clang sicherlich auch, aber das findet sich.
Beide Compiler sind von der Benutzung sehr ähnlich und ja: Ich finde es erstmal cool mehrere Compiler benutzen zu können.
Ja, allein schon hinsichtich eines robusten Codes finde ich es vernünftig, wenn der Code von beiden Compilern verstanden wird.
(16.04.2025, 14:08)HenneNWH schrieb: Die GCC/Clang-Welt deckt die zukünftige Entwicklung ab.
Dort wird es in der Zukunft noch eine Aufspaltung geben.
Was genau soll denn aufgespalten werden?
Noch eine naive Frage:
Macht z.B. die Definition g_lets_quit in g105de_seg005.c nicht die binär-Äquivalenz kaputt (also wenn der Code mit BCC übersetzt wird)?
Ich habe das Programm unter Fedora 41 das erste Mal kompiliert und wollte es jetzt unter meiner Neuinstallation mit Fedora 42 erneut kompilieren. Es gab zwischen den beiden Versionen allerdings einen Umstieg von SDL2 auf SDL3 als "Haupt"-Version. SDL2 wird jetzt im Paket sdl2-compat gepflegt.
Soll BrightEyes weiterhin mit SDL2 erstellt werden oder ist ein Umstieg auf SDL3 geplant? Die neuen Features werden vermutlich eh nicht gebraucht ...
Gestern, 16:24 (Dieser Beitrag wurde zuletzt bearbeitet: Gestern, 16:27 von HenneNWH.)
(16.04.2025, 14:08)Siebenstreich schrieb:
(16.04.2025, 14:08)HenneNWH schrieb: Die GCC/Clang-Welt deckt die zukünftige Entwicklung ab.
Dort wird es in der Zukunft noch eine Aufspaltung geben.
Was genau soll denn aufgespalten werden?
Noch eine naive Frage:
Macht z.B. die Definition g_lets_quit in g105de_seg005.c nicht die binär-Äquivalenz kaputt (also wenn der Code mit BCC übersetzt wird)?
Ausgehend von dem aktuell angepeilten Status des Projekts habe ich folgenden Plan gefasst:
Die Version G105de ist die umfangreichste von den 5 verschiedenen Versionen des Charaktergenerators.
Mit dem Quellcode von dieser sollte es ein Leichtes sein, auch die anderen 4 Versionen zu rekonstruieren
und ähnlich wie jetzt mit dem BCC diese Binaries für DOS zu bauen.
Damit wäre dem historischen Teil des Charaktergenerators meiner Ansicht nach genüge getan.
=> Ab ins Archiv.
Anschließend sollte in einer kurzen Aufräumphase alle unbenötigten Codeteile und Variablen entfernt werden,
welche in genau einer finalen DOS-Version (mit ein paar Bugfixes, einfach zu implementierenden Features und Unterstützung für alle 3 DSAGEN.DAT-Files) enden sollte. Die kommt dann auch ins Archiv.
Dann fliegt der ganze nicht-portable Code (Assembler für direkte Hardwarezugeriffe unter DOS) raus und die SDL >= 2.0 sollte sauber implementiert werden.
Mit der am Charaktergenerator gesammelten Erfahrung, sollte das Ganze dann auch genauso für die Schicksalsklinge gemacht werden. Dafür ist noch etwas Arbeit notwendig, insbesondere Einarbeitung meinerseits in SDL >= 2.0.
Natürlich erst, wenn die Zeit dafür reif ist.
Die originale DOSBox benutzt die nicht mehr unterstützte Version 1.2.15, welche noch Unterstützung für Audio-CDs hatte.
Seit der Version 2.0 gibt es diese in SDL nicht mehr.
SDL3 zu benutzen ist von mir auch angedacht, das werde ich aber erst in Angriff nehmen, wenn meine Linux-Distribution SDL3 anbietet (vermutlich ab Juni 2025). Dann ist auch ein guter Zeitpunkt, den Code mal auf nem RaspberryPi zu testen. ;-)
@Obi-Wahn: Wenn du mal vorpreschen möchtest. Im Makefile, g105de_seg002.c und g105_seg005.c aus "SDL2" einfach "SDL3" machen. Das sind nur 3 Zeilen. Und dann mal probieren ob es kompiliert.
@Siebenstreich: Die Variable g_lets_quit ist nur in der modernen Welt vorhanden, funktioniert aber nicht so wie von mir erhofft. Die binär-Äquivalenz (schönes Wort) prüfe ich gerade mit einem eigens entwickelten Tool, welches ich etwas allgemeiner halten möchte und es sich erst noch durch die verschiedenen Versionen der GEN.EXE etablieren muss.
Aktuell zeigt es mir an, dass sich nur noch 230/52336 Bytes (< 0,5 %) im Code vom Original unterscheiden.
Die neue GEN.EXE läuft auch schon mit Sound, Maus, Tastatur in einer unmodifizierten DOSBox,
verliert jedoch bei der Auswahl eines Typus seine Ansprechbarkeit.
Gestern, 16:33 (Dieser Beitrag wurde zuletzt bearbeitet: Gestern, 16:33 von Obi-Wahn.)
Naja. Fast.
Code:
obi@fedora:~/BrightEyes Entwicklung/BrightEyes/src/gen$ make
clang -O0 -g -fno-asm -c g105de_seg001.c
clang -O0 -g -fno-asm -c g105de_seg002.c
g105de_seg002.c:52:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack]
52 | #include "hero.h"
| ^
./hero.h:15:9: note: previous '#pragma pack' directive that modifies alignment is here
15 | #pragma pack ( 1 )
| ^
g105de_seg002.c:2115:25: warning: if statement has empty body [-Wempty-body]
2115 | if (g_have_mouse == 0);
| ^
g105de_seg002.c:2115:25: note: put the semicolon on a separate line to silence this warning
g105de_seg002.c:3919:22: warning: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior [-Wvarargs]
3919 | va_start(arguments, options);
| ^
g105de_seg002.c:3850:50: note: parameter of type 'signed char' is declared here
3850 | signed short gui_radio(char *header, signed char options, ...)
| ^
g105de_seg002.c:7076:14: warning: passing 'unsigned char *' to parameter of type 'signed char *' converts between pointers to integer types with different sign [-Wpointer-sign]
7076 | set_palette(g_buffer_heads_dat + flen - 32 * 3, 0, 32);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./g105de_seg005.h:5:30: note: passing argument to parameter here
5 | void set_palette(signed char*, unsigned char, unsigned short);
| ^
4 warnings generated.
clang -O0 -g -fno-asm -c g105de_seg003.c
clang -O0 -g -fno-asm -c g105de_seg004.c
clang -O0 -g -fno-asm -c g105de_seg005.c
g105de_seg005.c:32:4: error: call to undeclared library function 'fprintf' with type 'int (FILE *restrict, const char *restrict, ...)' (aka 'int (struct _IO_FILE *restrict, const char *restrict, ...)'); ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
32 | fprintf(stderr, "Could not initialize SDL: %s\n", SDL_GetError());
| ^
g105de_seg005.c:32:4: note: include the header <stdio.h> or explicitly provide a declaration for 'fprintf'
g105de_seg005.c:32:12: error: use of undeclared identifier 'stderr'
32 | fprintf(stderr, "Could not initialize SDL: %s\n", SDL_GetError());
| ^
g105de_seg005.c:42:4: error: use of undeclared identifier 'SDL_WINDOW_SHOWN'
42 | SDL_WINDOW_SHOWN
| ^
g105de_seg005.c:46:12: error: use of undeclared identifier 'stderr'
46 | fprintf(stderr, "Could not create Window: %s\n", SDL_GetError());
| ^
g105de_seg005.c:54:4: error: use of undeclared identifier 'SDL_RENDERER_ACCELERATED'
54 | SDL_RENDERER_ACCELERATED
| ^
g105de_seg005.c:31:32: warning: result of comparison of constant 0 with expression of type 'bool' is always false [-Wtautological-constant-compare]
31 | if (SDL_Init(SDL_INIT_VIDEO) < 0) {
| ~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~
g105de_seg005.c:81:21: error: use of undeclared identifier 'SDL_QUIT_renamed_SDL_EVENT_QUIT'
81 | if (event.type == SDL_QUIT) {
| ^
/usr/include/SDL3/SDL_oldnames.h:791:18: note: expanded from macro 'SDL_QUIT'
791 | #define SDL_QUIT SDL_QUIT_renamed_SDL_EVENT_QUIT
| ^
g105de_seg005.c:97:2: error: call to undeclared function 'SDL_RenderCopy_renamed_SDL_RenderTexture'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
97 | SDL_RenderCopy(renderer, texture, NULL, NULL);
| ^
/usr/include/SDL3/SDL_oldnames.h:1150:24: note: expanded from macro 'SDL_RenderCopy'
1150 | #define SDL_RenderCopy SDL_RenderCopy_renamed_SDL_RenderTexture
| ^
1 warning and 7 errors generated.
make: *** [Makefile:23: g105de_seg005.o] Fehler 1
Ich hatte online gesehen, dass SDL3 da einen Header pflegt mit typedefs zu den verschiedenen Typen von SDL2 -> SDL3, evtl. fehlt aber noch ein SDL3/ im #include. Ich weiß nicht, wie der Includepfad konkret gesetzt wird.
Danke fürs probieren, Obi.
Die <stdio.h> hab ich gerade eingefügt, damit das später nicht nochmal passiert.
Somit ist SDL3 erstmal, wie schon von mir vermutet, Zukunftsmusik der leiseren Art.
News:
* Aktuell zeigt es mir an, dass sich nur noch 12/52336 Bytes (< 0,02 %) im Code vom Original unterscheiden.
Besser geht es meinerseits nicht mehr. Die restlichen 12 Byte im Audio-CD-Teil haben jedoch dieselbe Funktionalität.
MISSION COMPLETE
* Die DOS-Version, welche ich mit dem BCC3.1 erstelle funktioniert jetzt auch ohne Fehler in der DOSBox.
* Im Header der EXE ist noch eine Unstimmigkeit zu klären.
* Im Datensegment unterscheiden sich noch 3 Bytes vom Original.
Ich hatte online gesehen, dass SDL3 da einen Header pflegt mit typedefs zu den verschiedenen Typen von SDL2 -> SDL3, evtl. fehlt aber noch ein SDL3/ im #include. Ich weiß nicht, wie der Includepfad konkret gesetzt wird.
![[Bild: 30GtE8l.md.png]](https://iili.io/30GtE8l.md.png)
