Reverse Engineering der NLT II

[Obi-Wahn]

Ich habe gerade mal versucht, das Ganze mit clang zu kompilieren. Beim Erstellen mit cmake gibt es diese Fehlermeldung, vielleicht hilft das:

Code:

obi@obi CLANG64 ~/BrightEyes/src/gen
$ cmake --build build --parallel
[4/4] Linking C executable ngen_cc.exe.exe
FAILED: ngen_cc.exe.exe
C:\WINDOWS\system32\cmd.exe /C "cd . && C:\msys64\usr\bin\cc.exe   CMakeFiles/ngen.dir/cda_code.c.obj CMakeFiles/ngen.dir/ngen.c.obj CMakeFiles/ngen.dir/powerp20.c.obj CMakeFiles/ngen.dir/vgalib.c.obj CMakeFiles/ngen.dir/ail_stub.c.obj -o ngen_cc.exe.exe -Wl,--out-implib,libngen_cc.exe.dll.a -Wl,--major-image-version,0,--minor-image-version,0  C:/msys64/clang64/lib/libSDL2.dll.a  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
/usr/lib/gcc/x86_64-pc-msys/13.3.0/../../../../x86_64-pc-msys/bin/ld: /usr/lib/gcc/x86_64-pc-msys/13.3.0/../../../libmsys-2.0.a(libcmain.o): in function `main':
/d/S/B/src/msys2-runtime/winsup/cygwin/lib/libcmain.c:37:(.text.startup+0x7f): undefined reference to `WinMain'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

[HenneNWH]

Diese Sache kann sich mit dem nächsten Commit hoffentlich zum positiven wenden.
Die Kommandozeilenparameter funktionieren unter Windows etwas anders. ;-)

Hab noch eine Ungereimtheit mit dem Mauscursor mit MinGW behoben,
die unter Linux nicht Auftritt.

[Obi-Wahn]

Ja, es funktioniert wieder.

[HenneNWH]

@Obi-Wahn:
Sooo, hab gerade die WinMain()-Funktion so erweitert, dass sie unter Windows wie unter Linux und DOS funktioniert.
Das könnte die Lösung für den Clang unter Windows sein.
Feedback welcome! :-D

Die EXE ist bei mir auch gelegentlich/unregelmäßig unter Win abgestürzt, da die Kommandozeilenparameter nicht korrekt gelesen wurden.

Wenn die GEN.EXE aus der SCHICKM.EXE heraus gestartet wird wird das Intro übersprungen.
Beispiele:
"NGEN.EXE b a 0" => Fortgeschrittenenmodus (Advanced) ohne MIDI-Sound
"NGEN.EXE b n 1" => Anfängermodus (Novice) mit MIDI-Sound

[HenneNWH]

Hab nochmal das Rendering erweitert und die Texturupdates weiter reduziert.
Jetzt ist es so, wie ich es haben will.

Test: Im Fortgeschrittenenmodus einen Elf erstellen und nach Rechts oder Links durchscrollen.

Es kann sein, dass es unter bestimmten Bedingungen zu Abstürzen kommen kann (OS nennen und wie der Absturz zustande kam).

[siebenstreich]

Was ist jetzt eigentlich der empfohlene "normale" Compilier-Vorgang mit Linux?

Ein 'make' im Verzeichnis 'src/gen' funktioniert nicht mehr (gibt ja nur noch Makefile_old).

[HenneNWH]

Code:

make -f Makefile_old

CMake hat das bisherige Makefile überschrieben.

Probier mal unter Linux das Vergrößern des Fensters mit TAB.

In meiner Win-VM funktioniert es wie es soll, nur unter Linux nicht mehr.

[siebenstreich]

Danke.

Nach einem ersten <TAB> passiert gar nichts. Beim zweiten Mal wird das Fenster einen Sekundenbruchteil lang größer und dann stürzt das Programm ab mit der Terminal-Ausgabe

Code:

DSAGEN.DAT DE_CD
RATIO = 4 W_WIDTH = 1280 W_HEIGHT = 800
Segmentation fault (core dumped)

Aufgefallen ist mir auch, dass die Bildschirmausgabe direkt nach dem Programmstart bereits deutlich größer ist als die DOS-Auflösung 320 x 200, die vor einiger Zeit ja zuerst erschien. Ich tippe auf anfänglich 960 x 600, also eine Vergrößerung auf 300%. <TAB> will anscheinend auf 400% umschalten.

[HenneNWH]

Genau so ist es! In meiner Win-VM klappt das jetzt auch, aber unter Linux (x86/ARM) nicht.
Probier mal:

Code:

gdb ./ngen_gcc
run
<TAB drücken bis es abstürzt>
bt

Die Ausgabe von bt ist für mich interessant.

[siebenstreich]

Code:

(gdb) bt
#0  0x00007ffff5e49802 in ?? () from /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#1  0x00007ffff5fcf7e3 in ?? () from /lib/x86_64-linux-gnu/libGLX.so.0
#2  0x00007ffff5fd1281 in ?? () from /lib/x86_64-linux-gnu/libGLX.so.0
#3  0x00007ffff7ed73f3 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#4  0x00007ffff7ea9bea in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#5  0x00007ffff7e3cdba in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#6  0x00007ffff7e3d8f6 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#7  0x00007ffff7e35e69 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#8  0x000055555556618e in sdl_update_rect_window (x_in=0, y_in=0, width_in=320, height_in=200) at vgalib.c:242
#9  0x000055555555c59b in gen_timer_vga (interval=100, param=0x0) at ngen.c:4224
#10 0x00007ffff7e674f4 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#11 0x00007ffff7e67085 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#12 0x00007ffff7f08b79 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#13 0x00007ffff7c6d1f5 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#14 0x00007ffff7ced89c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

