The Genius of Vitor Vilela...

[Josh128]

Im a huge fan of his work. Havent seen much of his latest stuff posted lately here so I wanted to update.


Project FASTRom: Axelay, UN Squadron, Super Castlevania IV, F-Zero - This is a new project that I was unaware of until yesterday. Its goal was reprogramming these games to force the SNES CPU into its 3.58MHz mode from the more often used 2.68MHz mode that was employed by many early games. Its mindblowing to me to think the original programmers could have done this, if they were knowledgable enough, and could have largely eliminated much of the slowdown that plagued early games without any extra hardware!

SA-1 Root project: Gradius III, Super R-Type, Contra III, Race Drivin'. This dude actually got the ~4 fps Race Drivin' to run at 20-30fps with the SA-1 chip.

SA-1 Pack project: A collection of tools to enable SA-1 hacks of SMW. AFAIK he does not have a completely hacked game available, but instead has given all these tools to the community to allow them to make their own hacks.

[NoAffinity]

Thank you for this. I wasnt fully up to speed on the current state of things. I'm excited to see race driving getting playability improvements.

Sent from my SM-G955U using Tapatalk

[Sumez]

Though the idea is cool, as a SNES programmer myself one thing that bothers me about this guy's projects is that it just helps spread the dumb rumor that the SNES CPU is hopelessly slow.

If I'd spent the time disassembling these games I'd try to improve the structure of whatever their performance bottlenecks are, rather than just unloading the code to a secondary CPU in the cartridge. Most of the games that suffer from slowdown on a SNES (or really any plaform of the time) honestly had no reason to. And any CPU is gonna be "too slow" if you don't design your game logic around what can be done in a frame. On the SNES especially there are a lot of creative ways to optimize performance, and having looked into the code of a few original games, more often than not the opposite was done, with piles of super wasteful routines.

Its mindblowing to me to think the original programmers could have done this, if they were knowledgable enough, and could have largely eliminated much of the slowdown that plagued early games without any extra hardware!

They could, but probably not using FastROM (even if there are probably examples where that is true, too). FastROM required, you guessed it, faster ROM chips to work, which at the time were usually more expensive. The reason is that the architecture of the 65816 CPU is generally bottlenecked by the speed of the ROM or RAM it is accessing.

[Josh128]

Though the idea is cool, as a SNES programmer myself one thing that bothers me about this guy's projects is that it just helps spread the dumb rumor that the SNES CPU is hopelessly slow.

Whatever anyone thinks about the SNES is on them, Vitor has never claimed the SNES is hopelessly slow. What he did do was make the SNES as fast as a Neo Geo with his SA-1 work, and show that had the developers decided, they could have used the chip in similar ways back in the day. Kirbys Super Star, a game I bought on its release, uses the chip and I honestly cant point to anything special about what it does with it. It doesnt load the screen with sprites without slowdown and didnt to anything out of the ordinary graphically that I can recall. Games like Gradius III and Super R-Type were incredibly ambitious arcade conversions for their time and there is no way the SNES was ever going to be able to pull off all the on screen sprites they programmed into them without dropping frames. Even the most optimized SNES game I can think of, Space Megaforce/Super Aleste, while impressive, still had some slowdown at times. To make use of the SA-1 like he has required completely reprogramming the ROMs and the way the CPU accesses them. No one in the hacking world to date has done anything remotely close to he has done with this SA-1 work.

If I'd spent the time disassembling these games I'd try to improve the structure of whatever their performance bottlenecks are, rather than just unloading the code to a secondary CPU in the cartridge. Most of the games that suffer from slowdown on a SNES (or really any plaform of the time) honestly had no reason to. And any CPU is gonna be "too slow" if you don't design your game logic around what can be done in a frame. On the SNES especially there are a lot of creative ways to optimize performance, and having looked into the code of a few original games, more often than not the opposite was done, with piles of super wasteful routines.

No disrespect to you, but it sounds like you are trying to diminish Vitors incredible accomplishments in this area. I dont doubt at all that many of the slowdown plagued games were poorly optimized, but the only example I can think of where any slowdown was removed or optimization was done was Super Ghouls N Ghosts Restoration. Its unclear as to what was done to achieve that optimization. Were you responsible for that hack and if not, what qualifies you to be able to criticize Vitors contributions in this area, which, at least to my knowledge are without equal?

They could, but probably not using FastROM (even if there are probably examples where that is true, too). FastROM required, you guessed it, faster ROM chips to work, which at the time were usually more expensive. The reason is that the architecture of the 65816 CPU is generally bottlenecked by the speed of the ROM or RAM it is accessing.

Its mindblowing to me to think the original programmers could have done this, if they were knowledgable enough, and could have largely eliminated much of the slowdown that plagued early games without any extra hardware!

I suspected this was the case, and I can appreciate the financial aspect of it, but it made for quite the black eye in the face of its competition in the Genesis. The Genesis had its own problems though, such as the shittiest video output Ive ever seen in a gaming system to date, and its tinny FM sound chip (in comparison to the SNES, at least).

