32X strengths

Ask anything your want about the 32X Mushroom programming.

Moderator: BigEvilCorporation

commodorejohn
Very interested
Posts: 70
Joined: Tue Mar 06, 2007 6:30 pm

Post by commodorejohn » Tue Jul 17, 2007 3:03 pm

It certainly doesn't look too hard; it's just a modified Wolfenstein engine, apparently.

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Tue Jul 17, 2007 8:46 pm

commodorejohn wrote: As far as DOOM goes, yeah, I suppose RAM limits would be a problem. I wonder how much a typical level takes? I'm sure the BSP and the textures are the bulk of it, but exactly how much? How does 32X DOOM deal with only having 256KB of RAM?
I've never messed around with the guts of DOOM, but I'm going to take a wild guess that most of the level-data is read-only. As such, it can just be accessed directly from ROM. RAM might have still been tight (especially given that some of the data was probably compressed and RAM was needed as a decompression buffer) which would explain why the code was running out of ROM rather than RAM.

TascoDLX
Very interested
Posts: 262
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Wed Jul 18, 2007 7:43 am

Wolfenstein 3D:

Source code here (same location as the DOOM source, no surprise).
Mask of Destiny wrote:VDP DMA bandwidth might limit your max framerate. I believe I calculated it to be around 12FPS if you're trying to update the whole screen. Of course, in Wolf 3D part of the screen is covered by the HUD so I'm not sure how much of an issue it would be.
First off, instead of updating the whole screen you're only updating the render window -- about 2/3 of the screen. The problem with this kind of render is that while you are updating via DMA you can't do anything else.

Okay, let's break things down. If you can't stand technical details, then skip ahead. For everyone else, here's the tutorial:

