I'm curious how we know this is the case. All of the register entries, in both Genesis Technical Documentation 1.0 and MacDonald's genvdp.txt, make no mention of per frame updating. Genesis Tech Doc makes it sound like you just set the speed of each scroll once, but neither fully explain the process (pg 48).
Macdonald describes it like this under the Horizontal Scrolling section:
"Here is some "C" pseudocode to illustrate how the VDP reads the scroll
table depnding on the settings of bits 0 and 1 of register #11:
void get_scroll(int line, int *scroll_a, int *scroll_b)
{
switch(vdp_reg[11] & 3)
{
case 0x00: /* Full screen */
*scroll_a = *(word *)vram[hscb + 0];
*scroll_b = *(word *)vram[hscb + 2];
break;
case 0x01: /* First eight lines */
*scroll_a = *(word *)vram[hscb + ((line & 7) * 2) + 0];
*scroll_b = *(word *)vram[hscb + ((line & 7) * 2) + 2];
break;
case 0x02: /* Every row */
*scroll_a = *(word *)vram[hscb + ((line & ~7) * 2) + 0];
*scroll_b = *(word *)vram[hscb + ((line & ~7) * 2) + 2];
break;
case 0x03: /* Every line */
*scroll_a = *(word *)vram[hscb + (line * 2) + 0];
*scroll_b = *(word *)vram[hscb + (line * 2) + 2];
break;
}
}"
Understanding the VDP's scrolling capabilities.
Moderators: BigEvilCorporation, Mask of Destiny
That mention of "every row" which sounds to me like every 8x8 pixel unit, makes the use of the effect seem much less intense than every line. If this is the case, then I don't see using the effect nearly as costly on CPU time. But when you do every line, it seems you'll spend a considerable amount of time updating scroll values for whatever parts that are in motion to keep the illusion of one part moving across the screen faster than another. But clearly some games do this.
Still the SNES is capable of the same thing with HDMA. Though you can still make the point that SNES has less overall CPU time.
Still the SNES is capable of the same thing with HDMA. Though you can still make the point that SNES has less overall CPU time.
I still can't find the requirement for updating anything every frame based on whether scrolling lines or cells was enabled. If it's there it's not documented very well. Also, it sounds like the Genesis' ability to line/cell scroll through the VDP is tied to a one word per line offset for each layer's a and B. Can somebody describe what is required to update each offset on a per frame basis?
(http://db.gamefaqs.com/console/genesis/ ... amming.txt Horizontal Scrolls)
(http://db.gamefaqs.com/console/genesis/ ... amming.txt Horizontal Scrolls)
HDMA aside, it seems like SNES developers chose to design their games around the SNES' "Mode" system for backgrounds. Based on the games, I'd say they typically stuck to Modes 1-4 if they weren't using Mode 7. At least, I can't think of any reason why they would want an overabundance of 4-color backgrounds.
At any rate, the Genesis' Cell scroll method being advertised by the VDP's registers is a really obvious reason why we see more scrolling in Genesis games. The SNES not having a "Mode" for that many scrolls is probably why developers didn't hand code it (and subsequently why fans of the hardware have no appreciation for 8-10 scrolls).
Just to be clear, whether or not both systems were roughly equal is not the point of my inquiry. The hardware dictated the effects developers preferred. While I'm scrounging through old magazines I need to remember to find that developer interview that complained about Nintendo not allowing (or discouraging) custom effects in SNES software. If I recall that statement correctly, there was an additional pressure from Nintendo, or at least the SNES design and development support, to stick to the Modes available, emphasizing Mode 7 as much as possible.
At any rate, the Genesis' Cell scroll method being advertised by the VDP's registers is a really obvious reason why we see more scrolling in Genesis games. The SNES not having a "Mode" for that many scrolls is probably why developers didn't hand code it (and subsequently why fans of the hardware have no appreciation for 8-10 scrolls).
Just to be clear, whether or not both systems were roughly equal is not the point of my inquiry. The hardware dictated the effects developers preferred. While I'm scrounging through old magazines I need to remember to find that developer interview that complained about Nintendo not allowing (or discouraging) custom effects in SNES software. If I recall that statement correctly, there was an additional pressure from Nintendo, or at least the SNES design and development support, to stick to the Modes available, emphasizing Mode 7 as much as possible.
What do you mean stick to modes available? And what do you mean "Mode" system for backgrounds? I don't think you understand what the "Mode" means.
The SNES PPU has drastically different behavior depending on which graphics mode is used. Mode 0 has 4 background layers that are all using 2bpp tiles. Mode 7 has only 1 background layer which has transformations of scaling and rotation. I do believe there was a way to have Mode 7 plus a window type layer but I can't recall. Ofcourse with HDMA or IRQ you can change mode mid-frame.
The SNES doesn't have a mode for horizonal line offsets, but it does have many other interesting features. Like one mode where every tile can have its own scroll offset. I remember hearing Chrono Trigger used it for certain effects. But anyway to do horizontal scrolls like in certain Genesis games all you need is a HDMA table. So the hardware for that is there.
The only reason I can think of for why SNES developers may have decided not to do similar effects to the games you mentioned may have been cpu time. Maybe they didn't think those type of effects were worth the lost CPU time. They certainly would take up atleast alittle time to update the table and perhaps calculations of when you need to update a particular row with fresh tiles. That would be my guess and I think it's a pretty good one.
The SNES PPU has drastically different behavior depending on which graphics mode is used. Mode 0 has 4 background layers that are all using 2bpp tiles. Mode 7 has only 1 background layer which has transformations of scaling and rotation. I do believe there was a way to have Mode 7 plus a window type layer but I can't recall. Ofcourse with HDMA or IRQ you can change mode mid-frame.
The SNES doesn't have a mode for horizonal line offsets, but it does have many other interesting features. Like one mode where every tile can have its own scroll offset. I remember hearing Chrono Trigger used it for certain effects. But anyway to do horizontal scrolls like in certain Genesis games all you need is a HDMA table. So the hardware for that is there.
The only reason I can think of for why SNES developers may have decided not to do similar effects to the games you mentioned may have been cpu time. Maybe they didn't think those type of effects were worth the lost CPU time. They certainly would take up atleast alittle time to update the table and perhaps calculations of when you need to update a particular row with fresh tiles. That would be my guess and I think it's a pretty good one.
-
tomaitheous
- Very interested
- Posts: 256
- Joined: Tue Sep 11, 2007 9:10 pm
Technically they are 24 color BGs for 2bit BG planes (mode 0). Remember, they have subpalette access. It is a strange mode though (mode 0). I'm sure some effects can be used to take advantage of it. Mode 1 is the most popular from what I've seen, though BG #3 is most often used as a status screen overlay - keeping you from wasting other BG parts or sprites for that.sheath wrote:HDMA aside, it seems like SNES developers chose to design their games around the SNES' "Mode" system for backgrounds. Based on the games, I'd say they typically stuck to Modes 1-4 if they weren't using Mode 7. At least, I can't think of any reason why they would want an overabundance of 4-color backgrounds.
That would be logical speculation, if it weren't for the many other type of effects developers where doing mid screen on the same HMDA table system. The Color Window has to be update on specific scanlines to get that gradient most often used. Mode 7 used as 3D perspective had to update the mode 7 scale register every scanline (no to mention scrolling every scanline in some situations). And there are already examples of developers using HMDA to set different sections of the a corresponding BG map to a different scroll value (creating a different scroll section). There's plenty of evidence to suggest developers knew how to use the HMDA table system (even something as simple as an RPG using it just for the text box to display gradients inside it). And there are games like Axelay that don't use mode 7, but actually update the scroll registers of *both* planes on almost all scanlines (in addition to updating the Color window regs at the top part of the screen). I don't think there's any evidence to support the fact that developers didn't know how to use HMDA or were intimidated by it, or even restricted use of it by Nintendo. Quite the opposite.At any rate, the Genesis' Cell scroll method being advertised by the VDP's registers is a really obvious reason why we see more scrolling in Genesis games. The SNES not having a "Mode" for that many scrolls is probably why developers didn't hand code it (and subsequently why fans of the hardware have no appreciation for 8-10 scrolls).
A response for the part in bold, it did have a mode. That's what HMDA is. It's a table system just like that of the VDP on the Genesis. Though more flexible in that it's not just limited to scroll registers. It's not like you're talking about the PC-Engine. Where is has to use an interrupt and use the cpu to manually update scroll position on the corresponding line.
There are always certain things as a developer that you weren't allowed/supposed to do, because of unpredicted results or the same but for future versions of the console (or old versions. Devil Hunter Yoko for the MD for example has a compatibility problem with some models). The only one that I know of for Nintendo is touching/updating OAM (sprite table) mid screen. Supposedly this was a no-no from Nintendo. Mike Dailly worked in Stunt Racer FX or some such snes game and was the only developer to get permission from Nintendo to update OAM mid screen. But other games demonstrated mid screen updates of more than just scroll registers. Mario Kart comes to mind, where it switches from mode 0 to mode 7 mid screen. And we know of games constantly changing the mode 7 transforms mid screen to warp it in strange ways (Space Megaforce one of the bosses).I need to remember to find that developer interview that complained about Nintendo not allowing (or discouraging) custom effects in SNES software. If I recall that statement correctly, there was an additional pressure from Nintendo, or at least the SNES design and development support, to stick to the Modes available, emphasizing Mode 7 as much as possible.
Magazines also get a lot of stuff wrong. Miss interpreted information from companies, things taken out of context, or just made up based on observation. Specs often wrong (and not consistent either for the same system). Etc. Wasn't there an example of a Sega rep trying to explain what Blast Processing (TM) was? And more often the production or team leader, that's not specifically a programmer or well versed, gets the interview and asked technical questions (which his qualification isn't always accurate to give a correct answer or might generalize something). Magazines are a poor choice for technical reference. Especially since all these old systems are now emulated and the technical specifications is probably beyond even what even most developers knew (through RE and testing).
Truly true. And SNES only has 8 DMA 'channels'.Gigasoft wrote:Wrong. A line scroll table requires exactly 1 HDMA channel.[...]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.
BUT that reminds me about in SNES you cann't do vertical scroll inside a plane/BG. So, for example, you cann't port Trouble Shooter 2 from MD to SNES at pixel perfect level.
SNES DMA stops CPU as is done in MD. In Sonic 3 HINT it's used to change the palette, to perform plane scrolls you don't need to freeze the CPU, it's done by VDP.Gigasoft wrote: 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.
Strictly speaking with the Mode 7 we can not do a Mario Kart game or Secret of Mana style map, because we must change the scaling factor every n lines (and that's not a scale conventional operation). But despite this fact, they are examples of mode 7 usually given, that's because I said that...Gigasoft wrote: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.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.
I assume you're talking about per-column vertical scrolling. Well, in modes 2, 4 and 6 every tile can be individually scrolled in either direction, but I can't find any documentation on this so I don't know exactly how it works. But it probably wouldn't be as practical as on the Mega Drive, if positions have to be set for all the tiles. The last part of the mine cart scene in Super Mario RPG has an example of this mode.BUT that reminds me about in SNES you cann't do vertical scroll inside a plane/BG. So, for example, you cann't port Trouble Shooter 2 from MD to SNES at pixel perfect level.
Yes, but HDMA doesn't freeze the CPU until it's done, only once every line for a short time. And I'm talking about vertical scrolling (per line), not horizontal. Ok, I just checked and it turns out that Sonic 3 scales the water graphics on the CPU instead of updating VSRAM (and this is perhaps even slower). If it had done it using VSRAM, it would still have needed to update it on every line using the CPU. However, I believe that Castlevania Bloodlines uses VSRAM to achieve its scaling effects, by updating it on every line.eteream wrote:SNES DMA stops CPU as is done in MD. In Sonic 3 HINT it's used to change the palette, to perform plane scrolls you don't need to freeze the CPU, it's done by VDP.
http://www.neviksti.com/wiki/Hardware_Registers#Mode_2Gigasoft wrote: I assume you're talking about per-column vertical scrolling. Well, in modes 2, 4 and 6 every tile can be individually scrolled in either direction, but I can't find any documentation on this so I don't know exactly how it works.
Anomie's Register Doc Version WIP (reg.txt) implies that Mode 2 is virtually identical to the way the Genesis VDP handles backgrounds. I am sure there are differences, but capability wise I cannot see why this mode couldn't be just as capable of 8 line scrolls as the VDP is.
So, unless developers just preferred Mode 1 over Mode 2, my premise about the VDP promoting scrolls more than the SNES PPU is weakened if not broken. Tom, by all accounts Mode 0 limits each of the four layers to 4-colors each. So the maximum limit on screen, if each layer used totally different palettes, would be 16 colors total for backgrounds. Are you saying that they could only pull from a single 24 color palette?
It is also interesting that the SNES can switch between modes between frames. I'm not sure how this looks in games, it would seem that it couldn't occur during scenes with noticeable scroll layers. I know that Contra IV has to do it in the first level for the bomber to scale in Mode 7, if I recall the scene with the bomber is immediately preceded by "load" where the player has to stop and be told to move forward.
On the subject of DMA and HDMA, both Anomie's document and a document called "Hardware.txt" say that they can be used, if timed correctly (isn't that a big if?), in tandem. What neither document says is what the upper limit is for how much data can be transferred between frames.
I'm also having trouble verifying how much VRAM the SNES actually has. Some sources say 64KB and some say 16KB (including Nintendo). In the case of the 16KB of VRAM being correct, the SNES's DMA/HDMA channels become *necessity* to treat the 128KB MAIN RAM as "unified" memory. In the case of 64KB VRAM, the DMA/HDMA channels become pure programming gravy.
So, unless developers just preferred Mode 1 over Mode 2, my premise about the VDP promoting scrolls more than the SNES PPU is weakened if not broken. Tom, by all accounts Mode 0 limits each of the four layers to 4-colors each. So the maximum limit on screen, if each layer used totally different palettes, would be 16 colors total for backgrounds. Are you saying that they could only pull from a single 24 color palette?
It is also interesting that the SNES can switch between modes between frames. I'm not sure how this looks in games, it would seem that it couldn't occur during scenes with noticeable scroll layers. I know that Contra IV has to do it in the first level for the bomber to scale in Mode 7, if I recall the scene with the bomber is immediately preceded by "load" where the player has to stop and be told to move forward.
On the subject of DMA and HDMA, both Anomie's document and a document called "Hardware.txt" say that they can be used, if timed correctly (isn't that a big if?), in tandem. What neither document says is what the upper limit is for how much data can be transferred between frames.
I'm also having trouble verifying how much VRAM the SNES actually has. Some sources say 64KB and some say 16KB (including Nintendo). In the case of the 16KB of VRAM being correct, the SNES's DMA/HDMA channels become *necessity* to treat the 128KB MAIN RAM as "unified" memory. In the case of 64KB VRAM, the DMA/HDMA channels become pure programming gravy.