SDLPoP; David's open-source port of PoP

[Falcury]

Falcury, good idea, changing the default for use_custom_options to "true"?

I think that the reason I liked it turned off by default, is that it protects against unexpected behavior if you accidentally fiddle with the settings (which is maybe rather easy to do in the menu interface). But you could change it, if you think it's best.
I guess this relates to the limitation that SDLPoP cannot modify the ini file, and instead relies on a binary configuration file to remember its settings. Maybe writing settings to the ini file directly is something we should add. (That would probably involve writing a more sophisticated ini parser than the simple one we are using now.)

[Norbert]

I think that the reason I liked it turned off by default, is that it protects against unexpected behavior if you accidentally fiddle with the settings (which is maybe rather easy to do in the menu interface).

If I understand your parenthesized phrase correctly, you're saying perhaps CFG modification needs similar protection. Maybe menu entries that are set to non-default values could have a different color, to stand out from the rest. It's what I'm doing on the 'EXE screens' of my level editors, with blue text.

Maybe writing settings to the ini file directly is something we should add.

I don't think I understand why two separate options (INI and CFG) exist; why the menu doesn't modify the INI file. But I'm guessing, based on your comment, it's simply complicated to parse the INI file, which I can imagine. On top of that, I think there's a third config option for mods? I think only you (Falcury), and perhaps David, get how that one works; I don't see many people using that...

Either way, as I wrote, I think use_custom_options is far too easy to overlook when you're trying to make changes further down the INI file, and then don't get why things aren't being impacted by changes you make. Protection against accidental fiddling is well-intended, but maybe unnecessary. After all, the user consciously decided to open, modify and save the INI file...

[David]

I don't think I understand why two separate options (INI and CFG) exist; why the menu doesn't modify the INI file. But I'm guessing, based on your comment, it's simply complicated to parse the INI file, which I can imagine.

INI parsing is already solved, the problem is saving the new settings into the INI while keeping all the comments intact.
I already mentioned this here: viewtopic.php?p=21524#p21524 (after the last quote)
But, come to think of it, it's indeed the parser that needs to remember all the comments.

On top of that, I think there's a third config option for mods? I think only you (Falcury), and perhaps David, get how that one works; I don't see many people using that...

A mod's configuration is simply another INI file located at mods/<name>/mod.ini, in the same format as SDLPoP.ini .

Either way, as I wrote, I think use_custom_options is far too easy to overlook when you're trying to make changes further down the INI file, and then don't get why things aren't being impacted by changes you make. Protection against accidental fiddling is well-intended, but maybe unnecessary. After all, the user consciously decided to open, modify and save the INI file...

I think that the reason I liked it turned off by default, is that it protects against unexpected behavior if you accidentally fiddle with the settings (which is maybe rather easy to do in the menu interface). But you could change it, if you think it's best.

So, should I change it now?

[Norbert]

Mentioned here:
https://www.linuxadictos.com/sdlpop-un- ... -snap.html

[Falcury]

Here is a new Mac build of SDLPoP, based on this branch.
It should work on Mac OS 10.6 and later. It has support for high DPI ('Retina') screens. (Although on high DPI screens there is an issue with the positioning of the mouse cursor on the menu screen.)

I have been working recently on improving compatibility with earlier Mac OS X versions. It's been quite an 'adventure'... If people are interested, maybe I could make a longer post detailing all of the steps necessary for building SDLPoP on the Mac platform, including the multitude of problems I ran into.

Also, it looks like running SDLPoP on big-endian systems (including PowerPC-era Macs) could be supported at some point. Although it isn't quite there yet; there are still some issues to be solved. See the GitHub issue here:
https://github.com/NagyD/SDLPoP/issues/185

[Falcury]

Although on high DPI screens there is an issue with the positioning of the mouse cursor on the menu screen

Here's a new build with the Retina screen mouse position issue fixed (commit).

Edit: changed the disk image format so it will actually mount in older Mac OS versions... sigh.

[Norbert]

Although on high DPI screens there is an issue with the positioning of the mouse cursor on the menu screen

