SDLPoP; David's open-source port of PoP

[Sance]

others are free to suggest ideas and fantasize about where they see SDLPoP down the line (knowing full well it may or may not happen).

Exactly.

Anyway here's a narrated speedrun on the 1.3 or 1.4 version:
https://www.youtube.com/watch?v=SuJjyN1ukjM
Have to say the game seems very-very broken this way.

[CRxTRDude]

Long story short, David & co. remain free just as before to work at their own pace on whatever they please, while others are free to suggest ideas and fantasize about where they see SDLPoP down the line (knowing full well it may or may not happen). Just my 2¢.

That's what I want to mean by my statements. As long as people know well that it may or may not be on their plans at the moment, they could feel free on doing so. For that, I'll just keep coasting along and try to check this out as much as I can.

[David]

You're right, there was probably no concept of external DLLs back then.

Even if there were, they were bundled with either the game or the operating system.

So, it would be technically possible to create updated DOS EXEs that could act as drop-in replacements for the original ones, as Poirot was wondering.

Yes.

I already found out what compiler was used: Microsoft C 5.1 Optimizing Compiler.
(Its libraries contain 1988, which matches prince.exe. Version 5.0 says 1987, and 6.0a says 1990.)

[Falcury]

I am looking for a simple way for guard hitpoints to be remembered when you re-enter a room after you have hurt the guard earlier (instead of guard hp always resetting to the maximum value).
Repurposing some unused bits of level.guards_color for each room is a possible method:

Code: Select all

leave_guard(), seg002.c:

#ifndef REMEMBER_GUARD_HP
	level.guards_color[room_minus_1] = curr_guard_color;
#else
	level.guards_color[room_minus_1] = curr_guard_color | (guardhp_curr << 4);
#endif

enter_guard(), seg002.c:

#ifdef REMEMBER_GUARD_HP
word remembered_hp = (curr_guard_color & 0xF0) >> 4;
curr_guard_color &= 0x0F;
#endif
[...]
get_guard_hp();
#ifdef REMEMBER_GUARD_HP
if (remembered_hp > 0) guardhp_delta = guardhp_curr = remembered_hp;
#endif

But I also found that there were some other fields in the level struct that do not seem to be referenced anywhere in the code:

Code: Select all

byte roomxs[24];
byte roomys[24];
byte fill_1[15];
byte fill_2[4];
byte fill_3[18];

Can we also safely use these fields for temporary storage of information about a room (e.g. remembered guard hitpoints)?
I wouldn't really want to add new global variables for this purpose because that will mess up the quicksave/savestate format and therefore break quicksave compatibility ungracefully...

[poirot]

You read my mind! I was wondering if it was possible to compile a DOS version without SDL, but making this work would just for fun.

Anyways, I'm getting familiar with the code so may be in the future I can add some features.

I agree with CRxTRDude with the spirit of keeping the original game, I'm getting too much nostalgic; but I can't deny that I've spent all my childhood wanting to create mods of the game, now, thanks to all you, modding the game, even the code, is a reality! I've been waiting 15 years for this, when I first learnt how to edit a file in pascal without getting any checksum trouble and created Princed V1 to start disassembling the maps... but all this with only one purpose: create my own mod! which I never did, may be it's time to start. Why? because CusPoP isn't mature enough to made all the changes I want, but having the source code is.

Anyways, I don't want to get too much off-topic, but I have to say it: I want to create a mod called "the other path", TOP (Falcury, what you've seen in the Github pull was a commit which I wrongly sent to the osx branch of the first explorations and modifications of the source for TOP), with more than 16 levels, different branches and ways, but keeping Mechner's original design spirit and of course keeping the original path... so only clever players may find rip-off levels, the rest of the players would play the original game. I've also found original screens in the Apple ][ disks (which are the same
as the ones in the DOS version) which are not included in the game: for example, level 1, before getting the sword, it had one more screen to go, but as Mechner got all 24 screens he had to drop one vertical block of three screens at the end just to re-use one, so two screens remain there, untouched, the same way as Mechner created them; even the screen links helped me locate the place where those screens used to be.

[Falcury]

Anyways, I don't want to get too much off-topic, but I have to say it: I want to create a mod called "the other path", TOP (Falcury, what you've seen in the Github pull was a commit which I wrongly sent to the osx branch of the first explorations and modifications of the source for TOP)

Ah, so I got a "sneak peak"
Good luck with your mod! It's a lot of fun to poke around in the code and as you say, the possibilities are endless! (All thanks to David's awesome work!)

[David]

Can we also safely use these fields for temporary storage of information about a room (e.g. remembered guard hitpoints)?

roomxs and roomys contain the x/y coordinates of the rooms.
They were used by Mechner's level editor, but nothing else uses them.
fill_1, fill_2 and fill_3 are also unused, there are no references to them in the source (as you wrote).
So you can reuse them, but don't forget to initialize them.
See also here: viewtopic.php?p=12377#p12377

But maybe it would be more appropriate if you reused some of the guards_*[] arrays instead.
For example, guards_dir[] contains only 1 bit of information (left/right).
guards_skill[] and guards_color[] don't contain more than 4 bits (as you wrote).
(The SNES level format merges guard direction with some other data, by the way.)
Again, don't forget to initialize them.

with more than 16 levels, different branches and ways, but keeping Mechner's original design spirit and of course keeping the original path...
so only clever players may find rip-off levels, the rest of the players would play the original game

