How about Samurai Shodown 2, 3 ,4 or 5 on the 32X
Printable View
How about Samurai Shodown 2, 3 ,4 or 5 on the 32X
Would love to see a port of Transport Tycoon, one of my fav games ever.
And yes the source is openly available.
Now that I think about it werent Hexen and Heretic made open source? and both based on the Doom engine...
Heretic is something fun, don't care for Hexen
I just meant all the stuff done in C was for 68k, referring to this previous discussion:
As I understad it, the Jaguar has 5 processors, the 68000 CPU/host, 3 inside the "Tom" ASIC: blitter, object processor, and "GPU" (general purpose 32-bit custom RISC processor with 64 "general purpose" registers -accessed in 2 32 register banks), and the last one in the "Jerry" ASIC referred to as the "DSP" ("digital sound processor"), another RISC CPU, similar to the "GPU," but tied to a 16-bit external data path (limited by the use of the 68k), and for some reason featuring a hard-coded 6-cycle access delay. (and I beleive a modified instruction set compared to the "GPU," as well as some additional bugs -distinct from those of the GPU)
Do you think you can get Doom working with the limited RAM available in the Sega CD?Quote:
Anywho, a SEGA CD 32X version of Doom certainly could run the game logic on the CD 68000, while the rendering was done by the 32X. That would make it VERY much like the Jaguar version. Remember that the 68000 in the Jaguar runs at 13.3 MHz, and the SCD 68000 at 12.5 MHz. This was one of the ideas I had for the CD 32X version of Doom as it makes better use of the resources, meaning a faster, smoother game.
Okay, that's makes sense. :)
Yes, the Jaguar is a real mess, which is part of the reason it failed. If the 32X/Saturn were "difficult" to program, the Jaguar was "insane". ;) I rather expect that many devs simply ignored much of the Jaguar hardware to make the task easier on themselves. Jaguar Doom certainly does.Quote:
As I understad it, the Jaguar has 5 processors, the 68000 CPU/host, 3 inside the "Tom" ASIC: blitter, object processor, and "GPU" (general purpose 32-bit custom RISC processor with 64 "general purpose" registers -accessed in 2 32 register banks), and the last one in the "Jerry" ASIC referred to as the "DSP" ("digital sound processor"), another RISC CPU, similar to the "GPU," but tied to a 16-bit external data path (limited by the use of the 68k), and for some reason featuring a hard-coded 6-cycle access delay. (and I beleive a modified instruction set compared to the "GPU," as well as some additional bugs -distinct from those of the GPU)
Yes, with compression on the graphics and sound, it should be workable. The idea is that only the game logic will run on the CD side, and compressed graphics will be passed on to the 32X along with the game state info needed to do the rendering. I've been experimenting with different methods of "texture" compression to find something usable by the 32X. I want the graphics needed for the level to fit into the 32X SDRAM, but there's only 256KB, so compression is clearly needed. I'm looking at formats that give 3:1 or 4:1 compression, but can be decompressed on the fly by the drawing routine with only a minimum of slowdown. In the same manner, sound would be compressed, stored in the CD Word RAM, and decompressed on the fly by the MD 68000 for playback through the PWM channels.Quote:
Do you think you can get Doom working with the limited RAM available in the Sega CD?
So the game would be altered to do something like this:
Extract and compress graphics needed for current level into CD Word RAM.
DMA data from Word RAM to 32X SDRAM.
Extract and compress sound effects to CD Word RAM.
Extract level state info to CD Program RAM.
Load level game logic.
Run level on CD 68000. Commands are sent through the communication regs to the MD 68000 to play sound effects, and to tell the MD 68000 to tell the 32X side when to process the next frame, along with render state info.
That's the basic plan for the CD version at the moment. Dividing things like that should make it possible to fit everything into the RAM available, and make best use of the processors.
wow that sounds incredibly complicated! Regards to the compression will it be lossless?
I doubt it'll be lossless (To achieve those ratios, you'd want a much more powerful CPU if it is lossless) but I doubt the quality loss will be that harmful.
Yeah, at least it's got a full 2 MB to work with though. A lot of interesting what if discussions on the Jag though. :)
And offer the option for CD tracks as well I would assume. (being able to add the 3DO sound track or one of the remixes would be cool, or of course use that ambient PSX ones for those who like them)Quote:
Yes, with compression on the graphics and sound, it should be workable. The idea is that only the game logic will run on the CD side, and compressed graphics will be passed on to the 32X along with the game state info needed to do the rendering. I've been experimenting with different methods of "texture" compression to find something usable by the 32X. I want the graphics needed for the level to fit into the 32X SDRAM, but there's only 256KB, so compression is clearly needed. I'm looking at formats that give 3:1 or 4:1 compression, but can be decompressed on the fly by the drawing routine with only a minimum of slowdown. In the same manner, sound would be compressed, stored in the CD Word RAM, and decompressed on the fly by the MD 68000 for playback through the PWM channels.
As for texture compression, might it be possible to get away with 16-color textures without looking too off? (not a fixed 16-color palette, but using optimized colors selected from the main 256 color palette for each texture)
Yeah, that's the best part of the Jaguar - the RAM.
That's my intention for the music. Especially since a lot of people here seem to detest FM music.Quote:
And offer the option for CD tracks as well I would assume. (being able to add the 3DO sound track or one of the remixes would be cool, or of course use that ambient PSX ones for those who like them)
Maybe. That would help as well. I should do some experiments on that, particularly since textures don't use close to 256 colors - the way lighting is handled in Doom is that the 256 color palette has a range of brightness levels, and a lookup table converts the value in the texture to a REAL palette index based on the brightness for the area where that texture is being drawn. That's why things further away or in shadow look darker. It's also why scenes don't look as good as you would think they should for 256 colors. You can't use all 256 colors for the best possible look since most of the palette is dedicated to shades of colors for the brightness.Quote:
As for texture compression, might it be possible to get away with 16-color textures without looking too off? (not a fixed 16-color palette, but using optimized colors selected from the main 256 color palette for each texture)
I like FM music (though with Genesis you've got the PSG in there too, and the option to use the YM2612's DAC -plus the CD PCM chip, but then it's kind of pointless with CD-DA possible -although tere are a fair number of PC releases on CD, particularly rereleases, that didn't use CD tracks in spite of having plenty of space free), 32x Doom's renditions are just terribly poor for the most part (if you go through all of them a few are pretty decent though, maybe even comperable to SB), generally a good deal poorer than the PC version's SB renditions (which aren't perfect, but certainly acceptable).
Although, some people seem to think the SB music sounds "the same" as the 32x music...