SDLPoP v1.18 pre-release
SDLPoP v1.18 pre-release
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
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 124 times
Re: SDLPoP v1.18 pre-release
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.
Re: SDLPoP v1.18 pre-release
I built the attached SDL2.dll today from the latest version from here: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?
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 103 times
Re: SDLPoP v1.18 pre-release
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
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?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.
Re: SDLPoP v1.18 pre-release
Thank you!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
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.)
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?
Re: SDLPoP v1.18 pre-release
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.)
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
Re: SDLPoP v1.18 pre-release
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
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
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
Code: Select all
$ ./prince
SDL_Init: No available video device
Re: SDLPoP v1.18 pre-release
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
https://github.com/NagyD/SDLPoP/pull/153
Re: SDLPoP v1.18 pre-release
Unfortunately this DLL has the sound bug from SDL 2.0.6 that was fixed in SDL 2.0.7.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
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.
Re: SDLPoP v1.18 pre-release
So, can I make a final v1.18 release now?
Re: SDLPoP v1.18 pre-release
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.]
Re: SDLPoP v1.18 pre-release
Sure!
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 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.
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.
Re: SDLPoP v1.18 pre-release
Strange, I fast-forwarded to the newest source and the bug is still there.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.
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.
Re: SDLPoP v1.18 pre-release
Falcury, I see you posted some pull requests.
Should I merge all of them (including the MIDI support) before the final v1.18 release?
Should I merge all of them (including the MIDI support) before the final v1.18 release?