Norbert wrote:The newer version uses the D-pad and (left) joystick for moving left and right, X as 'Shift', Y to jump and A to crouch. I've coded and tested this with my Xbox 360 controller. I'm happy with how it plays, where necessary one thumb is enough to combine two buttons. Also, up for up and down for down makes sense.

Ah, yes then I definitely see what you mean.
I found that A and Y are maybe too far apart to be comfortable to be used as the only controls for up/down? And moving quickly between shift/X and pressing A or Y is a bit hard. Anyway, I liked that there are multiple ways to do the same thing...
And at least there are enough alternative solutions to choose from!
I'm a bit too tired to continue thinking about this right now, maybe tomorrow

Looking at the game manuals, it seems the 'originally intended' way is to use the stick for all movement. I suppose this is understandable as the old joysticks apparently had far fewer controls, like shown for example in this post:viewtopic.php?f=68&p=19749#p19739

I also found this, which someone wrote in a guide:

Movement
~~~~~~~~
Although you can play with a joystick, I find that keyboard control is
a bit more responsive. It may just be my joystick, however. Play with
it and decide which you prefer. Control-K switches to keyboard
control. I think Control-J will switch to your joystick and calibrate
it.

So it seems the original joystick controls were already not the easiest to use... Still, apparently all-directional movement with the joystick is what players at least initially seem to 'expect' as the logical behavior (like I did as well).
So I suppose it would be best that the 'default' controller setting emulates this in the best way possible.

Still, I must admit that playing through the game with Y-movement disabled entirely is quite nice. You can have your right thumb 'rest' over the center of the A/X/Y key area and this gives very good control.

So perhaps we should do these two things...
- Make the default behavior 'as good as possible' for everyone who does expect the all-directional joystick movement. And we can try to reasonably reduce the annoyance about unintended vertical movement by decreasing the vertical sensitivity a bit further.
- Add a second mode where the sticks only do the X-axis.

It might be better with joysticks that can only move in 8 directions, if the joystick physically forces the user to specifically pick, for instance, either left or top left. But most modern controllers don't do that. We cannot change the physical properties of joysticks of modern gamepads via software. If we want to stay close to the original, the program should detect the gamepad and only use the original behavior if the hardware is an old-fashioned joystick. I still disagree with trying to get "all-directional joystick movement" to work. The joysticks were also bigger back then and were operated with multiple fingers or the entire hand. It's not the same hardware. Back then restrictor gates would physically help the player pick a direction. With, for example, an Xbox joystick, that is not happening, and if your thumb is off by more than 22.5 degrees, the game messes up. If you're playing a hard mod and are 10 minutes in, the last thing you want is for the game controller to mess up your run.

If the joysticks only do the X-axis, up and down could still be used for something. (Just nothing diagonal.) This means up could potentially be used as a combo of both up and the last direction the prince was running in/facing. If you know what I mean. And if the prince is not running, up could just be up. Something might be possible this way.

Norbert wrote:If we want to stay close to the original, the program should detect the gamepad and only use the original behavior if the hardware is an old-fashioned joystick. I still disagree with trying to get "all-directional joystick movement" to work.

Well, that is in part what I have been trying to do... You're right, it's certainly never going to work flawlessly, but, acknowledging that the controller hardware has changed, I think it was at least worth it to get the "legacy" controls working acceptably... (heh, and I would hate to throw away the progress I made )
I'm not sure how we could go about detecting different controller varieties... I suppose the easier option is to add a setting so that people can pick their preferred style.

What you mentioned about unwanted movements when turning around quickly: I improved that a bit by decreasing the Y-sensitivity near the neutral position, as well as clearing the remembered input during the turn animation.

Edit:

Norbert wrote:If the joysticks only do the X-axis, up and down could still be used for something. (Just nothing diagonal.) This means up could potentially be used as a combo of both up and the last direction the prince was running in/facing. If you know what I mean. And if the prince is not running, up could just be up. Something might be possible this way.

Yeah, I suppose the diagonal input is indeed the biggest problem...
If I understand you correctly, I kind of did something like this for running jumps and crouch-hops. For running jumps, you can slide the stick upward along the edge, all the way to the top, and the original direction will then be remembered (the kid keeps on running) until the stick returns all the way back to the neutral position. For crouch-hops, it used to be that when you slide along from the downward to the sideways direction, the "down" control gets released, so the kid stands up while you just wanted to do a crouch-hop - so using the technique you mentioned in this case you one can make it work like a "diagonal" input by ignoring the release of the vertical axis until the stick actually returns to the neutral position.

I feel a bit mentally drained thinking about SDLPoP and joysticks.
I guess whatever you've molded it into and whatever the default is now is probably fine, given your skills.
It's interesting to me that your (professional) background is in such a different field of study.

Starting version 1.15, the .c files are UTF-8 instead of ASCII.
No idea why, to be honest, but that's not the reason of this post.
What I noticed is that replay.c and options.c say "D�vid" instead of "Dávid".

Also, at least under Linux, replay saving is broken in the GitHub master branch.
And when there is no save file, using Tab gives a segmentation fault.

Upon pressing Tab on the title screen, check that there are actually >0 replays present before trying to load the first one

Changed window title for 1.17

Controller: use normal Y-axis sensitivity in all-directional mode

After playtesting the all-directional controller mode some more, I concluded that reduced Y-sensitivity didn't really help very much... And it is annoying because climbing and jumping becomes less responsive. So I undid this change from commit c7fd07c.

