Fluffy's Prince of Persia

[FluffyQuack]

I already had support for all the enemy variants in POP1, but I only ever defined enemies as the generic guards, so now I'm finally defining appropriate enemy type when they're spawned based on the level number. I also added support for adding in all enemy types in POP2, though there's still a ton of work left related to them:

[Alberto]

I always found Jaffar's fight to be top action, it isn't super difficult once you get the timing, but it is massively rewarding when you hear those sword clanks.

Could you theoretically use POP1 guards in POP2 and vice versa? Not that it is a good idea to implement though, it is just a random question aimed to stress test the game.

[FluffyQuack]

I always found Jaffar's fight to be top action, it isn't super difficult once you get the timing, but it is massively rewarding when you hear those sword clanks.

Could you theoretically use POP1 guards in POP2 and vice versa? Not that it is a good idea to implement though, it is just a random question aimed to stress test the game.

That's not possible right now. The biggest obstacle is that the coordinate system used in the POP2 animations and frame data isn't compatible with POP1.

I think that's something I will support in the long run, though. As I mentioned in an earlier post, I want to make a merged version of the two games where you can use all tiles, traps, and enemy types in either game. But right now my priority is keeping both games as faithful as possible, which means many systems are separated.

[Alberto]

Now that you mention it, I remember a post of the coordinate system explanation, and I feel so silly for forgetting about it. I have a very short attention span it seems sorry.

Even if merging both worlds is not entirely possible or convenient, I feel having one program to bundle both POP games is already good enough for preservation reasons.

[FluffyQuack]

Now that you mention it, I remember a post of the coordinate system explanation, and I feel so silly for forgetting about it. I have a very short attention span it seems sorry.

Even if merging both worlds is not entirely possible or convenient, I feel having one program to bundle both POP games is already good enough for preservation reasons.

Speaking of which, I'm curious how many people would consider my project good from a preservation standpoint. SDL-POP is unarguably great from that standpoint as the code is doing the same things as DOS POP, even replicating the exact same bugs. But I'm not making my project the same way. A lot of the code is doing extremely similar stuff, but sometimes I'm implementing things my own way because I think it makes more sense code-wise, it makes extra features easier to implement, or because it will be easier to work with in the long run.

A casual player probably won't be able to tell the difference, but speedrunners and hardcore fans would. My implementation will definitely be missing some bugs because I'm handling "rooms" in an entirely different way (also I like fixing bugs), and there might also be some very minor differences in AI behaviour.

