SpritesMind.Net

I am perusing through every technical document I can find for the Genesis presently. I thought that TmEE co. had told me a couple of years ago that the Genesis/MD VDP had specific scrolling capabilities within its own processing ability (read: not CPU intensive). In researching the Genesis VDP I have found Charles MacDonald's "Sega Genesis VDP documentation Version 1.5f (genvdp.txt)" most helpful.

In this document, under sections "Horizontal Scrolling" and "Priority" MacDonald makes some interesting points that appear to be native to the VDP itself. The "Horizontal Scrolling" section implies that the VDP handles locally whether either background A or B is scrolled full screen, split at the first 8 lines and then full screen, individual 8 line rows, or individual lines. If this is the case, it also implies that the 68000 is impacted by the effect of "parallax" very little or not at all.

Similarly, under "Priority", MacDonald states plainly:
"The VDP manages a fairly complex system of priorities between the two
background layers and sprites. The basic ordering is:


(back) (front)
A > B > C > D > E' > F' > G'

' = Denotes high priority
A = Backdrop color
B = Low priority plane B
C = Low priority plane A
D = Low priority sprites
E = High priority plane B
F = High priority plane A
G = High priority sprites"

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.

If I am reading MacDonald's document correctly, this means that the Genesis, in actuality, could produce a minimum of four independently scrolling *and* overlapping background planes, which were quite ingeniously seen only by VRAM as two and handled locally by the much maligned Genesis/MD VDP.

In the history of video games, this makes sense of the fact that more Genesis games use multi-scrolling backgrounds than SNES or TG16 games do. Despite their available CPU capabilities, or technical background layers, no system but the Genesis displays as many scrolling layers, by at least a factor of 2, as top Genesis software.

Premise: If the effect was hard coded and available, developers would have "naturally" been inclined to test it and enable it in production software. If the effect required hand coding and optimization, the effect would have played second or third fiddle to effects that were hard coded into the hardware.

So: TG16 and SNES games display fewer background scrolling layers, and more colors than comparable Genesis software. (Premise broken, SNES PPU's HDMA does the same thing as the VDP)

Example games with the effect:
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)

For Ristar L1 I count 10 eight line scrolls plus one line scroll
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

Bimini Run - one background is eight line scrolls to the horizon
Waves animate to appear like scaling
Only one layer represents the waves
The waves change palettes to indicate water depth near islands
Animated sprite transitions are as smooth as they come

Rings of Power: 9 cloud layers forced scrolled, 1 far forest, play ground
No testing on A/B layers yet.


To be analyzed:
Contra HardCorps
Castlevania Bloodlines
Formula 1 (Domark)
Kawasaki Superbike
Mickey Mania
Newman Haas IndyCar
Road Rash
Sonic 3D Blast
Street Racer (E)
Toy Story

You hardly could find more that three layers in SMD games, and third+ ones always constructed from sprites, reducing number of objects on screen.

Screensplit-like, or line scroll, is not layers. It is within one layer, and scrolled only by one axis. The same effect was used on systems with just one plane, like NES. It was heavily used on SMD just because it supported by hardware, reducing CPU load (you only have to fill scroll table instead of processing line interrupts).

Clever use of two layers together with sprites could create illusion of larger number of the layers. I recall it was done very nicely in Gunstar Heroes.

I would love to know which games you are referring to specifically, so I can test them. Certain games' background displays, like Gunstar Heroes, Ranger X or Red Zone, are a complete mystery to me. But games like Shinobi III, Sonic 2-3, Streets of Rage 1-2, Lightening Force and others seem to be using the above hardware capabilities rather than software (or sprite based) solutions that any system might have used.

I'm little lazy now (to take screenshots and write descriptions), so just take GensGS, or KMod, or any other emulator with VDP layers enable/disable feature, and check some games.

Shinobi III uses sprites on first level to overlay tree's trunks on the 'middle' plane above 'back' plane. Ranger-X and Gunstar Heroes often overlay the same two planes few times, it is difficult to describe, just check by yourself.

The hardware feature of line scrolling you can see in action in such games like Sonic or Rocket Knight Adventures - illusion of many layers, scrolling with different horizontal speed. They are actually just single plane, every line of the plane has it's own horizontal offset. The same feature used to sine-distorted backs, 'hot air' or 'fire' or 'underwater' effect.

