Printable View
I hear you.
Twisted Metal is my favorite car game.
The first one specifically.
I thought it was so cool we could get a cockpit view, and they put so much thought into them.
Then TM2 comes out...no cockpit view.
Terrible.
Also those live action sequences that were deleted from TM1 were awesome, and would have made the game solidly better than all the rest to me.
Intresting that you mention this, I'm not sure, but I think metal Head might actually use raycasting for the environment, with polygon models just used for objects, vehicles, and enemies. (all the buildings seem to be arranged at right angles as well, with flat ground, so more like Wolf3D or AvP on the Jaguar than Doom or even Gloom -which has a fixed hight lke the former two, but walls that can be positioned outside of right angles)Quote:
Originally Posted by Dirt Ball Gamer
That siad, a raycasting based racing game could be cool, and to the average games would still probably look like "true" 3D.
Hmm, has anyone ever made a racing game based on the Doom engine?
I still say Doom 32X should be finished and someone who knows how to work with YM2413 soundchips could give the ungodly music a facelift (maybe even conforming to the unique Genesis style). Using the 32X Doom engine it should be possible (albeit extremely time consuming) to do Doom II and Final Doom for 32X.
Some fresh, original ideas:
1. "32X Trivia Whiz"-- The text could rendered with polygons, so if you find a question confusing, you can look at it from a new perspective.
2. "Warehouse Pilot"--This was a game I originally thought would work well for the Super FX chip. It involves flying around a very large room full of brown cubes, taking inventory.
3. "SNES NCAA Basketball: The Spectator Sport"--This would be an upgrade to the original scaling/rotating SNES game, but with the "levitating court in blue infinity" given a reasonable, non-blue crowd.
4. Virtua Hamster: San Francisco Edition
Err - I never said I wasn't going to work on it. It's on the list right after the CD version of Wolf32X.Quote:
Originally Posted by Honey the Cat
And you're going to base it on one of the more modern sourse ports, right? Not anything to do with the original 32x port.
And honey, the Genesis doesn't have a YM2413, that's in the Japanese Master System, the Genesis uses a YM2612. ;) I seem to recall that TmEE mentioned part of the poor quality was using the GEMS sound engine, but that can't be the only reason, as even GEMS can sound decent when used properly (though ofen simple/bland, like common Adlib/SB compositions, but sever games still made it sound pretty good), and some of EA's own sound engines tended to sound worse, but Doom was just butchered. (I mean the in-game music in Sewer Shark is better)
Well some of the music was passible, closer to the PC SB rendition (which are perfectly acceptable, though could be better), but a lot (especially E1M1) sounded awful, you'd think they'd have at least made the 2st level sound better for first impressions. ;)
I've been looking over PrBoom+ to see if I can't keep some of the features compared to a plain Doom. Nothing like OpenGL rendering, obviously.Quote:
Originally Posted by kool kitty89
Are there any modern ports that have been optimized to be more suitable for something like the 32x? (like for cell phones or something likt that)
No. Even the most primitive cell phone is miles ahead of the 32X. Even the some of the oldest PDAs at least have more memory, which is the primary limitation on the 32X. All modern ports at least assume more memory. Most assume a much more powerful CPU. Many assume infinite resources and power (relatively speaking).Quote:
Originally Posted by kool kitty89
My idea was to simply finish E2 of the 32X doom and add E3 and maybe E4. Maybe it's been done though I don't know.
The original 32x version doesn't have sourse openly available, does it?
No. But the Jaguar version which WAS released has the 32X ties in it. What's missing is the 32X specific files. For example, you can see where the 32X version disables the directions a bad guy can face. So the Jaguar and 32X versions use a common code base, but have different system specific files, and the 32X has some functionality disabled (to save space in the cart). I should look over that again... maybe it's possible to recreate the missing parts to have the original project.Quote:
Originally Posted by kool kitty89
The Jaguar port does have some key things missing compared to the PC version (namely altered/missing textures, and some modification to levels) that transfers over to most contemporary console ports. (32x, PSX/Saturn, and 3DO, SNES being an original port)
Hey, that's a thought, the GBA is limited to 256 kB of work RAM as well, and they managed to pack a lot more of the game into it than the 32x version, but again, probably no free sourse, but that version is supposedly the most direct conversion of the original Jaguar port, so at least it shows that it's possible. (and that might indeed be a good starting point) I don't remember if they included 8-sided sprites in the GBA version.
The Jag version uses a lot of 68k C code, right, with RISC done in assembler? So might it be possible to move the 68k stuff over to the Genesis CPU and working on adapting the rest for the 32x side (plus the audio), or is the 68k's work RAM too limited for what was used in the Jaguar version?
Its "Source" not Sourse.
Just felt like pointing that out.
From the FAQ: http://www.gamefaqs.com/console/snes/file/588285/1774Quote:
Originally Posted by kool kitty89
10. NINTENDO GAME BOY ADVANCE DOOM
==================================
o A Nintendo Game Boy Advance, model AGB-001, and a Nintendo Game Boy Advance
SP, model AGS-001, were used as test systems for the GBA Doom game described
in this document. For testing multiplayer games, these system were connected
to identical systems via one or more Nintendo Game Boy Advance Game Link
cables (model AGB-005).
o Pros: The Game Boy Advance has a built-in screen, battery pack and link port,
making GBA Doom more portable than any desktop-PC or console Doom 1 game.
Multiplayer link ability, allowing 2 players in Cooperative games, and 2 to 4
players in Deathmatch games. Includes 8 Deathmatch-only bonus maps not found
in other commercial Doom games. Some flaws have been corrected in some maps
which were copied from earlier console Doom games. Games in progress may be
saved to any of 4 save-game slots in the Doom Game Pak, and save-game data
includes controller, lighting and audio settings. 2 lighting-style choices,
"Dynamic" (normal), and "Static" (low light levels are increased, and lights
that normally flash are always on). 6-level "Brightness" adjustment option
(somewhat similar to the "Gamma Correction" feature in the PC Doom games),
which controls the maximum brightness of both Dynamic and Static lighting
modes. Includes an "Autorun" option (player always runs). In the status
bar, current ammo levels and ammo limits are always displayed for all weapons
(in most other console Doom games, only the currently selected weapon can
have an ammo level displayed). Some controller customizing allowed (any of 6
preset button configurations may be selected).
o Cons: The original Game Boy Advance does not have any built-in lighting for
its screen, which means that GBA Doom can be difficult to view unless the
right amount of external light is hitting the screen at the right angle at
all times (a later model of the GBA, the GBA SP, does have built-in screen
lighting). Saved games may occasionally become corrupted, and fail to reload
correctly. Cooperative games have a 2-player limit, even when 3 or more GBAs
are linked. This game uses a slightly modified version of the Jaguar Doom
mapset (most of the maps in Atari Jaguar Doom are edited/simplified versions
of the original PC Doom maps), and includes no other single-player maps. The
player character can potentially become trapped behind a wall or barrier on
certain maps. Only 7 monster types in the game (tying with the Jaguar and
Sega 32X games for least variety). No Spectre Demon. No Cyberdemon or
Spider Mastermind monsters. No Blur Artifacts. No light-amplification
visors. No crushing ceilings. Weapons are cyclic-access only. In some of
the preset button configurations weapon-swapping can be awkward, and weapon
changes can occur unintentionally when performing certain maneuvers. Some
rooms in some map levels are inaccessible. The sound effect used to indicate
a player taking damage is also mistakenly used whenever a player lands unhurt
after falling a short distance. Frag counts for players in Deathmatch games
are only displayed in the Automap view. No tally screen is displayed, and no
opportunity to save the game is given, when a player goes through the exit to
the "MILITARY BASE" map level.
There's no such thing as 68k C code. There's 68k assembly, and then there's C. Anywho, the Jaguar code is mostly C with a smidgen of 68k assembly, while most of the rendering code was altered to assembly for their object processor (which, by the way, looks an AWFUL lot like 68k assembly... I think the "RISC" processor in the Jaguar is just a simplified 68000 with custom commands for drawing).Quote:
The Jag version uses a lot of 68k C code, right, with RISC done in assembler? So might it be possible to move the 68k stuff over to the Genesis CPU and working on adapting the rest for the 32x side (plus the audio), or is the 68k's work RAM too limited for what was used in the Jaguar version?
I'm not positive since we don't have the 32X files, but I think the game code runs on one SH2 while the rendering is done on the other SH2. It might be they ran the game code on the 68000 - it is a simplified version after all, it might fit in the 68000 Work RAM (remember that all the data is in the rom, only variables like the player status and object lists would be in RAM). Like I said, I need to go back through the Jaguar code to see if I can find more hints about how they did it.
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.
Without the CD, the MD 68000 is only 7.7 MHz, and only has 64KB of Work RAM (the SCD 68k has 512 KB), so you can see that running the game logic on the 68000 for the MD version would be slower, and you'd have to really watch the RAM usage. Another issue with running the game code on the 68000 would be that it would be running from the ROM, and while the 68000 is using the ROM, the SH2s cannot. So running code on the 68000 from the ROM would slow down any rendering by the SH2 fetching gfx data from the ROM, again slowing the game. Wolf32X copies a small code loop into the 68000 Work RAM that the 68000 runs so that it isn't constantly accessing the ROM. That allows the SH2s almost free access to the ROM, making Wolf32X faster.
So you can see the trade offs for various ways of running Doom on different platforms.
How about Samurai Shodown 2, 3 ,4 or 5 on the 32X
great idea do you have the source code? :PQuote:
Originally Posted by KnightWarrior
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
Yeah, I like Heretic better as well. Once I get Doom done, Heretic shouldn't be too hard to make using the same procedure.Quote:
Originally Posted by TmEE
I doubt the code is available for it but it would've been interesting to see the 32X with Neo ports.Quote:
Originally Posted by KnightWarrior
That would be truly awesome, and I would pay handsomely for it on a cart!Quote:
Originally Posted by Chilly Willy
I just meant all the stuff done in C was for 68k, referring to this previous discussion:Quote:
Originally Posted by Chilly Willy
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)Quote:
Originally Posted by Chilly Willy
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. :)Quote:
Originally Posted by kool kitty89
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.
Hell no! You can't compress video 3:1 or 4:1 losslessly. You're lucky to get 20% on lossless anything except for text. That's where the experimenting comes in - looking at the various methods to see which one is acceptable give the way Doom draws the graphics.Quote:
Originally Posted by matteus
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. :)Quote:
Originally Posted by Chilly Willy
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.Quote:
Originally Posted by kool kitty89
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...
You could use the XTDoom MP3's for the CD music. They're more faithful to the original DooM.
Well, it depends on the SB... the 32X is nearly identical to the AdLib and original SB and SB16. It's only once you reach the AWE series and wavetable synthesis replaced FM chips that you start to do better. The GUS would also sound better as it too used wavetable synthesis with actual instrument samples.Quote:
Originally Posted by kool kitty89
I'm comparing it to the SB-16 emulation in DOSBox and VDMSound (granted those lack the poor analog component issues the real SB had, though some later compatibles were better as seen in TmEE's comparison, I remember whatever SB-16 compatible card we had in my win95 PC sounded pretty darn clear for X-Wing)
I often play Doom in DOSbox set to SB-16 for music for fun, and almost always for X-Wing (they did a really good job with the composition in the 1994 CD Collector's edition, improved over the music used in the floppy release for sure, and I generally prefer it to general midi -or at least my PC's generic general midi)
The quality of th emusic in 32x is intolerable at points, E1M1 in particular is rather painful to listen to.
Maybe something is wrong with the sound in your SEGA. E1M1 sounds good to me, and that even comparing it to new source ports using sampled instruments. :D
I don't have my 32x yet (I hope to be getting one from my uncle when finds it along with his Master System), I've only heard it in Fusion, and youtube recordings, like these:
http://www.youtube.com/watch?v=2UhGo7P7Q0U
http://www.youtube.com/watch?v=AhxdAhC2sFI
Not soure how accurate that sound blaster live is, but this is what I'm used to hearing in dosbox:
http://www.youtube.com/watch?v=yr-lQZzevwA
That overly loud bass beat in 32x starting at ~0:17 is probably the worst part, otherwise the instruments still sound a bit off.
a bunch more examples here: http://sega-16.com/forum/showthread....ght=doom+music
Oh, and here's the Xbox doom classic version (bonus in Doom 3), incuded as that general midi sounds more or less identical to that of my old Athlon XP PC's onboard sound and my current laptop's as well.
http://www.youtube.com/watch?v=ofdtXKNdZd4
Okay, it's not identical, but it still doesn't sound like crap. It just has less treble and more base.Quote:
Originally Posted by kool kitty89
Anywho, it won't matter on my conversion - you'll just use whatever you want. :D
So you're not going to even attempt a cart version, just the CD one? (I guess that would make sense given that there's already a cart version)
I might... I want to work on the CD version first since it would be the best. Another issue with a cart version would be trying to fit it all on a cart. I'd really have to use the full 64 Mb of the MD-Pro 64. The only other choice would be to generate a cart image for each level and rely on the save game to let the user continue the game.Quote:
Originally Posted by kool kitty89
Glad to hear you've gone with the CD version! It makes things that bit more interesting seeing as there were only 4 32x cd games all of which were crappy FMV ports.
Out of interest what kind of open source games would be perfect for this setup?
Are we talking Open Source Dos games of the 256 colour EGA/VGA era?
Would Beneath a Steel Sky be possible?
Hey, there's an open sourse version of Jazz Jackribbit now too, not sure how well the 32x would handel it though. (if you were going to do it all on the 32x and not convert anything to be done by the Genesis VDP) Also not sure how openjaz compares to the original DOS version, but it looks liek the original had the same minimum system requirements as Doom. (33 MHz 386, 4 MB of RAM, VGA)