SDLPoP; David's open-source port of PoP

[Falcury]

- 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.

Thanks, I will change the Makefile and see if the gcc warning can be prevented.

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

Sorry, I should have explained better in my post (the GitHub post I linked to had a bit more information).
- You can record on the fly by pressing Ctrl+Tab to start/stop. Ctrl+R or Ctrl+Q also stops the recording and saves the replay.
- Alternatively, you can enter recording mode with command line parameter "record <levelnumber>" to start recording on the specified level. If you don't specify a level number you will first go to the title screen and then start recording on Level 1.
- To view a previously recorded replay, press Tab on the title screen. After the replay has finished, you will return to the title screen (or you can skip by using Ctrl+R).
- Alternatively, you can start the game with command line parameter "replay" to launch the replay immediately without first going to the title screen.

[musa]

I noticed that SDLPoP still has no icon but I've made a better one than the one I made last time.

[Norbert]

I noticed that SDLPoP still has no icon but I've made a better one than the one I made last time.

That icon, which is also being used for the General Stuff board of this forum, could be used for SDLPoP.
Note however that it is the PoP2 prince, while SDLPoP is a port of PoP1.
The image source is here, by the way.
Created by Luke Sedgeman, who is also the owner of the domain and website the source image is on.
In case David or anyone else wants to contact him, Luke has a contact form here, and uses an e-mail address "accounts TA sedgeman TOD com".

[Falcury]

Here is a new experimental build.
It includes:
- Options fully configurable in SDLPoP.ini
- Improvements to the replay viewing/capturing feature
- Some other small fixes

I also updated the ChangeLog and Readme files.

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.

I added a kill-switch to disable all gameplay tweaks in SDLPoP.ini: setting the topmost option (disable_all_fixes) to 'true' restores the exact original behavior. In this way, everyone should have full control I think?
Getting predictable behavior in replays then of course becomes an issue (when people use different options), but fortunately this is easily solved. The configuration gets remembered when you record a replay - therefore, viewing replays that were originally recorded with a different set-up should still work fine.

- 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.

I have fixed the Makefile and also added options.o (options.c contains the code to load the options from SDLPoP.ini).
I think I did made a mistake with the braces earlier - I used a union type with a struct embedded, so I think that's why the compiler expects double braces around the zero initializer.

Here is the text I proposed in Readme.txt:

[...]
Since version 1.16, you can turn gameplay fixes on or off in SDLPoP.ini.
To simply get the exact behavior of the original game, set the first option (disable_all_fixes) to 'true'.
However, you can also toggle individual fixes.

[...]

REPLAYS
=======

Q: How do replays work?
A:
Starting from version 1.16, you can capture or view replays in SDLPoP.
To start recording, press Ctrl+Tab while in game. To stop recording, press Ctrl+Tab again.
Your replays get saved in the SDLPoP folder as files with a .P1R extension (REPLAY_001.P1R, REPLAY_002.P1R, and so on).

To view a replay, you can press Tab while on the title screen.
The game then looks for replays with the REPLAY_XXX.P1R pattern and plays those in order (you can cycle by pressing Tab again).
You can also double-click on a replay file (and tell the OS that the file needs to be opened with the SDLPoP executable).
SDLPoP will then immediately play that replay. Dragging and dropping onto the executable also works.

Your settings specified in SDLPoP.ini (including whether you are playing with bugfixes on or off) are remembered in the replay.
It shouldn't matter how SDLPoP.ini is set up when you are viewing the replay later.
Note that any cheats you use do not get saved as part of the replay.

If you want to start recording on a specific level, you can use the command "prince.exe record <lvl_number>",
where <lvl_number> is the level on which you want to start.

Also beware that the format of the replay files is not yet final and may change in the future!
So it is possible that replays you record now will not work well in future versions.

Is this an acceptable way for the replay feature to work? Same for the options?

David, could you take a look at the pull requests on GitHub?
Also, do you want to include the shrunk music files with the official download? They do not take up as much space as they did before.

[Norbert]

It's great to see you're still adding improvements.
Good stuff.

The configuration gets remembered when you record a replay

