Page 1 of 1
Vertical Parallax effect in Battletoads
Posted: Tue Nov 29, 2011 3:47 am
by ninn
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.
Posted: Tue Nov 29, 2011 4:32 am
by Wave
I think it's done replacing tiles in CHR-RAM to make an effect that it's moving, you could check on an emulator.
Posted: Tue Nov 29, 2011 4:50 am
by Shiru
These effects are done by updating graphics of few tiles in video memory (CHR RAM for NES) every frame. You can see this effect on other 8-bit platforms, like 64, it done that way there too.
Posted: Tue Nov 29, 2011 4:54 am
by tokumaru
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.
Posted: Tue Nov 29, 2011 10:43 am
by Dwedit
They are loading new tiles into CHR-RAM every other frame, like this:
It repeats every 32 updates.
Posted: Tue Nov 29, 2011 10:46 am
by Sivak
Yeah. They do CHR RAM for a lot of the animations such as the waterfall in stage 1, the snakes in the snake pit, etc.
Posted: Tue Nov 29, 2011 4:22 pm
by Memblers
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.
Posted: Tue Nov 29, 2011 4:24 pm
by tepples
Battletoads is also known for turning on rendering late and using huge unrolled loops to copy from page $01.
Posted: Tue Nov 29, 2011 5:09 pm
by tokumaru
Posted: Wed Nov 30, 2011 4:05 am
by ninn
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.

Posted: Wed Nov 30, 2011 4:22 am
by Shiru
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.
Posted: Wed Nov 30, 2011 5:12 am
by tokumaru
Shiru wrote:You don't need a scanline counter, only CHR RAM.
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.
Posted: Wed Nov 30, 2011 6:34 pm
by kuja killer
yea it defintely sucks when using CHR-ROM to do it.
in my megaman odyssey game, i did the whole background parallax for the cave section of the 1st boltman level, and god that eats up soooo MUCH graphic space.
32 whole pages (64 tiles for each page).
sheesh
Posted: Wed Nov 30, 2011 8:11 pm
by tokumaru
kuja killer wrote:yea it defintely sucks when using CHR-ROM to do it.
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.
Posted: Wed Nov 30, 2011 9:55 pm
by kuja killer
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.