SDLPoP; David's open-source port of PoP

[Andrew]

It makes me extremely happy that since I last checked out SDLPoP it has attracted other expert coders besides David. This is excellent news and bodes well for the project's future.

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.

Yes, absolutely. First priority should be to create, as far as possible, a "perfect" port of the original so that it behaves just like the original (bugs and all!) but runs natively on modern OSes. This would also ensure 100% compatibility with existing "vanilla" version save games and so on. Later, bugs can be fixed and then new features added.

As a matter of fact, I would even go so far as to advocate two separate branches - the first being SDLPoP which would have no bug fixes or new features and once perfected would be essentially frozen, and the other being Enhanced SDLPoP (eSDLPoP?) with all the bells and whistles that would continue being worked on. Ideally (IMHO) SDLPoP's EXE would moreover be a simple drop-in replacement for the original, i.e. it would use all of the original data files (but perhaps accomplishing this would require too much effort?).

What do people think about this, especially the two branch idea?

[Norbert]

First priority should be to create, as far as possible, a "perfect" port of the original [...]

Correct me if I'm wrong, but I think this is already finished.
It uses MP3/OGG for the music instead of MIDI, but everything else is finished.
We already tested all tricks/bugs, and they are as the original.

Later, bugs can be fixed and then new features added.

That's where we are now, and there are already fixes for various things, and also new features.

two separate branches

There's no need, we just got the neat Y/N thing, and the INI is already being used.

it would use all of the original data files

That too is already possible. If you dump the DAT files in the directory, SDLPoP uses those.

[Andrew]

Correct me if I'm wrong, but I think this is already finished.
It uses MP3/OGG for the music instead of MIDI, but everything else is finished.
We already tested all tricks/bugs, and they are as the original.

I haven't had a chance to play around with 1.15 yet. So, the recreation of the original, warts and all, is perfectly accomplished with 1.15? If so that's excellent! Edit: Ah yes, the music. I think I remember reading that David was thinking about implementing support for the original game sound and music formats? If that can be accomplished it would make SDLPoP perfect IMO, although it's almost there in its current state.

There's no need, we just got the neat Y/N thing, and the INI is already being used.

I'd love a copy of the final SDLPoP code before any bug fixes and new features were added, but if I'm not mistaken this isn't possible because David had been adding bug fixes at least all along? Thus I'd still prefer separation so that at least one "pure" copy is available (and maybe, ones hopes, in the distant future a similar port of 1.3 and/or 1.4 as well).

That too is already possible. If you dump the DAT files in the directory, SDLPoP uses those.

That's brilliant but it's still not quite a drop-in replacement for the PoP1 1.0 EXE. Then again, perhaps no-one else is interested in something like that but me...

[Falcury]

Very nice.

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

Thank you!

The text, two minor suggestions. Maybe change:

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

No, I think it makes good sense to be very careful with the language here. It was indeed difficult to cram a lot of information into as few words as possible (I tried to be economical). Implicitly: "This disables some game quirks, including some that certain tricks depend upon - these will no longer work." I think "to set preferences" is grammatically correct, but I agree that the sentence may cause confusion because it is ambiguous.
(I'm not a native speaker either, by the way.)
So how's this?

To clarify "Certain tricks will no longer work by default": I added "by default" in order to imply that fine-tuning is possible.

It makes me extremely happy that since I last checked out SDLPoP it has attracted other expert coders besides David. This is excellent news and bodes well for the project's future.

Feel free to join in Mind you, I don't consider myself to be an "expert" coder (yet).

As a matter of fact, I would even go so far as to advocate two separate branches - the first being SDLPoP which would have no bug fixes or new features and once perfected would be essentially frozen, and the other being Enhanced SDLPoP (eSDLPoP?) with all the bells and whistles that would continue being worked on. Ideally (IMHO) SDLPoP's EXE would moreover be a simple drop-in replacement for the original, i.e. it would use all of the original data files (but perhaps accomplishing this would require too much effort?).

I'd love a copy of the final SDLPoP code before any bug fixes and new features were added, but if I'm not mistaken this isn't possible because David had been adding bug fixes at least all along? Thus I'd still prefer separation so that at least one "pure" copy is available (and maybe, ones hopes, in the distant future a similar port of 1.3 and/or 1.4 as well).

Well, it would be entirely possible to maintain a "minimal" release of SDLPoP. I don't know about the name though. And it would be fantastic to have a way of running SDLPoP in "1.3 mode" or "1.4 mode" (I suspect that having separate codebases for these wouldn't be necessary because the version differences are relatively minor, so it is possible that a simple compilation switch can do the trick)

[Norbert]

So how's this?

Better, in my opinion.

