overlapping parallax

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

overlapping parallax

Post by psycopathicteen »

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?
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: overlapping parallax

Post by TmEE »

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.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: overlapping parallax

Post by psycopathicteen »

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?
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: overlapping parallax

Post by creaothceann »

psycopathicteen wrote:the Panorama Cotton effect
I've looked at YT videos... but what exactly do you mean?
psycopathicteen wrote:the Donkey Kong Country 2 parallax effect
This?
psycopathicteen wrote:vertically block parts of the BG layer, with another part of the same BG layer
?
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.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: overlapping parallax

Post by TOUKO »

The rtype effect is only a vscroll effect ??
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: overlapping parallax

Post by creaothceann »

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.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: overlapping parallax

Post by TOUKO »

Ok,I thought it was a little bit complex to be done with only vscroll .
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: overlapping parallax

Post by tokumaru »

TOUKO wrote:The rtype effect is only a vscroll effect ??
There's clearly some shading going on too.
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: overlapping parallax

Post by TOUKO »

You're right, it's so discreet, i didn't notice.
User avatar
Gilbert
Posts: 564
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: overlapping parallax

Post by Gilbert »

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?
User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: overlapping parallax

Post by HihiDanni »

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.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: overlapping parallax

Post by Drew Sebastino »

HihiDanni wrote:The shading effect in R-Type III most likely used the color window + HDMA to adjust the fixed color (used by the color window).
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:

Image
Gilbert wrote:I think it's just done like the colony stages in Metamor Jupiter of the PCE.
That's honestly ugly af. :|
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: overlapping parallax

Post by psycopathicteen »

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.
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.
...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.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: overlapping parallax

Post by Drew Sebastino »

psycopathicteen wrote:I see DMA overload at 9:20. I don't see that happen in too many games.
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. :|
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: overlapping parallax

Post by TOUKO »

Gilbert wrote: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?
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 .
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.
i agree .
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)
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 .
Post Reply