3d software rendering on megacd

Chilly Willy · Post by **Chilly Willy** » Fri Nov 30, 2007 10:11 pm

TascoDLX wrote: Two nametables in H40 mode would be 64x28x2x2 = 7168 bytes because the scroll plane must be 64 cells wide.

Oh, right. I forgot that little detail.

But since we only need one scroll plane, perhaps we can put the nametables on top of one another. Both scroll planes would just be displaying the same pattern. If that works, it would cut the size down to 3584 bytes.

The point of two name tables is you have to refer to two different sets of patterns for double buffering. If you use one name table, you have to update the name table after updating the patterns to do double buffering. You can update the name table in a single VB DMA cycle, but that will slow down your game. Using two name tables allows you to flip buffers with a single register store to change which name table to use (well, two actually; one for each plane). So if you NEED the space, go with one name table and put up with one extra VB needed for the screen flip. If you don't, use two name tables for speedy screen flipping.

So I was already thinking of stacking the scroll planes... and then moving on to the screen flip itself.

Fonzie · Post by **Fonzie** » Fri Nov 30, 2007 11:16 pm

208? That's it? Well, I guess it's a record until someone claims otherwise. Congratulations!

Any irony?

I thought the limit for a normal VBLANK was around 128 tiles or so...

Anyway, I got my demo running on real hardware... It indicates 75 frames rendered for 50 DMAted and 60frames rendered for 60Dmated... As I render outside HINT/VINT at fullspeed and DMA during HINT, it may explain why I render crazy more frames for the 50hz machine (less DMA time wasted per second).

Btw : I'm speaking about DMA techniques, not megacd especially. My demo is megadrive only but applies to Megacd too.

you could always just DMA all the way through the active display period. I

During active period, I wonder if it worst it... The DMA speed is very slower, hence the advantage of extending the VBLANK period :/

Chilly Willy · Post by **Chilly Willy** » Sat Dec 01, 2007 1:36 am

PAL has 625 lines as opposed to NTSC's 525. If you're using the 28 cell mode for both, you have 2.32 times as many lines for DMA, while the frame rate is only 83% of NTSC. You can see that the extra lines more than make up for the lower frame rate in DMA terms, yielding 1.93 times as much VB time for DMA.

TascoDLX · Post by **TascoDLX** » Sat Dec 01, 2007 5:20 am

Chilly Willy wrote:The point of two name tables is you have to refer to two different sets of patterns for double buffering. If you use one name table, you have to update the name table after updating the patterns to do double buffering. You can update the name table in a single VB DMA cycle, but that will slow down your game. Using two name tables allows you to flip buffers with a single register store to change which name table to use (well, two actually; one for each plane). So if you NEED the space, go with one name table and put up with one extra VB needed for the screen flip. If you don't, use two name tables for speedy screen flipping.

My reasoning is that we need to rewrite the nametable to change the palette assignments anyway, so keeping two nametables in VRAM becomes quite pointless. Unless of course you aim for 16 colors only, but that's the only exception I can think of.

Fonzie wrote:
TascoDLX wrote:208? That's it? Well, I guess it's a record until someone claims otherwise. Congratulations!
Any irony? I thought the limit for a normal VBLANK was around 128 tiles or so...

Oh, so that includes the nametable? It's better than I initially thought but it seems like a small dent in the grand scheme of things.

Fonzie wrote:During active period, I wonder if it worst it... The DMA speed is very slower, hence the advantage of extending the VBLANK period :/

It depends if you want do anything else with the main cpu. There are certainly better ways to spend that time. Honestly, if you're willing to give up the bottom of screen, then I'm

with that.

Fonzie · Post by **Fonzie** » Sat Dec 01, 2007 3:45 pm

Well, dropping 32pixels (224-32 = 192) isn't a real trouble compared to the crazy power you get in exchange

Top of that, "software" rendered games will never been fullscreen... So!

And yeah, I'm in 256px width mode

If you would be ready to cut 32 pixels on top and 32pixels on bottom of screen (giving your game a panoramic area of 160*256) You may probably be able to DMAte around 300 tiles in a single VBLANK (so, refresh your screen in two frames only, keeping a lot of free-time, the Vactive, for processing power) ^^

Chilly Willy · Post by **Chilly Willy** » Sat Dec 01, 2007 9:16 pm

The old Atari systems used a default height of 192, so I don't see a problem with that. The "panoramic" 160 height you mention is probably also acceptable for some games. Keeping the render part of the screen to something like 240x160 would certainly cut down the memory footprint considerably. You'd have enough for sprites, and/or another plane (not a double-buffered plane, though). Do objects and creatures like Doom, but shown via the sprites. You could use the double-buffered plane just for the level, and the single-buffered plane for sky boxes.