Updated Changelog

Split the entries into a few categories for easier reading (general changes, game additions/changes/fixes, build changes/source code/refactoring)

Added the most recent changes

Removed some entries that mention the same thing a second time

Other small tweaks

Updated Readme

Added thanks to usineur for contributing

Updated gamepad controls documentation

Updated replays documentation

Edit:

A question: I am nearing the release of a new version of my mod, which uses a customized version of SDLPoP.
I could package the mod like I did earlier versions (basically, a SDLPoP folder with custom .exe and data files). This is probably what I'll do.
Or, I could also try to use the recently added "mod folder" method, but then I have the problem of how to launch a custom executable from a mod folder...
A solution might be to allow the prince.exe in the main folder to function as a kind of general 'launcher' for mods with custom executables. The customized executable might be compiled as a shared library (.dll or .so file) - at startup, prince.exe would detect the presence of the file mod.dll (for example), and it would then give complete control to the compiled mod.
We might also launch poirot's editor this way, come to think of it.
What are your thoughts on this? It is just an idea for how we might allow custom compiled SDLPoP mods. (I'm not saying that we should definitely do this!)

Nice to read that the replay feature should work again. I'll (re)try it out soon. I already want to write that I would like to look into finding a way to allow popot.org users to upload replay files. Maybe allow them to add a completion time too, or have the website calculate it based on the replay content. Either way, it would be cool if people can easily share, obtain and replay solutions. This would also give SDLPoP the attention it deserves. I haven't looked into it much, but from what I remember these replay files are - and should be - a lot smaller than videos uploaded to YouTube. This means storage space and traffic shouldn't be a problem.

On a related note, if possible, I suggest putting back an informational slide right at the start of SDLPoP, where it used to ask about enabling fixes/enhancements. The slide could list keyboard shortcuts, either a general overview or with just the things unique to SDLPoP. Of course, closing this slide should be possible with both the keyboard and the gamepad. I would really like to see the quick load/save and replay keys (and save path) there. These are part of SDLPoP's selling points. Currently, it's logical for users who don't dive into documentation to think SDLPoP is 'just' a way to play PoP1 without using DOSBox. Those who use just the GUI, just click the executable, will never see anything else. Maybe also mention SDLPoP.ini on this slide.

I don't know if end of line comments are possible in SDLPoP.ini, but if they are, maybe something like
start_minutes_left = default
could say
start_minutes_left = default ; The default is 60.
or
start_minutes_left = default ; default = 60
This gives users extra information and might also make it clearer to them that they can actually add a custom number there to modify the game's behavior.

I think, depending on how 1.17 will turn out exactly, that I will also modify popot.org to provide SDLPoP by default. On the page that allows visitors to download PoP1, for instance. And if we take the whole replay route, then it also makes sense to swap out executables of mods, as - I think - you suggested earlier. I'll definitely get back to all this soon; just wanted to share some first thoughts.

Norbert wrote:I already want to write that I would like to look into finding a way to allow popot.org users to upload replay files. Maybe allow them to add a completion time too, or have the website calculate it based on the replay content. Either way, it would be cool if people can easily share, obtain and replay solutions. This would also give SDLPoP the attention it deserves. I haven't looked into it much, but from what I remember these replay files are - and should be - a lot smaller than videos uploaded to YouTube. This means storage space and traffic shouldn't be a problem.

That definitely sounds interesting! Yes, the replays are a few kB at most each.

Norbert wrote:On a related note, if possible, I suggest putting back an informational slide right at the start of SDLPoP, where it used to ask about enabling fixes/enhancements. The slide could list keyboard shortcuts, either a general overview or with just the things unique to SDLPoP. Of course, closing this slide should be possible with both the keyboard and the gamepad. I would really like to see the quick load/save and replay keys (and save path) there. These are part of SDLPoP's selling points. Currently, it's logical for users who don't dive into documentation to think SDLPoP is 'just' a way to play PoP1 without using DOSBox. Those who use just the GUI, just click the executable, will never see anything else. Maybe also mention SDLPoP.ini on this slide.

Like this perhaps?

splash.png (1.15 KiB) Viewed 270 times

I backported this from my mod, for which I already added the splash screen for these reasons you mentioned earlier as well. I suppose you are correct that something like this might also be useful in unmodified SDLPoP.
In the implementation I have now, a random tip is displayed. I now have the following pool:

Cycling through tips is a fancy solution, but I suggest making sure that first-time users immediately get a good impression of the customizability of the program. That first impression may be all they're willing to give it, which means they could miss interesting information otherwise. Something like this should fit, if necessary with fewer newlines:

SDLPoP 1.17
To quick load/save, press F6/F9 in-game.
To record replays, press Ctrl+Tab in-game.
To view recorded replays, press Tab on the title screen.
Edit SDLPoP.ini to customize SDLPoP.
Mods also work with SDLPoP.
For more information, read doc/Readme.txt.
Questions? Visit http://forum.princed.org

If possible, please add an SDLPoP.ini option to disable the splash screen.

Also, I suggest using "1.17" only in a single location, e.g. #define VERSION "1.17".
And then using that in other defines or locations in the code.
(Note that defines allow the inclusion of other defines.)

I hope it's okay that I keep suggesting things from the sidelines, even though I'm a programmer myself.

Falcury wrote:That definitely sounds interesting! Yes, the replays are a few kB at most each.

More or less what you suggested a bunch of posts back, I think.
I have created a new thread to discuss this further here.