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.