[Unseen]

What he did do was make the SNES as fast as a Neo Geo with his SA-1 work, and show that had the developers decided, they could have used the chip in similar ways back in the day.

Sometimes they did decide, but management override them for cost reasons. The section "Enhancement chips" on this page (which quotes from this video) describes this process for Another World.

[orange808]

Though the idea is cool, as a SNES programmer myself one thing that bothers me about this guy's projects is that it just helps spread the dumb rumor that the SNES CPU is hopelessly slow.

That's true.

If I'd spent the time disassembling these games I'd try to improve the structure of whatever their performance bottlenecks are, rather than just unloading the code to a secondary CPU in the cartridge.

Easier said than done. In many cases, getting a game to hit frame rate all the time would require a significant rewrite. Who has the time?

Most of the games that suffer from slowdown on a SNES (or really any plaform of the time) honestly had no reason to. And any CPU is gonna be "too slow" if you don't design your game logic around what can be done in a frame. On the SNES especially there are a lot of creative ways to optimize performance, and having looked into the code of a few original games, more often than not the opposite was done, with piles of super wasteful routines.

On the other hand, everyone was learning on the job with the SNES. Nintendo wasn't exactly friendly to third party devs back then. They didn't share what they knew. Even if they had, lots of people got started on their games right after they got development hardware.

It's not reasonable to expect devs to understand what was best. Everyone was learning by trial and error with a deadline. Don't forget the deadline. Not much time to experiment with programming. Nintendo needed software and early releases had a better market position.

You're right about potential improvements, but there are reasons why. Good reasons.

They could, but probably not using FastROM (even if there are probably examples where that is true, too). FastROM required, you guessed it, faster ROM chips to work, which at the time were usually more expensive. The reason is that the architecture of the 65816 CPU is generally bottlenecked by the speed of the ROM or RAM it is accessing.

That's a good call out. Once again, the business side mattered.

It's also useful to point out that using the absolute most "efficient" path in code isn't always best from a development perspective. The ability to get things working properly without bugs and on time is its own kind of efficiency. And, of course, you can't make a bad game design fun with gimmicks. A lot of development time went into the game designs; it's more than just coding.

[Josh128]

What he did do was make the SNES as fast as a Neo Geo with his SA-1 work, and show that had the developers decided, they could have used the chip in similar ways back in the day.

Sometimes they did decide, but management override them for cost reasons. The section "Enhancement chips" on this page (which quotes from this video) describes this process for Another World.

I had read this in the distant past and forgotten about it! She mentions the fast roms vs the slow roms and that the fast roms were $.50 more expensive which is why they didnt use them. You'd think they could've just added $.50 to the MSRP if it was that big a deal and made that big a difference. Perhaps Nintendos iron-clad licensing rules limited what licensees could MSRP the carts for.

One thing Rebecca Heineman mentioned that I'll call out as total BS is that she "removed the SFX chip from a StarFox cart, figured out how it worked, and had OOTW running @60 fps on it". That definitely didnt happen.

Regardless, none of this changes the fact that Vitor has done more to show what the SNES was/is capable of than any other programmer since the SNES went EOL. No one else has done anything even remotely close, and I very much appreciate his contributions and hope he chooses to continue to take on new projects with additional games.

[Sumez]

Easier said than done. In many cases, getting a game to hit frame rate all the time would require a significant rewrite. Who has the time?

Well yeah that's the thing. But apparently Vitor Vilela has the time. Though I guess with the SA-1 being mostly based on the 65816, the Gradius III SA-1 hack might not actually require as much rewriting as I assumed. I guess as long as you are aware of what addresses a big block of code is accessing, you can probably offload it to the SA-1 without necessarily needing to understand everything it does...

On the other hand, everyone was learning on the job with the SNES. Nintendo wasn't exactly friendly to third party devs back then. They didn't share what they knew. Even if they had, lots of people got started on their games right after they got development hardware.

It's not reasonable to expect devs to understand what was best. Everyone was learning by trial and error with a deadline. Don't forget the deadline. Not much time to experiment with programming. Nintendo needed software and early releases had a better market position.

You're right about potential improvements, but there are reasons why. Good reasons.

Oh yeah, I think you are right about all of this, and that was pretty much my point too. Commercial console games of the time were generally hastily put together, with a certain threshold for at which point the game is just "good enough". No reason to optimize beyond that, and if there's already a standard for games slowing down, you might as well design the game around the slowdown.
I think that's especially true for Gradius III (less so for SGNG) which becomes a lot more difficult without the slowdown, and of course the arcade game had it as well.

My point isn't that developers are at fault for letting games slow down, just that it's a massive misunderstanding of how video game development for this kind of hardware works, to blame the CPU.
People are quick to look at the numbers and say hey the MegaDrive has twice the mhz, so it must be twice as fast, when that's not really the case at all, considering the SNES CPU can do most equivalent operations in half the number of cycles.