Nice.

To simply get the exact behavior of the original game, set the first option (disable_all_fixes) to 'true'.

My strong opinion on this matter is that, if there is one default, this default should be for the port to resemble the original game as closely as possible. How about this as a solution: when the program starts, ask the user if fixes should be enabled or not. And then present the options "[y]es", "[n]o" and "se SDSLPoP.ini". That way you/we can get rid of having one default. A simple scanf() would be sufficient, I think. What do you think of this idea?

[Falcury]

My strong opinion on this matter is that, if there is one default, this default should be for the port to resemble the original game as closely as possible. How about this as a solution: when the program starts, ask the user if fixes should be enabled or not. And then present the options "[y]es", "[n]o" and "se SDSLPoP.ini". That way you/we can get rid of having one default. A simple scanf() would be sufficient, I think. What do you think of this idea?

Sounds good to me!
I suppose equivalently, there could be three possible settings for disable_all_fixes: 'true', 'false' and 'prompt', with 'prompt' being the default.
The question then remains, should you be prompted only the first time you launch the game, or every time until you edit SDLPoP.ini manually?

[Norbert]

Either would probably be fine. Maybe David has any opinions on the matter. I was thinking that maybe instead of, or in addition to, "fixes", the question could/should include "and enhancements" or "and extensions", since it's doing more than just fix things. I'm not a native speaker of English. Somehow it should be clear that the choice is between having the port behave exactly as the original game, or getting whatever improvements are available.

Falcury, maybe you know this, how difficult would it be to make:
- tile type 0 with modifier 4 display a floor graphic? (which would make it a fake floor)
- tile type 0 with modifier 5 display a wall graphic? (which would make it a fake wall)
- tile type 1 with modifier 6 not display its graphic? (which would make it an invisible floor)
- tile type 1 with modifier 5 display a wall graphic? (which would make it a fake wall; really a floor)
- tile type 20 (0x14) with modifier 6 not display its graphic? (which would make it an invisible wall)
- tile type 20 (0x14) with modifier 4 display a floor graphic? (which would make it a fake floor; really a wall)
This is more or less what yaqxsw asked about here.

[Falcury]

I was thinking that maybe instead of, or in addition to, "fixes", the question could/should include "and enhancements" or "and extensions", since it's doing more than just fix things. I'm not a native speaker of English. Somehow it should be clear that the choice is between having the port behave exactly as the original game, or getting whatever improvements are available.

Agreed!

Falcury, maybe you know this, how difficult would it be to make:
- tile type 0 with modifier 4 display a floor graphic? (which would make it a fake floor)
- tile type 0 with modifier 5 display a wall graphic? (which would make it a fake wall)
- tile type 1 with modifier 6 not display its graphic? (which would make it an invisible floor)
- tile type 1 with modifier 5 display a wall graphic? (which would make it a fake wall; really a floor)
- tile type 20 (0x14) with modifier 6 not display its graphic? (which would make it an invisible wall)
- tile type 20 (0x14) with modifier 4 display a floor graphic? (which would make it a fake floor; really a wall)
This is more or less what yaqxsw asked about here.

I think the easiest would be to modify get_tile_to_draw() in seg008.c. There you can override *ptr_tiletype and *ptr_modifier to become something else - the game is already using this method to draw stuck raise buttons as normal floors instead (you can simply add more conditions!).
I'm going on holiday tomorrow, so I don't have time to test this unfortunately. But I think it should work.

[Norbert]

Cool. I'm definitely willing to help out by changing apoplexy to work with both SDLPoP and the already available DOSBox+original combo. (I already wrote about this in the past, but I cannot find back my own post about this, unfortunately.) I could also make it properly display new potions and tiles and whatnot, and make it possible to quickly add specific new tiles via the custom tiles screen.

[Eugene]

Hello!
I have a suggestion.
If after the start of the game you resize window, I suggest these values remember when closed the game. And the next time you start the game, windows size will restored .
how you like the idea?

Thanks.

[Falcury]