I'm not sure the following is an improvement; just throwing it out there: maybe change "This option disables some game quirks." to "This will disable some original game quirks." ?

Maybe make "X" the key for original behavior. I know this is a bit weird, but I'm thinking ahead. In 2016 I may want to add SDLPoP options to apoplexy, and it would be nice if, when we use apoplexy with a gamepad, the splash screen would mention letters that are available on most gamepads. Alternatively, the splash screen could be different for gamepad users. I'm not sure what would be the preferred choice here, consistency for just the application itself (Y/X for both keyboard/mouse and gamepad users) or across applications (Y/N is what keyboard/mouse users are used to, A/B for gamepad users). Actually, now that I'm thinking about it, just A/B would also be an option. Choice A (= yes), choice B (= no), makes sense for both keyboard/mouse and gamepad users. Just some thoughts.

[Andrew]

Feel free to join in Mind you, I don't consider myself to be an "expert" coder (yet).

Oh, if I could've, I would've! I assure you, from what I've seen so far on GitHub you're much more of an expert at this than me. Of course, as always I remain in awe of David's 1337 h4x0r skillz.

Well, it would be entirely possible to maintain a "minimal" release of SDLPoP. I don't know about the name though.

What's in a name? That's hardly important and can be anything. I would love to see such a minimal release though, kept separate from subsequent additions.