According to the manual, [for a NTSC Genesis/MegaDrive] you can transfer about 6 KB during VBLANK -- less than 1/6 of the patterns @ 320x224 or a bit over 1/5 of the patterns @ 256x224. During active scan (when the VDP is displaying) you can transfer 3.5 KB which is horrible considering that the active scan period is more than 6 times longer than the VBLANK period. (Also keep in mind that you'll need to update more than just pattern data for each frame, mostly pattern name table data.)

So, ideally you want to avoid transfers outside of VBLANK. The best you should expect is under 6 KB per frame @ 60 Hz. If you update less than 6 KB, you can get 60 fps. With less than 12 KB, you can get 30 fps. With less than 18 KB, you can get 20 fps. With less than 24 KB (actually less than 23.5 KB), you can get 15 fps.

(God, I hope my math is right.)

If you're wondering how you can perform partial updates without an ugly tearing effect, it's double buffering. There are two render buffers in VRAM: one is displayed on-screen, the other is scrolled off-screen. While you're updating one buffer, the other is displayed. When the updates are complete, you change the scroll position and now the new image is on-screen and the old image is scrolled off.

BTW, this is essentially the method employed by Virtua Racing (although VR has the benefit of an extra processor for rendering).

Now, back to the Wolf.

On the PC (in VGA), the max size for the render window is about 304x152 which is 38x19 cells on the VDP [>22.5 KB]. Since VGA resolution is 320x200, you'll have an extra 3 cell rows to deal with but leaving some border room (and tweaking the HUD) isn't that bad. However, because of the VDP's palette assignment scheme, you need to update the pattern name table. This could add up to an extra 2.5 KB. If you knocked off some cells (perhaps down to 36x18), you could potentially run at 15 fps.

If you move from 40 cell mode (320x224) to 32 cell mode (256x224), you lose some resolution but also cut down on the processing. You'd be looking at 28x18 cells which could bump you up to 20 fps if you squeeze it. All of this assumes you can fit all of the processing into these few frames.

Also, you have to address those RAM constraints, blah, blah, blah... yeah, I'm done.


Doom:
Mask of Destiny wrote:
commodorejohn wrote:As far as DOOM goes, yeah, I suppose RAM limits would be a problem. I wonder how much a typical level takes? I'm sure the BSP and the textures are the bulk of it, but exactly how much? How does 32X DOOM deal with only having 256KB of RAM?
I've never messed around with the guts of DOOM, but I'm going to take a wild guess that most of the level-data is read-only. As such, it can just be accessed directly from ROM. RAM might have still been tight (especially given that some of the data was probably compressed and RAM was needed as a decompression buffer) which would explain why the code was running out of ROM rather than RAM.
That sounds right.

I haven't broken down DOOM.WAD but I'd expect there are quite a few changes/conversions needed to get from PC to console. You'll likely need to compress some of the data (if you can). I believe most of the original data is not compressed, or at least I gather as much from the Unofficial DOOM Specs.


Rise of the Triad:

If any game deserves the 32X CD treatment, it's ROTT.

Source code here but I haven't seen it yet. Don't tell me how it ends! :D

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Wed Jul 18, 2007 2:19 pm

TascoDLX wrote:The problem with this kind of render is that while you are updating via DMA you can't do anything else.
Less of an issue on the Sega CD of course, since presumably the bulk of the processing on the faster Sega CD 68K.
If you move from 40 cell mode (320x224) to 32 cell mode (256x224), you lose some resolution but also cut down on the processing.
Unfortunately, knocking down to 256x224 downclocks the entire VDP so DMA bandwidth is decreased too. When Fonzie was working on his Sega CD video player I suggested he try switching to 320x224 during VBLANK and then switching back to 256x224 for the display, but he reported that it didn't work properly.

Fonzie
Genny lover
Posts: 323
Joined: Tue Aug 29, 2006 11:17 am
Contact:

Post by Fonzie » Wed Jul 18, 2007 5:23 pm

active scan period is more than 6 times longer than the VBLANK period.
That's absolutely crazy and nice to know ^^ I noticed that the VBlank was shorter than expected ^^ but not smaller than Vactive... So 6 times smaller... woot, that's a lot of processing power wasted when doing raster effect games :D !

Yeah, using the segacd's flipflop ram would be very effective (+ the bmp2tiles conversion)... It's still unknown why we never saw any great corridor shooters on megacd ^^ (yet, of course).

Switching between 40 and 32 cell mode during Vblank did not worked on my TV so far... I think it is because the VDP continue to send signals to the TV during Vblank (hence the little palettes dots at bottom of the screen on PAL systems).

------------
Doom 32x isn't optimized at all so far... They just seems to run the same code as the computer version (with a stretched down .wad and a FX card emulation using the other SH2).
Doom was one of the first game to be coded in 99.9% in C (if i recall what Steve told me) so they just ported it like that :)

commodorejohn
Very interested
Posts: 70
Joined: Tue Mar 06, 2007 6:30 pm

Post by commodorejohn » Wed Jul 18, 2007 6:09 pm

You know, if you could do Rise Of The Triad, I bet you could do The Elder Scrolls: Arena, if you could figure out a decent gamepad-based control scheme.

TascoDLX
Very interested
Posts: 262
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Wed Jul 18, 2007 9:13 pm

Mask of Destiny wrote:
TascoDLX wrote:If you move from 40 cell mode (320x224) to 32 cell mode (256x224), you lose some resolution but also cut down on the processing.
Unfortunately, knocking down to 256x224 downclocks the entire VDP so DMA bandwidth is decreased too.
Guess what? I screwed up my math! Well, not quite. I just misread the manual.

You can transfer about 7.2 KB during VBLANK in H40 cell mode (320) and less than 6 KB in H32 cell mode (256). My numbers are correct for H32, not for H40.