Hello!
I have a suggestion.
If after the start of the game you resize window, I suggest these values remember when closed the game. And the next time you start the game, windows size will restored .
how you like the idea?

Thanks.

I think we could add the window dimensions and a fullscreen on/off option to the configuration file?
In order to remember the last used window size, I suppose we would have to write out to another separate file (like SETUP.DAT)

I'm definitely willing to help out by changing apoplexy to work with both SDLPoP and the already available DOSBox+original combo. (I already wrote about this in the past, but I cannot find back my own post about this, unfortunately.) I could also make it properly display new potions and tiles and whatnot, and make it possible to quickly add specific new tiles via the custom tiles screen.

I think that would be very nice! Perhaps we will first need some sort of consensus about which new features we would like to see and how they should work.
Adding new tiles will of course break backwards compatibility...
But, on the other hand, if apoplexy evolves along with SDLPoP, we will also have the freedom to change the level format in order to enable new possibilities. We could for instance consider extending the 24 room limit, or enable level packs that contain more than 14 levels. Another possibility is to embed mod information into the LEVELS.DAT file itself, such as metadata, simple scripts and/or a CusPoP-like configuration. Or we could define a new SDLPoP-readable container format for mods that includes all the mod's resource data. I suppose it all depends on which direction we want to take.

[David]

[ Falcury submitted his post while I was writing mine. ]

If after the start of the game you resize window, I suggest these values remember when closed the game. And the next time you start the game, windows size will restored .

There is already code (options.c) to load settings from SDLPoP.ini.
The size of the window could be stored there. (Or in a different file?)

By the way, someone asked about MIDI support (again): https://github.com/NagyD/SDLPoP/issues/25
I might try one of the libraries mentioned here: viewtopic.php?p=16126#p16126
There are two parts of the problem: adding *new* music in various formats, and using the *original* MIDIs from PoP.
Adding new music should work if it can already played by itself.
But the original PoP MIDIs need the game-specific instruments.

[Falcury]

Another thing: SuavePrince discovered a peculiar trick in SDLPoP. See https://www.youtube.com/watch?t=91&v=NtQPlPrRKeg
It seems to become possible as a side effect of the "wall bump triggers tile below" fix. The fix changes the action after jumping straight into a wall to be actions_3_in_midair instead of actions_5_bumped - I think the side effect occurs because check_grab() will now be called in check_action() (seg006.c)

[Norbert]

Perhaps we will first need some sort of consensus about which new features we would like to see and how they should work.

I guess, to begin with, the new shadow potion and extra time potion, and the fake/invisible tiles?
David, maybe you could weigh in, mostly about how you see SDLPoP's future when it comes to customizations.
Somewhat related: maybe there could be a save potion; that dying quickloads to the potion's position.

After I'm done with adding SNES support to apoplexy, which will be done next February, I'll:
- add an "SDLPoP" button on the custom tiles screen that will bring up an entirely new screen with all SDLPoP's tiles and such,
- make sure the new tile foreground+modifier combinations show proper graphics instead of question marks (fake tiles will just be green dotted lines or something),
- add a pop-up when initiating playtesting that allows the user to pick between DOSBox and SDLPoP.
Adding SNES support includes large code changes, and I prefer not to do any large code merges.
Better to do stuff in steps. I didn't even expect to be working on apoplexy again, but I'm stuck with my Sparkours project and needed a break.

[musa]

[ Falcury submitted his post while I was writing mine. ]

If after the start of the game you resize window, I suggest these values remember when closed the game. And the next time you start the game, windows size will restored .

There is already code (options.c) to load settings from SDLPoP.ini.
The size of the window could be stored there. (Or in a different file?)

By the way, someone asked about MIDI support (again): https://github.com/NagyD/SDLPoP/issues/25
I might try one of the libraries mentioned here: viewtopic.php?p=16126#p16126
There are two parts of the problem: adding *new* music in various formats, and using the *original* MIDIs from PoP.
Adding new music should work if it can already played by itself.
But the original PoP MIDIs need the game-specific instruments.

You can remap the instruments using a file. Or you could use a Adlib emulator in the code. You don't have to write a new one there are already (free) existing ones.