A few limitations related questions...

Hi!

I already posted in this topic and I got some really useful answers! Thank you guys!
I played a few NES games since then and I realised how many things I missed.
There are a few more techniques that I don't clearly understand.

Parallax scrolling: I know it can be done in case of none overlapping background elements. And it involves IRQs. But I saw scrolling where there was overlapping.
Foreground elements: This is what I have no idea at all. I played G.I. Joe and it has many foreground elements. How it works and what are the limitations? What I can do and what I can't?
I saw that when there are foreground elements, there is usually one background colour. In Terminator 2 - Judgement Day, in the last level, the terminator can run up and down on stairs. The stairs have railings and they are in the foreground. But when the player decides not to walk up, but walk next to it, it appears in the background. R.C. Pro AM II had those bridges what you can go under.
In Platoon, there are bushes in front of the character. And the list goes on. Many games used this technique, but I kinda forgot about them.
Weird distortion effect: Mission: Impossible. This incredibly difficult beast had some interesting distortion effect. Probably I won't use anything like this, but I'm curious, how it was done.

Anyway, I started to develop my game in Unity, but now I use Game Maker and I think I made a good decision. I'm still on making my game true to the NES limitations. Maybe I'll not mess around with the limitations of being at most 8 sprites per scanline.

Are you sure that the overlapping parts were not done with sprites? Some emulators (FCEUX) let you hide background/sprites, which might help you figure it out.


Sprites have a flag for "background priority", meaning that they will be drawn behind the background graphics. Basically you can think of it as there being 4 "layers": background color, background priority sprites, background, foreground priority sprites. Note that in this model the "background" layer has 3 colors + transparency.

This is kind of hard to explain without pictures.


That's achieved by changing the horizontal scroll on every scanline.

It looks glitchy in the video, but this is simply done by writing to $2005 to change the horizontal scroll on each line.


This is simply using sprite priority bit.


It does not (at least not necessarly) involve IRQs. Just heavy CHR-RAM or CHR-ROM abuse. Overlapping is only possible using sprites.

I think you can use tiles to do what looks like overlapping parallax. You'd basically have to animate the tiles so they look like they're moving at a slower rate than the normal scrolling, then have them animate while the character moves left/right.

https://youtu.be/9L3ymCQR5PM?t=359

https://youtu.be/4PAKsDKk-CE?t=43

https://youtu.be/PZhY7i3Dojs?t=74

Note that all platforms are rectangular - if you had slopes, you'd run into attribute clash with colors, unless you only had 2 colors in either background (or they shared a palette). You can see the attribute clash in the 3rd link on the sloped edges.

Doing it this way eats up RAM though because you have to basically have "horizontal size of BG" * "number of tiles" * "size of each tile" bytes, so if you are doing this with a patterned 8x8 bg it's 8x larger, and 16x for 16x16, etc.

Developers always find clever ways to make it seem like the system is doing something it can't actually do. On the NES, there are several ways to simulate multiple background frames. When there's no overlap, creating a parallax effect is just a matter of changing the horizontal scroll mid-screen, which results in sections of the screen scrolling at different speeds. IRQs are very helpful in timing these splits, but they're doable without IRQs to some extent.

In cases where there are overlaps, one common technique is to complete the frontmost layers with sprites, like in this part of Bucky O'Hare. There are 5 independent scrolling sections here (6 if you count the status bar!): 1 for the stars, 2 for the frog ships, then the background mountains, and the last one for the platforms. The frog ships appear to overlap because the rudders are made with sprites.

Another effect from Bucky O'Hare that I love is this. They make it look like there are 2 completely independent layers over a stationary background, something that's nowhere near possible on the NES! Here's the trick: everything is in the same background layer, but the far background is very repetitive, and by changing the pattern when the background scrolls you can make it seem stationary (e.g. by scrolling the background right 4 pixels and swapping the pattern for one that's rotated 4 pixels to the left you cancel out the movement), and the frontmost layer repeats horizontally, so you can make it seem like it's moving sideways by drawing and erasing only the edges, where the spikes are, and cover the seam using sprites, which in this case are spikes.

Another game with impressive overlapping parallax effects is Sword Master. The effect uses mid-screen scroll changes together with pattern changes. If the screen scrolls 2 pixels, this means that both the background and the foreground will scroll that much, but to make it look like the background scrolled less than that, the patterns are switched with a version that's rotated 1 pixel in the opposite direction.

Open these games in FCEUX or another emulator that lets you see the patterns in real-time and you'll understand these effects better.


These effects are possible because sprites have a priority bit, that places them either behind or in front of the background. When they're behind the background, the sprite will only show over parts of the background that use color 0, which is considered transparent.


Change the horizontal scroll every couple of scanlines and you can create wavy distortions.

I wonder how those tricks in Bucky O'Hare were done on a software level. I know how it was done on a hardware level but it still looks somewhat complicated. Does it have objects that represent moving scroll-seams, or have a table of moving scroll-seams? The 2 layer playfield, the dark room with the circle of light, and the scrolling snake, must all share some code right?

If I were to implement independently moving layers, I'd probably treat them like what they really are: movable block maps. Just like a game normally does collisions against the level map, which is normally stationary within level space, we can do collisions against moving overlaid maps if we take their positions within level space into consideration when looking up the blocks that are near the player.

The scrolling snake could simply be modifying the level map in real time. It could also be a second block map, or even objects with several bounding boxes. As for the dark room, I don't see how it's related to these other parts of the game... it seems like a normal map, that you can't see because it's dark.

I mean how does it organize the PPU writes? It's probably only changing the edges of the scrolling layer or snake or light circle.

Or is it updating the entire nametable, and that's why there's so much black on the bottom?

Thankfully, the dark room is in a demo, so it's easy to debug. The whole name table is black, with squares of level tiles scrolling from right to left. The vertical movement is entirely created by the overlapping sprites that draw the circle. The game probably only draws the left edge of the squares as they move, and erases the right edge. Attributes can still be updated normally, since the background color is black.


In the dark room for sure, probably in the other cases as well. I don't think these effects share any significant portions code though, except maybe for the code that copies the buffers to VRAM... The dark room is just a visual effect that gets its data from the level map, changes to the spike room depend on the shape of the spiky platforms, which are either a separate map or a solid object, and the snake is an object that's drawn differently depending on its direction and whether it's turning... The source of the tiles being drawn varies a lot from case to case, so I don't see anything that could justify any code being reused.