Prince of Persia

This is the result: Yes, an option in SDLPoP.ini to disable the info screen seems a good idea.
We could additionally put it on a timer so if the user doesn't close the screen, the game will automatically jump to the title screen after some time.

Unrelated: small tweak of an earlier bug fix:
https://github.com/NagyD/SDLPoP/pull/99

Maybe we should free up two lines, one by removing "recorded" and one by removing the newline between the lines about SDLPoP.ini and mods. Then something like "<newline>[Press any key to start.]" (or "continue" instead of "start", or something similar) could be added at the very bottom. What do you think?

And maybe use 1 instead of 2 newlines after "SDLPoP 1.17".
That would give us yet another line, to add, for example: "SDLPoP also works with game controllers."

Norbert wrote:Maybe we should free up two lines, one by removing "recorded" and one by removing the newline between the lines about SDLPoP.ini and mods. Then something like "<newline>[Press any key to start.]" (or "continue" instead of "start", or something similar) could be added at the very bottom. What do you think?

Done!

Probably, the added remark on controller support is not as needed as the rest, because it "just works" if you plug in a controller, right?

Pull request for the info screen:
https://github.com/NagyD/SDLPoP/pull/100

Falcury wrote:Done!

Cool.

Falcury wrote:Probably, the added remark on controller support is not as needed as the rest, because it "just works" if you plug in a controller, right?

That's true, although if you didn't know about SDLPoP's inner workings and you had an Xbox 360 controller that you only used with the living room TV, would you think about hooking it up to your PC to try it out with SDLPoP. Then again, the original supported joysticks, so users may already assume this solid alternative will too. Yeah, probably not necessary. Plus it looks nice with the double newline at the top.

I'm mostly an onlooker, but, we may want to keep an eye on preventing - I think it's called - feature creep. I don't know when exactly a feature freeze is wise, nor am I in a position to make any kind of judgments in that department, but the last release was January 2nd, which is creeping up on us again. On the other hand, there's so much cool stuff still being added...

Yes, I'm aware of it... Is it time to draw the line?
I think after the release of 1.17 I'll probably want to take a break from adding new stuff.

Falcury wrote:Yes, I'm aware of it... Is it time to draw the line?

To be honest, I don't know.
You're on a roll and I don't want to stop you.

Falcury wrote:I think after the release of 1.17 I'll probably want to take a break from adding new stuff.

Okay. As you probably know I'm currently working on a level editor of the Mega Drive (Sega Genesis), using David's documentation.
When I'm done with that (~Jan 2017), next on my list is modifying popot.org, to allow SDLPoP replay sharing, among other things.

I got a stream of after walking the stairs after finishing the first level of this mod.
I don't know if it's related to the mod or not.

Yes, this always happens after entering the exit door.
The reason for this is that the game tries to draw the kid's frame 0. If you look at frame_table_kid[0], you can see that the image index for frame zero is 255. However, that image does not exist, which is why the warning is triggered.
I also noticed this and silenced the warning for image 255 in the branch of the pull request that's still open.

Here is the specific commit that silences the warning:
https://github.com/NagyD/SDLPoP/pull/10 ... 29e71f22e1

pop was my favourite dos games. this port is super. what i really miss is the crystal clear sound of my adlib inside my amstrad 1640 pc. anyway great

aldolo wrote:what i really miss is the crystal clear sound of my adlib inside my amstrad 1640 pc

Higher quality - but larger - OGG files that you can put in the data/music/ directory are available in this ZIP (38MB).

Norbert wrote:

aldolo wrote:what i really miss is the crystal clear sound of my adlib inside my amstrad 1640 pc

Higher quality - but larger - OGG files that you can put in the data/music/ directory are available in this ZIP (38MB).

goose bumps again!!!

David, at a random position in the code, assuming Char is the kid there, how can I calculate the center of the kid?
With my limited knowledge of the SDLPoP code, the best I could come up with is: (Char.x - 50) * 2
Also, I'm aware that it depends on the width of the current prince frame.
If I'd know the width of that frame and the location the prince is drawn, I could, of course, easily calculate the center.
Any pointers are welcome.

[Edit: Related code is here. During replay, press "i" five times.]

Unrelated,
Some minor errors cppcheck complains about:

---
[replay.c:92]: (error) Buffer is accessed out of bounds.
[replay.c:184]: (error) Common realloc mistake: 'replay_list' nulled but not freed upon failure
---
[seg009.c:1632]: (error) Memory leak: desired
---

Norbert wrote:Unrelated,
Some minor errors cppcheck complains about:

---
[replay.c:92]: (error) Buffer is accessed out of bounds.
[replay.c:184]: (error) Common realloc mistake: 'replay_list' nulled but not freed upon failure
---
[seg009.c:1632]: (error) Memory leak: desired
---

Interesting that a programs can catch things like that! Fortunately, none of these seem to be real problems

I would guess that the first one got flagged because the full 3 bytes of char magic[3] get filled (leaving no room for a zero terminator).

I am puzzled about the second one, about realloc(). Realloc can fail of course. But then it is a mystery to me why the program doesn't complain about malloc in other places... And really, I wonder why one would one even bother checking for memory allocation failure. We are not allocating large amounts of memory, running out of memory shouldn't be a concern... And if it ever happens that malloc or realloc does fail, there would likely be some things seriously wrong with the system itself... recovering gracefully from such a failure would be foolishly optimistic I would think.

Ironically, the memory leak of the variable 'desired' in seg009.c is 'desired' behaviour!
(or, maybe I just wanted to make that joke? )