(Link to video)
Submission Text Full Submission Page
This is the DOS version of Prince of Persia, the classic 2D platformer originally released for Apple II in 1989. This version is the most popular among the RTA runners of the game.

Game objectives

  • Emulator used: JPC-RR r11.8-rc2
  • BIOS used: The BIOS and VGABIOS that come pre-bundled with the emulator was used as instructed in the emulator description page.
  • The objective of the run is to complete the game, which is this case means saving the princess from the evil Jaffar.
  • No major glitches are to be used in the run, see below for more details.
  • The only notable "programming error" taken advantage of in the run is the jingle skip at the end of few levels. Killing an enemy at the end of a level before entering the final door "replaces" the long end of the level jingle with the the much shorter enemy kill jingle.
  • We control only one character in the run - the kid (who becomes the prince at the end of the game).
  • Hits are taken at some parts of the run if that's how the RNG is, it neither gains nor loses any significant time.
  • There are exactly two restarts, one skips a short jingle and one is just faster in terms of movement. No deaths.
  • Ruleset of this run is completely derived from the RTA No Major Glitches runs, which is as follows:
    • The following things are considered glitches:
      • Screen-wrapping
      • Guard-clipping (guard-jumping)
      • Falling or clipping through floors and closed gates (specifically corners)
      • Fall damage crouch cancel
      • Inactive chomper glitch
      • Guard through-gate lure glitch
    • Here is a guide that explains these with GIFs showing examples - https://www.speedrun.com/pop1/guide/m4j3u
    • Sound & music must be enabled at all times during the run.
    • Ctrl+A to restart a level is allowed, except for situations where it would cause a glitched advance to next level instead of restarting.
    • You can skip cutscenes between levels.

Comments

This is a "No Major Glitches" run of the game which is more movement based. Almost all the inputs can be buffered in this game. The biggest trouble of the run is dealing with guard RNG. They can not only mess you up when trying to cross them but also affect prince's positioning which is super important for the movement section that follows right after. The main way of manipulating the RNG used in the run is waiting for a few frames. In most of the cases waiting for 1 frame was sufficient but there were places where I had to wait for more. The biggest potential to improved this run is doing more research into RNG manipulation and making things stuff line up more perfectly. Jumping is the fastest movement when in flat terrain, however depending on the layout of the room, various other movements are done to gain time. The most common way to deal with enemies is to stop as close to them as possible and switch sides with them. After that we either get further away from them, put away our swords and continue, or strike them and put away our swords and continue. The latter is preferred only when it allows for an extra jump to be possible. I also tried a lot to set up soundblaster but for some reason the emulator used PC speaker sounds for SFX, luckily atleast the jingles played in soundblaster.

Stage by stage comments

Level 1

This level is a simple one but it already does something unintended. We lure the guard into the a specific spot and then we are able to take a path that gets around him without having to pickup the sword and killing him. This saves about a full minute. Aside from that several small movement optimizations were done, the bunny hops to skip the slow "getting up" animation, using the "turnaround" to bonk into walls faster, carefully spacing jumps to travel minimum distance and hence making maximum use of the "snap" feature to grab ledges to name a few. The good thing about this level is that its completely RNG free.

Level 2

This is the level where the RNG Gods strike first. I had to wait 1 frame for the first guard. I got hit by the second guard. The orange guard was surprisingly nice and I used the last guard to set-up a really precise chain of jumps that involves barely avoiding some spikes. The rest of the level is just movement and thanks to the massive "hitbox" of the final door we are able to get a massive snap and enter it to finish the level.

Level 3

This level is actually again one of the completely RNG free levels, despite containing the most infamous skeleton enemy. The entire level is full of movement optimizations, mostly the ones mentioned previously in level 1 description. We are able to jump over the skeleton avoiding having to swap places with him and just run away without having to deal with him, which is a really cumbersome process as he has infinite health and the only way to be rid of him is to push him into a pit. The rest of the level is straight-forward.

Level 4

