Understanding the VDP's scrolling capabilities.

[Ketsuban]

I notice that Sheath likes to use the term "independently scrolling background" or "independent layer", but I'm not sure he knows what it means.

The Megadrive has two independently scrolling background layers, called Scroll A and Scroll B. The scrolling effect in e.g. the Sonic games is not additional independent layers - it's altering the scroll values for some scanlines on Scroll B to produce the visual effect of extra layers.

[sheath]

I am using the term independently scrolling to bridge the gap between people outside of these forums that would need "parallax" or "line scrolling" explained to them every time.

I selected the term because on the screen, in the games I am talking about, these background segments, or "scrolls", move independently of each other in relation to player movement (i.e. it's not forced scrolling, the player makes the background move backward and forward). I might also call the layers dynamically scrolling backgrounds, if "independent" messes with the programming impression too much.

Tom, to your technical point, I am not sure what method or methods you are comparing in relation to what Shiru introduced. I'm also not sure how your discussion of how resource intensive it is on each system affects whether or not the VDP supports it natively as a hard coded effect. As I understand the HDMA channel on the SNES, and believe me I will read everything on it soon, we're talking more about a high bandwidth connection more than a piece of the hardware with hard coded effects.

The difference I am trying find evidence of would be the same as if the SNES had no Mode 7, but still had the hardware prowess to do it in software. If developers have to spend time hand coding something the effect is never going to be achieved with uniform results in other software. Thus, Mode 7 "style" graphics appears on other systems but looks totally different in action.

Likewise, Genesis scrolling effects like those in Sonic 2's Aquatic Ruins, show more dynamic layers and more interactivity with player motion than games on other systems. It makes sense to find the capability hard coded in the VDP that this effect would be relatively unique to the Genesis and other systems built like it. It would be very enlightening to see the same number of layers and interactivity in a SNES game, first, and then to know how resources are offloaded to various processors in each game, second.

[Eke]

I am using the term independently scrolling to bridge the gap between people outside of these forums that would need "parallax" or "line scrolling" explained to them every time.

I selected the term because on the screen, in the games I am talking about, these background segments, or "scrolls", move independently of each other in relation to player movement (i.e. it's not forced scrolling, the player makes the background move backward and forward). I might also call the layers dynamically scrolling backgrounds, if "independent" messes with the programming impression too much.

still, the Mega Drive VDP only has two scrollable layers (that can be defined to various sizes) + one sprite layer where you can position a limited amount of sprites (again, of various sizes). Playing with priority bits you can select which layer should be displayed for each pattern (8x8 pixels character) of the visible screen but that's all. Sure you could make each of the 224 lines scroll separetely but still it doesn't make 224 independant layers

as I understand the HDMA channel on the SNES, and believe me I will read everything on it soon,

I'd suggest you do that first before comparing advantages of both systems and making assumptions about which one is better at handling such or such feature, it's kind useless otherwise, you can't make any serious theory by just "looking" at emulated games.

That's said, I'm pretty sure the SNES had ways to do similar things with hardware without relying too much on CPU (remember the SNES main cpu is much slower than the genesis one !), people who designed those consoles were not totally stupid at that time and were perfectly aware of what their competitors were proposing

[sheath]

I honestly don't know why the discussion comes back to qualifiers like "better." Obviously more RAM of every kind would have allowed for more technical backgrounds and that would have been "better." I don't need to compare methods to say whether the VDP supports something natively. My premise is simple, if the VDP is handling the scrolling and dictating the 8 pixels per scroll standard, that's why more Genesis games use it. Whether or not the effect is "impressive" or "better" than any other effect is entirely subjective.

I just finished checking out some games using Gens KMod, among them the only game that uses sprites in the layers was Shinobi III. I'll use the term "scrolls" to be less confusing.

Sonic 2, Aquatic Ruin, 10 scrolls plus palette swap line for water.
Layer A is the player ground and palette swap line.
Layer B is the foreground foliage (can see layer A through leaves)
Layer B is also split into 9 scrolls behind Layer A
Over half of the layers scroll at independent speeds smoothly
Some of the scrolls in the foliage behind layer A scroll every other frame.

Ranger X, First Level, 7 scrolls
Layer A is the player ground
Layer A is is the mid range background including:
1 Hillside scroll behind brick wall
2 Ruins Wall at base of mountain range (every 2-3 frames)
3 Mountain Range with city being bombed (every 2-3 frames)
Layer B is large bricks in front of player ground
Layer B is brick wall behind player ground
Layer B is far background with mountain range and sunset

Lightening Force L1 4-6 scrolls on screen including line scroll water as 1
Layer A is multiple cloud scrolls in front and behind Layer B clouds
Layer A is Rocks in foreground at bottom of playfield
Layer A is clouds scroll in front of Layer B mountain range at center
Layer A is clouds scroll behind Layer B mountain range at center
Layer B is multiple cloud scrolls overlapped with Layer A clouds at top
Layer B is mountain range at center
Layer B is line scroll water at bottom behind Layer A rocks

Shinobi III L1 5 Scrolls sprites connect trunks in 4th with tree tops
Layer A is player ground which doubles for foreground tree cover at top
Layer B is 4 scrolls:
Grass behind player ground
Grass with dirt patches behind scroll 1
Grass with tree trunks behind scroll 2 and tree cover at top of screen
Far background forest

Redzone
Redzone mixes sprites with Layer A & B to complete the rotating ground effect, the FMV in the intro, and the "high color" title screen. It seems like no image is complete without all layers on.

Batman & Robin L1 just two layers with line scrolling in both
Layer B is linescrolled building and player ground
Layer A is line scrolled smoke/fog and overlayed "shadow/Hilight"
Shadow/Hilight effect darkens entire layer B

MUSHA Intro 6-7 scrolls on screen at once
Layer A is characters and objects
Layer B is 5 mountain range scrolls
Layer B is far background (doubles as reflection on glasses)

[eteream]

This implies a minimum of four planes that might be placed above one another by a skilled game designer. This would be significant, as the Genesis is known to have produced more than eight independently scrolling backgrounds, called "fake" parallax by those who do not consider the effect significant.

As I know you only have plane A & B. No more. On MD you can scroll each X axis line & each Y axis 8 lines, so... you can have up to 240*320/8*2 scrolls... in theory, of course.

As Ketsuban says, we have to differentiate between two types of scrolls, ones which involve different planes and others involving the same plane. The difference is that within the same plane can only scroll in one coordinate (well... in an ordinary game) and can not use transparency. I think we would have to find a name for each.

You can try Ristar (11 scrolls on 1st level).

I do agree that the way MD can do scrolling effects probably tempted developers to use it more than if they had to use interrupts. However SNES had HDMA, and developers did use it for various effects too.

Your final point, TG16 had a disadvantage in Background layers, but SNES and MD were pretty much on the same footing. SNES games commonly used graphics modes that provided 2 layers of 4bpp depth, and sometimes 2 layers of 4bpp plus a third with 2bpp. It had modes with various different behaviors like Per Tile priority.

So Genesis doesn't have some magic ability to display more layers. But it does have fewer color sets available. The line scroll table is comparable to HDMA in practice. Both systems have advantages and disadvantages.

With SNES you have up to 16 DMA's chanenles avaliable, so in practice you cann't do what genesis does. You need to spend all the displaying time (in contrast with vertical retrace time) updating scroll values if you want more than 16 scroll. In the other side, it wastes more memory on MD.

The difference I am trying find evidence of would be the same as if the SNES had no Mode 7, but still had the hardware prowess to do it in software. If developers have to spend time hand coding something the effect is never going to be achieved with uniform results in other software. Thus, Mode 7 "style" graphics appears on other systems but looks totally different in action.

Mode 7 is rotation & scaling (nothing more!) for a full plane, Out Run for example is line-scroll, nothing in common.
Simply, you don't have enough cpu to do it for the full screen. See 3D games for SNES or MD, their frame-rate is atrocious.

Anyway, I think nobody understands how mode 7 works. It have nothing to do with showing "maps" like Secret of Mana.

That's said, I'm pretty sure the SNES had ways to do similar things with hardware without relying too much on CPU (remember the SNES main cpu is much slower than the genesis one !), people who designed those consoles were not totally stupid at that time and were perfectly aware of what their competitors were proposing

SNES cpu slower than MD? No! It's worse design, but not slower (not by far). See cycles per instruction of both cpu's (MIPS too, but there is a trick here!).

[sheath]

As I know you only have plane A & B. No more. On MD you can scroll each X axis line & each Y axis 8 lines, so... you can have up to 240*320/8*2 scrolls... in theory, of course.

As Ketsuban says, we have to differentiate between two types of scrolls, ones which involve different planes and others involving the same plane. The difference is that within the same plane can only scroll in one coordinate (well... in an ordinary game) and can not use transparency. I think we would have to find a name for each.

You can try Ristar (11 scrolls on 1st level).

I'm all for separate terms for actual layers versus scrolls. I'm not sure everybody here realizes that there is no difference to the non-technical consumer. I just read through a dozen late 80s- early 90s magazine articles that referred to the Genesis' background capabilities as a "3D effect." That's how people see it, depth of field, and it doesn't matter to them at all how many layers are actually in VRAM independently.

For Ristar L1 I count 10 scrolls
Layer A is player ground
Layer B is the following scrolls:
Green leaves behind player ground
Purple foliage behind green leaves scroll
Pastel treeline with linescrolling water
Pink mountain range
Far background mountain range
Clouds bottom layer top
Cloud middle layer top
Clouds top layer top

Mode 7 is rotation & scaling (nothing more!) for a full plane, Out Run for example is line-scroll, nothing in common.
Simply, you don't have enough cpu to do it for the full screen. See 3D games for SNES or MD, their frame-rate is atrocious.

Anyway, I think nobody understands how mode 7 works. It have nothing to do with showing "maps" like Secret of Mana.

Mode 7 is limited to a far static background (usually a single color) and a scaling and/or rotated up-to 256 color background. As far as I have seen the SNES never scales sprites, it's always a switch to Mode 7 (see Contra IV bomber, Mario World Bowser fight).

Compared to Genesis pseudo 3D effects, well, in most cases they are entirely different. When the Genesis uses line scrolling to approach Mode 7 like graphics, (see Power Drive (UK), Toy Story's cart scenes (scaling sprites simultaneously), and Sonic 3D Blast's bonus scenes) they never turn the ground layer all the way around, which is useful for hairpin turns and free flight. The graphics style used in Outrun and Super Monaco GP, though, does seem to be capable of hairpins and connecting tracks.

For psuedo-'Mode 7 like' 3D the Genesis line scrolling effect seems to only be used for scenes that endlessly continue into the screen, whereas Mode 7 can use tracks that return to the starting point like, well, every Mode 7 racing game does.

The bottom line is both systems had technical and "arcade" racers that are considered equally well made. For whatever reason, the SNES didn't handle engines like the F1/Kawasaki games used, or the Hard/Race Drivin' games used nearly as well as the Genesis did. I also can't find any SNES game that creates a similar effect to the Road Rash series. Similarly, the Genesis never saw a game that looked *and* played like Mode 7 racers did.

[Gigasoft]

With SNES you have up to 16 DMA's chanenles avaliable, so in practice you cann't do what genesis does. You need to spend all the displaying time (in contrast with vertical retrace time) updating scroll values if you want more than 16 scroll. In the other side, it wastes more memory on MD.

Wrong. A line scroll table requires exactly 1 HDMA channel.

For example, a horizontal scroll table for BG1 would be defined with HDMA mode $4A, destination $0d and the following table:
.db $80
.dw ScrollTable
.db $F0
.dw ScrollTable+$100
.db $00

If you want to have a combined horizontal and vertical scroll table (such as, for the water seen in Launch Base 2), you could use HDMA mode $4B, destination $0d and this table:
.db $80
.dw ScrollTable
.db $F0
.dw ScrollTable+$200
.db $00

Notice how easy this was. In contrast, to implement the second example on the Mega Drive, Sonic 3 has to use a HBL routine that actively updates VSRAM throughout the entire part of the screen that contains the water surface, reducing the amount of processor time available for other processing.

Mode 7 is rotation & scaling (nothing more!) for a full plane, Out Run for example is line-scroll, nothing in common.
Simply, you don't have enough cpu to do it for the full screen. See 3D games for SNES or MD, their frame-rate is atrocious.

Anyway, I think nobody understands how mode 7 works. It have nothing to do with showing "maps" like Secret of Mana.

The map screen in Secret of Mana uses a combination of mode 7 and HDMA. Here, not only horizontal offsets, but the entire Mode 7 matrix is updated for every line. It would be trivial to implement this for the entire screen, but for aesthetic reasons they chose to display a sky at the top of the screen instead.

SNES cpu slower than MD? No! It's worse design, but not slower (by far). See cycles per instruction of both cpu's (MIPS too, but there is a trick here!).

Don't forget that SNES requires more instructions to accomplish the same task, because of fewer registers.

[Huge]

Anyway, I think nobody understands how mode 7 works.

I understand that mode 7 was an overrated visual gimmick.

[MottZilla]

Sheath, I took a look at a few of the examples you gave. Lightening Force, Batman, and MUSHA. I'm not convinced that the SNES is incapable of the different layer scrolling effects in some of these games. HDMA is very effective and as I recall was even in the GBA. You could probably pull off these scrolling effects on SNES with HDMA. They are nice effects though.

I would say before trying to crown the MD the winner in any comparison that you should seriously investigate from reputable sources about the SNES. If you know alot of the MD but relatively little about the SNES it is unfair to compare.

About Mode 7 and sprite scaling stuff, the SNES cannot in realtime scale sprites. The CPU could scale sprites before hand in RAM in an effort to save ROM space. Mode 7 is the only real time scaling method for SNES without a coprocessor. And ofcourse if you prescale the sprites you can do what looks like realtime scaling. The Genesis things you mentioned with what you call or seem to call realtime scaling may not be realtime at all. It may be prescaled. That would be the most efficient thing to do atleast, if you have the ROM or RAM to store it in.

MD and SNES are clearly different systems with different designs so developers did things differently. Not really surprising and it seems like that should be reason enough for why things are different.

[sheath]

Mottzilla, I am sorry that the discussion always comes back to this "better" "best" "worst" comparison. The fact is no SNES game does this many "scrolls." Additionally, the Genesis does what the SNES does not in this case *apparently* because the VDP handles it locally (with a handful of simple register entries?).

This makes sense, developers tend to stick to what the hardware was designed for. Whether or not the SNES was "capable" theoretically, I cannot find one game that does it, much less as many as I have already listed. The same thing happened every generation when one system hard coded an effect and another did not. The same thing happened with the Mode 7 "effect."

On a side note about sprite scaling. I have never seen a game with pre-rendered sprite scaling that reacts to the scroll speed of the game. I have only seen pre-rendered scaling play like an animation at the same speed every time. Whereas the Toy Story cart sprites, Road Rash Sprites, and F1/Kawasaki sprites all scale appropriately to the speed of the screen. Some even lose frames if the screen is scrolling too fast. I would assume this means it is true software scaling, but as usual facts prevail over opinion.

[MottZilla]

Well, in hardware with HDMA the SNES can scroll every single line displayed to its own coordinates if you so choose to do so. I'm certain games have used this for special effects, possibly Chrono Trigger for battle spells or something like that. Final Fantasy 6 might do such a thing as well. It seems to me that Genesis has a large scroll table for these effects where as the SNES with HDMA could have an adjustable length table which saves time when making adjustments to the values in the table. But I suppose you'd have to compare the total cpu time lost updating the table on MD versus the total cpu time lost on SNES and maybe then the impact on the Genesis isn't so bad. I'm not sure.

Certainly what the hardware design has is going to influence your work. I would say that the scroll table the MD has is probably more tempting to utilize than to abuse HDMA. I would also say that the MD with the faster CPU, has more time to update a huge table of scroll values. But with SNES's HDMA you don't have to do every single line, which can save time.

On sprite scaling, I'm not sure about existing games but just with my own opinion as a programmer it would seem to me that scaling the sprite in multiple sizes before action would be preferable to in real time if you have the memory to spare. It would free up more time for other tasks. Just my opinion on how I would want to do it.

[tomaitheous]

I would also say that the MD with the faster CPU, has more time to update a huge table of scroll values. But with SNES's HDMA you don't have to do every single line, which can save time.

Yup. And on the MD, if you enable row or line scroll table mode, you have to set *every* entry for *both* planes - regardless if you need it or not for plane X. I'm not really a fan of this. The HMDA line counter is nice in that it's flexible and not limited to either strictly 8pixels or 1 pixel tall and doesn't force you do update both planes. That, and you have 8 channels for HMDA to update up to 8 different regs of the sPPU on that line. Pretty powerful setup indeed.

Mottzilla, I am sorry that the discussion always comes back to this "better" "best" "worst" comparison.

But isn't that part of the presumption? If system X can do it better, then in theory it should do it more often - no? So, you can't really get away from the better/best part of the comparison, unfortunately.

I'm not sure everybody here realizes that there is no difference to the non-technical consumer.

Yeah, have seen the same thing on forums. There are pretty generic terms out there in the forums/gamer community. When I was a younger gamer, if we saw hsync scrolls on a single layer divide into separate speeds, but without overlapping parts and clearly edge to edge transitions - we called them "paper scrolls". Because it looked like someone took a picture and cut it into different strips and slid them across the screen - without regard transitional areas. Some games get away with it by having the common/solid color as the transition line (makes it look a little more natural).

But the type of "scroll" you're referring to has overlapping parts, correct? I.e. not the water line scrolls of Sonic stage 1, or the ocean floor of Ocean side view from TF4, but the overlapping parts like in TF4 same level with the clouds and mountains - right?

DD

Aaah, Tom ! Wherefore art thou tomaitheous !

DD

Haha. +2 rep points to you for getting the reference

And no one's answered my question about the scroll table reg. If it's locked during active display or not. If not, that makes the MD scroll tables less.. irritable. Guess I'll just test it myself.

[sheath]

Mottzilla, I am sorry that the discussion always comes back to this "better" "best" "worst" comparison.

But isn't that part of the presumption? If system X can do it better, then in theory it should do it more often - no? So, you can't really get away from the better/best part of the comparison, unfortunately.

I think that's part of the assumption by the media, system fans, etc, yes. If one system does an effect more, it must have been better at it. I personally work a different way. If one system does one effect more, there must have been a technical reason. In this case, or the case of Mode 7 on SNES, or transparency and gouraud shading on PS1, I think the reason is because of hard coded effects.

Now, if we can manage to find out how much CPU time, RAM, VRAM and GPU time is being used up for any given effect, for any given game, on any given console, then we can talk about which system is "better". I prefer instead to look at the production software and try to keep my observations as close to them as possible.

But the type of "scroll" you're referring to has overlapping parts, correct? I.e. not the water line scrolls of Sonic stage 1, or the ocean floor of Ocean side view from TF4, but the overlapping parts like in TF4 same level with the clouds and mountains - right?

I'd rather not be the one to define these terms (scrolls versus backgrounds). For this discussion I am considering a line scrolling section a single "scroll", and 8+ line sections single scrolls based on whether they scroll independently.

[Chilly Willy]

And on the MD, if you enable row or line scroll table mode, you have to set *every* entry for *both* planes - regardless if you need it or not for plane X.

Err - you just have to set it ONCE. If it doesn't change, then you don't need to change it. You're acting like you have to set EVERY entry EVERY SINGLE FRAME... which you don't. That's the point of having a TABLE accessed by the VDP - you set it once and the VDP fetches the values. Then you only change just those entries that need to change. If one plane doesn't change, you write its entries ONCE and forget about it. If half the plane you ARE scrolling doesn't change, you set it once and forget about it. See how easy that is?

[Gigasoft]

In most games, the screen scrolls more often than not, and both planes are scrolled. So even if you only have parallax in the background and not in the foreground (which is common), all the foreground entries must still be set on every frame where the screen scrolls, which happens most of the time. This is not so on the SNES.