overlapping parallax

I've been thinking about trying to make the Panorama Cotton effect, but in order to pull that off, I need to figure out the Donkey Kong Country 2 parallax effect, but in order to pull that off, I would need to know how to vertically block parts of the BG layer, with another part of the same BG layer.

Is this typically done with a byte for every scanline, and fill the layers over each other, or is there a faster way to do this that isn't too complicated?

All comes down to changing vertical scroll value every line to a new position on the tilemap according to what is the current line being drawn. All sorts of displacement, masking, windowing and scaling effects are done that way.

I was just wondering what sort of algorithms were used to decide which scan lines get blocked off by what. Do they just write over the "HDMA table" when drawing something in front, or is there a way to figure out what layers are partially cutoff before hand before making the scroll table?

I've looked at YT videos... but what exactly do you mean?


This?


?
Depending on the system, you just write a different horizontal scrolling value for the BG in each line via HDMA / interrupts / timed code.
For this effect you change the vertical scrolling value.

It might help to look at the VRAM (e.g. in BizHawk) while playing the game.

The rtype effect is only a vscroll effect ??

Yeah I think so, at least as far as the hardware is concerned. Of course you have to find the right values for each line, too.

Ok,I thought it was a little bit complex to be done with only vscroll .

There's clearly some shading going on too.

You're right, it's so discreet, i didn't notice.

I think it's just done like the colony stages in Metamor Jupiter of the PCE. The shading part could be just palette change (I remember in Metamor Jupiter only colour 0 was changed, but probably the whole subpalette was updated for each "face" in that SFC R-Type game) or maybe transparency effects?

The shading effect in R-Type III most likely used the color window + HDMA to adjust the fixed color (used by the color window). That's the power of color math: you can change a whole bunch of colors at once without having to strain the CPU in doing so (or spread palette uploads over multiple scanline interrupts for a single change across multiple colors).

If you look at a lot of 16-bit era games you'll find that per-scanline adjustments form the backbone of a lot of different effects. It's probably one of my favorite aesthetics.

As far as deciding what values to use, you'll probably want to compute the ranges to use before you do anything else, to avoid unnecessary processing.

Playing the stage in BSNES debugger, I can verify that it's doing this. It's actually using Mode 7 so it doesn't need to calculate what lines to drop. It's unfortunate that it isn't also shrinking the pillar F-Zero style since they were dealing with Mode 7, as the 3D effect would then be more convincing, but this would mitigate the saved CPU time by using Mode 7 for this in the first place. The bigger question to me, is how the game is calculating the collision for this: https://www.youtube.com/watch?v=djW3WTE ... 285#t=3m5s I mean, granted, it slows down through almost the whole segment.

R-Type III has a lot of cool visual gags. The stage 1 intro is probably the most cinematic thing in an SNES game:




That's honestly ugly af.

To do collision, they would have to convert the orientation with X=ax+by+c and Y=dx+ey+f. I need to think about how to calculate a, b, c, d, e and f.

I see DMA overload at 9:20. I don't see that happen in too many games.



...and that is the tricky part. I think I need to get something done right now so I'll try a quick "copy coordinates 224 times in a row and see how much speed it takes up.

I don't think I've actually ever seen that happen in an SNES game before, including this one. Using the hyper wave beam over the standard charge shot (the only two ways you're able to kill it with the original R-Type force pod) in that scenario is kind of stupid though, (what is likely generating the DMA overload) as you have to make sure you don't shoot the eyeballs and it still takes longer to kill it anyway.

About hardware pushing, I think this game probably has the worst sprite-per-line dropout in an SNES game and possibly any "16bit" game (different video, same game) https://www.youtube.com/watch?v=ExfYd_1D5Ww#t=19m25s

That's the area that the SNES and Genesis really get murdered relative to arcade machines from the time.

Yes in metamor the technique used and palette swap was obvious,but the rtype wrapping effect is more impressive and mainly less common for me .


i agree .


I remember the lava boss in axelay, there is many sprites dropout in this part,even if the part herself is beautiful .
We can thanks the two size limit in the same frame, is really a pain to maximise sprites on screen with that,it's more obvious when you know the snes has the best sprite pixels/scanline limit in H32 .

Theoretically it doesn't have to calculate anything at runtime, just store the boundaries in ROM for each degree of rotation.


It'd probably be in the TV's overscan area anyway.

I doubt that's what it's doing though. It does this in three different areas, and they all last a good while.


It's not, well, on my TV anyway. However, my TV is a flatscreen CRT from the 2000's, so I don't know how representative it would be of TVs from the time.

I thought about how to do the background blocking.

Use 2 tables that are 224 bytes long, with each byte corresponding to a scanline:
-layer number
-next chunk

Jump through the tables for a chunk that overlap with the beginning of the new layer, and another that overlap the end of the new layer. The chunk that overlaps the end, copy the "layer number" and "next chunk" bytes to the end of the new layer's chunk. Then change the "next chunk" byte on the chunk that overlaps the beginning (this is done afterwards in case the same chunk overlaps both of the new layer's ends). Now add the new layer's "layer number" and "next chunk" bytes to the tables.