Vertical Parallax effect in Battletoads
Moderator: Moderators
Vertical Parallax effect in Battletoads
Hi guys! 8)
I got another question for you - I can not explain that my own.
Lets have a look at this video - it is battletoads, level 2:
http://www.youtube.com/watch?v=wPd9TzBFc40
What puzzles me, is how did they manage to get that nifty parallax-effect?
Most of the time you see this effect, it is used in a horizontal manner ... and implemented with a line-counter (I guess). But in this game, it is used vertically. It looks very cool
How did they do that? What is their trick? Can you explain it to me? Enlighten me, please!
ninn, n00b.
I got another question for you - I can not explain that my own.
Lets have a look at this video - it is battletoads, level 2:
http://www.youtube.com/watch?v=wPd9TzBFc40
What puzzles me, is how did they manage to get that nifty parallax-effect?
Most of the time you see this effect, it is used in a horizontal manner ... and implemented with a line-counter (I guess). But in this game, it is used vertically. It looks very cool
How did they do that? What is their trick? Can you explain it to me? Enlighten me, please!
ninn, n00b.
Like Wave said, the game is most likely updating patterns every frame in accordance to the vertical scroll position to make it look like parts of the screen are moving at a different speed. The tiles being updated are most likely the ones at the sides, since they are made by a small repeating pattern (the left side is even equal to the right side, except for the color, which can be easily be explained by the use of different palettes).
Another possibility is that the game might be updating the name table instead of the pattern tables (all the possible scroll positions would be in CHR-RAM at all times), which would make more sense IF the number of tiles in the name table is smaller than the amount of bytes the patterns need AND not many tiles are necessary for all possible positions. It's most likely the other thing though.
Open the game in FCEUX and open the PPU viewer. If you see the patterns "moving" there, it's the patterns that are modified as the screen scrolls.
Another possibility is that the game might be updating the name table instead of the pattern tables (all the possible scroll positions would be in CHR-RAM at all times), which would make more sense IF the number of tiles in the name table is smaller than the amount of bytes the patterns need AND not many tiles are necessary for all possible positions. It's most likely the other thing though.
Open the game in FCEUX and open the PPU viewer. If you see the patterns "moving" there, it's the patterns that are modified as the screen scrolls.
You can see the same type of effect in Sword Master.
http://www.youtube.com/watch?v=SPhfMr44T-c&t=13s
Part of the trick with updating so many tiles per frame is writing really fast code. Simply using an unrolled loop would help quite a bit. If that Battletoads animation covers 12 tiles (looks like it), that's 192 bytes to update per frame - not a small amount.
http://www.youtube.com/watch?v=SPhfMr44T-c&t=13s
Part of the trick with updating so many tiles per frame is writing really fast code. Simply using an unrolled loop would help quite a bit. If that Battletoads animation covers 12 tiles (looks like it), that's 192 bytes to update per frame - not a small amount.
Or using CHR-ROM, like Sword Master does.Memblers wrote:You can see the same type of effect in Sword Master.
http://www.youtube.com/watch?v=SPhfMr44T-c&t=13s
Part of the trick with updating so many tiles per frame is writing really fast code.
Other examples of this trick being used for parallax effects:
http://www.youtube.com/watch?v=TSVWQGbENBI&t=3m
http://www.youtube.com/watch?v=L2WNPBXPAzQ&t=45s
http://www.youtube.com/watch?v=b1lpWKwZijY&t=5m40s
http://www.youtube.com/watch?v=QWygtM8zPcE
Wow!
I am overwhelmed by your answers!
Thanks for pointing me in the right direction, wave, shiru, tokumaru, dwedit, sivak, memblers, tepples
If I understand correctly, every time (or most of the time ^^) the screen moves on the nametable, the chr-ram gets updated (e.g. position of the tile is 'shifted'). that way, it looks like it is moving at another speed compared to the background.
But, qquestion:
Do I need a scanline-counter for that effect, or can I easily count frames for this effect? I know, that scanline-counters are something special, but this effect looks like it can be done with just a framecounter.
Thanks a lot for your helpful links and comments, especially for that super nice and personal animated gif, that made my heart smile! Thanks so much!
... you know you are on the right forum when something like that happens.
I am overwhelmed by your answers!
Thanks for pointing me in the right direction, wave, shiru, tokumaru, dwedit, sivak, memblers, tepples
If I understand correctly, every time (or most of the time ^^) the screen moves on the nametable, the chr-ram gets updated (e.g. position of the tile is 'shifted'). that way, it looks like it is moving at another speed compared to the background.
But, qquestion:
Do I need a scanline-counter for that effect, or can I easily count frames for this effect? I know, that scanline-counters are something special, but this effect looks like it can be done with just a framecounter.
Thanks a lot for your helpful links and comments, especially for that super nice and personal animated gif, that made my heart smile! Thanks so much!
... you know you are on the right forum when something like that happens.
You don't need a scanline counter, only CHR RAM.
The piece of background that moves with different speed is just a small repeating tileable pattern, like 4*4 characters or so. You need to 'scroll' graphics of these characters in RAM, using ROL/ROR etc opcodes accordingly to the general scrolling direction, and update these tiles in CHR RAM. You can do it this way: one frame you scroll the characters in RAM, other frame you send them into CHR RAM - thus they will scroll slower, creating parallax effect. So it is not 'position of tile' shifted, it is the graphics of the characters that is shifted.
Scanline counter is needed (not necessarily, though) for screen split tricks that divide screen into few horizontal stripes. You can combine both tricks, like in Sword Master - top parallax layer (mountains) is done with scrolled tiles, bottom layer (ground) is done with screen split.
The piece of background that moves with different speed is just a small repeating tileable pattern, like 4*4 characters or so. You need to 'scroll' graphics of these characters in RAM, using ROL/ROR etc opcodes accordingly to the general scrolling direction, and update these tiles in CHR RAM. You can do it this way: one frame you scroll the characters in RAM, other frame you send them into CHR RAM - thus they will scroll slower, creating parallax effect. So it is not 'position of tile' shifted, it is the graphics of the characters that is shifted.
Scanline counter is needed (not necessarily, though) for screen split tricks that divide screen into few horizontal stripes. You can combine both tricks, like in Sword Master - top parallax layer (mountains) is done with scrolled tiles, bottom layer (ground) is done with screen split.
Just wanted to note that you can do the same trick with CHR-ROM, if the mapper can swap small enough chunks. It's actually *easier* with CHR-ROM because you don't waste time rotating graphics and uploading them to VRAM, you just switch the appropriate bank every frame and you're done. The only disadvantage is that it wastes a significant amount of CHR-ROM, because all possible rotations must be present. Most games in the videos I showed use CHR-ROM, not RAM.Shiru wrote:You don't need a scanline counter, only CHR RAM.
-
- Posts: 130
- Joined: Mon May 25, 2009 2:20 pm
But it doesn't suck... it may use a lot of memory, but it's much simpler to program than the CHR-RAM version, which wastes a lot of CPU time software scrolling the patterns and precious VBlank time uploading them to the PPU. Both methods have advantages and disadvantages, so you can't really say one of them sucks when compared to the other.kuja killer wrote:yea it defintely sucks when using CHR-ROM to do it.
-
- Posts: 130
- Joined: Mon May 25, 2009 2:20 pm
oh right, sorry. my bad.
Yea i know they both have pros and cons each, against each other.
I really only just meant that comment towards the fact about the amount of graphic space it can take up. But i wasn't clear about it.
but anyway yea i do understand what you mean. In my opinion, CHR-ROM is far far better compared to the CHR-RAM method for doing parallax overall.
I wish i could do it more often for megaman odyssey, but i cant risk using all the graphic space. So only allowed to very "sparingly" once in a blue moon.
Yea i know they both have pros and cons each, against each other.
I really only just meant that comment towards the fact about the amount of graphic space it can take up. But i wasn't clear about it.
but anyway yea i do understand what you mean. In my opinion, CHR-ROM is far far better compared to the CHR-RAM method for doing parallax overall.
I wish i could do it more often for megaman odyssey, but i cant risk using all the graphic space. So only allowed to very "sparingly" once in a blue moon.