It still may be tough to get 20 fps in H40 but it's much closer than I originally thought.
Mask of Destiny wrote:
TascoDLX wrote:The problem with this kind of render is that while you are updating via DMA you can't do anything else.
Less of an issue on the Sega CD of course, since presumably the bulk of the processing on the faster Sega CD 68K.
Yes, it means the processing is less of an issue and you can transfer through active scan all you want. In H40, that's 11 KB per 60 Hz frame. For Wolf3D, the max you should expect is 30 fps, which is good. For games with a larger window, the max would drop to 20 fps.
Fonzie wrote:
active scan period is more than 6 times longer than the VBLANK period.
That's absolutely crazy and nice to know ^^ I noticed that the VBlank was shorter than expected ^^ but not smaller than Vactive... So 6 times smaller... woot, that's a lot of processing power wasted when doing raster effect games :D !
There's not a lot you should do mid-screen. The manual doesn't mention the HBLANK explicitly but if it's the same transfer capacity mentioned for active scan then that's worth about 8 or 9 palette entries.
Fonzie wrote:Doom 32x isn't optimized at all so far... They just seems to run the same code as the computer version (with a stretched down .wad and a FX card emulation using the other SH2).
Doom was one of the first game to be coded in 99.9% in C (if i recall what Steve told me) so they just ported it like that :)
That's pretty much what I expected. I remember reading that it only contains half of all the maps. No love.
commodorejohn wrote:You know, if you could do Rise Of The Triad, I bet you could do The Elder Scrolls: Arena, if you could figure out a decent gamepad-based control scheme.
If the source code was available (I don't believe it is). But from a hardware perspective, it seems more than reasonable.

ob1
Very interested
Posts: 463
Joined: Wed Dec 06, 2006 9:01 am
Location: Aix-en-Provence, France

Post by ob1 » Thu Jul 19, 2007 4:47 am

Fonzie wrote:Doom was one of the first game to be coded in 99.9% in C (if i recall what Steve told me) so they just ported it like that :)
I thought it was the contrary : 99,9%. I remember Carmack saying : "you know in PC ASM, only 2 display routines exist. So, we had to handcode everything".
Can anyone confirm ?

... by the way didn't we lose the topic ? I was talking about 32X strenght, not the Genesis being able to run Doom or not.

evildragon
Very interested
Posts: 326
Joined: Mon Mar 12, 2007 1:53 am
Contact:

Post by evildragon » Thu Jul 19, 2007 4:54 am

Im pretty sure it was C.. Doom wasn't even designed on a PC, I think it was a NeXT system...

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Thu Jul 19, 2007 2:04 pm

TascoDLX wrote:There's not a lot you should do mid-screen. The manual doesn't mention the HBLANK explicitly but if it's the same transfer capacity mentioned for active scan then that's worth about 8 or 9 palette entries.
When I was screwing around with Raster F/X I was able to turn off the display (required to prevent 'dirt' on the screen, originally noticed by Charles MacDonald), DMA 8 palette entries and turn the display back on during HBLANK in H40 mode, but only if I polled the status register rather than relying on H-INTs. That was also using the trick from Charles MacDonald's raster F/X demo in which the DMA transfer is mostly setup ahead of time so only one write is required to kick off the DMA during HBLANK.

If you use H-INTS you can only get away with 4 entries, presumably because by the time your H-INT routine executes you've already chewed through a relatively substantial part of HBLANK.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Thu Jul 19, 2007 5:25 pm

Mask of Destiny wrote:
TascoDLX wrote:There's not a lot you should do mid-screen. The manual doesn't mention the HBLANK explicitly but if it's the same transfer capacity mentioned for active scan then that's worth about 8 or 9 palette entries.
When I was screwing around with Raster F/X I was able to turn off the display (required to prevent 'dirt' on the screen, originally noticed by Charles MacDonald), DMA 8 palette entries and turn the display back on during HBLANK in H40 mode, but only if I polled the status register rather than relying on H-INTs. That was also using the trick from Charles MacDonald's raster F/X demo in which the DMA transfer is mostly setup ahead of time so only one write is required to kick off the DMA during HBLANK.

If you use H-INTS you can only get away with 4 entries, presumably because by the time your H-INT routine executes you've already chewed through a relatively substantial part of HBLANK.
Turning off display also puts the VDP in "non active" state so data transfert are faster. You can use that tip to maximise your transfert during H-Blank. Also you can gain a lot by desactivating the VDP before scanline 224, that reduce the vertical resolution but it worths it. Using a 190 pix resolution instead of 224 pix permit to almost double the DMA capacity.

