SDLPoP; David's open-source port of PoP

[David]

A very minor difference between the original and SDLPoP: if the game is in upside-down mode (after drinking the flip potion) and time runs out, the original does not show the torch flames and hourglass in the princess room, while SDLPoP does.

This happens with all cutscenes, including the intro!

Here is a screenshot from the DOS game:

DOS_bad_end_upside_down.png (6.93 KiB) Viewed 5243 times

The intro in SDLPoP in upside-down mode does something quite funny after the screen flashes:

SDLPoP_intro_blind_mode.png (16.68 KiB) Viewed 5243 times

In SDLPoP, the torch flames do not move for most of that cutscene (when upside-down).

Namely, they move only while the picture is fading in or out.

This is probably because fading in SDLPoP forcibly redraws the whole screen, while the DOS game doesn't do that.
Otherwise only the "dirty rectangles" are redrawn, i.e. those areas of the screen that actually changed.
However, the cutscene module does not handle these redraws correctly in upside-down mode.
Compare:
In-game: https://github.com/NagyD/SDLPoP/blob/ma ... 000.c#L863 -- note the flip_screen() calls.
Cutscene: https://github.com/NagyD/SDLPoP/blob/ma ... 001.c#L129

copy_screen_rect() will flip the coordinates of the input rectangle in upside-down mode, and flip_screen() is needed to match up the source image with these flipped coordinates.

Note how the top of the flames is exactly at Y=100, i.e. vertically in the middle of the screen.
This means that in the cutscenes, any dirty rectangle will be fully in the bottom half of the screen, and thus after flipping it ends up in the top half of the screen, where nothing moves.
(But see the second image above, where these flipped locations are actually redrawn.)

(BTW, I feel a little contradiction in how the game tries to minimize on-screen drawings using dirty rectangles,
yet in upside-down mode it flips the *whole* off-screen surface *twice* per frame.)

I tried to solve this now, but it's not so simple as copying the two flip_screen() calls from seg000.c to seg001.c.
I guess the simplest solution would be to turn upside-down mode off when a cutscene starts.

The "draw" command line parameter is also known to interact badly with upside-down mode, probably also for reasons related to the dirty rectangles.


While at it: blind mode also affects cutscenes differently in SDLPoP and the original game.

In the original game, there will be a black rectangle around the princess, the hourglass and the right front pillar.

DOS_cutscene_blind_mode.png (7.38 KiB) Viewed 5243 times

In SDLPoP, the background will be black.

SDLPoP_cutscene_blind_mode.png (2.08 KiB) Viewed 5243 times

In the DOS game, if you watch the intro in blind mode, the characters will leave a black trail wherever they move.

DOS_intro_blind_mode.png (6.81 KiB) Viewed 5243 times

The same happens in the cutscenes with the mouse.

[Norbert]

A very minor difference between the original and SDLPoP: [...]

Here's another minor difference: viewtopic.php?p=25343#p25343

Disable entering closed level doors: https://github.com/Falcury/SDLPoP/commi ... c9e03627f2

I guess it's not yet togglable.

[YURA]

The video will be the Supplement? to shoot in a different format? in the Menu it is advisable to add.

[Norbert]

Small suggestion/request: can you change the PoPOT link here
https://github.com/NagyD/SDLPoP/blob/ma ... e.txt#L243
to https://www.apoplexy.org/

[David]

Small suggestion/request: can you change the PoPOT link here
https://github.com/NagyD/SDLPoP/blob/ma ... e.txt#L243
to https://www.apoplexy.org/

Done: https://github.com/NagyD/SDLPoP/commit/ ... 03869e3a54

[Norbert]

This death crashes SDLPoP (and not the original game in DOSBox):



-----
#0 0x000055e463e8d7bc in exit_room () at seg002.c:321
321 if (level.guards_tile[kid_room_m1] >= 30 ||
[Current thread is 1 (Thread 0x7f67ddebc7c0 (LWP 7117))]
-----
#0 0x000055e463e8d7bc in exit_room () at seg002.c:321
#1 0x000055e463e89ad2 in play_frame () at seg000.c:801
#2 0x000055e463e8f6e7 in play_level_2 () at seg003.c:369
#3 0x000055e463e8fa45 in play_level (level_number=<optimized out>,
level_number@entry=1) at seg003.c:121
#4 0x000055e463e8fc1c in init_game (level=1) at seg003.c:46
#5 0x000055e463e884d8 in start_game () at seg000.c:223
#6 0x000055e463e8a6d6 in pop_main () at seg000.c:134
#7 0x000055e463e857b8 in main (argc=<optimized out>, argv=<optimized out>)
-----

[David]