[HenneNWH]

Okay, das hab ich bei mir auch. Gibst du mir mal:

Code:

lspci | grep VGA

[Obi-Wahn]

Unter Windows funktioniert bei mir im Moment alles. Das Programm startet sogar jetzt immer, das Problem scheint also behoben zu sein.

[siebenstreich]

Code:

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)

[HenneNWH]

Hab gerade auf SoftwareRendering umgestellt. Jetzt funktioniert es wie es soll unter x86-Linux.
Nur auf dem Raspi2 bleibt das Fenster leer.

@Siebenstreich: Hm, Intel-Grafik. Der Fehler tritt beim Rendern der Textur auf und liegt nicht wirklich in meinem Verantwortungsbereich. Probier mal die aktuelle Version.

[siebenstreich]

@Siebenstreich: Hm, Intel-Grafik.

Ja, und zwar ganz bewusst. Mit Nvidia gibt es immer wieder Ärger mit Linux. Intel dagegen produziert selber open source Treiber, und bisher gab es -- und zwar ausnahmslos -- noch nie Probleme.

Der Fehler tritt beim Rendern der Textur auf und liegt nicht wirklich in meinem Verantwortungsbereich. Probier mal die aktuelle Version.

Der segfault ist weg, jetzt geht es.

Der Mauszeiger läuft jetzt perfekt flüssig -- wenn ich es richtig verstehe, wird das ja jetzt von SDL übernommen.
Aber die Radio-Buttons hinken hinterher. Gut zu beobachten bei größeren Auswahlmenüs, wenn ich den Mauszeiger schnell von oben nach unten bewege, oder andersrum.

[HenneNWH]

Deswegen benutze ich auch Intel.

Der Mauszeiger ist jetzt unabhängig vom Framebuffer und der Fensterinhalt wird alle 50 ms / 20 FPS periodisch aktualisiert, wenn sich im Framebuffer etwas ändert.
Daher die von dir bemerkten Verzögerungen.

Wenn du das Programm beendest, kannst du folgende Zeile sehen:

Code:

sdl_update_rect_window() calls = 53101 updates = 478

Der calls-Wert ist, wie oft der Timer versucht hat den Fensterinhalt neu zu zeichnen.
Der updates-Wert ist, wie oft es wirklich nötig war.

[Crystal]

Mit Nvidia gibt es immer wieder Ärger mit Linux. Intel dagegen produziert selber open source Treiber, und bisher gab es -- und zwar ausnahmslos -- noch nie Probleme.

*notiert sich das, um seinen geplanten GamingLinux-PC besser mit einer Radeon auszustatten, statt einer Geforce...*

Danke für diese wertvolle Info aus dem Nähkästchen!

[siebenstreich]

Mit Nvidia gibt es immer wieder Ärger mit Linux. Intel dagegen produziert selber open source Treiber, und bisher gab es -- und zwar ausnahmslos -- noch nie Probleme.

*notiert sich das, um seinen geplanten GamingLinux-PC besser mit einer Radeon auszustatten, statt einer Geforce...*

Danke für diese wertvolle Info aus dem Nähkästchen! 

Es ehrt mich ja, wenn ich dir helfen konnte!

Ich bin mir nur nicht sicher, ob AMD so viel besser ist wie Nvidia. Die etwas schizophrene Ausgangslage ist meines Wissens jedenfalls die gleiche: Der Hersteller stellt einen proprietären closed source Treiber zur Verfügung. Parallel dazu wird von irgendwelchen Leuten ein open source Treiber geschrieben. Man muss sich entscheiden, welchen der beiden man verwenden will. Beide Optionen haben ihren Nachteil: Ersterer ist ein Fremdbaustein in deiner Linux-Distribution und spielt mit dieser u.U. nicht optimal zusammen (Beispiel aus eigener Erfahrung: schwarzer Monitor nach Systemupdate), zweiterer unterstützt evtl. nicht alle Hardware-Features und schöpft die Resourcen nicht optimal aus und hat im schechteren Fall auch irgendwelche blöden Bugs, weil die Hardware-Spezifikation nicht in allen Randfällen exakt umgesetzt wurde (Beispiel aus eigener Erfahrung: Nach dem Hot-Pluggen eines zusätzlichen Monitors ist die Grafikausgabe plötzlich wild durcheinandergewürfelt).

Bei Intel-Grafik mit offiziellem open source Treiber ist das anders. Aber für ein Gaming-Grafik-Monster ist Intel eher nichts.

[Obi-Wahn]

Im Moment ist AMD wohl etwas besser unterstützt, da Valve in seinem Steam Deck eine AMD-Grafikkarte verwendet, dadurch werden die OpenSource-Treiber für AMD etwas besser gepflegt.
https://www.pcgamer.com/valve-continues-...a-project/

[Crystal]

Danke für die zusätzlichen Infos.