ammianus
Very interested
Posts: 124
Joined: Sun Jan 29, 2012 2:10 pm
Location: North America
Contact:

Post by ammianus » Sun Feb 05, 2012 2:10 pm

What about using the CPU power and larger color palette for 2d games with a lot of animation through transforms (by software), or including 3d elements / effects?

I am thinking along the lines of Castlevania: Symphony of the Night, which had a lot of neat effects.
- The "3d" spinning coffin at save points
- A number of the enemies appeared to be collections of 2d polygons/sprites, so the movement was through transforms of those polygon "parts" instead of sprites of the whole character for each step of the animation. (maybe that's just an illusion). For example if memory serves this guy and his swords.http://faqsmedia.ign.com/faqs/image/art ... ter085.jpg, or http://faqsmedia.ign.com/faqs/image/art ... ter083.jpg
- Other effects like some of the spells, the fast moving clouds of some of the backgrounds, transparency of enemies, projectiles, fog.
- Obviously CD quality sound and the large size of that game are different animals due to storage size of a CD, but purely technically, some of the game elements that SotN did should be possible on 32X too?

I don't have Kolibri, but from youtube vidoes I am very impressed by the smoothness of the game and the nice detailed environment. Is that looking so well purely because of larger color palette?

What about a sort of car/bike racer like the Genesis Road Rash games, but again with more elements and better graphics? Or it always seemed to me that at high speeds or in 2-player mode, RR games became sort of jerky and the stuff would pop out at you from no where, perhaps the 32X could support a better framerate? I had Motocross 32X, and it kind of did some of these things with better graphics, although game play wasn't that great, more to do with game design than anything in the hardware I would think.

I am a big fan of classic 2d games/genres overall, would love to see some impressive stuff on 32x, expanding on what could be done on the MD, rather than more 3d FPS games :wink: (enough of them already!).


Edit: is sound capability of 32X the same as in the Genesis?

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Feb 05, 2012 8:33 pm

ammianus wrote: I don't have Kolibri, but from youtube vidoes I am very impressed by the smoothness of the game and the nice detailed environment. Is that looking so well purely because of larger color palette?
Partly - it also takes good artists to make good backgrounds. While a great artist can make the best of poor color palettes, a bad artist can make bad backgrounds with the best graphic modes/palettes.

What about a sort of car/bike racer like the Genesis Road Rash games, but again with more elements and better graphics? Or it always seemed to me that at high speeds or in 2-player mode, RR games became sort of jerky and the stuff would pop out at you from no where, perhaps the 32X could support a better framerate? I had Motocross 32X, and it kind of did some of these things with better graphics, although game play wasn't that great, more to do with game design than anything in the hardware I would think.
Yes, the first round of titles hardly scratches the surface of what the 32X can do. I'd love to see a Road Rash type game that takes more advantage of the 32X.
I am a big fan of classic 2d games/genres overall, would love to see some impressive stuff on 32x, expanding on what could be done on the MD, rather than more 3d FPS games :wink: (enough of them already!).
Yes, we'd all like to see a better 2D Sonic game, and some other things. One person over at SEGA-16 was asking for OutRun.

Edit: is sound capability of 32X the same as in the Genesis?
You have the regular Genesis sound + a stereo PWM channel. You might check out my mod player demos, and the newer Yeti3D demo that plays sound effects and mod music for the level. The 32X is quite capable of playing tracker style music with digitized instruments (MOD, IT, S3M, XM, etc), as well as mixing the music with digitized sound effects. Again, check out the Yeti3D demo.

My stuff all uses the Slave SH2 to handle playing the MOD and mixing the sound effects. Because it uses DMA for the PWM audio, you need KEGA Fusion 3.64, or Gens/GS r7 + my PWM audio fixes. It sounds best on real hardware.

Post Reply