Homebrew version of doom is being worked on for the genesis. Picture links inside

[Video]

Doom can be done on Genesis, probably Ok, but it'll probably look a lot like the SNES, with less colors (isn't the genny only capable of like 16 at a time?) I'd be one of the first to buy it if they could make it work on the genesis. I just think stufff like that is cool, especially the, You can't do that on that, stuff like Doom on Genesis will probably be.

[JB]

Doom can be done on Genesis, probably Ok, but it'll probably look a lot like the SNES, with less colors (isn't the genny only capable of like 16 at a time?)

Officially it's 64. 16 takes us back to the 99/4a and ColecoVision. Maybe Sega's pre-Master System/Mark3 systems, I'd have to rummage the specs up again.

 

Hardware trickery can get all 512 Genny colors onscreen at once, but it was only done with SegaCD games.

[Video]

Doh, Oh yeah, that's right. Of course the Genesis had more processing in other areas and could track more sprites I think, but even still, I figure the end result will still look a lot like SNES Doom.

 

As long as they use the extra sprites to animate the mosters from all sides instead of jsut the front like the 32X game, then that'll be OK.

[Jess Ragan]

Oh! I didn't read your response until just now, MegaManFan. Here's a link to the iPod version of Doom:

 

http://ipodlinux.org/Doom

 

JR

[JB]

Doh, Oh yeah, that's right. Of course the Genesis had more processing in other areas and could track more sprites I think, but even still, I figure the end result will still look a lot like SNES Doom.

SNES version will probably look better due to the higher color depth, actually.

They were using the SuperFX for SNES Doom, so the Genny doesn't have a major horsepower advantage that would otherwise make the game far more fluid.

...

A Genny port of Wolfenstien should kick the SNES version's ass, though.

[LocalH]

I call bullshit.

 

In those emulator screenshots, each one shows a slightly different pallet for the HUD and border elements, something that would NOT happen on a properly coded version - imagine if you were playing and the HUD flickered like hell because the pallet was constantly changing. Any competent coder would be able to split the pallet such that the HUD always uses the same colors, regardless of what pallet trickery you have to use on the main playfield. Hell, I've been coding on the Genesis for about six months and I could do it.

 

Also, the Genesis can only output 61 colors without some sort of raster tricks - there are four pallet lines, and each one has 15 colors plus transparent (there are 64 pallet entries, but $x0 are only usable for the background color, not game graphics). These screenshots show 64 colors total, which is too much even if you deduct black for the background, leaving 63.

 

Also, these screenshots show colors that the Genesis can't generate. There are only three bits per color component, stored like %0000 BBB0 GGG0 RRR0 in binary. The screenshots show colors that, when converted to Genesis color format, would reduce to identical values.

 

Also, the TV screenshots don't mean anything. It wouldn't be too difficult to fake those. Number one, that looks like a stock Genesis, which has horrible video output, yet none of the typical artifacts of stock Genesis output appear on the screenshots (especially around the reds, which exhibit the worst artifacts of any other colors).

 

Until I see a ROM, my proclamation is that it's complete and utter bullshit. All this guy has done is taken some screenshots from another version of DooM, reduced them in size by 1/2 using nearest neighbor resampling, resized them back up to their original size, slapped a HUD around it and then reduced to 64 colors. There is no DooM for the Genesis as of now.

Edited May 30, 2006 by LocalH

[Video]

Actually, I'd have to agree with LocalH. I did not initially look at any of the screen shots of the game, but lookin at them, it looks faked.

 

Most of the screens look like they took SNES Doom and added a border. I can't really tell from the screen shots, but it looks the same. It's the same size on the TV screen even, note that the SNES version wasn't full screen either, but didn't sport a boarder.

 

It does seem to be a reasonable fake, but it does look like it's been hacked from other games.

 

Is it my imagination, or is the Comparison photo showing the GBA game at a higher resolution than the other consoles?

 

Damn, that game must be on every 16 bit console on up....

 

