On level 6, after you saw the shadow, go right, and fall into the hole.
Listen to the music. It's not the usual death music!
Instead it's the level 4 ending music, or alternately, the music played when the prince dies in the shadow fight.
Integer overflow bug
Re: Integer overflow bug
I was testing this, when...
The guard died on the button and then slipped on the edge and fell into the wall!
As you can see, the button on which he died is still stuck.
What.
I should record a video of this, if I can ever do this again...
EDIT: I could do it again. Here is the video.
The guard died on the button and then slipped on the edge and fell into the wall!
As you can see, the button on which he died is still stuck.
What.
I should record a video of this, if I can ever do this again...
EDIT: I could do it again. Here is the video.
Re: Integer overflow bug
The video that David attached:David wrote:EDIT: I could do it again. Here is the video.
Re: Integer overflow bug
I investigated the cause of the overflow bug, using SDLPoP with the help of a debugger.
The test case is the level 12 skip.
When jumping to the new room to the left, the x/y coordinates of the kid are initially:
x = 53, y =199
After the room transition, this becomes:
x = 193, y = 199
Then, in redraw_screen(), exit_room_timer is set to 2.
As a result, for the next two frames, exit_room() prematurely exits while counting down exit_room_timer. (The room cannot change again during this time).
The next few frames, the x/y coordinates are:
x = 190, y = 211 (at this point, the y threshold for leaving the room downwards is reached, but leave_room() is never called)
x = 189, y = 244
x = 189, y = 244 (the same because the kid has grabbed the ledge down below)
At this point, leave_room() is called again.
Then the relevant code is this:
Because y = 244, the cast (sbyte)chary resolves to -12. As a result of this the leave_dir is set to 2 (up) instead of 3 (down).
This explains why the kid is moved to the room above.
Then, in goto_other_room(), Char.y += 189 occurs.
The new y value is 177. ((244 + 189) % 256)
The test case is the level 12 skip.
When jumping to the new room to the left, the x/y coordinates of the kid are initially:
x = 53, y =199
After the room transition, this becomes:
x = 193, y = 199
Then, in redraw_screen(), exit_room_timer is set to 2.
As a result, for the next two frames, exit_room() prematurely exits while counting down exit_room_timer. (The room cannot change again during this time).
The next few frames, the x/y coordinates are:
x = 190, y = 211 (at this point, the y threshold for leaving the room downwards is reached, but leave_room() is never called)
x = 189, y = 244
x = 189, y = 244 (the same because the kid has grabbed the ledge down below)
At this point, leave_room() is called again.
Then the relevant code is this:
Code: Select all
if (action != actions_5_bumped &&
action != actions_4_in_freefall &&
action != actions_3_in_midair &&
(sbyte)chary < 10 && (sbyte)chary > -16
) {
leave_dir = 2; // up
} else if (chary >= 211) {
leave_dir = 3; // down
} ...
This explains why the kid is moved to the room above.
Then, in goto_other_room(), Char.y += 189 occurs.
The new y value is 177. ((244 + 189) % 256)
- atrueprincefanfrom18
- Site Shah
- Posts: 1785
- Joined: January 21st, 2020, 2:53 pm
- Contact:
Re: Integer overflow bug
Another possible in the original PoP:David wrote: ↑January 30th, 2016, 1:04 pm How to "kill" the guard after the prince dies:
Not really useful, but it explains how they made this image from this page.
Re: Integer overflow bug
Guard wrap bugs happen when a guard getting pushed onto a specific tile in the next room. It can be caused by a gate (there is a check whether the gate is open enough which has several bugs on its own), spikes or a chomper. The "tile_col" variable points to the next room while the rest of the logic uses the visible "drawn_room" variable. That causes the guard to appear on the other side of the visible room when he should appeared in the next room (10 tiles to the left or the right depending on the side of the room).
I had submitted this PR that fixes that problem in SDLPoP when the "FIX_OFFSCREEN_GUARDS_DISAPPEARING" flag is enabled. The flag also fixes disappearing guards between rooms.
https://github.com/NagyD/SDLPoP/pull/237/files
Shadow auto control logic is very dependent on a specific room arrangement when shadow appears in the air. If prince/shadow/guard are located even 1 pixel off vertically, they can end up between rows that can cause very weird behavior. The landing depends on the tile and the action that is going to occur (landing/grabbing/picking up sword or potion, etc).
I had submitted this PR that fixes that problem in SDLPoP when the "FIX_OFFSCREEN_GUARDS_DISAPPEARING" flag is enabled. The flag also fixes disappearing guards between rooms.
https://github.com/NagyD/SDLPoP/pull/237/files
Shadow auto control logic is very dependent on a specific room arrangement when shadow appears in the air. If prince/shadow/guard are located even 1 pixel off vertically, they can end up between rows that can cause very weird behavior. The landing depends on the tile and the action that is going to occur (landing/grabbing/picking up sword or potion, etc).