1993 interview with Treasure

[Barone]

Nintendo ROM'er detected!

[makinagenesis]

I guess it was so crappy that no good games came out for it.

No Need for personal attacks. - The management.

[Zoltor]

Which I find hilarious because Sonic 2 was promoted to show Blast Processing, yet it slows down horribly. The game was extremely rushed (though nowhere near as rushed as Sonic 3 which was literally released in a complete prototype state with half the levels cut out and one character missing... yet plays much better than Sonic '06 >_>).

In practice that doesn't matter much... To make a sprite object move faster you just change a number, the amount of computations doesn't change, really, so in that sense only the amount of objects matters, not how fast they move. What's more interesting is how fast you can draw to the tilemap, since the amount of computations does increase the faster it scrolls (and Sonic falls kind of short there since it caps at a speed of 16 pixels in either direction per frame... which is 3 screens per second x_x).

The SNES doesn't help much either though... Super Mario World slows down when there are more than just a few objects on screen. This isn't an issue in the game itself since it was designed taking that into account, but it becomes a serious issue when hacking. And mode 7 games have dedicated hardware to do the relevant math calculations... and aren't useful for much else. There was multiplication and division hardware, but while it was faster than the 68000 instructions, it also dealt with smaller numbers (multiplication was 8-bit × 8-bit to 16-bit, division was 16-bit ÷ 8-bit to 8-bit - the 68000 instructions use double the sizes).

That said, sometimes I wonder why do games slow down. I can hit the sprite limit in the Mega Drive before the count object is so high the game engine slows down, and that's with naive algorithms. That's 80 objects right there. Granted, you may argue that most of the objects are barely doing anything interesting, but this is the case for most games after all, so that isn't a valid counterargument.

And I think that it was the PC Engine the fourth generation console here known for pushing a ridiculous amount of objects on screen without slow down, moreso than both the Mega Drive and the SNES.


Actually it was infamous for the whole arcade experience crap, which we all know was bullshit even the day it was released - Space Harrier II and Super Thunder Blade are steaming piles of shit in comparison to the arcade games from which they're spin offs (reduced framerate and almost all the cool details gone).


Both consoles have completely piece of shit sound hardware, period.

On the Mega Drive side, PCM playback is a giant hack involving some feature that was meant to be used as a last resort and that Sega didn't even provide full connections for, and in fact it looks like they tried to make it as hard as possible to do anything with it. The end result is that PCM playback on the Mega Drive is complete shit because developers couldn't do much with it. At least the Z80 had direct access to the ROM, which made up for its small amount of RAM.

On the SNES side, you have some ridiculous memory constraints that severely limited how samples could be used, resulting in either only short samples being used (not being much better than FM) or really low quality samples (sounding like crap). It didn't help Nintendo only allowed developers to use their own engine and nothing else, and that engine was also crap. That two second pause many games have when switching songs? That's the 65816 trying to slowly load the music data into the SPC700 memory! Had the SPC700 been given access to ROM, there really wouldn't have been any redeeming points for the Mega Drive hardware (except maybe that it sounds less muffled).


Don't assume Nintendo was much better. Developers had a lot of issues with the 65816 because the only other "major" system that used it was the Apple II GS, so there weren't many tools for developing with it (the 68000 was the opposite case, having tools about everywhere). This gave them serious issues not only when writing code, but also when debugging.

Lmao we all know "blast proccessing" is complete BS to biginwith, true the Genesis runs faster, but the whole BP slogan was made up as a marketing ploy(you know, when Sega actually knew something about marketing a product), slow down in Sonic 2 lol, well so much for that BP they are always spouting. Hm Slow Down in SMW, at very least It's got to be a super rare issue, the only slow down I recall is one of the sky world stages, where the screen auto scrolls, and there's these flying bomb enemies shooting fire balls(If you don't kill it, and allow others to come on the screen, then there's usually a couple of seconds of slow down, until the screen out runs 1 of them).


Yea I so didn't care much about the arcade xp on consoles, if I feel like playing a arcade game, I'll go to the arcades thank you very much.
Sprite limit doesn't seem to be the cause of slow down, It's how many moving things Vs how fast they are moving.

Be that it may, doesn't change how godly some of the SNES music was, so it was clearly leagues easier to make good music for the SNES, then for the Genesis.

Really, I've heard otherwise, that Nintendo went out of their way to give tools, and development kits to the developers, making it much easier for the developers to figure out how to make games for such..

[Thunderblaze16]

The SNES would kill itself trying to do any of them, heck the genesis can barely handle TF IV much less the SNES.

I'm interested in how.

[Thenewguy]

I distinctly remember a good bit of slowdown in the levels with fish in Super Mario World.

[Kamahl]

Oh, and if using a basic hardware feature negates a game's features, then Sonic is nothing special either, because it's simply utilizing the fact that the Genesis has a faster processor. Come to think of it, that negates any game that relies on speed, doesn't it? If Mode-7 is a meaningless hardware trick then so is your beloved Blast Processing.

But sonic isn't anything special either. It has nice color usage considering the hardware, that's pretty much the extent of it's "impressiveness" from a technical standpoint.

I'm interested in how.

The processor would pull in so much electricity trying to do all the computations in time there would be a short-circuit and the console would set itself on fire.

[Bastardcat]

Also, because godly Sega didn't make it.

[Zoltor]

I distinctly remember a good bit of slowdown in the levels with fish in Super Mario World.

Oh yep, you're right(forgot about that), it was fairly common when there was the squids with all the babies tied together like a tail, and they then spread out. There's only one other instance in the water where it happened, but It's stage specific, and a really small part of it(small enough it doesn't effect gameplay at all, where the squid enemies slow down areas is a problem).

