Prince of Persia

I want to do a guard trigger event, like explained in hacking post, can you please help me:
I need to add those or edit, also how to do it for any level...

Minor suggestions. (The following was tested with the Japanese ROM image.) Relative to the prince's current position in your program, if the prince starts looking right, he should be moved 13 pixels to the right and 3 pixels up. If the prince starts looking left, 4 pixels to the left and 3 pixels up. The program could also show a differently colored prince on levels 10, 11 and 12.

For future projects, you may want to use variable names in your code that are more descriptive. You seem to have a tendency to limit names to one or two characters. Two examples:

- Line 530 in smc.cpp of Pr1SnesLevEd:
if(tile[ti*si+(i<<4)+(s<<1)+j]&128>>o) d[o]|=1<<((i<<1)+j);
There you have ti, si, i, s, j and o; an array named d.
- Function unrle_lr(), starting line 237 in seg009.c of SDLPoP:
si, di, dp, while (bp), al, cl, etc. Things like "do { *(di++) = *(si++); --bp; } while (--cl);".

If you, yourself, have recently worked on such code, it doesn't matter what the variable names are like. But if you'd ever decide to look at (or work on) code you haven't touched in 1 or even 20 years, things might be different. Especially when there's a chance other people may look at (or work on) your code - like with your open source/free software - you may want to use more descriptive variables. Even with ints such as x and y, where you use x for x-coordinate, the variable name could answer the question 'x-coordinate of what'. This might also help others who do not use an IDE to guess variable types, since you do not use a naming convention where the name of a variable indicates its type.

For future projects, you may want to use variable names in your code that are more descriptive. You seem to have a tendency to limit names to one or two characters.

Erm, you're right.

- Function unrle_lr(), starting line 237 in seg009.c of SDLPoP:
si, di, dp, while (bp), al, cl, etc. Things like "do { *(di++) = *(si++); --bp; } while (--cl);".

These are register names from the disassembly.
I am now replacing these with better names.
(The "regular" variables didn't have names either before I gave them, though. I'm not sure why I skipped the register variables.)

When will this feature be incorporated?

A pixelart editor would be a dream.

Here's how many pixels the enemies need to be moved:

(The monster and brown/silver skeletons are estimates, because they move/look different in-game.)

All guards (including dead and fat):
- if looking right: 3 up, 1 left
- if looking left: 3 up, 10 right

Jaffar:
- if looking right: 8 up, 1 left
- if looking left: 8 up, 10 right

Both knights:
- if looking right: 10 up, 1 left
- if looking left: 10 up, 10 right

Shadow:
- if looking right: 3 up, 1 right
- if looking left: 3 up, 8 right

Girl:
- if looking right: 6 up, 1 left
- if looking left: 6 up, 10 right

Golden skeleton:
- if looking right: 5 down, 1 left
- if looking left: 5 down, 10 right

Monster (estimates):
- if looking right: 11 up, 1 left
- if looking left: 11 up, 10 right

Brown and silver skeletons (estimates):
- if looking right: 5 down, 13 right
- if looking left: 5 down, 4 left

Here's how many pixels the enemies need to be moved:

This info is for editing sprites graphics??

salvadorc17 wrote:

Here's how many pixels the enemies need to be moved:

This info is for editing sprites graphics??

It's about where Pr1SnesLevEd places enemies inside the editor.

For example, if you open the editor and go to level 18, room 11 (up, up, up, right), you can see the blue knight should be moved: 10 pixels up, 10 pixels right. He's currently too far down and left.

Another small suggestion.

The first room displayed for the Jaffar level is room 255. But 255 means there is no room. In that non-existing room, the editor appears to display some random tiles and backgrounds. Maybe it should just start in room 0? For the Jaffar level, room 0 is where the prince starts (gets teleported to), which means that if it's the first room displayed that would also be the most consistent behavior.

For me it will be interesting to add the hex-Hack into pr1snesleved instead of replacing/add number in hexadecimal editor.

For example add a small windows where you can select the speed of chomper , the jaffar sequence's , shadow , number of level ( when the game end ) , etc.

More easier for beginner , a great gain of time , and I don't think is very difficult to add that.

For me it will be interesting to add the hex-Hack into pr1snesleved instead of replacing/add number in hexadecimal editor.

Totally agree with you, that can be easy added, i have tried, but seems my c++ programming experience was not enought..

David wrote:If "Last resource doesn't fit into its place", then the editor places it elsewhere. (After the sprites.)

I'm actually surprised that nobody ran into problems with lack of space in the past.
From what I can tell the unused space in the original game is only 1501 or so bytes (00077A22-00077fff).
Even with the slightly different compression, you'd think authors would run out of space really fast.
Level 17, for example, is only 914 bytes in the original game.
As a comparison, level 18, which uses the same environment type, is 1714 bytes.
I guess maybe most mods were relatively small.
I checked Iso's Mod (Training Levels) and it uses 929 more bytes than the original just for the training levels.

[Edit:]
The original JP version has data in its "main resources second area" (0xE0A00 and up) though, right?
Yeah, it looks like where the biggest collections of 0x00's for US are:
0x5fa bytes, starts at 0x0079c6 <- 0.smc uses some of this area
0x5fa bytes, starts at 0x017a06 <- 0.smc uses some of this area
0x3a42 bytes, starts at 0x01c5be
0x76f6 bytes, starts at 0x0e090a
(I'm aware some of those 0x00's are used data.)
The JP version has nothing better than:
0x38 bytes, starts at 0x00b85d
0x40 bytes, starts at 0x020ad1
0x43 bytes, starts at 0x018cfe
0x50 bytes, starts at 0x0209c1

Norbert wrote:The original JP version has data in its "main resources second area" (0xE0A00 and up) though, right?

Although that area is not zero, I don't think those bytes mean anything.

All unused areas are filled with this thing that looks like noise to me.
In each 128-byte block, either most bits are 0 and much less are 1, or the other way around.
The roles are flipped in every other block, except in every 32th block.

I also found similar patterns in other ROM images.

I noticed this, a room link to 249.

There are some more:
- Prince of Persia: Remix III uses 225 five times (image, mirror).
- Prince of Vatísion uses 98 once (image, mirror).
- Miracles Don't Exist uses 25 once (image, mirror).
- The Quiet Levels uses 155 once (image, mirror).

Maybe use a warning pop-up there if an entered value isn't within certain ranges.
Something like 98 could be a typo or it was meant to be 254...

Norbert wrote:I noticed this, a room link to 249.


Maybe use a warning pop-up there if an entered value isn't within certain ranges.
Something like 98 could be a typo or it was meant to be 254...

Those are mistakes, could not be theyre used for sometihng special related with tiles?