updating the screen on Genesis

[maiki]

As far as I understand the is no video RAM mapped in CPU space. Everything has to be tranfered to VDP's RAM correct? So how do you actually render things on the screen in software? Do you have to update the tiles every frame (reload them into VDP)? For instance this software zooming demo... or the intro for Ranger X etc etc... How much time left is there to do the updates..? I guess there is plenty of room to do the whole screen software rendering at 60fps...

 

 

[Chilly Willy]

As far as I understand the is no video RAM mapped in CPU space. Everything has to be tranfered to VDP's RAM correct? So how do you actually render things on the screen in software? Do you have to update the tiles every frame (reload them into VDP)? For instance this software zooming demo... or the intro for Ranger X etc etc... How much time left is there to do the updates..? I guess there is plenty of room to do the whole screen software rendering at 60fps...

 

BWAHAHAHAHA! Uh, no. You don't come close to being able to update the whole screen via software on the Genesis. You have full access to the vram only during the vertical blank, which isn't long to do much. Through the active part of the display, you only get a few accesses per line. In all, you could update the screen at maybe 15 Hz on NTSC. PAL has a much longer vertical blank period as well as being 50 Hz instead of 60, so you can update the screen faster on a PAL console, but people gear their games around NTSC timing since its the more restrictive of the two (lowest common denominator).

 

Game that scroll at 60Hz use repeating tiles and only change the name table (tells what tiles make up the current display). You can update the name table at 60 Hz, and maybe have time to update a few changed tiles as well. Map editors allow you to define tiles and make big maps based on the tiles. Anywho, tile maps are why you see LOTS of repetition in fast scrolling games.

 

Sprites are all predone and stored in vram before they need to be used. You could start loading tiles for certain sprites when you hit a trigger point in the level that says that particular sprite is about to appear. So fast backgrounds and animated sprites are all about changing references to tile already in vram, not drawing them in software on the fly. Virtua Racing draws the screen on the fly, and runs about 15 FPS as a result. Even if the SVP can render faster, that's the fastest you can update the screen (in NTSC).

[maiki]

That's bad news I am afraid. Sega Genesis has not got enough hardware sprites for intensive shooters and I was thinking about going software way. But no way to go down to 15 fps.

[maiki]

Here is the question:

 

Defender in the Williams Arcade Hits compilation cartridge is not using any hardware sprites (tested with Genecyst) and everything runs at rock solid 60fps. So how come you cannot update screen at that rate when Defender clearly renders all the particles, object, shots... at this speed...?

 

[Chilly Willy]

You can make "sprites" using the background by making cells for each horizontal/vertical position, then changing the name table. That would work well for a game like Defender where you have VERY sparse graphics and only several small enemies/bullets. Basically, pre-rendered graphics instead of drawing on the fly.

 

Another thing some games do is to only update part of the screen at a time. For example, Duke Nukem does that for better speed, only updating half the screen at a time.

[maiki]

Pre-rendered? That is something I do not get in case of Defender. Everything is moving freely and everything is being mixed together according to the action. How would you prerender all those bullets, aliens, shots, stars... I would really like to know how they did that but myself I have not the knowledge.

[Chilly Willy]

Make multiple cells for an object - have a "shot" or other object shifted relative to the cell. Then instead of redrawing the shot, you simply change the name table to refer to the cell with the shot in the next position. After you reach the edge of the cell, then you move to the next/previous cell position in the name table.

 

Looking at Defender, that's probably not what they are doing. They probably draw directly to the screen as there is VERY little to update as long as you disregard the scrolling. The scrolling can be handled via hardware scrolling, minimizing how much you need to draw in each frame.

[maiki]

Yes the foreground mountains use second playfield and that is probably HW scroll. But the stars are on the same playfield as the rest of the graphics. OK you can make several cells to get the shot moving but if you look at the game it mixes everything together...

[Chilly Willy]

But it's not drawing the entire display, only those objects that move relative to the overall hardware scroll. So you probably only have a few objects that need to be draw each screen, thus keeping in the limits you can DMA per screen. In fact, what I'd probably do is limit movement to 2 pixels - that would be a full byte you would use for drawing. Then have all objects in vram and just use vram to vram copy to draw the object to the new location.

[maiki]

have all objects in vram and just use vram to vram copy to draw the object to the new location.

 

So you can actually set pixels to any location by VRAM to VRAM copy? Is there any speed advantage over normal RAM to VRAM transfer?

 

from Genesis manual:

 

[Bruce Tomlin]

Looking at that table, I don't think there is a VRAM to VRAM copy.

 

And if there was, I think it would be worse than RAM to VRAM because it would take twice as much VRAM bandwidth.

[Chilly Willy]

Looking at that table, I don't think there is a VRAM to VRAM copy.

 

Uh... it's the last entry in his table.

 

 

And if there was, I think it would be worse than RAM to VRAM because it would take twice as much VRAM bandwidth.

 

Pros: VRAM Copy doesn't halt 68000 while running like Memory to VRAM.

Cons: Has half the bandwidth since it copies a byte per cycle instead of a word.

 

So if all the source imagery fits in the vram AND not much changes per frame, VRAM Copy allows more CPU time for the rest of the game logic. If the source imagery doesn't fit in VRAM and/or you need more bandwidth, Memory to VRAM may do the trick, but halts the 68000 while running leaving less time for game logic.

[maiki]

I still do not understand how you would put an object to new location by vram to vram copy... you mean switching different tiles or shifting bits? How would you reposition an object pixel by pixel by that when it is all grid of tiles?

 

OK another one: how would you render those fishing lines at 60 frames per second on Genesis?

 

[Chilly Willy]

You could modify visible tiles by copying from tiles that aren't visible using vram copy. You could also change the name table (which is in vram) using vram copy.

 

You can reposition objects that are tiles by having multiple tiles of the object at different positions... or use vram copy to shift the tiles on the fly.

 

There are many ways you could render the fishing lines in the image. They could be sprites... or tiles for one of the background layers.

 

Many of these questions come from not being aware of what the Genesis VDP can do. I suggest people read the available docs, and look at some open source examples. Here's a good source of docs to read through:

 

http://emu-docs.org/?page=Genesis

 

Especially this one:

 

http://emu-docs.org/Genesis/sega2fhtml.rar