[Sik]

Hm Slow Down in SMW, at very least It's got to be a super rare issue, the only slow down I recall is one of the sky world stages, where the screen auto scrolls, and there's these flying bomb enemies shooting fire balls(If you don't kill it, and allow others to come on the screen, then there's usually a couple of seconds of slow down, until the screen out runs 1 of them).

I did say it isn't much of an issue in the actual game because they designed the levels taking that into account (though now that you mention it the game does indeed slow down more than I'm giving it credit for). Like I said though, it does become a serious issue with hacks, where it's extremely easy to get slow down when making a level.

In the end it only shows that their object manager was crap though. The SNES should have been able to cope with all that without slow down. It's in the really complex calculations (i.e. when you start pushing things to the extreme) where it falls behind. The 68000 simply has it easier than the 65816 at that.

Sprite limit doesn't seem to be the cause of slow down, It's how many moving things Vs how fast they are moving.

I was putting that as a comparison though. I have managed to get a huge amount of objects without slow down. It gets even funnier when by accident you make a bug that ends up spawning lots of objects. This happened with Project MD once (when implementing the flamethrowers, they'd spawn one fireball every frame, each one of them)... and no slow down ._. Also with some old fangame I put 72 platforms on screen, all with collision checks, and still no slow down either - and I'd have put more if it wasn't because I didn't have enough sprites left!

Ultimately slow down with so many objects is caused by either sloppy code or filling the screen with really complex objects (and like I said, the latter is almost never the case in a real game).

Be that it may, doesn't change how godly some of the SNES music was, so it was clearly leagues easier to make good music for the SNES, then for the Genesis.

It doesn't help almost nobody can make good FM instruments (but those who did certainly got some damn good stuff out of the chip - and Sonic games actually manage to explore a large amount of music genres instead of being all super-generic synth =P).

Really, I've heard otherwise, that Nintendo went out of their way to give tools, and development kits to the developers, making it much easier for the developers to figure out how to make games for such..

But I also recall developers complaining about the 65816 itself - probably not the best place to have issues at, since programming is where most issues arise. I do recall Nintendo eventually trying to make an emulator to ease debugging though (while Sega instead went with multiple hardware-based solutions).

And even then, having better tools helps, but the interface for the hardware components is horrible and counters that (the sprite table being a huge offender, the sound chip being another huge offender, then there being some weird limitations with the video hardawre, and all the hardware using 8-bit buses for communication, etc.).

[sheath]

Not in the audio department, optimizing color usage isn't easy either


Oh how could I ever forget about that? Moving 1 sprite quickly in an almost single screen with 1 or 2 slow moving enemies.
It totally has blast processing!

Well, there's always Road Runner Death Valley Rally. Or how 'bout them Unicycles. They both have lots going on in the backgrounds don't they?!11

[Bastardcat]

Well if we're dumping on a console because of the shittiest games for it, I have two words for those of you with your heads firmly planted up the Genesis's butt: Dark Castle.

[sheath]

This thread seems to have gotten a bit out of hand really. The SNES isn't as fast as the Genesis, it just isn't. The Genesis isn't flexible with its colors, at all, and doesn't have Mode 7. The audio on both systems have notable advantages and flaws. I think everybody should know this by now, but I think wrong things all the time.

But if you wanted to create a custom game engine with custom special effects and a custom sound engine, current evidence suggests the Genesis was the system to choose for such a project.

[Thunderblaze16]

Didn't Pier Solar have mode 7?

[Guntz]

Yes it did, but IIRC it's all in software. Pretty nifty but it's understandable how it was never attempted 'back in the day', what with time and budget constraints of corporate business.

[sheath]

Didn't Pier Solar have mode 7?

Mode 7 is the SNES' seventh graphics mode, which is all about scaling and rotating a single background layer.

From what I have seen of the Pier Solar flying segments it looks and plays just like SNES Mode 7 would.