SDLPoP; David's open-source port of PoP

[Falcury]

- 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 got the fake/invisible tiles somewhat working. I haven't made a pull request yet though, it's buried in my mod branch (sorry, I was lazy, I'll try to fix it later). This is the commit:
https://github.com/Falcury/SDLPoP/commi ... 7adb67e5f6

I added a way to emulate the "noblue"/"blue" option in the palace environment.
For some reason I thought that it would be a good idea to use a specific bit for this, so at the moment the upshot is that you add 8 to the modifier to get the alternate "noblue"/"blue" option.

The walls were rather tricky to do...
The game automatically recalculates the modifiers when the game is launched. The "blue"/"noblue" info is left-shifted into the most significant bit (so the modifier becomes either 0 or 128, all other info is thrown out), and then the game adds the wall connection data back in (either 0, 1 or 2, based on which neighbouring tiles are also walls).
So, to get wall modifiers 4 and 6 to work, I had to change load_alter_mod() in seg008.c so the modifier information would not be lost.
Another problem is that when you add fake walls in the dungeon environment, the game doesn't automatically get their wall connections right (it only checks for true walls). This could probably be fixed, but for now I hard-coded the wall connections for fake dungeon walls, using yet more special tile modifiers.
In short, to get a fake dungeon wall to display the way it should, for now you can use the following modifiers:

50 (palace) = fake wall (noblue)
5 or 50 (dungeon) = fake wall with no connections
51 (dungeon) = fake wall connected to wall on the right
52 (dungeon) = fake wall connected to wall on the left
53 (dungeon) = fake wall connected to walls on both sides

You can of course ignore this but it will look bad

[David]

Yes, I saw you made lots of changes there.

A few days ago I got an e-mail about this: https://github.com/Falcury/SDLPoP/commi ... 7a5f210ac8
Now that I look at it, it seems I got the mail because you mentioned me.

[SuavePrince]

Hi,is possible add option to change time,guard life,and other things..maybe can add in the next version

[Norbert]

Hi,is possible add option to change time,guard life,and other things..maybe can add in the next version

This would be useful.

By the way: note that, just like the original game, if you start SDLPoP with cheats enabled, you can use -/+ to change time and can kill guards with "k".
For example, for level 6 with cheats enabled:
SDLPoP.exe megahit 6
Or, for Secrets of the Citadel:
SDLPoP.exe fullscreen hard megahit 6

[David]

Hi,is possible add option to change time,guard life,and other things..maybe can add in the next version

You can change those in the source.

[SuavePrince]

You can change those in the source.

For example i need use allow triggering of any tile..add options such as cuspop or better created prince exe such as web-based version...i think be great help for all prince player,too make video how change(to modify)..i want use my mods with sdlpop,more easy and joyful for all people thanxsss

[salvadorc17]

You can change those in the source.

David, will be not better for those that does know how to compile, change those options into a config text file??

[Falcury]

OK, I created a couple of new pull requests:
- Demo mode: running the program with command line argument "demo" activates the demo mode of Prince of Persia 1. The game will display quotes from a couple of game reviews after beating level 2, and then restart.
- Alternate fix for guards following through closed gates: This fix was intended to stop guards following the kid to a different room when this is actually impossible due to an obstable. Now works both ways (left and right) and more reliably.
- Add collision vars, Char, Opp to quicksave list to fix unexpected behaviour
- Add ability to draw fake/invisible tiles: see earlier post.

I was thinking about the way we currently serialize and deserialize savestates and options. The current method is very effective and efficient: the memory contents is simply dumped into another buffer and later restored when it is needed. However, a limitation of this approach is that it depends on a carefully predetermined order of the variables. For example, one consequence of this is that quicksave and replay files become very un-future-proof: any slight change in the format can cause them to stop working or give unexpected results.
To solve this, we could perhaps try to use a serialization format that stores the specification of the data along with the data itself. We could (where necessary) use key/value pairs and thereby give ourselves much more flexibility to move things around or add new things. Quicksaves/replays created by older versions of SDLPoP could then fail more gracefully when there is a version mismatch. It would be possible to issue a warning like: "Warning: the variable 'curr_row_coll_room' could not be restored (data not found)"
I don't know if anybody has experience doing this. It seems that JSON is a popular format, but JSON would probably be unnecessarily bulky. MessagePack and Binn seem to be good lightweight options though. Or we could roll our own solution (but I don't know if that would be worth it).

A few days ago I got an e-mail about this: https://github.com/Falcury/SDLPoP/commi ... 7a5f210ac8
Now that I look at it, it seems I got the mail because you mentioned me.

Interesting, I did not know that GitHub does this!

You can change those in the source.

David, will be not better for those that does know how to compile, change those options into a config text file??

I agree that some configurable CusPoP-like features will be nice to have. I could try to work on it, although I'm also quite busy at the moment.
So I think this is the "to do" list for now?
- Add a prompt for enabling/disabling the game fixes & enhancements
- Improve the fake/invisible tiles, if people have ideas on how to do this
- Add some CusPoP-like customization features, for mod makers
- Fix the joystick controls
- Figure out a good way to integrate the custom potions
- (Maybe?) Try out another serialization format
- (Maybe?) Add support for midi files

[Norbert]

Maybe a certain range of potion modifiers could refer to line numbers in a text file, that drinking a potion could display text in the text bar.
With a specific bubble color that indicates the potion is a text potion?

[Falcury]

Hm, interesting, from there it seems just a small step to full-featured scripting... (here is an example in another game; well, actually implementing something like that might of course take a great effort)
By the way, what are your ideas on the appearance of the proposed checkpoint potion?

[David]

- Fix the joystick controls

Do you mean what Norbert wrote here and here, or is there some other problem?

[Falcury]

- Fix the joystick controls

Do you mean what Norbert wrote here and here, or is there some other problem?

Yeah that's what I meant But perhaps it was dealt with already, I might have missed it.

[David]

It's not done yet.
Right now I changed the cut-off point as Norbert wrote.
Remember that I can't test it.

As for the D-pad, should it be another option, next to Ctrl-K and Ctrl-J?
Or maybe merge the D-pad buttons with the keyboard state?
I.e. when a button is pressed on the controller, do as if the corresponding key was pressed on the keyboard.

[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?

OK, how about this:

Here is the pull request.

[Norbert]

Very nice.

And, more generally speaking, it's cool to see the positive impact of SDLPoP being open source.

The text, two minor suggestions. Maybe change:

"disables some game quirks"
to
"disables some game quirks and tricks"
or, if by quirks you mean just tricks, to
"disables some tricks"
?
(Or, "game quirks that allow for tricks", or something.)

"To set your preferences"
to
"To fine-tune your preferences"
or
"To fine-tune settings"
?
(I'm not a native speaker. Can you set preferences? Or do you /have/ preferences, and /set/ settings?)

I'm suggesting the latter because someone unfamiliar with SDLPoP will see a Y/N choice and then "To set your preferences [...]". Without specific knowledge of SDLPoP, 'setting preferences' is rather vague and possibly multi-interpretable. While preferences is plural, after reading the other text, it could be interpreted as merely a way to set a default for the Y/N choice. If I'm not mistaken, the INI file allows the user to both set default(s) and fine-tune which fixes and enhancements are enabled.

Maybe try to be more specific. Something like
"To set a default behavior and thereby bypass this screen, or to fine-tune [etc]"
Or maybe use "additional settings" in there somewhere.

Right now it says "To set your preferences" and the reader may think 'But I am already setting it, I'm picking Y or N, so why would I use the INI file?'

I hope I am not splitting hairs or being nit-picky.