Prince of Persia

Here is SDLPoP v1.21, attached to the post.
The ZIP contains the Windows binaries and the source as usual.

The list of changes since the last release can be found here: https://github.com/NagyD/SDLPoP/blob/v1 ... #L543-L562

I marked this release with a tag as usual: https://github.com/NagyD/SDLPoP/releases

Before announcing it on Facebook et al., I suggest creating a new ZIP (both here and on GitHub).
See: https://github.com/NagyD/SDLPoP/issues/221
(Maybe look at the copyright notices too... And, if I may - humbly, and without knowing your schedule - give a suggestion for your (pre-)release checklist: perhaps it's wise to release only on days where the next day you are off work.)

By the way, I don't know if this is deliberate or not, but the README.md in the package you attached on this forum just says "doc/Readme.txt" and is not a symbolic link to file doc/Readme.txt. Unsure how that's possible given the file is not in .gitignore. Actually, now that I'm thinking about it, does Windows 10 understand (such) symbolic links?

Norbert wrote: ↑August 21st, 2020, 8:04 am Before announcing it on Facebook et al. [...]

I'll post it on FB when the link is on PoPOT. It assures me that it's good to post as, all the testing work is done and there are no issues to fix. Just let me know when PoPOT is updated.

And thanks David for releasing the new version. Excited to use the new features!

Great, I messed up this release like the previous one...

Norbert wrote: ↑August 21st, 2020, 8:04 am Before announcing it on Facebook et al., I suggest creating a new ZIP (both here and on GitHub).
See: https://github.com/NagyD/SDLPoP/issues/221

Fixed: https://github.com/NagyD/SDLPoP/commit/ ... 5d8b23c56a

Norbert wrote: ↑August 21st, 2020, 8:04 am (Maybe look at the copyright notices too...

Fixed: https://github.com/NagyD/SDLPoP/commit/ ... 512b0574bf

Is SDLPoP now ready for the release?

Norbert wrote: ↑August 21st, 2020, 8:04 am And, if I may - humbly, and without knowing your schedule - give a suggestion for your (pre-)release checklist:

For starters, I should have such a list, and then I should remember to look at it before doing a new release.

I came up with this:
* Replace "(upcoming)" with the release date and the version number in ChangeLog.txt .
* Replace "(upcoming)" (if any) with the version number in Readme.txt .
* Update the version number in config.h and CMakeLists.txt .
* Update the copyright year in every source file. (Although ideally it should be updated on New Year's Day, or at least before the first actual commit of the year.)
* And perhaps, ask someone to verify if I missed anything, before I make the ZIP?

Norbert wrote: ↑August 21st, 2020, 8:04 am perhaps it's wise to release only on days where the next day you are off work.)

I'm off this whole week (and the next week too).
But apparently this does not mean I can pay more attention to things...

I started preparing the new release early afternoon, but then I bumped into the problem of whether I should merge fast_forward and quickload_while_recording even though those two functions could still be improved. (See the TODOs at the end of ChangeLog.txt.)
I couldn't decide, so I started doing something unrelated instead (it's a bad habit of mine).
I returned to the new release only some hours later. I decided to merge those branches as they are, but add the TODOs to ChangeLog.txt.
Apparently I wanted to get the release out of the door so much that I didn't even look at the title bar and the splash screen of the newly compiled version (where the version number appears).
I also pondered whether I should merge PR #219 (and read GitHub's help about actions), which also took away some time.

Norbert wrote: ↑August 21st, 2020, 8:04 am By the way, I don't know if this is deliberate or not, but the README.md in the package you attached on this forum just says "doc/Readme.txt" and is not a symbolic link to file doc/Readme.txt.
Unsure how that's possible given the file is not in .gitignore. Actually, now that I'm thinking about it, does Windows 10 understand (such) symbolic links?

The release notes of Git for Windows say the following:

On Windows 10 before 1703, or when Developer Mode is turned off, special permissions are required when cloning repositories with symbolic links, therefore support for symbolic links is disabled by default. Use git clone -c core.symlinks=true <URL> to enable it, see details here.

Back when I created my repository, I cloned it without enabling this option; and I haven't enabled it since then.
Because of this, the README.md in my work tree is a regular file instead of a symlink.
That file got into the ZIP.
(By the way, can ZIP files even contain symlinks? Here is a hint that they can.)

How would .gitignore be related to this?

David wrote: ↑August 21st, 2020, 10:03 pmIs SDLPoP now ready for the release?

I think so. Can you update the ZIP file in your first post with a newly compiled version?

David wrote: ↑August 21st, 2020, 10:03 pm* And perhaps, ask someone to verify if I missed anything, before I make the ZIP?

Although to verify certain things, such as (the behavior of) new features, an executable could be helpful, so perhaps it's useful if you do create a ZIP but one that you only share on this forum for testing purposes?
Then again, even with testing it's difficult to fully prevent (minor) bugs.

One other thing you could consider for the checklist is running something like...
diff -rq --strip-trailing-cr previousversion/ releasecandidate/
...and then using a visual diff tool on all files that have changed.
I generally do this myself to take one last look at everything that has changed since the previous version.
This has been useful. For example, I once noticed a missing break in a new switch...case statement.
On the downside, it means having to pour even more time into the project.

Norbert wrote: ↑August 22nd, 2020, 8:58 am I think so. Can you update the ZIP file in your first post with a newly compiled version?

Done.

Norbert wrote: ↑August 22nd, 2020, 8:58 am Although to verify certain things, such as (the behavior of) new features, an executable could be helpful, so perhaps it's useful if you do create a ZIP but one that you only share on this forum for testing purposes?
Then again, even with testing it's difficult to fully prevent (minor) bugs.

We used to make release candidates of SDLPoP up to v1.18.
So, I should make one again next time.

In a way, we can also think of the old ZIP file in the first post as a release candidate...

Norbert wrote: ↑August 22nd, 2020, 8:58 am One other thing you could consider for the checklist is running something like...
diff -rq --strip-trailing-cr previousversion/ releasecandidate/
...and then using a visual diff tool on all files that have changed.

I did something like that using Total Commander's "Synchronize dirs" function.
There I can filter to show only differing files, and then I can open a visual diff for each pair of differing files.

David wrote: ↑August 22nd, 2020, 8:24 pmDone.

Thanks.

atrueprincefanfrom18 wrote: ↑August 21st, 2020, 10:03 amJust let me know when PoPOT is updated.

Updated.

atrueprincefanfrom18 wrote: ↑August 21st, 2020, 10:03 amExcited to use the new features!

Me too.

[Edit: Fix.]

Norbert wrote: ↑August 23rd, 2020, 8:12 am Updated.

Thanks. Posted here.

By the way, this:

Norbert wrote: ↑August 23rd, 2020, 8:12 am

David wrote: ↑August 22nd, 2020, 8:24 pmExcited to use the new features!

Me too.

is written by me and not David!

atrueprincefanfrom18 wrote: ↑August 23rd, 2020, 8:41 amis written by me and not David!

Oops; fixed.

Congrats on the new release

Should I make a macOS build again?

David wrote: ↑August 21st, 2020, 10:03 pm I couldn't decide, so I started doing something unrelated instead (it's a bad habit of mine).

This is a familiar thing for me as well.

Falcury wrote: ↑August 29th, 2020, 10:11 pm

David wrote: ↑August 21st, 2020, 10:03 pm I couldn't decide, so I started doing something unrelated instead (it's a bad habit of mine).