Er... never mind that. Untill this rom pops up on the net, I doubt those are real screens.

[JB]

I didn't look at the screenshots either.

 

SegaCD's better-suited to it anyways. 'S got hardware for scaling the sprites(I think it can scale sprites, anyways), more space, and more sound capabilities(mainly the PCM channels. I don't see redbook as a good idea).

 

 

As far as the larger GBA screenshot... I'm pretty sure it's an actual photo of the screen as opposed to a proper VRAM capture.

The GBA screen is only 240*160, making it the lowest-res of the 4 systems shown.

3D0 ran at 320*240 or 320*480(upsampled to 640*480 for display), and the Genesis and 32x ran at 320*224 usually.

Edited May 30, 2006 by JB

[supercat]

My recollection is that the Genesis uses a mixture of tiled backgrounds and sprites. Can the Genesis use enough tiles and/or sprites to effectively build up a bitmapped region of the screen? How is the tile data stored?

 

If I remember correctly, the graphics in Doom, not counting the sprite overlays, are formed from a mixture of posts (for the walls) and spans (for the floors). Because all parts of a post or span are equidistant from the player, the basic loop for a post is basically:

 for (y=start; y<end; y++)
 {
putpixel(x,y,pattern(patx,paty >> 8);
paty+=something;
 }

The code for a span is somewhat similar, but needs to modify both patx and pady in the loop.

 

If the Genesis uses one byte for every two pixels, and if the graphics are effectively run at half-resolution, the inner loop for posts would probably be (sorry my 68000 is very rusty). I'm assuming 64 wall designs (though other powers of 2 would work)

 mov.b @A1+R0,@A0  ; Plot the pixel
 add.w R2,R1  ; R1 = row counter in source, times 64
 mov.w R2,R0
 and.w R3,R0
 add.w R4,A0

Not including loop overhead, that's still a fair bit of code. Five instructions totalling 6 words I think. With Duff's device, loop overhead could be minimized but if those instructions take 40 cycles to execute (I'd guess that's about right) and the Genesis runs at 8MHz, that's 5uS per double-pixel. Assume a window of 128x128 double-wide pixels, with half of them occupied by walls. That would be 40ms to draw the walls.

 

The spans for the floor would be a little nastier. Assume 64 patterns of 64x64.

 mov.b @A1+R0,@A0++ ; Plot the pixel
 add.w R3,R1 ; R1 = column counter in source, times 64
 and.w R4,R1 ; R3 = mask constant #$0FFF
 add.l R5,R2 ; R2 = row counter in source, times 4096
 mov.l R2,R0
 and.l R6,R0
 add.l R1,R0
 and.w R7.R0  ' Mask constant #$FFC0

Eight instructions totalling nine words. If that takes 48 cycles to execute, that would be 6uS per byte. If half the screen is floors, that's 48ms to draw the walls.

 

So 40ms+48ms would be about 90ms to do each frame. And of course, there are all the calculations needed to set up these loops. Maybe vaguely possible, but frame rate would be a bit annoying, especially if video steals CPU cycles (I don't know if it does on the Genesis).

[LocalH]

My recollection is that the Genesis uses a mixture of tiled backgrounds and sprites. Can the Genesis use enough tiles and/or sprites to effectively build up a bitmapped region of the screen? How is the tile data stored?

Yes, but the number of colors will depend on how large of a region will be used for rendering. Tile data is stored X-first, one nybble per pixel, so 32 bytes per tile, 16 colors per tile (color 0 is always backdrop/transparent). Plus, you have your nametables which determine X/Y flipping, patterns, pallets, and priorities for each tile, which takes 2 bytes per tile (so pallet selection is tile-granular). Nametables are laid out X-first across the whole scroll layer (which, for 320x224, would have to be 64x32). You have two hardware layers, A and B. So you essentially have four layers of depth but only two layers of actual background graphics. You also have up to 80 sprites at once (20 sprites or 320 pixels of sprite data per scanline), which I will call S, with the same priority, pallet, and X/Y flipping capabilities. Sprites are laid out Y-first. From top to bottom, you have high S, high A, high B, low S, low A, and low B. You also have a hardware shadow/highlight function which can be used in two ways - on a tile-by-tile basis using the priority bits in your nametables, which allows you to denote half or normal intensity, or through sprites using color $3E for half intensity and $3F for double intensity. You also have a total of 64KB of VRAM which holds everything mentioned earlier except the actual color pallets themselves, which go into 64 words of separate CRAM.

 

However you set the nametables up, it will not be a linear pixel map. Since tiles are stored in memory X-first, it might be advantageous to set up your nametable such that successive tiles are placed on the screen Y-first. However you handle this, you'll definitely have to develop an algorithm to convert standard pixel coordinates to tile memory offsets.

 

You also have to consider that VRAM has to be accessed through the VDP, which can be slow unless you disable tile rendering. You do have DMA which can mitigate this somewhat, but this requires building a buffer in 68k RAM and then transferring it during Vblank (potentially truncating the top and bottom of the screen by a few lines to gain more DMA time). As the system has 64K RAM total, this would require dedicating almost half of it to your VRAM buffer, including nametables and sprites.

 

Truth be known, the Sega CD would be much more suitable for such a game. There are two mutually exclusive features, either of which will aid in development. There is a "full graphics mode" where you can use a block of memory on the CD side to access a linear bitmap at one byte per pixel, to gain speed at the expense of memory. You also have scaling and rotation hardware which could be used to handle the sprite scaling, but you can not use this at the same time as the full graphics mode. You also have a much faster 12.5MHz sub CPU in addition to the 7MHz main CPU (which you could use to split up game logic to further enhance speed). I'm pretty sure that a CD version could at least equal the SNES version, if not best it.

[V.R]

I agree, I think those pics are utter tosh. There is no way in hell a Motorola MC68000 could run a port of Doom, absolutely impossible. Wolf3D yes, but not Doom.

[Bruce Tomlin]

My recollection is that the Genesis uses a mixture of tiled backgrounds and sprites. Can the Genesis use enough tiles and/or sprites to effectively build up a bitmapped region of the screen? How is the tile data stored?

All your stuff is nice except for one thing: the graphics aren't memory-mapped. It's a name/pattern table setup like the ColecoVision, with two pixels per pattern table byte. And you have to talk through VDP control and data ports just like on Coleco and SMS. It's got somewhat better bandwidth than the Coleco, but it's still basically the same principle.

 

Getting Doom to run on the Genesis is probably comprable to getting it to run on an 8MHz PC AT. What was the minimum spec for Doom? 25MHz 386? The SNES required an FX chip to do it, and even then it ran in a small overlay window that took up about 50% of the screen area.

[LocalH]

That's why I think the Sega CD would be a better platform to attempt such a thing on (and no, I'm not doing it, I've already got a long-term Genesis game project underway), as you have a 12.5MHz 68000 as well as the full graphics mode I mentioned before, which would remove the requirement for doing a lot of bitshifting during rendering, since the screen is represented as a linear bitmap at one byte per pixel. You still might have to use 2x2 pixels, but it should be doable.

 

Although there was Duke3D on the Genesis, I'm not familiar with how it plays. And it took every bit of the Genesis' 4MB of ROM space.

[+FujiSkunk]

What about the Sega Virtua Processor that made Virtua Racing possible? Not that I believe this port of Doom is using the chip, but would it make the game feasible?

[LocalH]

Well, I think the SVP only supported rendering flat-shaded polygons, but I'm not sure. There's not much documentation on the SVP anyway, so from a practical standpoint it probably wouldn't be as useful as the Sega CD, which has good documentation available.

[DeathAdderSF]

This whole "DOOM" on Genesis thing was nothing more than a pathetic hoax.

[Bill Brasky]

I feel dirty. Someone hold me.