malducci
-
Content Count
339 -
Joined
-
Last visited
Posts posted by malducci
-
-
Wow.... creepy. I'll miss your avatar, though
(seriously) -
So.. you wrote a piece of fiction about Craigslist? >_> This comes off more as lame than anything else (especially since people took this as an actual event).
-
Uhm.. why? Why does this question even need an answer? I think it's pretty clear why there wasn't a second crash during the late '80s. I know some members on here are either jealous of Nintendo's success and take over the market in the US, or just didn't like the new generation/style of video games - but the large majority of people (current gen gamers) were in love with video games during NES and the 16bit era. Why would there be a "crash"? Of course, this is relative to the US. Apparently, Europe never had a crash per se. Nor Japan.
What many don't realize is that the "big" crash of 1983 was actually the second videogame crash in America. The first happened in 1977 when all the Pong consoles and stuff like the Fairchild and Odyssey systems glutted the marketplace. You had stuff like the RCA Studio II that were marked down from 179.00 down to 9.99 in the clearance bins. Nobody wanted this clearly outdated stuff when the VCS came on the scene.Yeaahh, that's not a video game crash scenario. That's called out of with the old and in with the new. And that's, well.. completely different. The phasing out of an old generation and phasing in with the new/replacement one, doesn't constitute a "crash".
It seems like their was a plethora of crappy games made for the NES by 3rd partiesIf you were actually there in that era, and experienced all these "new" games, you'd understand. It was damn exciting. New stuff was coming out all the time, and there were tons of great games. If anything, there was more crap during the last part of the 16bit generation... when US developed crap starting flooding the market again (and not so up to par EU softs too).
-
1
-
-
Post-crash 2D systems which popularized adventure/platforming and other more complex games (NES, SNES/Genesis/TG16, etc)
Usually that's split between the 3rd (7800/NES/SMS) and 4th (PCE/TG-16+CD, SNES, MD/Genesis+CD) generations due to the big graphical (and audio) difference as well as time. (like comparing an A8-bit or C64 to an Amiga)
I agree they're different generations of technology, but not different eras. The NES, Genesis, SNES all represent pretty much the same style of games, the later systems just ran them better. Not much changed between those years other than the graphics and sound getting better.
I think it really depends on your threshold point of differences. BITD, the difference in gameplay between 8bit and 16bit was pretty noticeable. I guess relative to 2600/coleco/etc to NES/SMS/later gen home computers, it is a bigger difference than 8bit to 16bit. But I don't think that lessens the differences. In the whole scope of things, it looks like a smaller difference, but BITD - it was a pretty big difference in general. Having more sprites on screen, larger enemies and bosses, really changed the gameplay mechanics IMO from 8bit to 16bit consoles (NES/SMS to Genesis/SNES/TG). Of course, there will be simplistic games to be found earlier on the Genesis and TG16 as they were the first and closest to the 8bit transition. But in general, or ignoring those, the difference was fairly large.
-
Game Gear, if you can get your hands on Gunstar Heroes port. Incredible game, so say the least. The majority of the GG library is "meh" - but there are a few decent titles. And like others have said, the screen isn't too great. I have two GGs and about 30 games. I never play it. The lynx looks interesting and I would like to try out a few games, but overall - the library won't keep me interested (at all). Zaku would probably be the only reason I'd get a lynx (never owned one, but a friend had one). For all its technical prowess, the screen is too low res and the library just sucks not to my liking.
-
Is the SNES' processor actually fast enough to freak anyone out? Or does that require a DSP?
*sluggishly freaks out*
Hahahahaha
-
and there was still a huge place for it in the budget market. (I know several people who didn't get an SNES of Genesis until the mid 90s -SNES in christmas of '96 for me- as well as those equally late to the next generations -we got an N64 in christmas of '99, and I know plenty of others who picked up other consoles -especially the PSone- quite late too, or more recently the PS2)Plenty in relative to what? I would bet these late adopters were in the very low percentile compared to the gamers that were making these companies... their money. There's also the fact that old gen hardware, in the next or even two generations later - has the unfortunate effect of being susceptible to these frugal "gamers" buying used software for cheap (instead of new and/or repackage stuff). Why buy new stuff when you can buy the same thing for a lot less money? The business model doesn't really work. Hence, why companies don't really do it. As it is, the used game market is huge even for the current generation of consoles. And add renting on top of that. No wonder companies are slowly trying to sneak in DLC. Before you know it, it will be pretty much all DLC. The whole frog in the boiling pot of water analogy.. thing.
-
The genesis 3 wasn't even released until 1998.
Yeah, but that's Majesco - right? Seems a little too desperate even for Sega for them to try and milk the Genesis for every last penny, when the N64 was out and the DC was just around the corner. Was Sega really that bad off at the time, or was it in fact just the start of Majesco? I do remember the "retro" Majesco Genesis systems hitting CompUSSR when I worked there waaaaaaayy back. IIRC, DC was already out (or maybe it had just come out, I don't remember). Anyway, I never considered anything repacked by Majesco to be Sega. Licensed or not.
-
What's most funny about that statement, is that Genesis was in production a year or two after the SNES released it's last title
The Genesis is STILL being produced to this day. Well, it's not THE Genesis, but it is still licensed by SEGA. The Firecore and Gencore are what I'm talking about.
Of course, 20-year old chipsets are not hard to emulate, which is why you get 3-way systems from ybit, or whatever the hell its name is.
I'm not counting clone systems though, and as far as Iknow, sega's not licensing any games at all....That's what I'm meaning, Frogger, 96, is the last game I'm aware of for the SNES, and I personally got several games for the genesis from 98 (and think thee were some 99's, but won't swear to that)
Real honest to goodness licensed games from Sega for the Genesis in 1998? Do you have a list?
It's not that I don't believe you, but.. what store was going to carry this new titles? It just seems absurd that any company would take the time to develop a game for the Genesis in 1998, when no stores (non! in my area) carried anything "new" for the Genesis. Used shops, sure. But new? Nope. Toys R Us had some old stock left over, but you had to "ask" for this at the counter. Once in a while you'd get discount bins, but I'm almost positive this stopped by 1997 for Genesis and SNES stuff (and it was old stock, not new developed games on shelves).
-
I doubt any did wavetable synthesis, though some may have added additional PCM channels (perhaps ADPCM), though the NES already has a dedicated 7-bit DPCM channel.
The N106 is wavetable. It's just like a GUS sound card ( a unified bank of memory and channels that point into this global memory for which sample to play. The more channels you enable, the more frequency steps you loose. And the max frequency starts dropping). It's also a very similar the Konami SCC and PCE audio chip (which are small wavetable chips). Not the frequency thing, but that you define small samples for it to playback at a specific frequency. MMC5 adds a PCM channel. Not sure what others add as far as PCM (never heard of ADPCM for NES). The DPCM channel on the NES is just 1bit deltas (signed) that accumulate the PCM sound (it's padded to 2bits though. The reason becomes apparent when you look at the frequency table). But the DPCM channel is a bit too coarse in frequency steps to be considered wavetable. And I'm not sure on the specs of the FDS extra channel. (Wavetable is kinda incorrect, it's really referred to as sample-based synth)
I'm sure some added variable pulse and not just square. (NES has variable pulse)In the NES scene, all pulse modes are referred to as square. It's not the literal sense of the meaning (50% duty cycle). It's square in the sense that it's only "on/off" (square edged pulse), as opposed to anything else (like triangle, saw, sine, or something custom).
Per: That's cool. I've would have never thought to check it out like that. Kudos
-
What I mean is actually two things. One, the classic consoles lasted a very long time and as that console's lifetime progressed, the creators of the games learned how to really get everything possible out of the console. The best examples are the Atari 2600 (1977-92) and the NES (1985-94). For both consoles there are lots of games where you really get the impression that they are REALLY pushing the console (in terms of graphics/sound/speed) with everything it's got, and perhaps uses some programming tricks to make the console do things that previously was not thought possible (especially the Atari 2600). And as an avid classic gamer/collector, I think those kind of games are quite fascinating.
Furthermore, I like how even when the next generation of consoles came out, back then the old console still hung on for a few more years. For example, the NES continued as an active console for three more years after the SNES, and the original Playstation kept going for what, six years after the PS2? You just don't see that in today's consoles; the old console has it's support dropped pretty much immediately (how many N64 games came out after the GameCube's release, and how many GameCube games came out after the Wii?), though the PS2 is still chugging along about five years after the PS3 (but clearly on it's final days). For those who do current consoles, do you ever play any games where you really feel like the console is being pushed to its limits, or do even the best looking games don't really look like it's making the console break a sweat?
Well, you have a very distinct way of looking at things
Or you put your threshold pretty far out there. PS wasn't "active" 6 years after the PS2 came out. PS was on it's last legs in 2000. Just because a couple of games a year come out for a few years, doesn't mean anything in the context of "chugging along". The NES was pretty dead before the SNES came out. A handful of titles doesn't mean squat. If you look at the system realistically, 1-2 years is the lead out time of the previous generation. This really hasn't change since the NES days. 16bit started in very late '89 in the US. By the start of 1991, the NES was pretty much dead and definitely forgotten by end of 1991. Same with SNES/Genesis and the Playstation/Saturn 32bit generation (yes, 3DO and Jag were out before, but come on - putting them in the same 32bit generation as the PS/Saturn just makes them look even that more pathetic). 360 came out in the end of 2005, PS3 end of 2006. By the end of 2007, PS2 was hurting bad. Admittedly it lasted a little big longer than expected, but I'd contribute that fact to the problems of the PS3 it had early on (priced pretty expensive, looked at best on par with 360 but mostly looking slightly worst in graphics and frame rate).I was a gamer in all of those generations. Including this one. And I wasn't an early adapter of systems either (for the most part early for 8bit and 16bit, but not for the rest).
-
That Jag looks awesome. Nice job
-
Yeah, 1megabyte of ram doesn't do much for consoles of that date. Unless you mean 1megabit (128k), which is what the snes had.
And 10,000 polygons per screen? Screen as in a single frame instance of movement? 60fps, that's 600,000 polygons a second. Hell, even at 30fps that 300k polygons a second. Pretty unrealistic. Unless you mean 10k polygons per second. But that's extremely low (333 polygons per frame as 30fps).
I like the 6309 idea. That is one badass CPU. Of course, it needs to be matched by clocked speed of around 7-8mhz and back up by at least 8k logical segments for external memory mapping. DMA doesn't have to happen at interleaved memory access. If the video system is "port" based like SNES and Genesis, then a fast DMA that stalls the CPU until finished... is just fine (it's what happens on both the SNES and Genesis).
-
I'm also sick of the Snes being thought of as an rpg-only system.
I'm sick of Genesis being thought of as a sports games and Sonic-only system.
Both of you have good points. I had a SNES and loved it growing up, but I played a lot of Genesis at a friends house during the time also, so I think both systems are very good.
Each system had it's pluses. The Genesis had a faster processor so it was better at doing action and shoot-em-ups. The SNES had superior sound and video hardware, so it featured better graphics and music.
But a great game could be made for EITHER system if the programer knew what they were doing.
The Genesis had some awsome RPG's made for it (the Phantasy Star and Shining Force games) and the SNES had some great fast paced shooting and action games for it (Gradius III, F-Zero, and Contra III)
After all, it's not the HARDWARE that determines if a system does well or not -- it's the GAMES.
the kumbaya speil fails when you list the snes port of gradius iii as 'great' and 'fast-paced'
the snes port of gradius iii is an abomination, the quintessential example of 'great graphics are more important than great gameplay'
fact is, nintendo had 2 years to come up with a system that bested the genesis in every way imaginable. they didnt
I'd say that they remedied that one sole problem with via cart addons (the way the bottom half of the logic address range is layed out/fixed - it's obvious that they planned on this idea from some point of developing the SFC).
-
16-bits is about 8-bits too many.
No problem, the 65816 is backwards compatible with the 6502, so I guess the SNES should be able to run 8-bit code too.
That is true. Actually, if you happen across the Super8, you can play NES and Famicom games on your SNES.
Some how I doubt it's using the SNES processor in 8bit mode. More like it's a mini NES packed via crappy emulation and the video (register writes and data updates) is passed onto the snes cpu to send to the sPPU (like how the wideboy works for the NES and the super gameboy works for the SNES).
-
On which system in particular?
I'm wondering how the Genesis differs from the Super Nintendo.
On the Genesis, I know you can request local to vram DMA during active display - but there are only a tiny amount of slots available during active display to write to vram, scrollram, or palette ram (which all reside inside the VDP). So I would imagine a DMA request from vblank would still try to continue on through when active display hits (it doesn't necessarily mean that, but the logic supports it. I've never tested for that). And the CPU is stalled during the DMA process (and should also be during active display DMA). There is a DMA status flag, which normally you couldn't read because the CPU would be halted during the whole DMA process, but if the DMA were somehow stalled or stopped on active display transition - I guess you could read that flag to see if the VDMA completed or not. So maybe on the Genesis, it does get halted/stalled when going into active display.
On SNES, Anomie's doc states that regular DMA will be halted when the display goes active. And if the current DMA channel is also the same HDMA channel used for active screen FX, it will be canceled out (otherwise it'll continue when the display has ended). There's no mention of the CPU being halted during active display when the DMA is temporarily halt, but the logic suggests that it would be halted/paused and the cpu would be free - except for the few cycles HDMA might take on those scanlines.
-
If slowdown is caused by the cpu running out of cycles in one frame, then why doesn't the framerate drop with the gameplay speed, instead of having sprites move by half distance per frame at 60fps?
You'd have to know your out of cycle time first, if you were going to make a setup dropped frame rate VS just slowing down. Not to mention the serious complexities of doing something like that on these old system.
-
I know there are garbage pixels on the Genesis... hence the flickering sprites to hide that in sonic games suing palette changing for water effects. Not sure about the SNES, I know there's some limitation to it, but for the window layer (the solid color layer, usually the furthest BG, but sometimes used for transparency iirc) raster bar effects seem to work fine, like the sky in Donkey Kong country, but that may have to do with the nature of the window layer too.
In general, mid-screen palette changing would be much less necessary than on the Genesis anyway due to the much greater number of subpalettes. (8 for sprites and BG opposed to 4 shared ones on the genesis -still 1/2 of what the PCE offers though, plus the PCE can modify the screen during active display)
The SNES has a Color Window. You can just update that instead of changing the palette entries mid-screen (can fade the screen down, etc). Not to mention transparency of BG layers to others and sprites. And like you said, more subpalettes means you could just change the map position to another point in a mirror section of the map that has alternate subpalette references. Lords Of Thunder does this on the PCE for the water level, for when the enemy smashes the ground and the water pours into the hole - lowering the level (which is absent on the SegaCD version).
-
However, in the context of ROM I mentioned above, there are cases where using 2.68 MHz ROM vs 3.58 MHz accessed ROM can affect slowdown if fetching data from ROM is a limiting factor.
It's doing more than fetching from ROM. 99.99999% of code is running from ROM. Thus, all instructions are slower. There's also the problem that you have to access rom in the higher banks of the SNES memory map layout. All lower rom range is still slow access regardless if you turn on the high speed (could allow you to mix fast and slow roms). Or just mirror the lower range with the higher range, though you half your normal cart space (little bit less because "all ram mode" is in the last few banks). Then you have to start using mappers and such for larger carts.
-
The PC Engine would need 139 ns (or faster) memory, right?
Correct, because it runs at 7.16mhz. I typically use 120ns rom/ram. (internal system ram is usually 120ns or 100ns - depends. Guess whatever they had on stock/hand at the time).
I'm a bit curious how Sega got away with using 150 ns PSRAM for the 68000's memory on some early model MDs with a 7.67 MHz 68k, that seems too slow. (this came up at Sega-16 a while back, though it was also mentioned that later models switched to 120 ns and then 100 ns PSRAM)The memory bus cycle of the 68k is 4 cpu cycles, not 1 like on the 65x arch. But, IIRC - you still need memory to respond in 2 cycles (unless you stall it with dtack or such). I.e. the data needs to be on the bus by the end of the second cycle. So in theory on the original 68k, you should be able to get away with memory at half the processor speed without any wait states. A look through the data sheets would say for sure though.
http://www.cpu-world.com/info/Pinouts/8088.html http://www.cpu-world.com/info/Pinouts/8086.html
The 8086 has data lines multiplexed for the 16 address lines, though on the 8088 only address lines 0-7 are multiplexed. (then there's the additional 4 segment lines) That's how they managed to fit it in a 40 pin DIP.
Heh, it is. But what are the timings? It's possible that the address setup time to the latch is less than 1/2 memory cycle or even faster. It just happens that on the 65816, they chose 1/2 memory cycle. They could have achieved it in faster time. 1/4 or 1/8, etc. Register latches were fairly fast and cheap (8bit latches easily in the 20ns range).
This made me curious as it's often noted that a major reason for IBM selecting the 8088 was due to cost not only of the chip, but associated memory. Now, if it's a similar case as the '816. that would mean the 4.77 MHz 8088 (or 8086) would require 100 ns DRAM (or slightly slower), while a similar, non-multiplexed MCU (including the 68k, obviously) at that speed would only require 200 ns DRAM (or slightly slower). Of course, they also wanted an 8-bit bus for cost reasons and the 68008 wasn't yet available -though cheaper DRAM could have been a trade-off for using a 16-bit bus. (especially since a 4 MHz 68k -or 3.58 MHz one following the 14.32 MHz clock, would still outperform the 4.77 MHz 8088/8086, while only requiring slightly faster than 280 ns DRAM) Then again, even a Z80 could be considered a better choice than the 8088 in some respects... (granted they'd have needed bank switching hardware)Like I said for the original 88/86, you'd have to look at the external memory timing charts to see what speed ram/rom is required.
-
Huh, that's something I didn't know. That goes for RAM too, right? Still, that doesn't explain why the SNES runs THAT slowly, especially since it runs at only 2.68 MHz when accessing DRAM and often ROM as well. (ROM can be either 2.68 or 3.58 -I think switching to 3.58 MHz ROM on some games contributed to reduced slowdown too) Unless they decided to go with fairly slow DRAM, like 180-200 ns (for that 2.68 MHz value), had they gone with 100 ns DRAM (which should be reasonable for 1990), I don't see why the CPU couldn't have been clocked at 4.3 or perhaps 5.37 MHz (from the 21.48 MHz master clock) -along with the variable speed bus. (for slower/cheaper ROMs) The SNES isn't even 1/2 the speed of the PC Engine or MD, and the latter had to use double the data lines for ROM as well. (granted neither of those used plain DRAM for main memory -the MD used PSRAM and the PCE used SRAM)It goes for anything on the bus. The 65816 is missing the upper address lines, so externally you only have 64k of address lines. To overcome this, the multiplexed the upper address lines on the data bus. So what would normally be 1 complete memory cycle, is now 1/2 + 1/2. 1/2 the memory cycle you take the data bus and store it in a simple register latch (external or on the die/package), then on the second 1/2 cycle you use the 16 address lines of the normal 6502 pins and the 8 from the latch to form a 24bit address line, you then read in the contents from the data bus. But the problem there in lies, you need memory to respond at 1/2 memory cycle or twice the speed of a normal memory cycle.
The 65816 on the snes is custom. It's not stock. It has another memory layout ontop of the existing memory layout/system. It facilitates somethings, and hinders performance in other situations. You use long addressing more often. Anyway, if the cart itself had ram mapped to second half of the external address range - you could turn on the CPU to 3.58mhz mode and access that ram at full speed. But that still doesn't fix the whole DP (re-termed from ZP) address range. It's still going to get a penalty since it's in original ram. DP are the 65x address registers.
But anyway, a 3.58mhz 65816 requires a little faster than 139ns memory. A 65xx at 3.58mhz only requires a little faster than 279ns memory.
Hmm, did the 8086/8088 have that same problem?The original x86/x88 had so many other problems - this would be the least of them. Instruction times are incredibly slow. But I don't remember it having a multiplexed address bus (it has a bank system, but that's different). Other MCU types do though, but are like that for small pin package format.
They could have gone with a faster 65C02 derivative and implemented a bankswitching scheme to extend the address bus, either with external logic or integrated in a custom CPU package. (I believe did that for the PC-engine, with a 21-bit address) At very least they should have allowed separate ROM/RAM bank selection rather than having to treat ROM as secondary storage, not directly accessible by the CPU. (I assume due to the original intention of the console being cassette based)Internally or externally handled, I don't think it doesn't makes a that big of a different. Only that the mechanism/system exists. On the PCE, you're saved the trouble of having to write to a memory mapped port in the cpu's logic address range. The registers are on the CPU itself, and you you can transfer between Acc and the MPR (8k page register) like you would the SP(stack pointer) and X register. It's convenient and a little faster, but you're not swapping memory in and out for single bytes fetches and such. So the over head is tiny to non existent in most cases. Hardwiring writes to right before the int vector range for MMU external regs would be just as good. You only need 8 bytes for eight 8k pages.
IIRC the 65C02 family didn't get some of the enhancements of the '816 which facilitated more efficient use of high-level languages like C, though that wouldn't have been too much of a problem with the Lynx existing in a time where games were programmed primarily in assembly language. (it wasn't until the next generation that coding in C became a major factor for game consoles)There are two 65C02's. The original ones WDC put out are missing some instructions. Rockwell later added a few bit set/clear, bit logic against address, and bit test branch. WDC adopted these sometime after and made them official. So you could say there's a ver1.0 and ver 1.1 of the C02. These never made it into the 65816 line. The PC-Engine's 65x variant is based on Rockwells design, but adds more instructions, dma/block transfer instructions of the 65816, and internal registers for mapping in external memory (21 external address range like you said). The PCE HuC6280 also has the beginning of branch relative addressing (for JSR and for JMP), but they limited the operands to 8bit. The 65CE02 extends them to full 16bit which makes them more useful, but this is more computer related coding (you write completely relative based code that can be loaded anywhere in ram) There's also nothing stopping them from making long addressing modes like on the 65816. It just takes one more operand byte for the 3 byte of the PC. About C? Two things really help the 65816 in C. 1) long addressing(indirect, direct, indirect+indexed, direct+indexed). This REALLY speeds up things up for pointers. 16bit index registers VS 8bit ones definitely effects speed too on the C compiler generated code. 2) Stack relative addressing. C is built on passing arguments on the stack and the '816 added SP+index mode just for retrieving this. The 65CE02 has stack relative addressing too. Though, I have to say the second part could be simulated easily in pseudo stacks just fine (and is).
-
I like the idea of consolized Atari Lynx.
Handheld Atari Lynx specs-
cpu: 3.58Mhz 6502
resolution: 160x104
colors: 16 out of 4096
ram: 16 kB
Console Atari Lynx specs-
cpu: 3.58Mhz 65816
resolution: 256x224
colors: 256 out of 32876
ram: 128 kB
You realize that the '816 requires twice the ROM/RAM speed as the 65c02 even though both are 3.5mhz, right? It has a multiplexed address and is the stupidest thing ever (that they didn't release a full pin package version without the over head and need for faster rom). It's one of the reasons why the SNES cpu runs as slow as it does. ROM speed costs.
I would personally take Rockwell's R65C02 (over the plain 'c02) at twice the speed (7.159mhz) than that regular ol' '816 at half speed. You could even add onto Rockwell's design like Hudson did (and mitsubishi did). The 65CE02 or clone of would have been an excellent choice too.
-
-
Did the 32x really have nothing for you though, or did you just never try the games that you might like? Again, unless you don't care for splace/flight combat games or shooters, or have an unnecessary aversion to untextured polygons, you should like Shadow Squadron at least. Temp's worth checking out, perhaps Chaotix or Kolibri. T-Mek, perhaps Metal Head, and After Burner Complete and Space Harrier are excellent conversions. (probably second only to the Saturn Ages releases -which I'm not sure even made it to the US) You've probably already tried Virtua Racing and Virtua Fighter, so no need to go there. (I'm not really partial to fighting games, but I do like Virtua racing, though I even like the Genesis Version of VR for that matter)
I think there are a couple others I'm overlooking too.
Anybody who says the 32X library's crap obviously haven't played many games for the system. There are 31 cart releases, compare these numbers to my recommended list. Yes it includes already mentioned games:
After Burner Complete
Blackthorne
Doom
Golf Magazine Presents 36 Great Holes Starring Fred Couples
Knuckles' Chaotix
Kolibri
Metal Head
Mortal Kombat II
NBA Jam Tournament Edition
Pitfall: The Mayan Adventure
Shadow Squadron
Space Harrier
Spiderman: Web of Fire
Star Wars Arcade
T-Mek
Tempo
Virtua Fighter
Virtua Racing Deluxe
Zaxxon's Motherbase 2000
These are all legitimately good games. Some may have some faults or carry the shame of being Genesis upgrades, but they aren't outright bad. That's 19 out of 31 cart releases. That means more than half the 32X library is worth owning. Try saying that about the Virtual Boy, or ANY console for that matter.
Yeah, nothing on that list interests me though. So that's 0 out of 31 for me
SH and AB were "OK", BITD - but I didn't even play them on the Genesis when they were new. Not even when they there were in the $5 bins and I was bin hunting in the late day of the Genesis.Did the 32x really have nothing for you though, or did you just never try the games that you might like? Again, unless you don't care for splace/flight combat games or shooters, or have an unnecessary aversion to untextured polygons, you should like Shadow Squadron at least. Temp's worth checking out, perhaps Chaotix or Kolibri. T-Mek, perhaps Metal Head, and After Burner Complete and Space Harrier are excellent conversions. (probably second only to the Saturn Ages releases -which I'm not sure even made it to the US) You've probably already tried Virtua Racing and Virtua Fighter, so no need to go there. (I'm not really partial to fighting games, but I do like Virtua racing, though I even like the Genesis Version of VR for that matter)I think there are a couple others I'm overlooking too.
No, I went through the whole library with emulation. Nothing I cared for (and couldn't stand Metal Head). I own a 32x (because it came free with one of the Genesis' I bought), but I have (IIRC) no games for it. I really dislike all virtual fighter games/series (Tekken 1 BITD was badass, VF was just crap). VR has no appeal to me. Doom was a poor port of a fun game that I already had on the PC (and which I quickly grew tired of. Doom 2 was boring). I don't care for any of the other games either. Back then, I felt extreme about this. Nowadays, I'd picked up SH, AB, and Tempo. That's about it. And Tempo "only" for the sole reason that it was developed by Red Company. I think there could have been quite a few gems on it, but just never happened IMO. And for the record, the only "gems" I live on the SegaCD are the japanese ports. I can't stand the EU and US dev'd softs on it. Probably why I don't like anything on the CD-i, 3DO, CD32, Jag. Sorry.
In comparison, Genesis is awesome with lots of great games. SNES too. SegaCD offers a handful of gems, but by comparison to the Genesis library - you're not missing a much if you go by ratio. And 32x, IMO pretty much nothing at all.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
What are all the non-games released for video game consoles?
in Classic Console Discussion
Posted
Magical Dinosaur Tour for TGCD