Here's a new build with the Retina screen mouse position issue fixed (commit).

Is this mostly for testing, or a suitable replacement for (upgrade of) SDLPoP-1.18.1.dmg here?

[Falcury]

Is this mostly for testing, or a suitable replacement for (upgrade of) SDLPoP-1.18.1.dmg here?

Yes, it would probably be fine to update/replace the download package with this one. I have just now tested it again, it seems to work as expected on Mac OS 10.6 and 10.14. Although it's probably best if other people can also test it and verify that it works.

Strictly speaking it's not a 'clean' 1.19 build, because it includes some post-1.19 fixes (for example, this one). Although I guess it probably also doesn't make much sense to go back to an earlier state. In addition, the changes from David's big-endian branch are merged, and I made a bunch of changes on this branch. Still, all of those changes don't really impact the functionality. And the 1.18.1 package also diverged a bit from the main line, so this one is not very different in that regard...

[Norbert]

Yes, it would probably be fine to update/replace the download package with this one.

Alrighty, done.

[Norbert]

Anyway, the overarching goal is to be able to play (nearly) all DOS mods out of the box.
With the addition of MIDI support and completing the set of CusPop options, that goal is getting closer.

I have no idea how difficult the following would be to implement, but maybe one day it could also have a customizable
loose_floor_delay = 11
which could be changed up to 127 (7F).

And which would make three changes:
viewtopic.php?p=14274#p14274
"80 3E 28 43 0B, change 0B to the number of frames between touching and falling"
"F6 46 06 80 74 0F, change 74 0F to 90 90"
viewtopic.php?p=14282#p14282
"80 7E FE 00 75 D3, change 75 D3 to 90 90"

Of course, this suggestion/request is primarily self-serving, as it would make my upcoming Neon Persia playable with SDLPoP.

[David]

I have no idea how difficult the following would be to implement, but maybe one day it could also have a customizable
loose_floor_delay = 11
which could be changed up to 127 (7F).

Done on a new branch: https://github.com/NagyD/SDLPoP/commit/ ... 54c7a9d93d

Of course, this suggestion/request is primarily self-serving, as it would make my upcoming Neon Persia playable with SDLPoP.

I tried that mod and I found a bug in the detection of the "allow triggering any tile" hack.
I fixed it on the same new branch: https://github.com/NagyD/SDLPoP/commit/ ... 605de16329

Please test it, and if you too think that it works correctly then I will merge the branch.

[Norbert]

Done on a new branch: [...]

Cool, thanks for that.
Maybe time for a new release, on October 3rd?

Please test it, and [...]

Yes, I'll check it out soon (tomorrow).
I'll create a new post with my findings.

[Norbert]

Yes, I'll check it out soon (tomorrow).
I'll create a new post with my findings.

It works, both the PRINCE.EXE auto-detection (e.g. playtesting via apoplexy) and modification of the INI.

By the way, I still keep running into this:

Either way, as I wrote, I think use_custom_options is far too easy to overlook when you're trying to make changes further down the INI file, and then don't get why things aren't being impacted by changes you make. Protection against accidental fiddling is well-intended, but maybe unnecessary. After all, the user consciously decided to open, modify and save the INI file...

Assuming I'm fairly smart, and seeing how it continues to confuse me, a long-time SDLPoP user/tester, I'm pretty sure virtually everyone who will ever try to tweak these settings will be unaware that use_custom_options needs to be toggled before any changes will be applied...

[Norbert]

As mentioned by 4DPlayer in another thread, the official Ubuntu Twitter account mentioned SDLPoP.
https://twitter.com/ubuntu/status/1179805300158799873

And also on Facebook.
https://www.facebook.com/ubuntulinux/po ... 0000368592

[David]

It works, both the PRINCE.EXE auto-detection (e.g. playtesting via apoplexy) and modification of the INI.

Merged into master: https://github.com/NagyD/SDLPoP/commits/master

I think use_custom_options is far too easy to overlook when you're trying to make changes further down the INI file,

Enabled it by default: https://github.com/NagyD/SDLPoP/commit/ ... 9643eaa698