SDLPoP; David's open-source port of PoP

[Norbert]

I was wondering, why does SDLpop store everything in game directory? Most games store their saves, screenshots and so on in paths such as

Code: Select all

~/.config/sdlpop/screenshots/

or something. Also it seems to create QUICKSAVE.SAV and PRINCE.HOF in current directory, which is strange.

Does SDLpop have option to build it like a regular linux package, with executable in /usr/games/prince and all other static files in /usr/share/sdlpop and with all dynamic files in ~/.config/sdlpop or ~/.local/sdlpop or at least ~/.sdlpop, though modern programs mostly switched to use .config

Though, being able to download the source, then do just tar xf sdlpop*; cd src; make; cd ..; ./prince and being able to play is pretty neat.

SDLPoP does save most things in directories, e.g. screenshots/ and replays/. Exceptions are files that the original game also saves in the top level directory, that is PRINCE.SAV (with Ctrl+g, starting level 3) and PRINCE.HOF (after winning the game). Plus QUICKSAVE.SAV, because it's similar to PRINCE.SAV, although its save location is not consistent.

As for an option to build to specific directories, others have made similar suggestions (here and here).

[Zukelik]

I have installed it in one directory such as ~/games/sdlpop but launched it from home directory, by full path ~/games/sdlpop/prince and files like QUICKSAVE.SAV were created in my home directory instead of game's top level directory..

[Norbert]

Plus QUICKSAVE.SAV, because it's similar to PRINCE.SAV, although its save location is not consistent.

I have installed it in one directory such as ~/games/sdlpop but launched it from home directory, by full path ~/games/sdlpop/prince and files like QUICKSAVE.SAV were created in my home directory instead of game's top level directory..

Yes, the save location of QUICKSAVE.SAV is inconsistent.
As you write, it depends on the launch directory, something that should probably be changed.

[Norbert]

There's a bug that makes command-line option "mute" stay active across sessions, even when (later) running the application without it.
I don't know how that is possible, but I've ran into it multiple times. Maybe it's a Linux-only issue.

[Norbert]

Maybe on Windows the program should check if the required DLL files are available.
viewtopic.php?p=33770#p33770
Or, as I do with apoplexy (here), simply also include these files on GitHub.

[Norbert]

(After reading this.) Perhaps a bit far-fetched, maybe even unwise, but some byte of LEVELS.DAT could be used to verify whether the mod is suitable for vanilla SDLPoP. That modders who create custom mods that require their SDLPoP forks can have vanilla SDLPoP show a warning. That they could do so by: 1. modifying the byte to a non-default value, and 2. telling their SDLPoP fork to ignore the byte. The idea is that if players take LEVELS.DAT (and other files) from a specific SDLPoP fork and attempt to play them using vanilla SDLPoP, that they'll see a warning.

[Norbert]

In seg000.c, maybe it's useful to, under

Code: Select all

// They can be repurposed to add new stuff to the level format in the future

add

Code: Select all

// WIP: https://www.popot.org/documentation/documents/multiplayer.txt

To prevent developers from repurposing the first three without being aware of in-progress efforts.

[David]

(After reading this.) Perhaps a bit far-fetched, maybe even unwise, but some byte of LEVELS.DAT could be used to verify whether the mod is suitable for vanilla SDLPoP.

The last byte of the level (at offset 0x900) is always 0x09 in the original levels, and probably in all edited levels as well.
The exception is the potions level which is one byte shorter.
This byte was added in the DOS version, by the way.
This byte is the last byte of level.fill_3[], which is zeroed after the level is loaded.
If we make fill_3[] one byte shorter and add a new member after it, then it won't be zeroed.

The unknown II area is always zero in the original levels, but it's used by RoomShaker.
If any level of a mod (accidentally) contains a RoomShaker debug start then this area is not zero on that level.

[David]

In seg000.c, maybe it's useful to, under

Code: Select all

// They can be repurposed to add new stuff to the level format in the future

add

Code: Select all

// WIP: https://www.popot.org/documentation/documents/multiplayer.txt

To prevent developers from repurposing the first three without being aware of in-progress efforts.

Done: https://github.com/NagyD/SDLPoP/commit/ ... d8f8f254bd

[Norbert]

Done: https://github.com/NagyD/SDLPoP/commit/ ... d8f8f254bd

Thanks.

[Norbert]

Not that interesting, but; these two recently created a noticeable amount of visitors to the SDLPoP page:
https://ragequit.gr/forum/threads/lifti ... ost-584646
https://www.vogons.org/viewtopic.php?p=1015446#p1015446

[VelCheran]

I wonder, could it be possible to simulate the same "dark transition" between screens as in the original game?
It would really help when using SDLPoP to train to speedrun pop1, because otherwise the timings get wrong, especially when you need to jump right after changing screens.

[David]

I wonder, could it be possible to simulate the same "dark transition" between screens as in the original game?

SDLPoP used to have that, but I removed it back here: viewtopic.php?f=126&t=3512&p=15022&hili ... awn#p15022

However, the lack of this has been bothering me a bit as well.

Here is my fix: https://github.com/NagyD/SDLPoP/commit/ ... d5d041a101

[VelCheran]

Thanks!
I tried to compile it using Dev-c++ but it failed, however
And I forgot my C++ classes for a very long time. I installed the required libraries as written on Github, and I opened the release.dev file but I get an error saying "The compiler set you have selected for this project, no longer exists. It will be substituted by the global compiler set..." . Should I install a specific compiler for it? Because I tried with the default one, and got those errors:
https://pastebin.com/Nj5fT6BD

[David]

Because I tried with the default one, and got those errors:
https://pastebin.com/Nj5fT6BD

This is the key part:

Code: Select all

types.h:34:18: SDL.h: No such file or directory
types.h:35:24: SDL_image.h: No such file or directory

The compiler cannot find the SDL headers.

Go to Project -> Project Options... -> Directories -> Include Directories, and add the directory which contains SDL.h and SDL_image.h .
With your setup it's probably: A:\Dev-Cpp\include\SDL2

Alternatively, you could open types.h, and change these lines:

Code: Select all

# include <SDL.h>
# include <SDL_image.h>

back to their original form:

Code: Select all

# include <SDL2/SDL.h>
# include <SDL2/SDL_image.h>

Or just uncomment (remove the "//" from) every line which starts with "//#".

The SDL2/ part was removed here: https://github.com/NagyD/SDLPoP/pull/23 ... 88b91ef92f
It already caused problems back then, because I had to manually add the SDL2 directory to the Include Directories to allow compiling with Dev-C++: https://github.com/NagyD/SDLPoP/commit/ ... 72390dd004
Unfortunately this fix depends on the exact location where Dev-Cpp was installed, and you have Dev-Cpp on a different path than what the fix assumes.

I will probably revert the #includes to their original forms.
Or perhaps add some more #ifs to keep everyone happy, once I find out how to detect each possible OS and build environment.

BTW, why do you have your drives as A: and B:?