This level starts with a movement section which involves a precise turnaround to make a loose tile open a door that needs to be opened to progress. It becomes even more precise if we need be in a good position to be able to jump and grab a ledge on the way back. Proceeding further we deal with the first enemy. He didnt pose any problems although he managed to push us one unit further than where we need to be but thanks to the snap feature it doesnt lose any time. We proceed an meet the enemy beside the door, we temporarily spare him and proceed to the section where the final button is. After some precise jumps back and forth through a chomper and going through the mirror that suddenly spawns and creates a friendly shadow of us, we return to the enemy and kill him to skip the end level jingle.

Level 5

This level is both heavily RNG and movement based. There is nothing special to talk about this level other the fact that I got pretty decent RNG from the guards.

Level 6

This is the shortest level of the game, it contains the "mini-boss", aka the fat guard. We dont have to kill him so we just ignore him and jump through the final pit to trigger the next level.

Level 7

If you played the casually, you know that this is exactly where the hard part of the game starts. There are few guards in the level who actually gave the perfect patterns that can be expected from them. This is also the first level where we continuously step away from an enemy till we reach a pit to skip the sword put away animation. After some precise platforming the movement section and dealing with the next guard, we take the floating potion to reach the bottom of the level and exit it.

Level 8

This level has quite a few guards and some cool movement sections. The way we deal with the first guard is the first major difference from RTA runs, we throw him into the spike pit instead of switching sides with him so that we can clear the next jump without having to grab the ledge and also preserving the momentum. After traversing the long corridor and dealing with some guards on the way, we reach the final section of the level. The final orange guard was not behaving and marks the first instance of having to wait multiple frames to get the required result. And then we finish the final corridor and exit it without having to wait for the mouse to come rescue us and proceed to finish the level.

Level 9

If I have to pick one level that I am least happy with despite being happy with the overall result, it will probably be this one. The RNG I got was below decent and were such that it forced me to certain movement sections without making full use of the snap. But as a reward we get to do the most satisfying movement section in my opinion perfectly. And then we proceed to the final guard and again use the backing away continuously to skip the sword put away and enter the final door.

Level 10

This level again has a lot of guards and also a lot of variety in the way we deal with them. This is the first level where were are forced to kill a guard that is not near gate (atleast in order to be fast). We also kill the final guard to skip the jingle. Despite all this, I surprisingly got really good rng and had wait very few frame throughout the whole level.

Level 11

Most of this level is fully consistent, other than the last guard, and he decided to give the worse pattern unfortunately. But as a redemption, we lure him near the end of the door and throw him off the edge and enter the final door while skipping the jingle.

Level 12

As a reward for all the things we did so far, we are presented with a RNG-free level. After some platforming we climb the tower and and the end we meet our friend shadow again and merge with him. We have to wait for the merging to completely finish or else the invisible bridge in the next room wont spawn.

Level 13

Two things in this level. Falling tiles and Jaffar. The former was luckily nice and I was able to get around without having to do any sort of manipulation (yes they dont fall in a consistent pattern). With Jaffar we are able to do a running jump from a very specific position to get as near him as possible and stab him before he wakes up. This is actually slower in IGT which is used to time the RTA runs of the game but faster in TAS timing thanks to fact that we can chain two jumps on the way back. The IGT is already stopped at this point.

Level 14

This level is a nice, charming reward for completing the game and we get to reunite with the princess at the end of the corridor. The only thing notable about this level is some carefully timed jumped to get under doors without losing momentum. And this final cutscene is considered to be the end of the game.

Final Thoughts and acknowledgements

I had quite a lot of fun making this and I hope you will watching this as well :D. I am happy with the result I got but I may return to this in the future to try make some improvements, especially in terms of RNG. I would like to specially thank 7eraser7, eien86, higlak for helping me in routing certain parts, timing the strats and in general the whole RTA speedrunning community for being supportive and providing very good feedback whenever I asked for it.

