Closed potens1 closed 2 years ago
mefistotelis
commented
2 years ago I don't have a proper logging yet..
logging in bflog.h (LIBLOG macro) needs to be changed to just use printf. Then you can compile the binary with additional logging by defining "__DEBUG" in c pre-processor flags, ie:
CPPFLAGS="-DDEBUG -D__DEBUG" CFLAGS="-m32 -g -O0" CXXFLAGS="-m32 -g -O0" CCASFLAGS="-g" LDFLAGS="-m32 -g -O0" ../configureThis way you should get an error message before exit(1) is called.
potens1
commented
2 years ago I did not saw there was a debug option in configure, so I run it again with the debug enabled (full), here is the output of it
I don't know if the problem is related to a missing sound files, but here is the tree of installed file
I can also provide the output of strace but right now, what I see (at the very end of it), is an error trying to load an image, right after starting setup_screen_mode. (No clue if that could be the problem)
strace -e trace=open,openat,close,read,write,connect,accept swars
...
write(1, "setup_screen_mode 1\n", 20setup_screen_mode 1
) = 20
openat(AT_FDCWD, "swars_icon.png", O_RDONLY) = -1 ENOENT (No such file or directory)
write(12, "\1\0\0\0\0\0\0\0", 8) = 8
close(17) = 0
write(14, "\1\0\0\0\0\0\0\0", 8) = 8
close(14) = 0
close(15) = 0
close(13) = 0
close(16) = 0
close(12) = 0
close(10) = 0
close(11) = 0
close(9) = 0
+++ exited with 1 +++
**EDIT
Putting a swars_icon.png file in the current(!) directory remove the error, but it does not help
write(1, "setup_screen_mode 1\n", 20setup_screen_mode 1) = 20
openat(AT_FDCWD, "swars_icon.png", O_RDONLY) = 45
read(45, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\1\0\0\0\1\0\10\6\0\0\0\\r\250"..., 4096) = 4096
close(45) = 0
write(12, "\1\0\0\0\0\0\0\0", 8) = 8
close(17) = 0
write(14, "\1\0\0\0\0\0\0\0", 8) = 8
close(14) = 0
close(15) = 0
close(13) = 0
close(16) = 0
close(12) = 0
close(10) = 0
close(11) = 0
close(9) = 0
+++ exited with 1 +++
I don't have a proper logging yet..
logging in bflog.h (LIBLOG macro) needs to be changed to just use printf. Then you can compile the binary with additional logging by defining "__DEBUG" in c pre-processor flags, ie:
CPPFLAGS="-DDEBUG -D__DEBUG" CFLAGS="-m32 -g -O0" CXXFLAGS="-m32 -g -O0" CCASFLAGS="-g" LDFLAGS="-m32 -g -O0" ../configureThis way you should get an error message before exit(1) is called.
Sorry I did not saw your message while redacting mine, I will have a try, Thank you !
potens1
commented
2 years ago I tried to modify the logging but without success, I replaced LbSyncLog by printf on this line
https://github.com/mefistotelis/swars/blob/master/bflibrary/include/bflog.h#L53
And after that that added includes (otherwise I had compilation errors)
#include <stdio.h>
#include <errno.h>But now I can not compile because I've some assembler errors:
Sorry if my tries sounds silly to you, but not knowing C/C++ dev is not helping too much
mefistotelis
commented
2 years ago Well, replacing by 'printf' is clearly not enough. Though I can't see what the issue is.
I just finished what I wanted to rewrite, so will check out the logs support now. Debug tools are important, especially because we have no tests for the project.
potens1
commented
2 years ago That's great... and I'm a bit sorry for you since I think it's not the "funniest" part to improve. But indeed, being able to get accurate report of what's going on will help later.
PS: I reformatted to output of the assembly errors but I don't think it will help further.
mefistotelis
commented
2 years ago The logging is now working. Log file is created in the same directory where binary is - you need to make sure there are write permissions.
Also, it seem likely that the issue you have is due to mode 640x400 being used - try hard-coding height to 480 as a workaround:
diff --git a/bflibrary/src/x86-win-sdl/sscreen.c b/bflibrary/src/x86-win-sdl/sscreen.c
index 80deef3..178ff9e 100644
--- a/bflibrary/src/x86-win-sdl/sscreen.c
+++ b/bflibrary/src/x86-win-sdl/sscreen.c
@@ -233,9 +233,9 @@ TbResult LbScreenSetupAnyMode(TbScreenMode mode, TbScreenCoord width,
sdlFlags |= SDL_FULLSCREEN;
}
// Set SDL video mode (also creates window).
- lbScreenSurface = lbDrawSurface = SDL_SetVideoMode(mdWidth, mdHeight,
+ lbScreenSurface = lbDrawSurface = SDL_SetVideoMode(mdWidth, 480,
mdinfo->BitsPerPixel, sdlFlags);
if (lbScreenSurface == NULL) {
LOGERR("failed to initialize mode %d: %s", (int)mode, SDL_GetError());Hi !
So, I compiled the latest commit (with CPPFLAGS="-DDEBUG -D__DEBUG" CFLAGS="-m32" CXXFLAGS="-m32" LDFLAGS="-m32" PKG_CONFIG_PATH="/usr/lib32/pkgconfig" ../configure --enable-debug=full), here is the full output of the error.log file:
I tried with and without the 400->480 patch but it does not change anything, both failed with the same lines:
Sync: Bflib: LbScreenSetupAnyMode: mode 640x400x8 setup succeeded
Debug: Bflib: LbPaletteSet: starting
Error: Bflib: LbPaletteSet: SetPalette to ScreenSurface failed: Surface doesn't have a colorkey
Error: Bflib: LbPaletteSet: SetPalette to DrawSurface failed: Surface doesn't have a colorkey
Error: Bflib: LbScreenSetupAnyMode: palette setting failed
Warning: Bflib: LbScreenReset: screen got reset while locked
Debug: Bflib: LbScreenUnlock: starting
Sync: Bflib: LbScreenReset: screen reset finishedThe diff between the two logs are:
219c219
< Debug: SWars: setup_host: &setup_host() = 0x566620a3
---
> Debug: SWars: setup_host: &setup_host() = 0x566470a3
222c222
< Sync: Bflib: LbScreenSetupAnyMode: mode 640x400x8 setup succeeded
---
> Sync: Bflib: LbScreenSetupAnyMode: mode 640x480x8 setup succeeded
259c259
< Sync: Bflib: LbScreenSetupAnyMode: mode 640x400x8 setup succeeded
---
> Sync: Bflib: LbScreenSetupAnyMode: mode 640x480x8 setup succeeded
Also, about the error.log file, it is not created where the binary is, but in the current directory (from where I run the swars command, which is waaaay better :-) ), I guess it tries to create it next to binary in case of gui double click or shortcut.
I don't know if you will be able to see anything wrong in those logs, but, if you need me to try other stuffs, please let me know.
mefistotelis
commented
2 years ago it is not created where the binary is, but in the current directory (from where I run the swars command, which is waaaay better :-)
Right, I made some assumptions there. The logs should be really placed in the same base folder where saved games are; so I will modify that later. Original SW Port had the folders sorted correctly, but in a hacky way.
The issue seem to be with 8-bit surfaces, not with 640x400. But why SDL created non-colourkeyed (non-8bit) surface on your machine, I'm not really sure. Also interesting is that both surfaces - the one for blitting on screen and the one for drawing things within the app - seem to be affected.
SDL Surfaces can actually have two colour spaces, separate for input and output. I wonder if both sides have failed...
What you could do is ignore the error, and check how the displayed image will look. ie remove the ret setting lines:
diff --git a/bflibrary/src/x86-win-sdl/spalette.c b/bflibrary/src/x86-win-sdl/spalette.c
index c002277..fc35f1a 100644
--- a/bflibrary/src/x86-win-sdl/spalette.c
+++ b/bflibrary/src/x86-win-sdl/spalette.c
@@ -83,7 +83,6 @@ TbResult LbPaletteSet(const ubyte *palette)
if (SDL_SetColors(to_SDLSurf(lbScreenSurface),
lbPaletteColors, 0, PALETTE_8b_COLORS) != 1) {
LOGERR("SetPalette to ScreenSurface failed: %s", SDL_GetError());
- ret = Lb_FAIL;
}
}
lbDisplay.Palette = lbPalette;
@@ -92,6 +91,5 @@ TbResult LbPaletteSet(const ubyte *palette)
if (SDL_SetColors(to_SDLSurf(lbDrawSurface),
lbPaletteColors, 0, PALETTE_8b_COLORS) != 1) {
LOGERR("SetPalette to DrawSurface failed: %s", SDL_GetError());
- ret = Lb_FAIL;
}
}Nope, no luck, this time the window initialize and then... it core dumps...
Message: Process 1568997 (swars) of user 1000 dumped core.
Module linux-gate.so.1 with build-id 2d52deb63570759335eac64723e540580341add9
Module libicudata.so.71 with build-id 0ae07e9b05ad55d35c9ca4e270ac7473f6892129
Module libicuuc.so.71 with build-id d36d6c3cb0f1cbddbb814803e9c0c061f08d27db
Module libxml2.so.2 with build-id 4b5fc1cf9ca37703239ab65936f901747a6f794d
Module libncursesw.so.6 with build-id 4ce458d6a84714b606d955dcde45e0f464022f93
Module libdl.so.2 with build-id b813519c6d1aaed0b146662db17b1ce022023be7
Module libffi.so.8 with build-id 2bcd779cf0cb1d8583813bcf37976575a6078f4b
Module libvulkan.so.1 with build-id 2b37d11f4b0a5d2078822202207fa0eceb51e159
Module libdrm_nouveau.so.2 with build-id 3b4f0518661aa11bd7ef59ca6554c200194c4f7a
Module libdrm_amdgpu.so.1 with build-id 15953136d199c68d40f42eb6294910c46c8d89e2
Module libelf.so.1 with build-id 6cb26ac4b2ccc738b5e544534a8d1753a3cb6896
Module libdrm_radeon.so.1 with build-id 73553dfbe982683cd4520415f06dd61167f4939f
Module libsensors.so.5 with build-id c941cd0d5121a8707c7c598773d91e1bc545da06
Module libLLVM-13.so with build-id ad2ec3a3a29bb4f476c2cc6125e7039ee43fb3a8
Module radeonsi_dri.so with build-id aa2cf25c0fc212117b49ec68927cd0bbd955fde7
Module libxcb-xfixes.so.0 with build-id 4429db0a6ff61aa8a660a5fc2c4feed56726880d
Module libxshmfence.so.1 with build-id 380d9258321f7103b18e0f3ec6db6d1608906ae1
Module libxcb-sync.so.1 with build-id 20e3e329957f59f35c8e8109f522c4e879d110ae
Module libxcb-present.so.0 with build-id 6c7c43f22ecafb03587fb389eb02e7042764f87e
Module libxcb-dri3.so.0 with build-id e7595e557d4b7e8203b2399cd075c5cf03273fb9
Module libexpat.so.1 with build-id 04afefa75a726ecd0d440f6ba5c8be90d2dc79d0
Module libxcb-shm.so.0 with build-id c478bab45d8cef998d3d744755528b23dd9c445b
Module libxcb-dri2.so.0 with build-id cac0f9549552dd9df8bbe5001b71240f57c46b45
Module libX11-xcb.so.1 with build-id 13b07177140ab3e8fa02ff00534aa330cb686599
Module libxcb-glx.so.0 with build-id 817fea1247bcd2ed52775646ce5e5ad22768f3cf
Module libdrm.so.2 with build-id 40a5e0f2b0bbddb1ca3c2dc9f5592bc9921ebc8a
Module libglapi.so.0 with build-id bfd52f56c4b1e41c8b7d1eed2c4cb99cc734d63e
Module libGLX_mesa.so.0 with build-id c725ea71991b29627a39dbf1587d1e00cad82c39
Module libGLX.so.0 with build-id 92c5b648663ea46e00344148f13d0e4413ece785
Module libGLdispatch.so.0 with build-id deb094bd23d7b05cfe2715882db8caadfdc7a2ab
Module libGL.so.1 with build-id 7d4cc9852ee6fd480756b2bbedc10c20167ed71a
Module libspa-audioconvert.so with build-id b1d6a27886c6b9e9ab5e163e688b46d6144ae04e
Module libpipewire-module-session-manager.so with build-id b29fad333292be4d32af76847b8e033ffb62b2e5
Module libpipewire-module-metadata.so with build-id d42c487ecdba8f711a12e3a2ccfd762af3f368fd
Module libpipewire-module-adapter.so with build-id dc0b0907a96efe0479355daa2173fcaca6a107b9
Module libpipewire-module-client-device.so with build-id 9701e0464257cd1b32fc635efc33ce4642531a5b
Module libpipewire-module-client-node.so with build-id 71d5fb3816f7ed642e4b8d93394165ca7df55d17
Module libpipewire-module-protocol-native.so with build-id e2cc47dc4cc1e547a1c978783c5f8e3377d3b6c4
Module libpipewire-module-rt.so with build-id c9a07c45e110f4cbf249a93f0ee7a207271ea763
Module libspa-dbus.so with build-id 71ccf3fffc9665eb9946fa94038addf4f6852f92
Module libspa-journal.so with build-id 6a14f20d700bd8f53dac1724fd313116c361b4f1
Module libspa-support.so with build-id b499963b77e01c084852724b4f167021f3fed8d7
Module libpipewire-0.3.so.0 with build-id 515c4b8626cf990756ccb69af1b7dcf91533658c
Module libudev.so.1 with build-id 2b6c50ee94ef710e85bf0ab7228978cdfa6bd7a5
Module libXxf86vm.so.1 with build-id f1169af23caebbe5cb024fc832230503aad832ae
Module libXss.so.1 with build-id 6bbc2db6c0e1f095aaeca37c89dd3dabba9e3319
Module libXrandr.so.2 with build-id 3295bdef0e30b5fd9da27c99bf5d6fd1c14551aa
Module libXi.so.6 with build-id ae19d465b15227ab5e08de671bc16532450e384f
Module libXinerama.so.1 with build-id ac215c8573b00954e0257efdae64546bed54c652
Module libXfixes.so.3 with build-id d04e7cb05d21774a5403cdea89e8023c4e2dbd78
Module libXrender.so.1 with build-id 8d67a935a15bfc2f18084d0a493880189f806583
Module libXcursor.so.1 with build-id ae3c97e2f155847562267b1707c75fb9884a2350
Module libXext.so.6 with build-id 51364f7aaaad05288c6403f4cd82dc20bd1c2975
Module libXdmcp.so.6 with build-id d6d2063b49e333551fb395c4699ce68908342ca2
Module libXau.so.6 with build-id 37885701fd17e23735180bb9afefba9fd93eafce
Module libxcb.so.1 with build-id 4187de5462ea94547789043cd82a227550b36d73
Module libX11.so.6 with build-id 2fce7e6a3cff4a4a6268ee72a65b54353dc534af
Module libpthread.so.0 with build-id 5dbb72a31482c3975409bb7fa47fd888a82ce685
Module libgpg-error.so.0 with build-id 6ecfdea2e1871208214eee924c1a309656c8913d
Module libzstd.so.1 with build-id 442775044f6163f8c14265443311007e63d5d3e0
Module liblzma.so.5 with build-id f08d32c158738d5bcd5dfab2cd522a4e940ea692
Module libgcrypt.so.20 with build-id 8ece9a72febf606ba62e6071765e3cc597a6edf0
Module libcap.so.2 with build-id d397a803349e73a6f637ed31c890a3f56d9789ac
Module libsystemd.so.0 with build-id efcfe8562568888fb068feb8d5fbb99286dba141
Module libdbus-1.so.3 with build-id 9a7836e28749a17ddf276a7e8bdfbfced6021807
Module libSDL2-2.0.so.0 with build-id f75c4c420a84b979b05945cf77f191261ecd31a0
Module libogg.so.0 with build-id e798778c0bb9b885eb0ebad5d581ba596603a22e
Module libvorbis.so.0 with build-id c5630c7d41a701a37e59bca6101fbcc397b4e126
Module ld-linux.so.2 with build-id fedfde2c74e726f8e8765cb79c4f7c184aad3df7
Module libc.so.6 with build-id e5708a71bf73aa086629f1404cf3e314eb82766f
Module libgcc_s.so.1 with build-id c595e9170ddd2d74814f136f8bb17df6034adbe1
Module libm.so.6 with build-id 46402c9a5dee53f66886a2ad95ac46763fdee0ca
Module libstdc++.so.6 with build-id 1826c72b6968d69e5c976e46d41c87cae23723c8
Module libz.so.1 with build-id eef8f76603fae7a2876659fe737c1aebadb8b90b
Module libpng16.so.16 with build-id 202b8ec7361ff29d13abdcbeb691a9273494d2d9
Module libvorbisfile.so.3 with build-id 4e73b2b22779d9987f3a258577392848fd90616b
Module libopenal.so.1 with build-id 33fea610542380d799e9a59f17840e59db7a26b1
Module libSDL-1.2.so.0 with build-id eb342c70a5d0d9f29f54313937a833c133bc90bc
Module swars with build-id af6437fa2c1e054e11f44d305e5d560168aef5a5
Stack trace of thread 1568997:
#0 0x00000000f2c6b181 __glDispatchCheckMultithreaded (libGLdispatch.so.0 + 0x18181)
#1 0x00000000f2c43819 glXSwapBuffers (libGLX.so.0 + 0x2b819)
#2 0x00000000f7654c69 n/a (libSDL2-2.0.so.0 + 0xf8c69)
#3 0x00000000f7628fae n/a (libSDL2-2.0.so.0 + 0xccfae)
#4 0x00000000f7ea002d n/a (libSDL-1.2.so.0 + 0x602d)
#5 0x00000000f7ea7fd6 SDL_UpdateRects (libSDL-1.2.so.0 + 0xdfd6)
#6 0x00000000f7ea815c SDL_UpdateRect (libSDL-1.2.so.0 + 0xe15c)
#7 0x00000000f7ea8bf2 SDL_SetPalette (libSDL-1.2.so.0 + 0xebf2)
#8 0x00000000f7ea8c29 SDL_SetColors (libSDL-1.2.so.0 + 0xec29)
#9 0x0000000056799cbe LbPaletteSet (swars + 0x169cbe)
#10 0x0000000056785b1c ac_LbPaletteSet (swars + 0x155b1c)
ELF object binary architecture: Intel 80386
That doesn't seem to be application side issue.
Are other GL applications working on that machine? ie. the simplest, glxgears?
You can try various drivers which SDL supports: https://wiki.libsdl.org/FAQUsingSDL
Another curious thing is that your sdl-1.2 seem to be a wrapper around sdl-2. I'm not sure how normal this is. This also means I'm not sure whether you should try the drivers for 1.2 or for 2.0. You should try all.
potens1
commented
2 years ago Yes... and no.
I was thinking everything was working on my machine since I use it a big part of the time to play on it (under Linux) from dosbox games up to RedDead 2, Doom Eternal and so on...
So, I tried to remove sdl (1.2) from my machine, and discovered only openxcom is using it on my machine.
Trying to run it results in:
[10-06-2022_22-39-07] [FATAL] OpenXcom has crashed: Use SDL_GL_SwapBuffers() on OpenGL surfacesSo, yes, there is a problem here with opengl and sdl (1.2).
It appears that arch is using sdl12-compat which is a wrapper around sdl1.2 to make it compatible with sdl2 (because sdl2 was released in 2013, and sdl1.2 is not compatbile at all with wayland, the replacement of Xorg), and it is happening on other projects (https://github.com/libsdl-org/sdl12-compat/issues/185)
So, sorry for the noise... I will see if I can downgrade/replace sdl12_compat with sdl12 (without breaking the distribution) and, in case of success, I will let you know.
Thank you for the time you spent on this (and also for the syndicate wars walkthrough ;-) )
mefistotelis
commented
2 years ago In the stack trace, SDL2 calls libGLX.so. So if it was supposed to use Wayland, that's not correct. SDL2 tries to use GLX, which basically is the good old X11 API.
Try:
SDL_VIDEODRIVER=wayland ./swarsNo no, sorry I was not clear, I'm running it under X11/Xorg (I tried other drivers without success).
That said, I just tried it under wayland, with SDL_VIDEODRIVER=wayland, but with the same result (coredump).
I think this should be resolved at sdl12-compat level (since, on my case 100% of the ... two... packages that are using it are crashing)
mefistotelis
commented
2 years ago ok. Solved from the port size.
Hi,
First of all, thank you so much trying (continuing to try) to bring this to modern era !
I just compiled it without (at least to my knowledge) errors, but it does not work.
When I run it, I see a window initializing, but it quits as soon as it starts.
I don't see any error message (nor in log, neither on console), but the return code is "1"
Console output
``` ~/$ time swars; echo $? Syndicate Wars Port 0.3.3.0 The original by Bullfrog Ported by UnavowedI tried to find some working commit, without success for the time being (tried a dozen), and I'm not able to compile the latest release.