And it would be fantastic to have a way of running SDLPoP in "1.3 mode" or "1.4 mode" (I suspect that having separate codebases for these wouldn't be necessary because the version differences are relatively minor, so it is possible that a simple compilation switch can do the trick)

That's a great idea, and probably much easier to keep track of than separate codebases. A bunch of #ifdefs and conditional compilation ought to do the trick. I've also seen some programs behave differently based on their filenames, so I can just imagine it now... The same executable named as Prince10.exe, Prince11.exe, Prince13.exe or Prince14.exe automatically behaving like the original versions did respectively, quirks and all.

Maybe make "X" the key for original behavior. ... I'm not sure what would be the preferred choice here, consistency for just the application itself (Y/X for both keyboard/mouse and gamepad users)

If you're posing a question then Y/N are the obvious options to use. Y/X will just confuse the heck out of people. Just my 2¢.

[Norbert]

Maybe make "X" the key for original behavior. ... I'm not sure what would be the preferred choice here, consistency for just the application itself (Y/X for both keyboard/mouse and gamepad users)

If you're posing a question then Y/N are the obvious options to use. Y/X will just confuse the heck out of people. Just my 2¢.

Sure.
I primarily meant that we may want to think about gamepads from the start.

The screen doesn't just have the question, it presents the user with an additional overview of the options.
- - - - - - - - - -
Enable ...?

A: enhanced behavior
B: original behavior

A / B ?
- - - - - - - - - -
Is not that confusing, and it would work with both gamepads and keyboards.
Then again, different text if a gamepad is plugged in would also work.

[CRxTRDude]

Hey guys, if you try to well basically package the things, you may want to separate the builds for various systems instead of cramming all builds into one compressed file.

I did manage to make them run to my system removing some of the stuff not needed.

I also think it's not needed to add in the readme on music that the mp3 and flac does not work. They will not work because you're using libogg, and it's in the right direction to use OGG since it's open source than the rest of those two. Although there is a way to make their compression better though to make them smaller and then make them as a separate download for SDLPoP than using the ones in PoPOT, so that they'll just decompress it directly.

I would also suggest maximizing Github's capabilities through branches. You could work on features separately from the masters, allowing you guys to make the replay in peace without screwing the main branch.


Also, I would suggest adding on Readme.md that issues need to be placed in the forums instead on Github. I don't think you guys use the Issues feature of Github often.

[Falcury]

I added a pull request for the dialog box and the open potion placement in the copy protection level. I probably made some mistakes here and there because I'm not experienced at disassembly. But I'm happy that I got it to work. David's function names and annotations in the disassembly were very helpful for some of the functions that didn't have a C version yet.

Also, I see David added some very neat things (support for 1.3/1.4 colors and 1.3/1.4 WAV format).

Here is a new test build for Windows, for those who want to try out the new stuff:

SDLPoP_v1.16b4.zip

(4.75 MiB) Downloaded 242 times

To test the alternate colors, place Prince.dat from V1.3 in the SDLPoP directory. Same for Digisnd1.dat, Digisnd2.dat and Digisnd3.dat for the 1.3 WAV files.
To test the copy protection level, set 'enable_copyprot' to 'true' in SDLPoP.ini.

I also think it's not needed to add in the readme on music that the mp3 and flac does not work. They will not work because you're using libogg, and it's in the right direction to use OGG since it's open source than the rest of those two. Although there is a way to make their compression better though to make them smaller and then make them as a separate download for SDLPoP than using the ones in PoPOT, so that they'll just decompress it directly.

Welcome to the forum
The OGG music files have already been recompressed. But I do not think these were included yet in the latest ZIP (however they can be found on GitHub).

Also, I would suggest adding on Readme.md that issues need to be placed in the forums instead on Github. I don't think you guys use the Issues feature of Github often.

Both are probably fine to use, I guess?

[Norbert]

It has become almost impossible to make a running jump using a gamepad.
I can't promise I'll be able to help, but I'll take a look at the source code.

[Norbert]

It has become almost impossible to make a running jump using a gamepad.
I can't promise I'll be able to help, but I'll take a look at the source code.

Okay, here are my findings.

1. First of all, given how the joystick code currently works, I was wrong about the (-)30000 values.
Those need to be (-)8000 values or it's impossible to combine directions, such as left+up.

2. This adds D-pad support:

Spoiler: show

Code: Select all

Add to data.h:
----------
extern int dpad_states[2] INIT( = { 0, 0 } );

Change in read_joyst_control() of seg000.c:
----------
if ((joy_states[0] == -1) || (dpad_states[0] == -1))
if ((joy_states[0] == 1) || (dpad_states[0] == 1))
if ((joy_states[1] == -1) || (dpad_states[1] == -1))
if ((joy_states[1] == 1) || (dpad_states[1] == 1))

Add to seg009.c:
----------
case SDL_JOYHATMOTION:
  switch (event.jhat.value)
  {
    // [0] = hor | [1] = ver
    case 1: dpad_states[0] = 0; dpad_states[1] = -1; break; // up
    case 2: dpad_states[0] = 1; dpad_states[1] = 0; break; // right
    case 3: dpad_states[0] = 1; dpad_states[1] = -1; break; // right + up
    case 4: dpad_states[0] = 0; dpad_states[1] = 1; break; // down
    case 6: dpad_states[0] = 1; dpad_states[1] = 1; break; // right + down
    case 8: dpad_states[0] = -1; dpad_states[1] = 0; break; // left
    case 9: dpad_states[0] = -1; dpad_states[1] = -1; break; // left + up
    case 12: dpad_states[0] = -1; dpad_states[1] = 1; break; // left + down
    default: dpad_states[0] = 0; dpad_states[1] = 0; break;
  }
  break;

3. In my opinion, currently, neither the joystick nor the D-pad work properly. The problem is that on the one hand it often doesn't react to certain input when you want it to, while on the other hand it often reacts to certain input when you don't want it to. It's all over the place. For example, when I printf the event.jhat.value and only press to the lower right on the D-pad I should see 6 constantly but many, many 4's show up. The joystick is even worse.

My suggestion is to use both the D-pad and the joystick for movement left and right, and use buttons to jump and crouch.
Of course this might make using 'Shift' with jump/crouch trickier, but with X as Shift and A/Y for jump/crouch, I think this should work.

(Also, moving to the Game Controller API would be a good idea. See this section in the migration guide.)

[Falcury]

Kind of makes me want to buy a controller so that I can actually test this and play around with it...
As I don't have one at the moment, I'm not much help
1. and 2. would be good to put into a PR on GitHub, I think?

[Norbert]

Kind of makes me want to buy a controller so that I can actually test this and play around with it...

I'm curious, what is preventing you from actually buying one? Aren't you curious enough to see and feel what it's like to play it using a gamepad? My gut tells me that the Xbox 360 controller is the most used and best supported gamepad in the world, so it never hurts to have one laying around.

1. and 2. would be good to put into a PR on GitHub, I think?

Perhaps. But in my opinion it would be better to have someone confirm (or dismiss) what I wrote about the current problems with using a gamepad with SDLPoP. If it's not just me holding the game controller strangely, then the code should be rewritten to make the gamepad work as I suggested in my previous post. Also, the Game Controller API is a better solution and should be used. That old SDL 1.2 Joystick API is still available in 2.0, but it's uglier, because it returns different values for the same actions depending on the OS and controller and produces less readable code.

[Falcury]

I'm curious, what is preventing you from actually buying one? Aren't you curious enough to see and feel what it's like to play it using a gamepad? My gut tells me that the Xbox 360 controller is the most used and best supported gamepad in the world, so it never hurts to have one laying around.

I am certainly curious; but I never really felt an acute urge to buy one... Well, I might pick up an Xbox 360 controller then, when I have the chance.

[Norbert]

I noticed the cutscene before level 2 cannot be interrupted while it's fading in, while this is possible with the original DOS game. I didn't test other cutscenes.