This is a familiar thing for me as well.

I don't think it is - as David wrote - a bad habit, though.
Maybe doing something unrelated allows you to linger over it subconsciously.
Plus, when you later return to the issue, you might see it from a different perspective or with new insights.
I'm fairly certain it shouldn't be too difficult to find studies on this that show benefits.
And, unless you miss a deadline or too heavily postpone, likely there are no downsides either.

` - key which increases the speed of the game has a todo: after drinking a floaty potion the Kid can move very fast however the floaty effect stays longer because music is not at the speed of the game...

If you use cheats, and change to a different room (using U, H, J or N) than the one where the Kid is, and Quicksave. After you Quickload, you are put into the room you switched during cheat key instead of the one where the Kid is. Can it be fixed?

In rare case, it may also happen that player has Quicksaved with cheats and when he Quickloads there are no cheats enabled and might get confused.

atrueprincefanfrom18 wrote: ↑November 22nd, 2020, 6:26 pm If you use cheats, and change to a different room (using U, H, J or N) than the one where the Kid is, and Quicksave. After you Quickload, you are put into the room you switched during cheat key instead of the one where the Kid is. Can it be fixed?

Fixed: https://github.com/NagyD/SDLPoP/commit/ ... 37c3a9ae01

By the way, maybe it would be useful to have a key which returns the view to the room where the prince is, without quickloading?
In MININIM the Home key does this, but in SDLPoP Home makes the prince jump left, so we need a different key for the new function.

atrueprincefanfrom18 wrote: ↑October 17th, 2020, 8:40 am ` - key which increases the speed of the game has a todo: after drinking a floaty potion the Kid can move very fast however the floaty effect stays longer because music is not at the speed of the game...

Fixed: https://github.com/NagyD/SDLPoP/commit/ ... c9f55b2173
I also added a few related compile-time options.