SDLPoP; David's open-source port of PoP

[Norbert]

Can I make a ZIP now, or does someone have more additions?

I don't think 1.15 has to be perfect and without bugs?
Maybe just release 1.15 unless there are game breaking bugs...
If it is better than 1.14, I'd say release 1.15. It's almost 6 months since 1.14.

[David]

Right then, I don't want it to become the next Duke Nukem Forever.

Here is v1.15, with source+exe+dlls like the previous releases.
Thanks to everyone who contributed!

For some reason, GitHub did not notice that I merged the last pull request.

[salvadorc17]

This version is working good, just for know, you can use apoplexy editor with this version???

[Norbert]

In level 4, the gate on the right in the starting room, trick 2 does not draw the guard forward.
This used to work. Maybe fix this for 1.15 (replace the ZIP)?

[David]

That is disabled by one of the fixes in config.h, namely FIX_PRESS_THROUGH_CLOSED_GATES.
This raises the question: Should fixes be enabled by default?

This version is working good, just for know, you can use apoplexy editor with this version???

If you copy the exe and dlls into the prince folder of apoplexy then you can play edited levels.

[Norbert]

In my opinion it should definitely be as the original game.
Any changes/fixes should be optional, and changes/fixes should not be enabled by default.

[Falcury]

I just figured it out: An else was missing in redraw_needed().
Looks like I overlooked a jmp in the disassembly. (Even though it's followed by a separator line as wide as the screen.)
Who would have thunk there were still some of these?...

That's fantastic

From https://github.com/NagyD/SDLPoP/pull/21/files
I'm not sure what FIX_GUARD_FOLLOWING_THROUGH_CLOSED_GATES does.
Also, that "Kid.curr_row * 10 + 9" looks strange. get_tile() expects a column there, so it should be just 9?

Yes, I think I confused something while working on too many things at once... You're right, it should just be the rightmost column in the room.
It should also be curr_tile2 instead of curr_tile. Strangely enough, it did seem to work when I originally tested it...
I got frustrated by the bug that when a guard is located near the left of the room, facing you (but behind a closed or closing gate), he will still "follow" you to the room to the left when you move there. The consequence is that he either teleports through the gate, or simply disappears from his original room and cannot be defeated anymore. See the attached quicksave, that probably explains it better.

QUICKSAVE.zip

(788 Bytes) Downloaded 472 times

In my opinion it should definitely be as the original game.
Any changes/fixes should be optional, and changes/fixes should not be enabled by default.

Yes, then there should be an easy way to enable/disable them without recompiling. We could use an INI file for this.
I think the graphical fixes should be fine though, seeing as they don't impact gameplay in any way.

As a side note, I do also like the idea of adhering faithfully to the original game as Jordan Mechner envisaged it - I think Jordan might have fixed a lot of the bugs himself, if they had come up during the production process (they are clearly not an intentional part of the game).

[David]

Strangely enough, it did seem to work when I originally tested it...

I tried it, it does not work in its current state.
But it works with the changes you wrote.

Another solution is to check the value of can_guard_see_kid.
It is 2 if the guard is following the kid. (See the comments in check_can_guard_see_kid().)
Maybe the condition "Guard.sword == sword_2_drawn" could be replaced with "can_guard_see_kid == 2"?
It works with your test case, but I did not test it thoroughly.

Yes, then there should be an easy way to enable/disable them without recompiling. We could use an INI file for this.

That's a task for the next version, then.

In my opinion it should definitely be as the original game.

Right, I disabled all options whose name starts with "FIX_".
Do ALLOW_CROUCH_AFTER_CLIMBING and DISABLE_TIME_DURING_END_MUSIC also count as fixes?
I disabled them anyway.

Here is the version with fixes disabled.
(I also recompiled the exe in release mode.)

[Norbert]

Thanks David. I'll upload and announce it here and there.

As far as controller support goes, this will need some work.
Try standing still (no running/jumping) and just turn around quickly a bunch of times (left, right, left, etc.).
With the joystick on the controller it's difficult not to push up or down when going left and right like that.
The D-pad may be more suitable.
Or, maybe the joystick and D-pad should both be options, and only be used for movement right and left.
Y and A could be used for respectively moving up and down.
In apoplexy, I check if the joystick movement on the y-axis is substantial enough for the program to react.
I haven't checked any SDLPoP source code, but I have a feeling maybe it's not doing that (enough).
The 'cut-off point' could/should be at 45 degrees, with movement larger than (-)30000.

[Falcury]

David, do you have a wishlist of things to implement or fix in future versions?

For now, I have started working on a feature that adds simple recording/replaying capabilities. It works by capturing the kid's moves and saving them out to a file. Replaying behaves a bit like the demo level - although the guards behave predictably in replays (random_seed is saved with the replay).
Some thoughts about this:
- Currently, I use a file called REPLAY.SAV for output, but I think it may be better to use a separate file extension for replays (for example *.P1R, similar to Jazz Jackrabbit 2's naming scheme). An advantage would be that you could launch replays just by double-clicking or dragging them on top of the SDLPoP executable. Also they will be harder to confuse with the other files that use the .SAV extension.
- I suppose replays should probably be saved as REPLAY_001, REPLAY_002, etc.
- Possible command line options: "record <levelnumber>" starts recording at the specified level, "replay" plays the replay. To start/stop recording on the fly, we could use the familiar Ctrl+Alt+F5 from DOSBox (recording on the fly requires that a savestate is saved along with the replay).

Maybe the condition "Guard.sword == sword_2_drawn" could be replaced with "can_guard_see_kid == 2"?
It works with your test case, but I did not test it thoroughly.

There's also the situation where you arrive from the other side of the gate, crouch-hopping under a closing gate. I haven't yet tested if that works with "can_guard_see_kid == 2" too (but I think it probably will).
A situation where the gate is "opening" instead of "closing" should probably be treated differently... in the case of an opening gate, the guard will soon be able to follow, even if he cannot move through the gate immediately. However, I do not know an easy way to tell apart a closing gate from an opening gate.

As far as controller support goes, this will need some work.

I do not have a controller myself unfortunately.

[Norbert]

we could use the familiar Ctrl+Alt+F5 from DOSBox

That shortcut won't work (properly) on Linux though, because Ctrl+Alt+F# are shortcuts to switch to the various virtual text consoles.
That's why, for example, Linux users who want to record with DOSBox need to first rebind the familiar Ctrl+Alt+F5 shortcut.
(See "Under GNU/Linux, if Ctrl+Alt+F5 cannot be used [...]" here.)

As far as controller support goes, this will need some work.

I do not have a controller myself unfortunately.

I've sent segra a private message and pointed him to my suggestions/remarks.
If necessary, one day, I could look at and improve the related source code myself.

[Falcury]

That shortcut won't work (properly) on Linux though, because Ctrl+Alt+F# are shortcuts to switch to the various virtual text consoles.
That's why, for example, Linux users who want to record with DOSBox need to first rebind the familiar Ctrl+Alt+F5 shortcut.
(See "Under GNU/Linux, if Ctrl+Alt+F5 cannot be used [...]" here.

OK, I changed the key binding to Ctrl+Tab, as was suggested in the post you linked to.
You can also view a saved replay by pressing Tab on the title screen.
Here is an experimental build containing the replay feature:

[Norbert]

I changed the key binding to Ctrl+Tab

Thanks.

Here is an experimental build

Neat. Works under Linux too.

Some suggestions:
- In the Makefile, replay.c should be replay.o.
- When compiling I see a warning about "missing braces around initializer" on line 133. This is probably a gcc bug though.
- Maybe in future posts include details for non-programmers who want to try out your modifications.

So... people who download the ZIP file above, you can use that customized SDLPoP version to record yourself playing.
What you do is you start with "prince.exe record". Then when you're done and want to stop recording, press Ctrl+R.
To replay what you have recorded, start with "prince.exe replay". Then on the title screen (beginning of the game, before you start level 1), press Tab.

[David]

- Maybe in future posts include details for non-programmers who want to try out your modifications.

Information about changes should be included in the ChangeLog, and, if it fits there, in the Readme.

For now, I have started working on a feature that adds simple recording/replaying capabilities.

This can be used to post solutions or to make testcases.
Some versions of PoP (PC98, X68000) automatically record each level but only the shortest play is kept for each level.

The 'cut-off point' could/should be at 45 degrees, with movement larger than (-)30000.

Joystick support was added here (by segrax). You can try different numbers there.

[Norbert]

- Maybe in future posts include details for non-programmers who want to try out your modifications.

Information about changes should be included in the ChangeLog, and, if it fits there, in the Readme.

I was talking about the experimental build. That it's nice if the non-programmers on this forum understand how to try out experimental things. I had to look in the source code to find out I had to use "prince.exe record", Ctrl+R, and "prince.exe replay". Even expecting people to dive into a ChangeLog or Readme file to find out how to test an experimental build's custom feature may be a bit much.

The 'cut-off point' could/should be at 45 degrees, with movement larger than (-)30000.

Joystick support was added here (by segrax). You can try different numbers there.

Yeah, those -8000 and 8000 values should be (closer to) -30000 and 30000.
At least, in my opinion.