overlapping parallax
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
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?
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?
- TmEE
- Posts: 960
- Joined: Wed Feb 13, 2008 9:10 am
- Location: Norway (50 and 60Hz compatible :P)
- Contact:
Re: overlapping parallax
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.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: overlapping parallax
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?
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: overlapping parallax
I've looked at YT videos... but what exactly do you mean?psycopathicteen wrote:the Panorama Cotton effect
This?psycopathicteen wrote:the Donkey Kong Country 2 parallax effect
?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
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Re: overlapping parallax
The rtype effect is only a vscroll effect ??
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: overlapping parallax
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
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Re: overlapping parallax
Ok,I thought it was a little bit complex to be done with only vscroll .
Re: overlapping parallax
There's clearly some shading going on too.TOUKO wrote:The rtype effect is only a vscroll effect ??
Re: overlapping parallax
You're right, it's so discreet, i didn't notice.
Re: overlapping parallax
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?
Re: overlapping parallax
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.
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
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: overlapping parallax
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.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).
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.Gilbert wrote:I think it's just done like the colony stages in Metamor Jupiter of the PCE.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: overlapping parallax
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.
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.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.
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: overlapping parallax
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.psycopathicteen wrote:I see DMA overload at 9:20. I don't see that happen in too many games.
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.
Re: overlapping parallax
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 .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?
i agree .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 remember the lava boss in axelay, there is many sprites dropout in this part,even if the part herself is beautiful .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)
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 .