This:
http://www.youtube.com/watch?v=y-7dT2c_bX4
Printable View
Man, I LOVED this game at the arcades! It even looks like a 32x game! Who do we have to kill to make this happen? :D
I agree, it looks like it could be an easy adaptation for somebody with the know-how.
-edit-
I also think the Master System, using the Zaxxon 3D style engine, could easily handle the levels and gameplay of this one.
I've played this on the original xbox mame emulator. Alot of fun!
This game was also made 12 years before the 32x....
The game itself is near impossible to find in arcade form these days even, they only made about 1,500 units.
1500 units is probably why this is the first time I've seen it.
Aladdin's Castle near me had one and I pumped a lot of quarters into it. One of my favorite arcade games of all time. Now, if someone would only port it to 32X....
This could easily be pulled off on the 32X!
I checked the info on the game: a 6809 for the main cpu for the game logic, a custom 2901 bit-slice math engine for the polygon drawing, and four pokeys for the audio. Very interesting system... and rather hard to keep working from reports. :)
With some effort it can be pulled to plain Genesis too
Enough with the "cans", who can we get to "do"? ;)
I, Robot is still an extremely impressive game for it's time. I never knew it ran that smoothly. I thought it chugged along at something like 15fps... Sometimes it's good to be wrong I guess. :)
letīs try to put it on plain genesis, then 32x
I came here expecting to see something like Final Fantasy VII or something more powerful as a perfect game for 32X.
I still think the 32x could have easily pulled off Alone in the Dark 1
Castlevania Syphony of the night...that coulda been done on 32x surely? just the right blend of 2d and 3d.
With a lot of cuts in sound and animation/graphics perhaps... remember you have ROM limits to work with, even using decompression on the fly to expand on that. (and anything falling back on the Genesis's layer would need to cater to the color limitations)
With the CD you could fit the entire game more easily, but have to cut down on animation/graphics/sound more on a per-level basis and you could have CD-DA music of course (only cut-down PCM sound effects), plus you could have a bit more resource for handling decompression and such (but bottlenecked by the Genesis's CPU bus bandwidth and everything has to pass through that to get to the 32x).
If you segmented the levels with midpoints where the game paused to load more, that could probably address some of the RAM limits. (at the expense of more frequent loading)
I'd say for the 32x to truly show off it's 32bit ablities, most of it's best late-generation titles would have to be CD titles, I simply cannot imagine cartridge titles being the primary media.
Virtua fighter?
I am fairly confident that SOTN started on the SNES and moved to the PS1. It just seems too similar graphics wise to the 16-bit games. The shared SNES tracks helps the theory as well.
As to Rondo of Blood needing massive cuts on a 32X cart. It all depends on whether they converted all of the music to samples like they did with the SNES Drac X, or used memory hogging tiles instead of the originals, added new graphics and effects, or tried to maintain the full voice acting cutscenes (completely unnecessary).
I would very much like to see a 32X upgrade of Elite.
Probably more like the DOS version:
http://www.youtube.com/watch?v=bjoMq-H3b8o
The DOS game also supported general midi and MT-32 sound.
And remember Elite II only came out in 1993, so it would only have been about a year old when the 32x was released. ;)
However, it's a very complex and involved game, not really good for console gaming as such. (if some of the PC graphic adventures ended up niche, I'd hate to think what a game like Elite would have done :p)
Starfighter from the Archimedes (and 3DO -crap Saturn port) would have been interesting though.
X-Wing would have been far more realistic for the 32x in terms of a mainstream game and with some cuts it probably could have made it in a similar fashion as the Floppy Disk version, but that's still not really mainstream console gaming as such (albeit no less so than Wing Commander) and the 6-button bad would be a tight fit for all the commands needed.
Especially if they managed some actually good use of the YM2612 and possibly one-upped the OPL3 rendition of the tracks on the CD-ROM release.
Perhaps more like:
http://www.youtube.com/watch?v=jqiNyCB9qCo
http://www.youtube.com/watch?v=QiYOj53J6Ks
Actually an update to the x68000 star wars game would have been interesting on the 32x too. (sort of an evolution of the Atari Arcade game)
Hell, or maybe an interesting game to port to the Genesis itself more in the form of the original x68000. ;)
A 32x version would have to have graphics cut way back to fit into ROM practically and a 32x CD version would have other compromises related to fitting into RAM per load.
The PSX has mass storage and a LOT of RAM to work with and the main RAM as auxiliary graphics storage. (so not just video RAM, which wouldn't be too far from what the MCD has to offer if fully dedicated to graphics storage) And you'd almost definitely want to manage a software renderer using indexed 16 color textures with look up tables to save space. (albeit that's almost definitely what the PSX version already does) If you want to maximize rendering speed you'll also have to render into SDRAM and eat up some of the already limited space. (the framebuffers are slow and it's a good deal faster to render in SDRAM and then copy the final result to the framebuffer in many cases -especially with more than one layer being rendered)
Compressing all graphics would help as well, but that will only go so far even if CPU resource isn't an issue. (and then you start getting into lossy compression which may or may not even be useful -sometimes ratios are lower than losless at decent quality- and it might be preferable to specifically use graphics that compress better using lossless techniques) Storing all graphics on the MCD compressed (and audio) would help as well.
So less animation, less background detail, etc, etc. And not to mention the hit to audio it would take. (SFX and music) Excluding a CD32x release, of course. With DMA mixing and some good compression, you probably could get some pretty good sound though, but that's assuming they got the docs out for the DMA.
But the only way you'd avoid massive cuts to such a game is if it was barely taking advantage of the newer hardware of the PSX/Saturn, which I don't think is the case.
I also wouldn't be definitive about it starting life as an SNES game... though if it runs in the PSX's 256 wide mode that would be an indication (same res as SNES in the case of graphics aready being worked on for the SNES), but there's far more animation than would be likely on the SNES, even if it was a 1996 game.
I agree, SOTN on the 32X and definitely on the SNES would have taken a hit in the animation department. The SNES game wouldn't have had as much background scrolling as the PS1 game even if it did manage to have all of the same details.
Actually, the 32X game might have had trouble with this too unless backgrounds were ground up designed to use the Genesis layers and a custom background layer engine was made that could actually run on the SH2s. Isn't Kolibri the only existing 32X side scroller to even use the 32X for a background layer?
Either way, I would assume that the game would look more on par with Super Metroid rather than the PS1 release. Of course the tile based 2D would save quite a bit or ROM in comparison to the PS1 game.
Hot dang, I finally found the first person space ship shooter I remember.
SPACE LORDS!
In the scenes where you have a lot of small detail in the BG, or in the into cutscene with the many tree layers, much of that could be supplemented by sprites on the SNES, on top of using BGs. (and you'd almost certainly be using mode 1 to get that extra 4-color tile layer that games like DKC and Earthworm Jim 2 used -and some others used for basic stuff like the status bar rather than wasting sprites -SFII does that)
Atari corp should have licensed that (and several other Atari Ggames/TWI games) for the Jaguar given the fairly favorable relationship they seemed to be in by 1993 (after the Jag hype set in)... far too few games showing the massive scaling prowess of the Jag (Super Burnout being one of the best examples), let alone perhaps some Sega licenses in 1994 after the settlement in favor of Atari Corp.
And side from the scaling games there were some of the AGames polygonal games that ACorp had already licensed for the ST or Lynx (like Hard Drivin', Steel Talons, and especially Stunn Runner -a Race Drivin' update with some nice added scaling sprites and gouraud shading would be nice -sort of like what the Saturn did but less/none of the texture mapping)
Looking at the specs for Space Lords and T-Mek I'm not sure why both didn't come out on 32X.
the system didnt live enough.... if Sega gave it more years, im sure a few 3d gems should been release...
Naw, the 32X's mere existence causes journalists' heads to explode to this day. Even though the engineering is sound, the launch games are more good than bad, and the add-on sold out at launch, it looks like a 'shroom and caused Michael Jackson to stop making good music.
A lot of those types of games could also have been on the MCD, again with color limitations and other trade-offs, but tons of scaling arcade games that could have been pushed there.
And of course note that the CPU resource is not the big part of those arcade machines (ie the 14 Mhz 68EC020), but the custom scaling hardware. (just as with Sega's scaling boards where CPU resource was not directly tied to scaling performance -not sure why they needed the multiple CPUs on some boards but it might have had something to do with management of the custom chips or sorting priority with massive numbers of objects on-screen -ie Z-sorting the sprites)
No... the engineering is very bare bones, though not bad given the less than 6 month development window. They could have done a lot better for a similar price point with more time/resources. (even the Sega CD has a fully asynchonous interface with system and memory clocked independently from the MD... the framebuffers could have been at 12.5 MHz like the MCD word RAM if that was the case, let alone the potential to consolidate memory more in general and use a highly integrated VDP with more hardware acceleration and buffering to efficiently allow the SH2 and video RAM to be in one shared block -more like the jaguar for example)
But tying all that to the MD is still inefficient compared to a discrete backwards compatible system, let alone a system not tied down to backwards compatibility. (the Saturn wasn't, but it had the wrong design philosophy, the Jaguar had the right philosophy in cost/performance terms but not the resources to push it to market and more delays due to funding limits -and actually too low of a cost limit given Atari's aim to sell it at $150 and also having to sell at a profit -though technically after R&D and advertizing costs they didn't break even by the time it was canceled -but it did buy them the necessary time to win some substantial litigation and end Atair Corp on an economically positive note)
The Jaguar was almost 3 years in the making when solidified for production (dev units went out at the end of 1992 I believe, but there were still tweaks to the final production versions -same with the 32x and some others -hence the broken PWM on dev units) and there were still some bugs (exacerbated by the super low-cost implementation -in hindsight there were desirable trade-offs that could have still met a similar price point but other companies could have met that price point without stripping so much out -selling at or just below cost whereas Atari had to sell above cost) and all that was alongside very restriscted funding and an engineering team basically limited to 2 guys (2 of the 3 engineers who designed the Flare 1/Multisystem chipset) albeit with a rather high risk of failure given how big of a project they'd bitten off. (with the TOM chip they created the largest ASIC ever produced by a 3rd party -non foundry- and targeted a .5 micron manufacturing process when the industry standard was 1 micron -which is what the 3DO used- and even the SH2 was done in .8 micron as was the Pentium released in '93 while the Power PC 601 was .6 micron as was the 1993 R4200, in 1994 you saw some advanced CPUs starting to use .5 micron like the PPC 603 and 604 and some Alpha chips as well as the SH4)
They wouldn't have to go through anything that elaborate though, Sega had plenty of shortcuts to take with such with existing hardware to build on as long as they tied the necessary documentation and engineers together to support it. (you had the SSP1601 already licensed and implemented in the SVP ASIC, you had the ASIC in the MCD, the Ricoh cound chip -also licensed I believe, and for RAM they might have wanted to focus on the 80 ns 512 kB and 128 kB DRAM chips they were already stocking for the MCD and SVP -the framebuffers in the 32x did used those but clocked down to only 7.67 MHz rather than the 12.5 MHz rated speed used in the MCD -again, using that alone without extensive buffering, it could have been really nice if they took the CD ASIC, modified it to work with 8-bit or maybe even 16-bit packed pixels easily, added the SSP-1601 as well as a bitmap display controller somewhat like the 32x -though you wouldn't need the fill function or RLE mode- and use 2 512 kB DRAM chips on a 32-bit bus with 1 SH2 -to save cost and board space- and the 128 kB framebuffers all at full speed -probably clock the SH2 down to 25 MHz to match the rest- and maybe even integrate the Ricoh sound chip in the ASIC and if possible, rather than adding dedicated wave RAM add a DMA interface to allow ROM and system RAM to be used for PCM)
Not and quick and dirty as the 32x (and requiring engineering staff and documentation tied to the MCD and SVP), but far more cost effective ans still should have been reasonable to put together in a relatively short time. (if they did it that way, hypothetically they could have made a fully backwards compatible system based on that rather than the Saturn and configured it to switch between different modes and omit all redundant hardware, but that would be tight to manage if they wanted to make the MD+32x+CD forewards compatible as you'd have to still match some of the bottlenecks like the CD data having to pass through the MD section and some other snags like that)
So we're back to a standalone backwards compatible system being more efficient. ;) (in which case you could go the dual MD VDP route rather than MD VDP+Super VDP framebuffer -the latter option would probably be preferred if you were more interested in 3D and highcolor rendering while the former option would limit to 256 color 3D max -maybe highcolor/truecolor alpha effects- while being much more balanced in 2D -either being far cheaper than the Saturn even if configured with similar amounts of RAM)
In any case, that's the sort of project that should have been possible if the Mars/32x design had started in mid 1993 rather than early 1994. (though if they organized it quickly enough they probably could have had it out sooner than the 32x in that context)
And technically speaking, with the enhanced ASIC AND the SSP-1601 (SVP) used, even a plain 12.5 MHz 68k (or 16.67 MHz even -also a direct division of 50 MHz) could be good enough for managing the game engine and such (especially alongside the MD 68k), though the SH2 would be nice due to its cache and fast accessing to maximize shared bus efficiency. (something the SH1 also lacks and could be very important if texture memory was shared with the CPU -I wonder if that's a bottleneck on the MCD like it is with the Jaguar and 3DO)
These games and System 32 based games would have been severely limited on the Sega CD in color, objects on screen and/or framerate. I love the Sega CD like nobody's business, and I would have loved to have seen an adaptation of Space Lords and T-Mek, but the 32X just was better suited for that kind of thing. Granted, a random awesome developer could prove me wrong any day now, but the libraries just don't support the theory.
Bare bones should not equate to bad engineering, especially if we're going to launch into a hypothetical alternative discussion. I still really don't see the appeal for a cart based stand alone Saturn console. Even paying $160 for a 32X, it still had a lot of appeal for finally making the Genesis into something that could adapt Model 1 and earlier Sega Arcade games very well.
Are you fixated on the Jaguar? Is that why you keep coming back to this? Atari had a different position in that they had no residual hardware on the market with the Jaguar, so a brand new system launch looked more than acceptable. Genesis owners, which were a huge market at the time especially in the US, just would have been more inclined to buy an add-on rather than start all over.
I can see it both ways, but with a Genesis and Sega CD already at home, I just would not have considered a "half way" Saturn console at the time. Of course, kick ass games can make me buy almost anything.
Indeed, space lords seems a fun game. I like the pace of it. But i think 32x could have better use, if more perfect coin up conversions were done, making 32x the arcade machine on home! All system-16 can fit perfectly on 32x, right? And surely a few system-32...
From what I can tell from After Burner and Space Harrier, the 32X could handle emulating System 16 and Space Harrier hardware games. T-Mek is obviously an adaptation, but given the rush for launch it turned out quite well. Since the Saturn didn't handle Gale Racer all that well, I'd say System 32 games getting a 1:1 conversion is a bit out of reality. Then again, it's all about how much time and resources was spent on the conversion.