feos: Embedded the encode.
feos: Fixed formatting.
slamo: The quality of this run is obviously quite good. The routing and the overall use of tech is well done. Unfortunately, as outlined in this post, this run uses a cracked version to skip a copy protection sequence and therefore does not meet our standards for game authenticity.
There was much discussion about the game category. There are still things that might be considered glitches such as the jingle skip, and trying to draw the line between "major" and "minor" glitches is always going to be arbitrary. When you come up with a goal other than any% or 100%, please make sure the goal is very well-defined and constantly adhered to. The goal should offer some different content than any% and 100%, and it should also be entertaining enough; my impression from this run and its feedback is that a pure glitchless run would check both boxes, if you can indeed prove that no glitches are being used.
It's pretty clear that you know how to make a good TAS, and I hope you do pursue other TASes in the future; so much of the DOS library is untouched!
Rejecting for modified game files.
slamo: Revisiting this for Playground, and I think it fits. The goal is somewhat arbitrary but well-defined, and we know that it syncs with a known cracked version. This cracked version isn't eligible for publication but these should generally be ok for Playground, as long as the version isn't too obscure. Moving to Playground.

GMP
He/Him
Editor, Reviewer, Active player (360)
Joined: 5/22/2020
Posts: 197
Location: Chennai, India
Nach wrote:
To think of it differently, SDLPoP ports a DOS version to Windows and Linux (so the levels and various mechanics found in the game should be nearly identical), and this version is open sourced and freely available. If one were to TAS that, off the top of my head, I don't see any objections as to why we wouldn't accept it.
Oh, from what I understand it is actually far easier for eien to make a TAS in SDLPoP, he painstakingly copied the inputs to JPC-RR only because it was the only emulator relevant to this game that was listed as acceptable in the site guidelines.
Emulator Coder, Judge, Experienced player (608)
Joined: 2/26/2020
Posts: 698
Location: California
GMP wrote:
Oh, from what I understand it is actually far easier for eien to make a TAS in SDLPoP, he painstakingly copied the inputs to JPC-RR only because it was the only emulator relevant to this game that was listed as acceptable in the site guidelines.
If you can get it working with libTAS, that should be acceptable as a Linux submission.
GMP
He/Him
Editor, Reviewer, Active player (360)
Joined: 5/22/2020
Posts: 197
Location: Chennai, India
CasualPokePlayer wrote:
If you can get it working with libTAS, that should be acceptable as a Linux submission.
If I ever work on a TAS of this game again, I would simply use a original version of the game. But I will pass this information to the team doing the any% TAS.
eien86
He/Him
Judge, Skilled player (1700)
Joined: 3/21/2021
Posts: 174
Location: Switzerland
Using SDLPop would greatly simplify our work, as we already have developed tools to feed it frame-by-frame commands and produce replays that can be played by SDLPop everywhere else. That would relieve us from painstakingly inputting the commands into JPC-RR and also solve the sound emulation/jittering issue. If we are allowed to submit these movies under Linux/SDLPop, then I'll start working on it immediately. I would note in the submission though, that these runs can be proven to be reproducible in the original DOS game.
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11268
Location: RU
Right now, DOOM movie replay system is the only exception to movie formats that we allow, which are normally based on emulation. Because when you're emulating the hardware the original game is meant to run on, it's a guarantee that no possible flaw or cheating is involved that may come from the in-game movie replay system. Some games provide too much freedom in their internal movies, like forcing your position to something arbitrary, which wouldn't be possible while playing normally. So if we want to add support for some new in-game movie replay system, which is by definition game-specific, we need to make sure it doesn't allow illegitimate techniques, has proper savestate support, is deterministic, and is overall reliable enough for general TAS use. Another option would be to use libTAS. Because it already guarantees legitimacy of the movie, even though it's not an emulator (but an API translation layer), and has reliable TAS tools. It only work on Linux and WSL2 though.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
GMP
He/Him
Editor, Reviewer, Active player (360)
Joined: 5/22/2020
Posts: 197
Location: Chennai, India
There has been some confusion between the two threads, precisely because this thread has been discussing about any% and the other thread about NMG. I request any future discussions about the any% or the future plans to rectify to be moved to it's appropriate thread - http://tasvideos.org/forum/viewtopic.php?t=22620
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11268
Location: RU
GMP wrote:
Thanks man, yeah I have learnt my lesson and will never do a arbitrary goal TAS again lol.
GMP wrote:
Yesterday in the RTA speedrunning community, we discussed about the sort of arbitrary nature of the ruleset and we decided its not very apt to call it "glitchless" and renamed the category to "No Major Glitches". So I decided to add that as the branch to this run. However if the judges feel that it is not necessary, feel free to remove the branch.
Arbitrary goal is not a problem if it's clearly defined and the community supports it, and if it's properly achieved. The problem with this submission originally was that some of the techniques used do look like glitches to some viewers. The proper way to resolve this is by bringing up official information of some kind that proves it's an intended mechanic. For example, explicit checks in the code, or explicit mentions on the manual. Then whatever the community had doubts about, but what has been proven to be intended, can stay in the future run. And what looks like a glitch and lacks explicit official support, should be avoided. But why still care about the "true glitchless" branch now that we've ranamed this to "NMG"? We don't officially use the term "major glitch" because it's too subjective. Instead we use heavy glitch abuse, and so far, looking at what glitches this run avoids and the other one uses, it's what makes them different branches on SRC. Now here's what our thing looks like: [2601] NES Mega Man "game end glitch" by pirohiko & finalfighter in 00:32.11 versus [4131] NES Mega Man by Shinryuu, pirohiko, Maru & finalfighter in 09:45.35 [3264] N64 Super Mario 64 "1 key" by Tyler Kehne, mkdasher, sonicpacker, snark, SilentSlayers, ToT, Plush, Gaehne D, Eru & sm64expert in 04:21.30 versus [2062] N64 Super Mario 64 "70 stars, no Backwards Long Jump" by Jesus, Kyman, MICKEY_Vis11189, MoltovM, Nahoc, snark, sonicpacker, ToT, CeeSammerZ, coin2884, Eru, Goronem, Mokkori, Nekuran, Nothing693 & pasta in 42:58.52 Note the tremendous time difference, and how fundamentally different the resulting branches look. It's called a major skip glitch, because it's a glitch that skips majority of the game. So for games where such a glitch is possible, the run that avoids it is usually entertaining and different enough to be its own branch. But there are also games where heavy glitch abuse doesn't skip most of the game, but some people find it questionable in terms of entertainment. So we allow to void it if it makes the movie more interesting, or equally interesting but different enough. [3570] Genesis Sonic the Hedgehog by Aglar in 14:13.87 versus [1937] Genesis Sonic the Hedgehog "no zips" by Aglar in 17:36.58 [696] Genesis Pulseman by Twisted Eye in 25:16.02 versus [862] Genesis Pulseman "no motion glitch" by IdeaMagnate in 33:57.15 In this game, it's a set of glitches that's avoided or used. It's not a set of major skip glitches, and their sum is not a major skip glitch, because each of them skips only a small portion of the game and is in itself not severe enough. What do we call it then? I actually don't know. And on the first glance it may look like categorization is only a small and barely relevant problem. "Oh we can't come up with a proper branch label so we must reject the run." But the main question is why can't we come up with a proper branch label? From reading the thread, I think it's because the goal is not a clear cut. Avoiding more glitches will make this branch more different from any%, and also more entertaining, because people won't feel that questionable glitches are spoiling the fun. When coming up with a new goal (new for our site), we want it to be as different from any% and 100% as possible, because that way we can feature as much content as possible through all the variety of branches that we can afford. Minor differences blend together, and it gets hard to expect unique content from branches that are published differently. So we encourage maximum difference. Bottomline. The feedback regarding this run's goal was mixed not (just) because it wasn't labeled the way the RTA run is. It's because the borderline of a glitch definition is blurred. So I think that doing a properly glitches run will be received just as good in terms of votes (if not better), and will also not cause the questions about its category. And the best way to resolve those questions is to draw the line where the developers draw it explicitly. And if they don't address something that causes questions, just avoid it.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
GMP
He/Him
Editor, Reviewer, Active player (360)
Joined: 5/22/2020
Posts: 197
Location: Chennai, India
Ok, that was a very well-put post, and gave a lot of insight. Seeing that this run has many problems, I might consider doing a new one in its place. But before that I would like to get some feedback in the form of a list of things that should be avoided if I am doing a pure "glitchless" run. Taking data from the thread, here are thing that viewers felt were glitches: - Swapping sides from guards and turning away from guards in mid-combat. Here is a section of the manual which mentions it - https://i.imgur.com/zk9CPfk.png - "Walking on air". As I already mentioned, this is a standard mechanic in the series. I have already linked this before but here is the same mechanic in the ps3 port - https://i.imgur.com/b5FNosj.mp4 I am not denying it has different physics and introduces new mechanics but I am sure anyone who is familiar with the franchise would even get the thought that it could be a glitch. - Avoiding damage from a falling tile by ducking. I agree, that this doesnt belong if a run to be made under the "glitchless" branch. - One hit kill jaffar. In the "to stop fighting" section of the manual snapshot I linked above, it is mentioned that "when you are off guard, a single sword blow can kill you", this exact same mechanic applies to enemies as well. The only thing we do is find a way to get close to him and strike before he becomes alert. Feel free to point out other tricks I did in the run that would be considered glitches as per this site standards and also feel free to point out tricks that I mentioned in the ruleset that *won't* be considered glitches here.
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11268
Location: RU
Do you have to perform anything specific to walk on air aside form... just keep walking? And how long does it last at max?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
GMP
He/Him
Editor, Reviewer, Active player (360)
Joined: 5/22/2020
Posts: 197
Location: Chennai, India
feos wrote:
Do you have to perform anything specific to walk on air aside form... just keep walking? And how long does it last at max?
Assuming by "walking in air", the turn around is what is mentioned, it's simply just about holding the opposite direction as current running direction at the right moment. It lasts for about a second, basically till the turnaround animation is completed. Edit: Timestamp of what I am referring to - https://youtu.be/qEUwTODtHLk?t=490
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Thank you for that post, I think it's great to have discussion on what is or isn't a glitch, instead of reusing RTA's definition.
GMP wrote:
Swapping sides from guards and turning away from guards in mid-combat. Here is a section of the manual which mentions it - https://i.imgur.com/zk9CPfk.png
"Guard AI is pretty dumb"; sure, I can buy that this is not a glitch, but I'd like to check how much luck manip it requires.
"Walking on air". As I already mentioned, this is a standard mechanic in the series.
I believe this became a standard mechanic in the series because it was a glitch in the first game. From the level design (e.g. of level 12), the intent is that a running far jump requires a three-tile platform, and it is unintended that you can do it on a two-tile platform (by running in the other direction and "walk on air" to turn around for a running start). Several ports of POP1 don't allow this trick (e.g. [4158] NES Prince of Persia by Challenger in 16:16.06, [1193] Genesis Prince of Persia by Aqfaq in 19:03.48, [3523] PCECD Prince of Persia by Challenger in 05:14.31); therefore I believe this is not a standard mechanic in the first game.
"when you are off guard, a single sword blow can kill you", this exact same mechanic applies to enemies as well.
In your video around 14:10, attempting to attack someone "off guard" doesn't one-shot him. Even if that were an intentional mechanic, that you run up to Jafar from half a screen away, from his front? That should clearly "activate" him, and it's a glitch that it doesn't.
GMP
He/Him
Editor, Reviewer, Active player (360)
Joined: 5/22/2020
Posts: 197
Location: Chennai, India
Radiant wrote:
Thank you for that post, I think it's great to have discussion on what is or isn't a glitch, instead of reusing RTA's definition.
GMP wrote:
Swapping sides from guards and turning away from guards in mid-combat. Here is a section of the manual which mentions it - https://i.imgur.com/zk9CPfk.png
"Guard AI is pretty dumb"; sure, I can buy that this is not a glitch, but I'd like to check how much luck manip it requires.
"Walking on air". As I already mentioned, this is a standard mechanic in the series.
I believe this became a standard mechanic in the series because it was a glitch in the first game. From the level design (e.g. of level 12), the intent is that a running far jump requires a three-tile platform, and it is unintended that you can do it on a two-tile platform (by running in the other direction and "walk on air" to turn around for a running start). Several ports of POP1 don't allow this trick (e.g. [4158] NES Prince of Persia by Challenger in 16:16.06, [1193] Genesis Prince of Persia by Aqfaq in 19:03.48, [3523] PCECD Prince of Persia by Challenger in 05:14.31); therefore I believe this is not a standard mechanic in the first game.
"when you are off guard, a single sword blow can kill you", this exact same mechanic applies to enemies as well.
In your video around 14:10, attempting to attack someone "off guard" doesn't one-shot him. Even if that were an intentional mechanic, that you run up to Jafar from half a screen away, from his front? That should clearly "activate" him, and it's a glitch that it doesn't.
Fair points for the last two. Regarding the first one, yeah it's really simple. I am willing to bet you can do it in your copy of the game pretty easily right now.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
GMP wrote:
- Avoiding damage from a falling tile by ducking. I agree, that this doesnt belong if a run to be made under the "glitchless" branch.
I recall seeing this in a manual for one of the ports. The explanation was that if the tile hits you in the head it hurts, but not if you're ducking for cover. So it seems intentional you're supposed to not be damaged when ducking.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
GMP
He/Him
Editor, Reviewer, Active player (360)
Joined: 5/22/2020
Posts: 197
Location: Chennai, India
Nach wrote:
GMP wrote:
- Avoiding damage from a falling tile by ducking. I agree, that this doesnt belong if a run to be made under the "glitchless" branch.
I recall seeing this in a manual for one of the ports. The explanation was that if the tile hits you in the head it hurts, but not if you're ducking for cover. So it seems intentional you're supposed to not be damaged when ducking.
Interesting, I actually didn't know that. I guess that is the history behind it being allowed for RTA NMG runs as well.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
GMP wrote:
Nach wrote:
GMP wrote:
- Avoiding damage from a falling tile by ducking. I agree, that this doesnt belong if a run to be made under the "glitchless" branch.
I recall seeing this in a manual for one of the ports. The explanation was that if the tile hits you in the head it hurts, but not if you're ducking for cover. So it seems intentional you're supposed to not be damaged when ducking.
Interesting, I actually didn't know that. I guess that is the history behind it being allowed for RTA NMG runs as well.
Found it:
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
GMP wrote:
Regarding the first one, yeah it's really simple. I am willing to bet you can do it in your copy of the game pretty easily right now.
Yes, I can confirm that; I got about 60% success rate with zero practice. Interestingly, the sequel Prince of Persia 2 appears to run on the same engine, and does not allow the walking-on-air trick. I get the impression that they've deliberately removed it.
Nach wrote:
I recall seeing this in a manual for one of the ports. The explanation was that if the tile hits you in the head it hurts, but not if you're ducking for cover.
Huh. My headcanon is now that that's a bug and they covered for it by adding it to the manual, because of how little sense it makes. Still, the fact that it is in the manual makes it fair game for any glitchless run.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Radiant wrote:
Interestingly, the sequel Prince of Persia 2 appears to run on the same engine, and does not allow the walking-on-air trick. I get the impression that they've deliberately removed it.
The engine does feel very similar. They've added a bunch of things to it though. Their trap door in the floor traps probably required they modify how the running and falling logic works.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11268
Location: RU
What's the source of that pic, Nach?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Radiant wrote:
Nach wrote:
I recall seeing this in a manual for one of the ports. The explanation was that if the tile hits you in the head it hurts, but not if you're ducking for cover.
Huh. My headcanon is now that that's a bug and they covered for it by adding it to the manual, because of how little sense it makes. Still, the fact that it is in the manual makes it fair game for any glitchless run.
Here's the source code which handles falling floor and player interaction:
*-------------------------------
*
*  Crush char with falling block
*  (Ordered by ANIMMOB)
*
*-------------------------------
crushchar
 lda level
 cmp #13
 beq :1
 lda CharPosn
 cmp #5
 bcc :1
 cmp #15
 bcc ]rts ;running-->escape