I think I understand the effect, but on the MD/Genesis is it handled in the VDP, or by the 68000? If it is handled by the VDP it is a unique hard coded effect that developers would have been inclined to use. The documentation, and your first post, implies that the processing was handled by the VDP. In much the same way, the Playstation 1 gained an "advantage" in graphical effects by supporting goraud shading and transparency in the video processor. The effect in software is dramatic and uniform.

SNES had tile priority too. It wasn't somehow less capable than the MD.

If you are talking about background effects where in strips going left to right, different sections scroll at different rates, this is hardly something to brag about as even NES games did that. By that logic, Ninja Gaiden 3 in the second level has 4 of 5 background layers (which we know is false) just because the status bar doesn't scroll, and then there are various layers from the sky to the foreground which scroll at different speeds. Similar effects were used in Batman Return of the Joker.

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.

sheath wrote:I think I understand the effect, but on the MD/Genesis is it handled in the VDP, or by the 68000? If it is handled by the VDP it is a unique hard coded effect that developers would have been inclined to use. The documentation, and your first post, implies that the processing was handled by the VDP. In much the same way, the Playstation 1 gained an "advantage" in graphical effects by supporting goraud shading and transparency in the video processor. The effect in software is dramatic and uniform.

It is handled both by VDP and CPU, but unlike earlier systems, VDP has special feature to simplify implementation of the effect, so CPU only have to prepare list of offsets at any time, instead of tracking TV beam and modifying offset at needed lines. It is not so unique, though - Neo-Geo and other arcade hardware had it too.

Shiru,

Thanks again for your responses. Is there any measurable aspect to how the MD's VDP centric approach affects CPU usage, versus the "traditional" approach? It all sounds to me like a matter of how much time a programmer wanted to spend implementing the scrolling effects. The Genesis/MD approach made it relatively "easy," whereas the TG16 and SNES approaches (plural intended) made it relatively time intensive.

I should say that the purpose of my post has nothing to do with proving which approach was "better". I am looking for notable hard coded effects to explain the obvious differences in effects displayed in production level software.

There are few approaches for raster effects, line scrolling is among them (sorted by CPU time, from high to low):

- It is only possible to determine when the frame starts, so CPU has to wait for certain time (wasting time or executing very well timed code to keep sync).
- The VDP provides coordinate(s) of current TV beam position, so CPU have to poll them constantly and react then needed position is reached.
- VDP has some feature which triggers interrupt when needed TV beam position is reached (raster interrupts).
- VDP has ability to update settings according to list during displaying frame.

SMD's video hardware has ability to generate interrupt on frame start and line start (every N lines), which is useful to all sorts of the raster effects, and also list of scrolling offsets, which simplify line scrolling even further. If you only need to implement line scroll, you don't have to use line interrupts. However, if you want, say, modify Y offset of scroll (to scale picture vertically, for example), you have to use line interrupts, spending more CPU time.

I can't recall all the details how other system works for now. I remember that NES, for example, had no line interrupt, however it had two special flags which allow you to determine when some position is reached by TV beam (sprite 0 hit and sprite overflow). So on plain NES you only able to use first two methods for raster effects. There also were few mappers which had counter interrupts (can be used as line interrupt), allowing to use third method.

Line scrolling is just as simple to implement on SNES as it is on Mega Drive. This is easily done using a HDMA channel.

An example of line scrolling is seen in the ground of Ryu's stage in Street Fighter 2, which behaves similar to the water in Launch Base 2 in Sonic 3. Mode 7 screens such as the world maps in Secret of Mana and Final Fantasy VI also use a form of line scrolling, where the entire transformation matrix is altered on each line instead of just the horizontal offset.

The following video shows a SNES game featuring the illusion of many layers using parallax:
http://www.youtube.com/watch?v=TpH-fjpmlcQ

That Super Scope video only shows four to five independent layers. I have seen the same in UN Squadron, I think, and I have seen five in Valis IV (forced scrolling cloud layers). All of these are well within the SNES's standard background capabilities. Whereas scenes such as those created by the games I listed above were never done in SNES software.

