SDLPoP v1.18 pre-release

Open-source port of PoP that runs natively on Windows, Linux, etc.
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

SDLPoP v1.18 pre-release

Post by David »

It's been about a year since the v1.17 release, so I think it's time for the next.

I have attached a Release Candidate build to this post.

Pending questions before the final release:
* Which version of SDL should I bundle? SDL 2.0.6 and 2.0.7 have bugs, so does this mean that I should use SDL 2.0.5?
* Can I merge "fuzzy pixels", or should I leave it out for now?
https://github.com/NagyD/SDLPoP/issues/ ... -362821873
Attachments
SDLPoP_v1.18RC.zip
(4.76 MiB) Downloaded 104 times
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Re: SDLPoP v1.18 pre-release

Post by Norbert »

David wrote: February 3rd, 2018, 6:18 pm* Which version of SDL should I bundle?
A related question: if I include a 64-bit Linux binary at popot.org, can I dynamically link with SDL 2.0.4 or does SDLPoP 1.18 require 2.0.5+? And, if I cannot dynamically link, should I use `sdl2-config --static-libs --cflags` after installing SDL 2.0.5+ somewhere alongside the 2.0.4 from the distro repo? I do think including a Linux executable is user-friendly. Without it, it's like shipping without prince.exe and expecting end-users to compile+link. I think - but I'm not sure - that it'll search for libSDL2.so on the user's system, which is a symbolic link to the installed SDL lib, which may be anything from 2.0.4 to 2.0.7 or even more recent.
Falcury
Calif
Calif
Posts: 565
Joined: June 25th, 2009, 10:01 pm

Re: SDLPoP v1.18 pre-release

Post by Falcury »

David wrote: February 3rd, 2018, 6:18 pm * Which version of SDL should I bundle? SDL 2.0.6 and 2.0.7 have bugs, so does this mean that I should use SDL 2.0.5?
I built the attached SDL2.dll today from the latest version from here:
https://github.com/SDL-mirror/SDL

It includes a fix for the issue discussed here:
https://github.com/NagyD/SDLPoP/issues/ ... -357447802

Another question:
Do you want to include the in-game menu feature in this release?
It's basically finished, and I fixed the remaining bugs (I think) and the high CPU load.
I could squash it down into a single commit to make merging easier, if you wish.

And the same question for this pull request.
Attachments
SDL2_scaling_bug_fixed.zip
(289.85 KiB) Downloaded 87 times
Falcury
Calif
Calif
Posts: 565
Joined: June 25th, 2009, 10:01 pm

Re: SDLPoP v1.18 pre-release

Post by Falcury »

Norbert wrote: February 3rd, 2018, 7:40 pm if I include a 64-bit Linux binary at popot.org, can I dynamically link with SDL 2.0.4 or does SDLPoP 1.18 require 2.0.5+?
Probably unlikely if it's been compiled with a newer version. On Windows at least, I get the following message if I try this:
The procedure entry point SDL_RenderSetIntegerScale could not be located in the dynamic link library
Norbert wrote: February 3rd, 2018, 7:40 pmAnd, if I cannot dynamically link, should I use `sdl2-config --static-libs --cflags` after installing SDL 2.0.5+ somewhere alongside the 2.0.4 from the distro repo? I do think including a Linux executable is user-friendly. Without it, it's like shipping without prince.exe and expecting end-users to compile+link. I think - but I'm not sure - that it'll search for libSDL2.so on the user's system, which is a symbolic link to the installed SDL lib, which may be anything from 2.0.4 to 2.0.7 or even more recent.
Sounds like a good idea. How large does the executable then get? Does the linker only link SDL2 statically, or all other libraries as well?
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: SDLPoP v1.18 pre-release

Post by David »

Falcury wrote: February 3rd, 2018, 11:31 pm I built the attached SDL2.dll today from the latest version from here:
https://github.com/SDL-mirror/SDL

It includes a fix for the issue discussed here:
https://github.com/NagyD/SDLPoP/issues/ ... -357447802
Thank you!

