-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
bsnes (SNES Emulator) Introduces Overclocking (No slowdown Starfox, Contra3, etc)
- Thread starter jediyoshi
- Start date
How's compatibility overall?
Can you elaborate on this a little?
For the games with noticable frame-drops that actually caused me to engage the overclocking features, I'd say around 50/50 between worked perfectly / had issues or crashed.
Not tried it, but I'd imagine Argonaut designed the game with the slowdown in mind so the enemy amount etc makes the game harder without the slowdown
It's too bad Retroarch is such a pain to use. I can't save of Retroarch using the android version on my GPD XD.
I just want a Star Fox ROM that is pre-patched to run at 60fps.....or at least 30.
I heard folks can mod their carts to do it, but I have no idea what that entails, and wouldn't feel comfortable with it.
I heard folks can mod their carts to do it, but I have no idea what that entails, and wouldn't feel comfortable with it.
Impressive, but that means that games are going to be harder and run at a completely different speed to the original, which is why Starfox is completely out of sync.
It'll be harder to hit enemies as they'll move faster, and you'll have less time to avoid bullets and objects etc. Not something I want tbh, I'll play stuff at the original speeds.
It'll be harder to hit enemies as they'll move faster, and you'll have less time to avoid bullets and objects etc. Not something I want tbh, I'll play stuff at the original speeds.
This feature just came out, so I haven't found any footage of it w/BSNES.
Only thing I found is this footage that dates from January, SNES9X does have a similar overclock features, though it's more prone to accelerate more than just the framerate. It does however give a good idea of how better it is with the OC.
It's not out of sync, the audio is just coming from the overclocked version (right side of the video). The games will run at a "proper" speed had the SNES been more powerful.
I'm not a huge fan of overclocked Starfox. Sure the framerate improves, but the rest of the game speeds up as well.
Not sure about the others but atleast the PS1 emulator, Bettle PSX on Retroarch has a overcloking feature.
I mean it's out of sync with the original. It will take less time to complete a level as you're flying through it quicker, enemies are flying quicker, bullets are moving faster. Everything had been designed around the speed it was originally running, and now that's just been sped up meaning it will be a harder game to play.
Not sure. Last time i checked, bettle Saturn did not have all the features of bettle psx such as higher resolutions or overclocking. Maybe its been added on update later but i don't know.
The biggest problem I have with Star Fox running at an overclocked speed is that the timing is all wrong. yeah, the game runs smoother, but it really was designed to run at its low framerate. It's the same problem that many old emulators had while running SFX games. Now, if someone can get a smooth FPS while retaining the timing of the original game, I would be impressed.
Contra 3 overclocking looks pretty good, though.
Contra 3 overclocking looks pretty good, though.
The amount of latency-reducing settings in various emulators are always increasing, and lots of them don't affect accuracy (the resync of runahead can cause some accuracy issues).
The bottom line is a beefy PC is the best way to emulate.
I also bristle a bit at 'emulators have lag' type comments. I've seen speedrunners beat Punch-Out!! (sighted and blindfolded) on Wii (NES Virtual Console) paired with a CRT via analog and that's a torture test. It depends on implementation. If you're using a PC instead of some cheap Pi you've probably got more latency in your display device than the emulation+os+drivers.
I'm hands on with this stuff, just this week I was testing mGBA to see if I could get runahead working on Switch (not powerful enough, don't bother).
The bottom line is a beefy PC is the best way to emulate.
I also bristle a bit at 'emulators have lag' type comments. I've seen speedrunners beat Punch-Out!! (sighted and blindfolded) on Wii (NES Virtual Console) paired with a CRT via analog and that's a torture test. It depends on implementation. If you're using a PC instead of some cheap Pi you've probably got more latency in your display device than the emulation+os+drivers.
I'm hands on with this stuff, just this week I was testing mGBA to see if I could get runahead working on Switch (not powerful enough, don't bother).
Last edited:
Like I said, star fox was made for the limitations. Just TRY to play it with no slowdown. Done it and yeah, the speed makes the game almost unplayable, or at least increases the difficulty quite a bit.
The obvious giveaway is that the digitized speech in the scramble sequence doesn't even play all the way through in the overclocked version. People have been overclocking the game for awhile now with other emulators or the actual cart and parts of the game (like Sector Z) are a nightmare.
Star Fox wasn't meant to run at that speed. Everything in the game was deliberately designed around the slow framerate of the original. Running the game faster isn't an improvement because now everything moves too fast, is harder to avoid or hit, and looks completely off. The music is also out of sync. Just look at the intro cutscene where the actual cutscene ends before its audio does. No one should be celebrating this.
Playstation programming typically isn't scanline driven like SNES and NES and such games are. By the time the playstation had come around, things like fixed timestep had been a thing in games programming for several years, especially with things like Doom popularizing it. There are some games with very tight timing that were, like the DDR games, but for the most part, games run at a fixed timestep.
I mean, I disagree. The core engine goes back to things like StarGlider on the Amiga and Atari ST, and the convention was "as fast as your machine could run it." The atari ST versions for example always ran a tad bit fast, because of the faster clock speed of the 68000. There was no "standard" speed.
Doom uses fixed timestep at 35 hz, exactly half the refresh rate of the VESA standard. Changing the framerate of doom requires rewriting the entire event handling portion of the code, which is actually what things like ZDoom do.
No? Why would it be? Bsnes isn't a commercial product, there is no competition between them.
Huh? BM is just saying the new feature may make them use BSNES instead of the NT/SD2. I don't see what you're getting at.
I agree about the music, but I find the game way too easy by default. While I'd have to play it to be sure, it looks overall way more fun this way. Definitely a welcome option.
How can you disagree with the fact that the intro cutscene ends before its music/audio does?
I would love to see overclocking possibilities on all emulators, to be honest. For example something like bsnes does now I'd like to see for Genesis, too.
This is cool, but Star Fox isn't meant to run that fast. I'd rather have it be faithful to the original hardware experience. 3D game logic being tied to a frame rate always makes these "improvements" harm the gameplay.
That Gradius 3 SA-1 hack though? Fucking amazing.
That Gradius 3 SA-1 hack though? Fucking amazing.
That involves taking a donor cartridge with a higher clocked SuperFX chip and burning the Starfox rom to an eeprom then soldering it to the board.
There appears to be some people here confused about slowdown vs render speed here. This is to eliminate slowdown. The reason slowdown occurs in retro games is because of the timing loop they operated on. Old games work on the principle that the television itself times how code can run. Code is split into three sections: Active scan code, HBlank code, and VBlank code. Think of them almost like entirely different programs.
In computing, the illusion of multitasking is achieved by switching between running code -- typically, a CPU can only run one program list's instructions at any given time. To make it look like multiple programs are running at the same time, they'll use an interrupt from the CPU to switch which program is being run. Every few microseconds, a CPU will switch to the next program to run. Since this happens so fast, we can't perceive the switch and it looks instantaneous.
Retro consoles kinda work like this, except it's the TV that determines the switch. This is because old TVs had a physical gun that would change the position of where the scanout was being drawn. When the gun stopped drawing and had to move to the next position, that provided perfect opportunities to run different kinds of code for different tasks not limited by BUS limitations due to scanout from the console.
I don't really need to explain the difference between active scan and hblank code here, but what's important is vblank code. Vblank is what happens when the gun reaches the bottom of the television screen and has to move all the way back to the top to begin drawing the next frame. This actually in relative terms takes a very long time, and during that time the entire console's resources are free to use. So Vblank is where most of the really heavy, long calculations go. However, since the television works at a fixed interval, if your VBlank code takes longer to execute, you'll run into problems.
When the raster gun moves back into position at the top of the screen to begin drawing the next frame, what happens is that the CPU of the system will switch back to a very small segment of code to check if VBlank is complete. When your Vblank code is done, you set a flag to indicate it's done, and if that flag isn't set, rather than switching back to the active scan segment of the code to begin drawing, the system will instead return back to the Vblank code to continue running. However, again, the TV determines timing, and thus you won't get another interrupt to switch back to active scan code until the gun moves back to the top of the screen, meaning an entire frame later.
Say our TV refreshes at 60 hz, but our VBlank code is longer than VBlank period. It thus takes 2 frames for us to finish our calculations. That means we technically refresh at 60/2 = 30 hz. If we took 3 frames, 60/3 = 20 hz. And so forth. Unlike a decoupled fixed timestep system like in Doom, old games typically have no real world way to tell how much time has passed between frames, so they don't account for the delay. So when this skipped beat occurs, to the player, it looks like they just actually started running slower, because now the internal logic is being done half as fast.
With emulation, we can actually redefine the parameters of the virtual television. What BSNES is doing is inserting extra scanlines into the "virtual television" to give segments of code more time to run. Thus, no more slowdown.
But, usually for superFX chip games, the framerate is also tied to how long it takes the math coprocessor to actually crunch the numbers for the vertexes, to build the tiles for the graphics, so forth. Thus, a game like starfox has two different timings to account for. This eliminates slowdown, but won't necessarily improve the framerate. Other emulators, and indeed switching Starfox Roms with a faster SuperFX cart, WILL change the starfox framerate by having the SuperFX math co-processor actually work faster. It takes less time for it to do the same math.
What people are seeing in the starfox videos is what starfox looks like with no slowdown, but not necessarily a free framerate.
How the fuck does this not have its own thread? I'm trying this out right now and it's almost exactly what I've been wanting from a custom control method for the Trilogy, some minor control issues aside.
I'm talking about actual gameplay moments. Obviously things like the audio cues in those instances were timed to the framerate they had achieved after the engine was already working. But if they're desyncing here, that's a clue of how their development process worked -- they built the game to run as fast as possible, and once it was already running, then they timed the audio cues.
I'll take 99% of the game actually playing better over a couple of seconds of intro audio being in sync, personally. And "no one should be celebrating this" is just goofy.
I love this channel, and yes, this is a great example with awesome visuals about how it works. This guy makes the best visualizations on the subject, hands down.
I've got Super NT (plus SD2SNES, plus Super Game Boy 2, plus GB Everdrive), MiSTer, and a gaming PC all plugged into my 65" OLED so I play things various ways.