Posted: Tue Jul 17, 2007 3:03 pm
It certainly doesn't look too hard; it's just a modified Wolfenstein engine, apparently.
Sega Megadrive/Genesis development
http://gendev.spritesmind.net/forum/
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.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?
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.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.
That sounds right.Mask of Destiny wrote: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.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?
Less of an issue on the Sega CD of course, since presumably the bulk of the processing on the faster Sega CD 68K.TascoDLX wrote:The problem with this kind of render is that while you are updating via DMA you can't do anything else.
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.If you move from 40 cell mode (320x224) to 32 cell mode (256x224), you lose some resolution but also cut down on the processing.
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 !active scan period is more than 6 times longer than the VBLANK period.
Guess what? I screwed up my math! Well, not quite. I just misread the manual.Mask of Destiny wrote:Unfortunately, knocking down to 256x224 downclocks the entire VDP so DMA bandwidth is decreased too.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.
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.Mask of Destiny wrote:Less of an issue on the Sega CD of course, since presumably the bulk of the processing on the faster Sega CD 68K.TascoDLX wrote:The problem with this kind of render is that while you are updating via DMA you can't do anything else.
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: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 !active scan period is more than 6 times longer than the VBLANK period.
That's pretty much what I expected. I remember reading that it only contains half of all the maps. No love.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
If the source code was available (I don't believe it is). But from a hardware perspective, it seems more than reasonable.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.
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".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 :)
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.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.
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.Mask of Destiny wrote: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.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.
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.
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.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?
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.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, 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.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 (enough of them already!).
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.Edit: is sound capability of 32X the same as in the Genesis?