Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store
Warnings about File Attachments - Please Read!
IGNORED

Adventure - Red Dragon (Rhindle) - bug or intentional programming?

Tidus79001

By Tidus79001
in Atari 2600

 Share

Recommended Posts

Tidus79001 Dragonstomper

Tidus79001

Posted
Posted (edited)

I am sure that others know of this as I have known about this trick since the game was originally released on the 2600 (not claiming to have found something new or relatively unknown), but I am curious if this was a bug that was never caught before the game was released or was intentional programming. I have found that Rhindle, the red dragon is not able to eat you eat when if you press yourself against the the top border of the screen and are positioned directly above his snout. Whenever you do that he will stay there pressed up against you until stop holding the directional control on your joystick to the up position (see embedded screenshot on this topic). Once you stop holding upwards holding the directional control Rhindle then will try to attack/eat you again, but until that point he is immobilized. Just a curious behavior that I have always wondered about as this trick will not work with the green (Grundle) or gold (Yorgle) dragons.

 

Rhindle.png

Edited by Tidus79001
  • Like 2
Link to comment
Share on other sites
Nukey Shay Quadrunner

Nukey Shay

Posted
Posted

Both the player and the red dragon move at 3-pixel jumps (i.e. their x/y positions are altered by +/- 3 pixels whenever their subroutiones are called). The yellow and green dragons move 2 pixels at a time. The reason that red gets locked is because of how the collisions are handled. Wall collisions are checked on every frame...the enemies, only 1 out of 3 (when their own routine is executed). When you collide with a wall, you are actually IN the wall for a frame. The collision is updated and the program bounces your sprite back in the opposite direction on the next 2 frames. First vertically (if applicable), then horizontally (if applicable). The red dragon subroutine is executed on this last frame. Dragon sprites follow your position by trying to match their horizontal and vertical positions with yours. Since the corrections to your sprite have already been applied, the red dragon sprite cannot collide with it...it's matching the "bounced back" position but the null collision was from the previous frame that had you stuck in the wall.

 

The fix would have been to deal with the red dragon on one of the 2 earlier frames instead of the last one, I think. As noted, the yellow and green dragons don't have this problem, because they move 2 pixels vs. the player's 3.

  • Like 10
Link to comment
Share on other sites
Tidus79001 Dragonstomper

Tidus79001

Posted
  • Author
Posted (edited)

Both the player and the red dragon move at 3-pixel jumps (i.e. their x/y positions are altered by +/- 3 pixels whenever their subroutines are called). The yellow and green dragons move 2 pixels at a time. The reason that red gets locked is because of how the collisions are handled. Wall collisions are checked on every frame...the enemies, only 1 out of 3 (when their own routine is executed). When you collide with a wall, you are actually IN the wall for a frame. The collision is updated and the program bounces your sprite back in the opposite direction on the next 2 frames. First vertically (if applicable), then horizontally (if applicable). The red dragon subroutine is executed on this last frame. Dragon sprites follow your position by trying to match their horizontal and vertical positions with yours. Since the corrections to your sprite have already been applied, the red dragon sprite cannot collide with it...it's matching the "bounced back" position but the null collision was from the previous frame that had you stuck in the wall.

 

The fix would have been to deal with the red dragon on one of the 2 earlier frames instead of the last one, I think. As noted, the yellow and green dragons don't have this problem, because they move 2 pixels vs. the player's 3.

 

Wow, great explanation! Very detailed and technical but still understandable. How did you come about this knowledge? Did you read through the code or did you just notice it by a programmers trained eye? Just curious how hard it would be to change the Red Dragon subroutine to 2 steps. If it was changed to fix the behavior of the Red Dragon would he still react the same in game minus that issue where you can immobilize him?

Edited by Tidus79001
Link to comment
Share on other sites
Nukey Shay Quadrunner

Nukey Shay

Posted
Posted