The bigger reason is probably as you implied, that the MegaDrive being based on well known off-the-shelf components made it quicker for devs to dive into it compared to a poorly documented Nintendo console. I'd also point at the 68k being much more basic to program, but a lot of these devs should already have experience with the 6502 architecture from the NES/Famicom.

[RebeL9]

I wish the 16:9 SMW would be able to play on actual hardware

[Ed Oscuro]

One thing Rebecca Heineman mentioned that I'll call out as total BS is that she "removed the SFX chip from a StarFox cart, figured out how it worked, and had OOTW running @60 fps on it". That definitely didnt happen.

That's quite believable to me. That's more or less what some people have done today for their own SFX homebrew enhancement projects. The worst sticking point would have been knowing the internal workings of the SFX but people did have the Internet even back then. All of this has to be taken in the context of the creative things people got up to in the face of Nintendo's less than stellar support, and also having to work with the hardware at a low level anyway.

I repost this lots but just look at the wiring of this NES-era monster from Rocket Science Production (seemingly not to be confused with Rocket Science Games, Elon Musk's old night job): http://devkits.handheldmuseum.com/NES_M ... ontrol.htm
It looks insane but it's mostly a matter of figuring out which pins should be connected where.

[gray117]

It's a really nice effort by someone clearly invested in not only having a look, but also re-tooling the roms... but even this guy will have certain parameters by which he will be interested in working to.

Back in the day a lack of documentation was a factor, lack of well written documentation another factor, a lack of time to 'polish' vs. omg it simply works after we've put it together... all these contribute to why stuff like this happens... it's not a knock on the original developers or even those who might have hampered the results when trying to maximise profit and/or minimise issues during development (and available parts to test on). If you were following someone's guidelines and there was a mistake or something just not super clear - that likely effected a year or 2 of development and multiple games... It's all literally an artifact of the times and the environments under which many of these games were created: Just separate fascinating parts of game development.

That various ongoing explorations still revealing some of the challenges and decisions that developers wrestled with is just so fascinating. Where they discover new ways to use the same/similar hardware is equally admirable. That we as players may then play a tweaked/remastered/newly developed game for an old system is just the icing on the cake - and testament to the enduring appeal of both the games and the hardware.

... And yeah I had no idea someone was doing this - nice!

[Ed Oscuro]

Yeah, B. Fargo doesn't look like the hero of the story here, but perhaps cost-cutting measure added to Interplay's war chest so they could fund future games like Fallout. As a consumer you hate to see it but this kind of tradeoff goes on everywhere. You can even see it in development of new homebrew products here - "I could use a better SOC but it would add to the price..."

[Josh128]

One thing Rebecca Heineman mentioned that I'll call out as total BS is that she "removed the SFX chip from a StarFox cart, figured out how it worked, and had OOTW running @60 fps on it". That definitely didnt happen.

That's quite believable to me. That's more or less what some people have done today for their own SFX homebrew enhancement projects. The worst sticking point would have been knowing the internal workings of the SFX but people did have the Internet even back then. All of this has to be taken in the context of the creative things people got up to in the face of Nintendo's less than stellar support, and also having to work with the hardware at a low level anyway.

I repost this lots but just look at the wiring of this NES-era monster from Rocket Science Production (seemingly not to be confused with Rocket Science Games, Elon Musk's old night job): http://devkits.handheldmuseum.com/NES_M ... ontrol.htm
It looks insane but it's mostly a matter of figuring out which pins should be connected where.

If you consider the respective release dates of OOTW and StarFox for the SNES, it will be a lot less believable, unless you believe in time travel, that is.

Would also like to add that I’ve tried both versions of Race Drivin and gameplay timing corrected version is incredible, very crisp controls. Frame rate is similar or better than VR on Genesis!

Also tried my fav shmup of all time, UN Squadron. I have to say, the FastROM mod makes a very nice difference, played to second to last level on normal and don’t recall any slowdown. Very crisp and arcade like feel compared to the original SlowROM version.

[Ed Oscuro]

Oh, good eye. That's my homebrew theory out the window. The dates are quite close here. Unless they got an advance copy from Nintendo (which seems just possible, though Star Fox seems to have been kept secret until its Jan '93 CES unveiling) it seems unlikely they would have had access to Star Fox before the November '92 launch date which I see online (and that's just launch date, not taking into account lead time on actual production). The UK/European release seems to have been May '93 so it is just possible that perhaps Rebecca did some research on an enhancement for the European market. Unlikely, but just possible.

It's also possible she's confusing the SuperFX and DSP-1 chips. The timing makes it more plausible that the donor cart could have been Super Mario cart or especially Pilotwings.

[strygo]

I wish the 16:9 SMW would be able to play on actual hardware

I’ve been hoping someone would add 16:9 support to the SNES MiSTer core. It likely would drive more conversions.