This death crashes SDLPoP (and not the original game in DOSBox):
[...]
#0 0x000055e463e8d7bc in exit_room () at seg002.c:321
321 if (level.guards_tile[kid_room_m1] >= 30 ||
[Current thread is 1 (Thread 0x7f67ddebc7c0 (LWP 7117))]

I made a similar level, and although it doesn't crash on my system, I found what is the problem.
kid_room_m1 == 65535, because Kid.room == 0.

Try replacing the condition with this:

Code: Select all

		if ((kid_room_m1 >= 0 && kid_room_m1 <= 23) &&
			(level.guards_tile[kid_room_m1] >= 30 || level.guards_seq_hi[kid_room_m1] != 0)
		) {

And see if it solves the crash.

By the way, the chomper is not even necessary.
Another way to get kid_room_m1 == 65535 is to climb down at the bottom of a room that has no room below.


While I was testing this bug, I found another bug, and this one also happens in the original game!
The prince falls into a weird empty room (room -128 according to the "C" cheat key), and then back to the starting room.
The ZIP contains a video of this bug and a LEVELS.DAT with the test level.

fall_into_room_0.zip

(42.27 KiB) Downloaded 186 times

[Norbert]

Try replacing the condition with this: [...] And see if it solves the crash.

Yes, no longer crashes.

While I was testing this bug, I found another bug, and this one also happens in the original game!

Here's David's recording:

[David]

Try replacing the condition with this: [...] And see if it solves the crash.

Yes, no longer crashes.

Right. I committed the fix: https://github.com/NagyD/SDLPoP/commit/ ... 7cd74b66f8

[Norbert]

Video about running the Vita port.
(And a related tweet.)

[Norbert]

It's too difficult for modders to understand that something like "guard_type = 1" will only work if use_custom_options is also modified.
Therefore my suggestion is to change the default of use_custom_options to "true".
Maybe requires some minor other changes, e.g. setting copyprot_level to "never".

[David]

It's too difficult for modders to understand that something like "guard_type = 1" will only work if use_custom_options is also modified.
Therefore my suggestion is to change the default of use_custom_options to "true".
Maybe requires some minor other changes, e.g. setting copyprot_level to "never".

The latter is not needed, because enable_copyprot is false by default.

BTW, I found a bug: If I set start_in_blind_mode to true then the the whole screen will be black.
When the screen flashes, the moving sprites become visible for the duration of the flash.
This fixes itself when a cutscene is displayed, or if I disable and reenable blind mode with Shift+B.

EDIT: It seems this bug is already known: https://github.com/NagyD/SDLPoP/blob/ma ... g000.c#L81

[David]

BTW, I found a bug: If I set start_in_blind_mode to true then the the whole screen will be black.
When the screen flashes, the moving sprites become visible for the duration of the flash.
This fixes itself when a cutscene is displayed, or if I disable and reenable blind mode with Shift+B.

EDIT: It seems this bug is already known: https://github.com/NagyD/SDLPoP/blob/ma ... g000.c#L81

Fixed: https://github.com/NagyD/SDLPoP/commit/ ... 267fe68200

Another bug related to blind mode remains:
If (in blind mode) you enter a room with a guard, then the guard will display with the color of the last guard seen outside blind mode, *or* all black if there was no such guard.
That is, unless the current level has special guards (fat, Jaffar, etc.), because their palette is loaded when the level starts.
This bug is present in the original game as well.
The cause of the bug is simple: The guard's palette is not changed if blind mode is on: https://github.com/NagyD/SDLPoP/blob/ma ... 003.c#L248
The fix is trivial: Just move if(curr_guard_color){...} before the if(is_blind_mode) line.

Should I fix this as well, or do black guards go well with the mostly-black screen of blind mode?

[Norbert]

It's too difficult for modders to understand that something like "guard_type = 1" will only work if use_custom_options is also modified.
Therefore my suggestion is to change the default of use_custom_options to "true".
Maybe requires some minor other changes, e.g. setting copyprot_level to "never".

The latter is not needed, because enable_copyprot is false by default.

Ah.
Falcury, good idea, changing the default for use_custom_options to "true"?

Fixed: https://github.com/NagyD/SDLPoP/commit/ ... 267fe68200

With one line.

Is bugs.txt still necessary/up-to-date?
At the bottom, maybe "speaker and midi sounds" has since been implemented?

[David]

Is bugs.txt still necessary/up-to-date?

It's certainly not up-to-date, it hasn't been updated since 2015.
As for its usefulness, I guess I wrote most of it for myself.
I don't think it's useful, except maybe to someone who wants to see every single bug I fixed before the first release.
The changes after the first release are documented in ChangeLog.txt as well, sometimes with different wording.

The "Not (yet) implemented" section could be moved to a new file, similarly to todo.txt of PR.

At the bottom, maybe "speaker and midi sounds" has since been implemented?

Yes: support for MIDI sounds was added in v1.18, and support for PC speaker sounds was added in v1.19.

The next line mentions stretching (window resizing), it was implemented in v1.15 when SDLPoP was ported to SDL2.