By looking at the order of subroutine execution. Objects are handled on seperate frames because there's not enough time to do all of them on any single frame. The "bounce back" effect seperates vertical from horizontal on 2 frames so that the player is allowed to "slide" along walls instead of just bouncing back to his original position (this accounts for the wobble when you slide horizontally...the vertical position is updated first - if no collision results from that, no horizontal correction is necessary). A consequence from that design is *no* dragon executing on the 3rd frame can reach the player when you are colliding upward against a wall. A goofier effect plays out if you swap the red dragon subroutine with either of the slower ones (or change the speed of the red dragon to be 2 pixels)...the dragon will shift 2 pixels to the side repeatedly in a vain attempt to reach the player's co-ordinates. Probably why WR chose to put the red dragon there and not the yellow or green.

 

A fix would be to throw something inconsequential in that 3rd frame, and move the red dragon on the earlier frame (swapping JSR MoveRedDragon with 1st frame's JSR Surround would work in the processor time allowed), but WR might have overlooked that. It still does not fix the problem of dragons not being able to eat a player colliding downward against a wall. When relying on hardware collisions only, this would need to be checked over the course of all 3 frames. However, doing that unfortunately breaks the player's "slide" effect which also relies on hardware collisions.

 

To completely fix both quirks, only use hardware collisions for the player movement, and use relative positioning checks for dragon attacks - relative positioning is already in use for the bat to grab offscreen items, so WR obviously knew how to implement it. Whether he intentionally left these quirks in the game is anybody's guess.

 

BTW the movement speed (or "delta") of the red dragon is set at address $F79E. Yellow and green deltas are at $F7B9 and $F7D4 respectively.

  • Like 2
Link to comment
Share on other sites
Tidus79001 Dragonstomper

Tidus79001

Posted
  • Author
Posted

By looking at the order of subroutine execution. Objects are handled on seperate frames because there's not enough time to do all of them on any single frame. The "bounce back" effect seperates vertical from horizontal on 2 frames so that the player is allowed to "slide" along walls instead of just bouncing back to his original position (this accounts for the wobble when you slide horizontally...the vertical position is updated first - if no collision results from that, no horizontal correction is necessary). A consequence from that design is *no* dragon executing on the 3rd frame can reach the player when you are colliding upward against a wall. A goofier effect plays out if you swap the red dragon subroutine with either of the slower ones (or change the speed of the red dragon to be 2 pixels)...the dragon will shift 2 pixels to the side repeatedly in a vain attempt to reach the player's co-ordinates. Probably why WR chose to put the red dragon there and not the yellow or green.

 

A fix would be to throw something inconsequential in that 3rd frame, and move the red dragon on the earlier frame (swapping JSR MoveRedDragon with 1st frame's JSR Surround would work in the processor time allowed), but WR might have overlooked that. It still does not fix the problem of dragons not being able to eat a player colliding downward against a wall. When relying on hardware collisions only, this would need to be checked over the course of all 3 frames. However, doing that unfortunately breaks the player's "slide" effect which also relies on hardware collisions.

 

To completely fix both quirks, only use hardware collisions for the player movement, and use relative positioning checks for dragon attacks - relative positioning is already in use for the bat to grab offscreen items, so WR obviously knew how to implement it. Whether he intentionally left these quirks in the game is anybody's guess.

 

BTW the movement speed (or "delta") of the red dragon is set at address $F79E. Yellow and green deltas are at $F7B9 and $F7D4 respectively.

Again great information. Thanks for taking the time to reply. Honesty it doesn't really bother me the behavior of the Red Dragon as it was more is a curiosity than an issue (unless you go out of your way to intentionally perform this trick it doesn't really come into play). I am note suggesting the Red Dragon is broken or should be change as they game is perfect and his behavior is a quirk that I have enjoyed playing with for all these years. Still not going to deny it would be interesting to see the game with the fixes just to see how would respond once they are in place. I would try hacking those changes in myself but I don't know 2600 programming so that would be out of the question for me to even attempt. :)

Link to comment
Share on other sites
  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...