:1 lda CharAction
 cmp #2
 bcc :ground
 cmp #7
 bne ]rts

* Action code 0,1,7 -- on ground

:ground
 ldx CharBlockY
 inx
 lda FloorY,x
 sta CharY ;align w/floor

 lda #1
 jsr decstr
 beq :kill

 lda CharPosn
 cmp #109
 beq ]rts
 lda #crush
 jmp jumpseq

:kill lda #hardland ;temp
 jmp jumpseq
My understanding of it is that if the character is running, or is in a position other than regularly standing on the ground, they are supposed to get crushed by falling tiles. Here's the position codes I could find so far: 1 - standing still 2 - hanging at one angle 4 - falling 5 - mid bump 6 - hanging at another angle 7 - turning Higher numbers indicate climbing. According to the comments, only position 0, 1, and 7 are supposed to be damaged by a falling tile. We still need to determine the meanings for position 0 and 3. Based on the comment, it is intended that position 0 is damaged by a falling tile and position 3 is not.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Okay, I found this in a different part of the code:
 lda CharPosn
 cmp #109 ;crouched (e.g. on loose floor)
Meaning there's an explicit check in the code above to see if the character is in the crouched position before processing the crushing/killing sequence. If he is crouched, the function is terminated. Meanwhile I found this in a different part of the code:
cmp #111 ;crouching
I think there's multiple crouching positions because there's animation between starting to crouch and fully crouched. So only the crouching position represented by 109 is safe, while the other crouch states are not.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
What's the source of that pic, Nach?
I own four different versions of the game. Broderbund MS-DOS Broderbund Macintosh Konami Game Boy Konami SNES The manual for the first two have it, while the manuals for the last two do not. Now I'm thinking I should test the Konami versions to see if they have this mechanic or not. Edit: I tested the Game Boy version a bit. So far, I couldn't get any tiles to fall on my head at all. Jumping up to hit a tile falls down immediately and hits the ground before you do from the jump. I looked at a place in the game where normally there's automatically falling tiles by themselves to see if I could run under them. However in the Game Boy version has these areas with the tiles already on the floor. Now I'm also noticing the Game Boy version's manual doesn't even mention anywhere you should avoid falling tiles like the manual for other versions do. Edit: I tested the SNES version. You get hurt by falling tiles in this version while ducking. Edit: I didn't feel like breaking out my CD, so I tried a site which had an MS-DOS version in DOSBox, and I see getting hit by the falling ceiling in this version causes double damage, which I don't recall from playing the game years ago. So either this version is different, or the crouching to safety from falling tiles mechanic only works in certain states of crouching, but not all of them.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Here's the relevant source from SDLPoP: Download seg007.c
Language: c