Norbert wrote: February 3rd, 2018, 7:40 pm I think - but I'm not sure - that it'll search for libSDL2.so on the user's system, which is a symbolic link to the installed SDL lib, which may be anything from 2.0.4 to 2.0.7 or even more recent.
In the Linux executable here, SDL2 is referenced as "libSDL2-2.0.so.0", i.e. the last part of the version number is not in the filename.
So you're probably right.
(I haven't actually checked how SDL is installed on a Linux system, but I might do so later.)

Falcury wrote: February 4th, 2018, 12:28 am
Norbert wrote: February 3rd, 2018, 7:40 pm if I include a 64-bit Linux binary at popot.org, can I dynamically link with SDL 2.0.4 or does SDLPoP 1.18 require 2.0.5+?
Probably unlikely if it's been compiled with a newer version. On Windows at least, I get the following message if I try this:
The procedure entry point SDL_RenderSetIntegerScale could not be located in the dynamic link library
I'm not sure how you mean "I dynamically link with SDL 2.0.4".
If you meant compiling with SDL 2.0.4, then the executable should work with newer versions of SDL as well, only the integer scaling will be disabled.
However, if you mean compiling with SDL 2.0.5, then running with SDL 2.0.4, then it won't work, because the executable will try to call SDL_RenderSetIntegerScale, which is not in SDL 2.0.4.
On Windows it results in the message that Falcury posted; and I think I have seen a similar message on Linux.

We could use the workaround that I outlined here: https://github.com/NagyD/SDLPoP/issues/ ... -351948623
(Get the address of SDL_RenderSetIntegerScale using dlopen+dlsym or LoadLibrary+GetProcAddress.)
That way SDLPoP would use SDL_RenderSetIntegerScale if it's present, and skip it without errors otherwise.
Is this a good idea?
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Re: SDLPoP v1.18 pre-release

Post by Norbert »

Okay. So, seeing many Linux end-users, including all using Mint, still have SDL 2.0.4, I'd have to either compile with that version or I'd have to statically link against a newer version and include/ship the Linux SDL libraries in the package. A potential problem with the latter is that any security issues with SDL that are discovered later would remain present in SDLPoP even if the end-user upgrades their distro version of SDL.

I'm actually in the exact same situation with the PoP package I'm working on myself. That's basically done, but will I now wait until May/June or will I include static libs...

Seeing SDLPoP will be released first, the below spoiler contains what might work:
(This is literally untested, because I only tested this with my own package, and there it failed.)
Spoiler: show
Some notes:
- This is untested and probably won't work at all.
- The prefix would need to be a dir inside the SDLPoP dir?
- Clearly something's going wrong with libpng16.

1. Install a recent SDL2 alongside the system version.
SDL2$ ./configure --prefix=/home/norbert/mysdl
SDL2$ make
SDL2$ sudo make install
2. Same, for libpng
libpng$ ./configure --prefix=/home/norbert/mysdl
libpng$ make
libpng$ sudo make install
3. Same, for SDL2_image.
SDL2_image$ LIBPNG_CFLAGS="-I/home/norbert/mysdl/include/libpng16" LIBPNG_LIBS="-L/home/norbert/mysdl/lib/ -lpng16" ./configure --with-sdl-prefix=/home/norbert/mysdl/ --prefix=/home/norbert/mysdl
SDL2_image$ make
SDL2_image$ sudo make install
4. In the Makefile replace
sdl2-config --libs
with
/home/norbert/mysdl/bin/sdl2-config --static-libs `/home/norbert/mysdl/bin/libpng-config --cflags --static-libs`
5. $ sudo ldconfig
6. Remake SDLPoP and run it using:
$ LD_PRELOAD="/home/norbert/mysdl/lib/libpng16.so.16" LD_LIBRARY_DIR=~/mysdl ./prince
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: SDLPoP v1.18 pre-release

Post by David »

David wrote: February 4th, 2018, 12:27 pm (I haven't actually checked how SDL is installed on a Linux system, but I might do so later.)
This is how the distro's official SDL is installed: (SDL 2.0.4)

Code: Select all

$ ls /usr/lib/i386-linux-gnu/libSDL2-*so* -al
lrwxrwxrwx 1 root root      20 márc  10  2016 /usr/lib/i386-linux-gnu/libSDL2-2.0.so -> libSDL2-2.0.so.0.4.0
lrwxrwxrwx 1 root root      20 márc  10  2016 /usr/lib/i386-linux-gnu/libSDL2-2.0.so.0 -> libSDL2-2.0.so.0.4.0
-rw-r--r-- 1 root root 1210748 márc  10  2016 /usr/lib/i386-linux-gnu/libSDL2-2.0.so.0.4.0
This is how the hand-compiled SDL is installed: (SDL 2.0.6)

Code: Select all

$ ls /usr/local/lib/libSDL2*so* -al
lrwxrwxrwx 1 root root      20 febr   4 12:30 /usr/local/lib/libSDL2-2.0.so.0 -> libSDL2-2.0.so.0.6.0
-rwxr-xr-x 1 root root 4706156 febr   4 12:30 /usr/local/lib/libSDL2-2.0.so.0.6.0
lrwxrwxrwx 1 root root      20 febr   4 12:30 /usr/local/lib/libSDL2.so -> libSDL2-2.0.so.0.6.0
David wrote: February 4th, 2018, 12:27 pm (compiling with SDL 2.0.5, then running with SDL 2.0.4)
On Windows it results in the message that Falcury posted; and I think I have seen a similar message on Linux.
This is interesting: On Linux, I get the error only if I enable integer scaling in SDLPoP.ini, i.e. when SDLPoP would actually use the missing procedure.

Code: Select all

$ ./prince
./prince: symbol lookup error: ./prince: undefined symbol: SDL_RenderSetIntegerScale
Also, for some reason, SDLPoP won't start if SDL 2.0.5 or newer is installed:

Code: Select all

$ ./prince
SDL_Init: No available video device
Falcury
Calif
Calif
Posts: 565
Joined: June 25th, 2009, 10:01 pm

Re: SDLPoP v1.18 pre-release

Post by Falcury »

I squashed the pull request with timer-related code changes into a single commit on a new branch.
https://github.com/NagyD/SDLPoP/pull/153
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: SDLPoP v1.18 pre-release

Post by David »

Falcury wrote: February 3rd, 2018, 11:31 pm I built the attached SDL2.dll today from the latest version from here:
https://github.com/SDL-mirror/SDL

It includes a fix for the issue discussed here:
https://github.com/NagyD/SDLPoP/issues/ ... -357447802
Unfortunately this DLL has the sound bug from SDL 2.0.6 that was fixed in SDL 2.0.7.
If this is indeed the latest SDL source, then I guess I need to reopen that bug report...

EDIT: I pulled the latest SDL2 source from http://hg.libsdl.org/SDL, and it doesn't have this bug.
Maybe they fixed it since you compiled the DLL.
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: SDLPoP v1.18 pre-release

Post by David »

So, can I make a final v1.18 release now?
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Re: SDLPoP v1.18 pre-release

Post by Norbert »

David wrote: February 25th, 2018, 11:19 am So, can I make a final v1.18 release now?
I would still change
const char quick_version[] = "V1.16b4 ";
Let's say, for argument's sake, that there have been 3 different quick save formats and this is the third iteration.
Then this should say V0.3 or something similar.
Because now the version number is so close to the SDLPoP version that it's misleading.

[Edit: By the way, in CMakeLists.txt it still says 1.17.]
Falcury
Calif
Calif
Posts: 565
Joined: June 25th, 2009, 10:01 pm

Re: SDLPoP v1.18 pre-release

Post by Falcury »

David wrote: February 25th, 2018, 11:19 am So, can I make a final v1.18 release now?
Sure!
Norbert wrote: February 25th, 2018, 1:44 pm I would still change
const char quick_version[] = "V1.16b4 ";
Let's say, for argument's sake, that there have been 3 different quick save formats and this is the third iteration.
Then this should say V0.3 or something similar.
Because now the version number is so close to the SDLPoP version that it's misleading.
I guess that's fine, although then people can't transfer quicksave files to/from the new version.
Norbert wrote: February 25th, 2018, 1:44 pm [Edit: By the way, in CMakeLists.txt it still says 1.17.]
Ah, yes, that version number is for the macOS app bundle.
That's still broken unfortunately because of dependency hell on macOS that I couldn't figure out. :|
Falcury
Calif
Calif
Posts: 565
Joined: June 25th, 2009, 10:01 pm

Re: SDLPoP v1.18 pre-release

Post by Falcury »

David wrote: February 17th, 2018, 7:30 pm Unfortunately this DLL has the sound bug from SDL 2.0.6 that was fixed in SDL 2.0.7.
If this is indeed the latest SDL source, then I guess I need to reopen that bug report...

EDIT: I pulled the latest SDL2 source from http://hg.libsdl.org/SDL, and it doesn't have this bug.
Maybe they fixed it since you compiled the DLL.
Strange, I fast-forwarded to the newest source and the bug is still there.
Maybe it's specific to the MSVC compiler?

Anyway, I think that SDL's audio convertor functionality is to blame for this bug.
If I convert digi sounds manually (see this commit) the problem disappears entirely.
The sound quality becomes a bit better as well, at least on my system.
Specifically, the 'muffled' aspect of the sound that I mentioned here is fixed by this.
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: SDLPoP v1.18 pre-release

Post by David »

Falcury wrote: March 1st, 2018, 4:18 pm Strange, I fast-forwarded to the newest source and the bug is still there.
Maybe it's specific to the MSVC compiler?
I don't know, I tried only on Linux with GCC.
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: SDLPoP v1.18 pre-release

Post by David »

Falcury, I see you posted some pull requests.
Should I merge all of them (including the MIDI support) before the final v1.18 release?
Post Reply