Super Nintendo and Wii U were Nintendo's best consoles. Iconic.
Jury's still out on Switch but barring any missteps it's coming for that #1 spot.
Jury's still out on Switch but barring any missteps it's coming for that #1 spot.
True, yesterday I tried Lost Levels. I got to world 2, people say it's crazy difficult but I found myself struggling with the controls and not the levels themselves.NES games are unplayable.
Super Nintendo still holds up as one of if not the best console of all time
I was super impressed with those Dragonfly screens back then. I was just looking at that issue a couple days ago when I made a thread about the NA TG16 and Genesis launch era.
Scaldingly bad take, there was a ton of variety on SNES.SNES barely even registers for me since I'm not super into JRPGs or Mario (and even then, the NES's Mario games were better than the SNES's).
The PS1 was a really underrated 2D console.I don't really think it's much of an opinion thing.
We can even focus on the games with 2D sprites like Symphony of the Night, Breath of Fire 3 and 4, Final Fantasy Tactics, the arcade game ports of the Namco Museum series, the Capcom Generations games, Alundra, Lunar 1 and 2, Grandia, DDR, BeatMania, MegaMan 8 and X4, Pocket Fighter, Super Puzzle Fighter II Turbo, Suikoden 1 and 2, Adventures of Little Ralph, Gradius Deluxe Pack, Parodius Deluxe Pack, Salamander Deluxe Pack, Detana Twinbee Yahoo Deluxe Pack, Harmful Park, Buster Bros. Collection, Herc's Adventures, Gunner's Heaven, Heart of Darkness, In the Hunt, and many, many more. This is just off the top of my head.
There's a bunch of great 3D games, too!
Nah, it really wasn't. It was a good system, with a tonne of great to amazing games, but it had a lot of flaws on the technical side, and I really don't know how anyone's hands actually dealt with those controllers.
It'll probably still be part of my Top 5 Systems of all Time list, but it's not perfect.
Out of curiosity what was your issue with the controller exactly? I ask because I don't remember having any issues with it as a kid but nowadays when I use my 8bitdo SF30 Pro which has roughly the same shape I still have no trouble but it's also not the most comfortable controller ever.
I didn't have any issues with my small teenager hands either. Nowadays it just causes cramps eventually.
The Mega Drive's Controller was a lot more comfortable for bigger hands. It's just a nitpick anyway, I just don't think any console deserves the perfect label.
Hah, IRL I can never get anyone to care about the differences between the sfc and snes, and feel like more people prefer the snes over sfc if they have an opinion. Everyone seems to agree the snes cartridges suck in comparison thoughAnd despite it not being a popular opinion around here, I love the American version. It looks so happy and fun.
It's a shame 60fps never became the standard in the 3D era. It should be the bare minimum.And games ran in 60fps. You can't say that about today's games.
The SNES is definitely the last Nintendo console that could be considered the total package.
It's a shame 60fps never became the standard in the 3D era. It should be the bare minimum.
It's a shame 60fps never became the standard in the 3D era. It should be the bare minimum.
As an aside, there actually were a few 30fps games on the SNES, like Joe & Mac and Super Double Dragon. Not really sure why.
There are lots, and lots of games on the SNES below 60 fps, it's just that modern gamers don't know what dipping below 60 fps on these retro consoles looks like because they're used to modern consoles fixed timestep. I.e. on a modern console, games run at a fixed speed regardless of the framerate, if the framerate drops below the target 60 fps, the drawing system is decoupled from the main game loop and frames are skipped. The game runs at the same speed, but you see fewer frames to compensate.
Retro games don't work like this at all. Old game programming is split into 3 tasks, each essentially their own small program. These are switched between using hardware inturrupts, just like a modern multitasking operating system uses interrupts from the CPU to know when to context switch. Except, unlike a modern CPU, these switches are mapped to intervals dictated by the refresh cycle of the television screen. There are 3 periods - 1: active scan, which occurs while the television screen is drawing a single line of horizontal output. 2: Horizontal blank, which occurs in between each active scan when the raster gun must physically move back to the left of the screen for the next active scan. 3: Vertical blank, when the entire frame has drawn and returns back to the upper left portion of the screen to draw.
These 3 periods have different tasks relative to the output of a single frame. Vertical blank is the most important period and one of the longest, it's where all the computation heavy tasks are handled; joypad polling, tileset swapping, all DMA (fast talking to external hardware from the CPU), metatile construction, etc. When the final line of active scan occurs, a non-maskable interrupt is sent which switches periods so VBlank can occur. VBlank, unlike active scan and hblank, can run longer than the actual vblank period. When your vblank program ends, you need to set a memory address variable to represent that your vblank period is over. When the raster gun moves back to the upper left portion of the screen and is ready to begin the very first active scanout, a second nonmaskable interrupt is sent to switch periods. But this NMI has a caveat, it runs a very small "program" before actually switching the periods which checks the memory address to see if the VBlank period is over. If it is not, it'll send a third, very quick NMI to switch back to the Vblank period to run more Vblank code. You can only switch between Vblank and activescan at the very beginning of the television screen refresh period, a NMI to switch out of vblank won't be sent again until the raster gun moves back to the upper left portion of the screen. So even if your vblank routine runs just a few cycles over the amount of time between the last active scan and the next, the SNES must wait an entire frame before it can start drawing again.
This exhibits in slowdown. Unlike modern systems, there is no fixed timestep. If your game takes too long to draw, the game just physically moves slow. Slow down = frame drops. The SNES is infamous for lots and lots of slow down all over their games. Example: The game thunder spirits on the SNES sometimes runs at 7 frames per second compared to the same scene running at 60 fps on the Genesis.
Regarding the SNES being perfect, non-programmers really have no idea how limiting the SNES CPU was. For one, it was still based off of the ancient 6502 design, with all the flaws inherent to that architecture. The SNES variant upgrade was mainly to address external busing (i.e. to make it "16-bit" vs the 8-bit 6502), but the internal architectural problems exist. From a simple laymen's perspective, the SNES and Genesis CPUs are both 16-bit external, but that explains how they move data externally between components. To explain what I mean in a relatively simple way, let's talk quickly about how components of the machine talk. A video game console can almost be thought of like a bunch of small computers running in tandem on a single board. The Video chip runs independently of the CPU, with it's own ram (called VRAM), it's own timing, etc. In order for the CPU to talk to the video chip, there is a small area of shared memory between the two called a data port. If the CPU wants to talk to the Video chip, it writes data to this memory address, which the Video chip can then read when it's ready. The size of the data that can be written to these external ports is 16-bit. To put that into reference, that is the same as one 65536 value, or two 256 values, or four 16 values, or eight 4 values, etc. You can pack more, smaller data into one bus return to maximize your bus. One 16 bit bus is functionally the same as two eight bit buses, four four-bit busses, eight two-bit busses, etc. So if you have a bunch of small variables, you can do more work with a single bus.
Memory in computers is laid out into orders of speed. It takes comparatively eons for computers to talk to external parts because of how long it takes to the electrical currents to actually travel (plus how long it takes for those external components to respond). An example of comparative time:
So, to combat this, there are levels of RAM depending on their speed. Retro systems like the Genesis and SNES didn't have cache as that was new and expensive, so they really only had two types of memory - DRAM (the main ram of the system), and registers. Registers are very tiny pieces of memory directly connected to the CPU. They are what the CPU uses to do calculations entirely. The CPU actually cannot see any memory directly outside of the registers. In order for the CPU to, for example, write to VRAM to change a palette color, the CPU must put a value into a register, then put a value representing the destination RAM address into another register, then execute a command that tells the external buses to operate to move the memory to the destination. In essence, registers can be thought of as hardware variables, or dedicated data ports. Registers are tiny. Like an SNES register is 16 bits, or two bytes each. They are also very few in numbers.
THIS is where the Genesis absolutely curb stomps the SNES. Here's the real secret to the Genesis, why people consider its CPU so much better than the SNES's CPU. The Genesis' 68000 is actually a 32-bit processor. The 68000 comes in flavors, and the specific flavor of the genesis CPU is known as a sixteen/thirty-two hybrid. It has a 16-bit external bus, but 32 bit internal registers. This means you can do two writes to external memory 16 bits at a time to fill a single register on the Genesis, but once you have your values in registers, you can treat it as any other 32-bit memory. The Atari ST is thusly named because it uses a 68000 CPU: The Atari Sixteen-Thirty-two. Not only are the Genesis registers 32-bit, but they are also super numerous, there are 8 data registers and 8 address registers. 16 general purpose 32-bit registers in those days for a home console was pure insanity.
Let's take a simple task like multiplying a large set of numbers against each other to see how the Genesis CPU is just inherently better at such a task. Say I need to multiply sixteen 16-bit values quickly as part of some calculation. With the Sega Genesis CPU, I can load up all 8 32-bit data registers with values, packed two 16-bit values per 32-bit register. Once all my registers are loaded up, I can access every single value in a single cycle. I do all my calculations in, say, 16 cycles, then output the result through an address register. On the SNES, this process is very different due to the lack of registers. I'd have to load some data into registers from RAM, do a temporary calculation, then write that back out to DRAM, then load the next set of values from RAM, do more calculations, write those back out to DRAM, then again, then again, then take those temporary values in DRAM and move them to registers and multiply them again, move them to DRAM, then again, and I'll wind up at the solution. Because my registers aren't as wide, I can't pack values into a single 32-bit integer to save writes, because my registers are not numerous, I need to write back to DRAM to store values because I don't have registers open to do that. Every write to external DRAM takes a comparatively extremely long amount of time. All this is in addition to the SNES CPU also being clocked half as fast as the genesis CPU. And this is also on top of the 68000 having better dedicated opcodes to mathematical commands.
There really is no comparison between the SNES and Genesis CPUs. It's not really close. The SNES CPU was weak even when it released, it was, for intent and purposes, a generation behind. The SNES doesn't hit 60 fps nearly constantly, lots of games are well below 60fps, and this is all why.
...I was just talking about a handful of games that are capped at 30fps.
What's sad is that in the arcades, it mostly was. Early 3D games like Daytona USA, Virtua Fighter, Ridger Racer, House of the Dead, etc. were running at a buttery smooth 60fps. But obviously, those machines had much more power than your average home console...