SDLPoP; David's open-source port of PoP

[Falcury]

Okay. It doesn't work for me. Maybe because I compile/link it myself to be able to run it on Linux, that not all changes are in the source files?

Hm, I'm not sure what could have gone wrong; but you can take a look at my code changes here.

[musa]

I made a icon for SDLPoP. I got the image from this forum.

[Norbert]

I reported the bug in the SDL Bugzilla: https://bugzilla.libsdl.org/show_bug.cgi?id=2986

They accepted my patch.

Nice.
I also received a reply from Ryan. Apparently they're planning to release SDL 2.0.4 soon.

[David]

I also found the cause of a bug where leveldoors continue to slide open indefinitely under some circumstances (multiple exit doors, visiting the shadow room in level 6, or anything else that sets leveldoor_open to something other than 0 or 2).

There was a patch to fix it in the original game: viewtopic.php?p=13128#p13128

I had a burst of madness and created a potion that temporarily changes the kid into the shadow.

I see you added a new variable. It should be saved to/loaded from the quicksave file.
But then the existing quicksave files become unusable.

- Should quicksaving be allowed after the kid has died? (I was unfortunate enough to do this by accident...)

Probably not, it makes no sense.
Maybe the error message could say then "no quicksave now" or "here".

Similar for quicksaving midjump/midfall/on a loose tile/while weightless/entering an exit door/drinking a potion

While entering an exit door: Again, it makes no sense, because then you already completed the level.
If you save while weightless, and then load it back, then the kid will not be weightless, because this relies on the music playing.
midjump, midfall, on a loose tile, drinking a potion: Why not?

- Quickloading while executing certain movements, such as running jumps, may cause the kid to start moving immediately after the quickload has completed. Can this be prevented?

Add this at the end of quick_load():

Code: Select all

	ctrl1_forward = 0;
	ctrl1_backward = 0;
	ctrl1_up = 0;
	ctrl1_down = 0;
	ctrl1_shift2 = 0;

Okay. It doesn't work for me. Maybe because I compile/link it myself to be able to run it on Linux, that not all changes are in the source files?

I will try that.
However, under Windows, the special potion still works for me if I recompile from the sources.

(Also, "Levels.dat" should be renamed to "LEVELS.DAT"?)

[Falcury]

There was a patch to fix it in the original game: viewtopic.php?p=13128#p13128

Ah, ok. Interesting, I hadn't realized that the prince could go through closed level doors.
Do you know if there are other known bugs in the original game that we could fix?

midjump, midfall, on a loose tile, drinking a potion: Why not?

I think Pop3D tends to regard such actions as "unsafe" for quicksaving, but I agree with you that there is no good reason for this!

(Also, "Levels.dat" should be renamed to "LEVELS.DAT"?)

Yes, I suppose so! Although I only put my own mod in there for testing purposes.

Do we want to keep the shadow potion as a feature, though? I think I will at least keep it as an easter egg for my level set, but perhaps it is too "unauthentic" for the main release?

[Norbert]

I added the potion to level 6. You can quickload to the relevant part of the level to see the potion in action.

Are you sure?
When I use F9 to quickload the only potion nearby is a red one that doesn't seem to have any special effects.
I do see an unusual potion somewhere, but then you're really making us work for it...

[...]

Edit: the quicksave file attached takes you directly to the potion.

Yes, that's the unusual potion I meant.
With this new quicksave you created it does work, thanks.

[David]

Right, I tried it under Linux.
The shadow potion works fine.
(As Norbert wrote in the meantime...)

However the game is slow and it uses 90% of the CPU.
Maybe because of what you wrote here: https://github.com/Falcury/SDLPoP/commi ... 23150135da

- Some inelegant workarounds, game runs quite inefficiently (lots of surface conversions); needs refactoring

[Norbert]

Cool potion, by the way.

[Falcury]

Cool potion, by the way.

Thank you!

Right, I tried it under Linux.
The shadow potion works fine.
(As Norbert wrote in the meantime...)

However the game is slow and it uses 90% of the CPU.
Maybe because of what you wrote here: https://github.com/Falcury/SDLPoP/commi ... 23150135da

- Some inelegant workarounds, game runs quite inefficiently (lots of surface conversions); needs refactoring

I thought I had fixed this specific problem in a later commit... It really should perform at least on par with the SDL1 version. I don't have Linux set up so I can't really test it. On my laptop (from 2008), I get typical CPU usage of about 1-3% on Windows.
Does this problem apply to all versions since the SDL2 migration, or was there a regression somewhere since?
Perhaps passing different flags to SDL_CreateRenderer() in set_gr_mode() makes a difference?

[David]

I thought I had fixed this specific problem in a later commit...

Does "lots of surface conversions" refer to surface->texture conversions? (In request_screen_update.)
Because that is still there.

I don't have Linux set up so I can't really test it.

Norbert uses Linux, but he didn't write about this problem.

On my laptop (from 2008), I get typical CPU usage of about 1-3% on Windows.

I get the same under Windows. The game is slow only under Linux.

Does this problem apply to all versions since the SDL2 migration, or was there a regression somewhere since?

I tested only this latest version. But I will try others.

Perhaps passing different flags to SDL_CreateRenderer() in set_gr_mode() makes a difference?

I tried to remove SDL_RENDERER_ACCELERATED, but no difference.
I might try other flags.

[Norbert]

On my laptop (from 2008), I get typical CPU usage of about 1-3% on Windows.

I get the same under Windows. The game is slow only under Linux.

I have two computers, both Linux machines, and even on the slowest PC it uses only 2.3-2.7% of a single core.
That's an old dual core 6600 @ 2.40GHz. So the game is slow only under your Linux.

[David]

SDL_RENDERER_SOFTWARE makes it faster. (Uses 40-50% of the CPU)
Then I installed the newest video card driver (nVidia) and it solved the problem.
(Uses 1-2% of the CPU with SDL_RENDERER_ACCELERATED)
(So an improper hardware acceleration can be *slower* than a software renderer?)

[Norbert]

I also received a reply from Ryan. Apparently they're planning to release SDL 2.0.4 soon.

Release Candidate 1 for SDL 2.0.4 can be found here.
More information here.

[David]

I found a funny bug:
If the screen is flipped (Shift-I, potion), and something flashes (Shift-T, Shift-W, potion), then the screen is redrawn incorrectly without flipping.
But then animated objects are drawn over that correctly.
It was probably around ever since flashing was implemented.
Fixed: https://github.com/NagyD/SDLPoP/commit/ ... 09325aee0b

[Falcury]

Hm, that bug is quite interesting
Now that I look at it, there seems to be a minor difference with flashes in the original game: in SDLPoP, the lower part of the screen does not participate in the flash, but it does when I play the original game using DOSBox.

I have added the fixes discussed earlier:
Clear movement controls when quickloading: https://github.com/Falcury/SDLPoP/commi ... 45c3ddcd18
Disable entering closed level doors: https://github.com/Falcury/SDLPoP/commi ... c9e03627f2

A new fix:
Fix level doors in the starting room displaying a blue area when they slide open: https://github.com/Falcury/SDLPoP/commi ... 5f77d794fb

As a new experimental feature, I have been trying to implement this:
https://github.com/Falcury/SDLPoP/commi ... 5b018dae3b
The idea is that special tiles can be used to trigger special events in a non-hardcoded way. Nonlinear gameplay also becomes possible: multiple start positions based on which exit door you took in the previous level, skipping levels or backtracking to previous levels, etc.
The number of "scriptable" events is small at the moment but can be expanded.