So what does this exactly mean?
Do you want to keep the main path as the original, and change only the side paths?
For example, where the original level had a small potion in the ceiling, and the like?

I've also found original screens in the Apple ][ disks (which are the same as the ones in the DOS version) which are not included in the game

Yes, there are interesting things in unused rooms...

By the way, I found a video that shows something that looks like an older version of level 1: https://vimeo.com/2704881 (second half)

I see you're also working on adding an editor to SDLPoP: https://github.com/NagyD/SDLPoP/compare ... lot:editor

[Andrew]

I see you're also working on adding an editor to SDLPoP: https://github.com/NagyD/SDLPoP/compare ... lot:editor

@Poirot/Enrique: Don't take this the wrong way but I'm genuinely curious - is there a specific reason to get started on yet another editor rather than enhance one of the existing ones to add support for new SDLPoP features as required?

[Falcury]

roomxs and roomys contain the x/y coordinates of the rooms.
They were used by Mechner's level editor, but nothing else uses them.
fill_1, fill_2 and fill_3 are also unused, there are no references to them in the source (as you wrote).
So you can reuse them, but don't forget to initialize them.
See also here: viewtopic.php?p=12377#p12377

But maybe it would be more appropriate if you reused some of the guards_*[] arrays instead.
For example, guards_dir[] contains only 1 bit of information (left/right).
guards_skill[] and guards_color[] don't contain more than 4 bits (as you wrote).
(The SNES level format merges guard direction with some other data, by the way.)
Again, don't forget to initialize them.

OK, I added a pull request.
I wasn't able to properly isolate unused bits of the guards_dir[] array, though. I think this is because these are the used values:

Code: Select all

enum directions {
	dir_0_right = 0x00,
	dir_56_none = 0x56,
	dir_FF_left = -1
};

So it seems that the DOS version uses all 8 bits...
(I used guards_color[] for the hitpoints)

[poirot]

So what does this exactly mean?
Do you want to keep the main path as the original, and change only the side paths?
For example, where the original level had a small potion in the ceiling, and the like?

No, for example in level 7 when you get to the last room where you have an impossible jump and you have to go down instead. What if there is a green potion there and you can do the jump? that's what I want to do! Extend existing levels. May be you can get to level 8* through another exit gate. Other example: Level 4, the tile at the gate room is loose and you can pass to level 5 without jumping through the mirror... so the same levels without mirror... what would happen? This can be done with one global variable... level 6 would be bigger, have another exit, may be you can get to level 7*, where other things happen.

By the way, I found a video that shows something that looks like an older version of level 1: https://vimeo.com/2704881 (second half)

Wow, that will help!

I see you're also working on adding an editor to SDLPoP: https://github.com/NagyD/SDLPoP/compare ... lot:editor

That level editor was going to be a surprise! I'm planning to pull request when it get more stable.

@Poirot/Enrique: Don't take this the wrong way but I'm genuinely curious - is there a specific reason to get started on yet another editor rather than enhance one of the existing ones to add support for new SDLPoP features as required?

Great question! I can think on three main reasons why I'm doing this:

• It's a live editor, you can edit while playing, you can use it to practice (shift+mouse click puts the kid wherever you want).
• It works on mac, there is no editor working on mac (I was tired of using Princed V2.5 on dosbox), I've tried to port Apoplexy but I failed miserably and I didn't want to break norbert's code, specially POP2 support.
• And the real reason that got me on the move is that I want to change three #defines in the code (number of levels, number of rooms per level, number of supported environments), recompile and have a level editor still working.

[David]

I wasn't able to properly isolate unused bits of the guards_dir[] array, though. I think this is because these are the used values:

I think that 0x56 is used only in the Kid, Guard, Char, Opp variables.
guards_dir[] is written only in leave_guard(), and that function returns early if Guard.direction == dir_56_none (among others).

It works on mac, there is no editor working on mac [...], I've tried to port Apoplexy but I failed miserably

That's strange, since both SDLPoP and Apoplexy use SDL...

[Falcury]

I worked on fixes for some annoying movement/collision glitches: (pull request)

FIX_GLIDE_THROUGH_WALL: Fixes the kid being able to glide sideways through the top sections of walls/tapestries while in freefall. (see Trick 49, Trick 66)
FIX_DROP_THROUGH_TAPESTRY: Fixes the kid dropping through tiles when dropping down from a tapestry. (see Trick 44)
FIX_LAND_AGAINST_GATE_OR_TAPESTRY: Fixes the landing animation aborting when landing against a gate or tapestry+floor instead of a wall

I wasn't able to properly isolate unused bits of the guards_dir[] array, though. I think this is because these are the used values:

I think that 0x56 is used only in the Kid, Guard, Char, Opp variables.
guards_dir[] is written only in leave_guard(), and that function returns early if Guard.direction == dir_56_none (among others).

Ah. So the only possible values are really 0x00 and 0xFF (although 0xFF is still 8 bits unfortunately...)

[Andrew]

It's a live editor, you can edit while playing, you can use it to practice (shift+mouse click puts the kid wherever you want).

Now that sounds really interesting! Look forward to trying it out.

[David]

Ah. So the only possible values are really 0x00 and 0xFF (although 0xFF is still 8 bits unfortunately...)

Yes, but you can convert between 0xFF and 1 at the two places where guards_dir[] is accessed.

[David]

I just tried some fake tiles with the new Apoplexy.
It seems that the prince can "hide behind" the left side of invisible walls.