8-10 independently scrolling background layers, with some showing individual line scrolling at the same time, was only done in Genesis software. I'm trying to figure out whether there was some hardware related reason why this is true. The VDP supporting the effect locally provides just such a reason.

sheath wrote: 8-10 independently scrolling background layers, with some showing individual line scrolling at the same time, was only done in Genesis software. I'm trying to figure out whether there was some hardware related reason why this is true. The VDP supporting the effect locally provides just such a reason.

Well, if you don't understand "why", then you don't understand the hardware still. You need to hit the books harder and/or start coding to figured it out. I'm not going to bother wasting my time again explaining anything though, just to have it ignored.

That aside, I think the linescroll method is more cpu resource involved using the scroll block method than it is on the SNES using HDMA (which is still a "block" method, just more flexible about which line is the next, instead of forcing you to do +1 or +8 steps of a table). On the Genesis/MD, you have to update every fricking fine scroll entry on both planes. You're forced to if you want linescroll on the Gen/MD or use the finest vertical resolution, regardless if you want to scroll on every line or not. If you're going to have only a small section of the screen as "linescrolls" or such on the Gen/MD, H interrupts seems a better option (even with the +44-50 cycle per line overhead). Opinions? Any game examples that change the "scroll" mode mid screen for it start parsing the scroll table differently mid screen on the MD/Gens?

Tom, are you actually trolling me? If you don't want to contribute to the topic, start your own please.

There is one like you in every technical forum. You can't handle being wrong about anything, so you dodge the topic every time you are proven wrong (eg. scrolling is aesthetically unpleasing). Then you argue incredible circles around your own logic, and proof text everything I say. To take a line from your own tone, I'll assume you know nothing about the term proof texting. That is when you look at an argument, or publication, with the only purpose of proving it is wrong. People who are after dishonest gain, and people who's egos have overwhelmed them, do this. Proof texting is *not* a practice of a knowledgeable person who simply wants to contribute to a forum.

On top of all of that, you think you are the only person in the whole world who isn't biased. Yet you jump on every positive statement about the MD/Gens hardware in a *Sega* centered forum. So yeah, congratulations, you have more assembly knowledge than I do. That is no excuse for your rudeness.

sheath wrote:Tom, are you actually trolling me? If you don't want to contribute to the topic, start your own please.

Troll, sir? No, sir. What I stated and asked was very relative to what the topic at hand is discussing. I took hours of my time to explain near the very beginning of that "other" thread. I wasn't going to repeat that same mistake. But what I stated *and* what I asked, is directly related to what you're talking about, and might/would help provide some information for you or more along/keeping the thread going by other replies (if you can follow it. I don't know how far along you are in understanding the video systems yet, but more info the better). But if you don't want me to post in your threads, then I'll kindly delete my posts.

You can't handle being wrong about anything, so you dodge the topic every time you are proven wrong (eg. scrolling is aesthetically unpleasing).

The only thing you proved is that you found it impressive. I tried to prove to you through example and specs that it's not an advantage the Genesis has over the SNES. And further more, if I say anything negative perceived about the Genesis, it's your misinterpretation of my attempt at correcting miss information. Nothing pisses me off more than the spread of false information, regardless of the system. Anyway, I totally respect the fact that you're taking the initiative in trying to figure this out on lower/technical level. It's not easy and it's frustrating in the beginning. I just wish more people would do this, though.

So yeah, congratulations, you have more assembly knowledge than I do. That is no excuse for your rudeness.

So "hit the books harder and/or start coding to figure it out" is rude now? Every single one of us here that codes for these consoles has done just that. Putting our blood, sweat, and tears into learning these systems at such a low level. Nothing was simply given to us and such. And for the record, it's a hella of lot more than just assembly. Learning the CPU in and out is one thing, learning the rest of the hardware is something else.

You're trying to figure things out and reading docs. That's a good thing. Some of these question were already covered early on in your "other" thread though. Anyway, you actually going through the docs and trying to understand/make sense of them - I applaud you for that. No disrespect there.

tomaitheous wrote:Troll, sir? No, sir.

:DDD

Aaah, Tom ! Wherefore art thou tomaitheous !

:DDD