// seg007:15D3 void __pascal far fell_on_your_head() { short frame; short action; frame = Char.frame; action = Char.action; // loose floors hurt you in frames 5..14 (running) only on level 13 if ( (current_level == 13 || (frame < frame_5_start_run || frame >= 15)) && (action < actions_2_hang_climb || action == actions_7_turn) ) { Char.y = y_land[Char.curr_row + 1]; if (take_hp(1)) { seqtbl_offset_char(seq_22_crushed); // dead (because of loose floor) if (frame == frame_177_spiked) { // spiked Char.x = char_dx_forward(-12); } } else { if (frame != frame_109_crouch) { // crouching if (get_tile_behind_char() == 0) { Char.x = char_dx_forward(-2); } seqtbl_offset_char(seq_52_loose_floor_fell_on_kid); // loose floor fell on Kid } } } }
My understanding of the code in this version is that a falling ceiling is always supposed to take 1 damage if you're crouching, the only difference is the animation that plays.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Nach wrote:
there's an explicit check in the code above to see if the character is in the crouched position before processing the crushing/killing sequence.
The explicit check is after processing crushing killing, same as in the SDLPoP source:
 lda #1
 jsr decstr       <= Decrease strength, i.e. hit points
 beq :kill        <= kill player at 0 hp

 lda CharPosn
 cmp #109         <= then here's the check for crouching.
 beq ]rts
So the idea of the code is to force the player into crouching animation when hit, unless he was already crouching.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
It appears you are correct, thanks!
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11268
Location: RU
What about other things mentioned in Post #505613? So far it looks like this run is indeed true glitchless!
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.