I think it's an interesting topic as I see differing opinions on it. For instance, we recently had remasters of the classic Tomb Raider games (random brag: I did some work on them!) and those are extremely faithful, but not 100% so. I looked a lot at feedback and the vast majority of people are very happy with them, but I occasionally see someone say they'd rather play the originals as they want the original experience to be as untouched as possible (ie, they think the graphics aren't close enough, or they want the save crystals by default).

[David]

I found a funny bug in the 2025-03-14 release:
I wanted to climb up to the ledge at the start of level 8... and the prince entered the closed exit door instead.

Then it happened again on level 10:

[FluffyQuack]

I found a funny bug in the 2025-03-14 release:
I wanted to climb up to the ledge at the start of level 8... and the prince entered the closed exit door instead.
entering_closed_level_door_level_8.png

Then it happened again on level 10:
entering_closed_level_door_level_10.png

Oh yeah, my code for that is a bit flawed. I check if there's an exit door where the player is, and if that's true, I do this check to determine if the door is open:

Code: Select all

if(1) //TODO: Check if door is open
{
	[...]
}

That reminds me of a feature I want to add for the heck of it. Since I keep the full state of every level in memory at all times, I want to make it so you can go through the entrance door to go back to the previous level.

[Alberto]

Small beginnings. I think you are already on the right track.

Technically speaking POP1 is currently preserved, so long we have the source code available. Let's imagine that POP1's source code suddenly disappears from all available records, including the compiled code so no reverse engineering is possible, then the code would cease to be preserved. Even if someone with good memory manages to rewrite it, because then the question becomes how could we be certain this new rewritten code is in fact the original code?

My favorite example are dinosaurs, no one really knows how they looked. We can somewhat faithfully recreate their look from bones and fossilized tissue, but they are gone. Even if we were able to clone them, they wouldn't really be the same dinosaurs from before. Another good analogy is cooking. We could all have the same recipe (the thing to preserve), but our experience & skill, understanding of the ingredients, kitchen tools and our own sense of taste dictates the end result. So, execution is different from preservation.

For me, preservation also involves the enthusiasm of the community to keep porting or creating new versions of the original games. Because that enthusiasm is what keeps the original source code available, like a reference point we can all go back and check. Without the original we wouldn't be able to complain about unintended behaviors of new versions lol.

[Alberto]

That reminds me of a feature I want to add for the heck of it. Since I keep the full state of every level in memory at all times, I want to make it so you can go through the entrance door to go back to the previous level.

That would be awesome and very immersive!

Talking about custom levels, just imagine you need to press a timed floor tile from the previous level to proceed. Like you begin the level trapped between two cell doors and discover you can go back. Mind blown! 🤯

[FluffyQuack]

That would be awesome and very immersive!

Talking about custom levels, just imagine you need to press a timed floor tile from the previous level to proceed. Like you begin the level trapped between two cell doors and discover you can go back. Mind blown! 🤯

Would be a good way to hide very obscure secrets. Add a button near the end of the game that opens a portcullis in the first level!

On a related note, each time I encounter something that's completely hardcoded in the original, I'm trying to find a way to find a clean implementation that doesn't require a "only do this thing in this room at this position"-check and instead implement it like a proper feature that can be applied anywhere. For instance, near the end of POP1, you have to do a leap of faith and then empty tiles suddenly turn into floor tiles. This is super hardcoded in POP1 by checking if the player steps on certain empty tiles in specific locations and then turning them into floor tiles. Instead of that, I'll add a flag that can be applied to any tile that means "keep tile invisible until player steps on it."

There's a couple of times in POP1 and POP2 where the player is essentially teleported to a location during normal movement (falling down back into dungeon after shadow prince closes a portcullis in POP1, or prince entering the ruins levels after the magic carpet ride in POP2). When implementing those, I'll just make it possible for any tile to function as a teleporter with the logic "if player enters this tile, then teleport player to X position in Y level."

Another thing that's hardcoded is the one level in POP2 with two exits that lead to different starting points in the next level. That's a cool feature which I wish they did more of, but it's implemented in super hardcoded way. In my code, I'll make it possible to freely define an exact destination for any exit door. Similar to my teleport idea above.

Of course, all of this means that when I get around to making my level editor, levels will be saved in a format that's completely incompatible with original POP1 and POP2, but it will allow for much greater freedom for level makers.

[FluffyQuack]

I did a major change to how levels are stored in memory. When I started the project, I went with a simple structure for level size. I define a giant array that's big enough for any POP level (I calculated max size based on worst case scenario: a level with all rooms aligned in a line, so the max was something like 320x96 tiles). The code was similar to this:

Code: Select all

princeLevelTile_s tiles[PRINCE_MAXLEVEL_SIZEY][PRINCE_MAXLEVEL_SIZEY];
princeLevel_s *lvl = p_levels[0]; //Contains tiles array
lvl->tiles[0][5].dataSpec = 255;

Easy to set up and easy to use, but a ton of memory wasted since no level in POP1/POP2 occupies that much space. I wasn't sure how to set up a 2D array that's fast performance-wise, supports dynamic size, and with syntax that isn't too painful to use. What I ended up with is code similar to this:

Code: Select all

#define TILES(x, y) (lvl->tilesNew[(lvl->sizeX * (y)) + (x)])
princeLevelTile_s *tiles;
princeLevel_s *lvl = p_levels[0]; //Contains tiles array
lvl->tiles = (princeLevelTile_s *) malloc(sizeof(princeLevelTile_s) * lvl->sizeX * lvl-sizeY);
TILES(0, 5).dataSpec = 255;

That was the best I could think of. I prefer the syntax of the first system as I find it more readable, but this is at least very short syntax. It does have the downside it assumes the level pointer is called "lvl" but that was already the case in 99% of my code anyway, so it shouldn't be an issue moving forward.

I could benchmark this change using my gameplay state save/load system. That system is implemented in a "dumb" way: when I save a gameplay state, I save literally everything related to gameplay. It saves the state and definition of every single tile. This was easy to implement because 99% of my gameplay state is stored in one struct. Just have to make sure to save a few extra variables and fix up some pointers when loading.

The sizes of uncompressed gameplay states with my original huge tile arrays were this:

• POP1 = 15,688,536 bytes
• POP2 = 27,426,072 bytes

And the same sizes with dynamic level sizes:

• POP1 = 758,744 bytes
• POP2 = 1,298,936 bytes
• POP2 without the additional 14 developer levels = 668,712 bytes

I also compress the savegame states which makes them less than 10k each. That said, there are more optimizations to do. I can minimize the amount of space each tile takes by being smarter with how some data is stored.

I think I'll keep the save/load system the same, though. It's overkill to save everything, but it works well.

[FluffyQuack]

Addendum to my previous post: I probably should have remembered to look into my game state save/load code or tested if state loading worked at all. I didn't do either, so the same code would have just saved the actual level tile data as a broken pointer with no actual data saved. So that makes the above numbers bogus.

Here are the real sizes after updating the save/load function to work with the dynamic level sizes:

• POP1 = 2,024,760 (89,615 compressed)
  POP2 = 4,546,168 (72,046 compressed)
  POP2 without the additional 14 developer levels = 2,077,784 bytes (38,196 compressed)

Still a huge reduction in size, at least.

[FluffyQuack]

I'll upload a new build now and then. Like this one: https://fluffyquack.com/prince/builds/2025-04-09.zip

You can now press "shift+k" to jump to the previous level. That way you can play the "demonstration" level in POP1 which occupies the very first level slot. You can use the "entrance doors" if you enable one of the toggles in the menu. I added support for some of the level ends in POP1 so it should now be possible to get to the Jaffar boss fight without using debug cheats (edit: actually, no, since the mouse never appears). I started working on adding enemies in POP2. You can see them now, but they have almost no behaviour implemented.

[FluffyQuack]

Been doing more work related to enemies and combat. Most of the code related to fighting guards is implemented now.