So I decided today that I'd try creating a TAS of Drakkhen 2: Dragon View, since I've been playing and breaking it to death lately. I looked at your website and saw that BizHawk is the only "acceptable" emulator for SNES TAS's anymore. Okay, fine. I've used it for a while but I don't like it because it seems to lag slightly on my relatively-fancy computer. I figured I would try it anyway.
I spent my entire day grinding along, probably 9 hours on maybe 20 minutes of gameplay but it was damn good (from an amateur perspective) and I was proud of it.
It crashed. Gave me some kind of error window about something to do with memory that I should have copied down (I should seriously not be having memory problems). Aaaand it seems like EVERYTHING I did today is now gone. I guess I should have saved along the way, but CAN you even resume recording a saved file? I don't see any obvious way anyhow.
I have "Automatically Backup Movies" checked. There does appear to be a backup recording, but it's eight minutes of nothing. Sooooooo....
Why is BizHawk the standard again? I've been screwing around in five different versions of SNES9x for weeks now and I have never had anything close to this problem. Even when the emulator crashed, the recording it was recording was STILL THERE.
Even if I actually can just save and resume along the way, I'm just... Done. I'm not risking my work on this emulator again. Killed all my motivation instantly.
I guess I will try again someday, when I've calmed down sufficiently, with snes9x... But can you explain why it is listed as "Deprecated / Obsoleted / Not Reccommended"?
I guess I will try again someday, when I've calmed down sufficiently, with snes9x... But can you explain why it is listed as "Deprecated / Obsoleted / Not Reccommended"?
Greatly surpassed by bsnes-based emulators in accuracy.
The priority date for snes9x 1.51-1.53 is not even decided yet, seems to be quite far off.
And yes, bsnes-based emulators are fairly slow. One needs quite powerful CPU to reach 200fps for instance (even without chips).
I guess I will try again someday, when I've calmed down sufficiently, with snes9x... But can you explain why it is listed as "Deprecated / Obsoleted / Not Reccommended"?
Greatly surpassed by bsnes-based emulators in accuracy.
The priority date for snes9x 1.51-1.53 is not even decided yet, seems to be quite far off.
And yes, bsnes-based emulators are fairly slow. One needs quite powerful CPU to reach 200fps for instance (even without chips).
Tasvideos would rather ban snes9x submissions entirely, as it is lower accuracy than bsnes core (Bizhawk, higan, bsnes/lsnes, etc). However, the requirements to run this core at 60FPS are very high and not met by all computers currently in use. On top of that, the developer of bsnes does not have much interest in improving the performance (and especially it will never be made more performant at the cost of accuracy). As such, I think it will still be possible to make snes9x 1.51-1.53 submissions until a few years from now.
I was aware that bizhawk and its ilk are very demanding, it just seems strange that it can bog down my computer where newly-released games on high-quality settings do fine. I know this is a really dumb statement so forgive me, but how hard can it really be to emulate an SNES?
By branches you mean all the different versions and improvements and such? I can understand that. As I said - just trying to collaborate with some people recently I had to hunt down several different versions.
Anyways... this talk of dates and accuracy - do you think there will come a day that a run that was done on SNES9x 1.53 right now will be considered no longer valid? I really really don't want to risk being disqualified sometime later in such a manner.
Thanks for taking my rant in stride by the way.
On top of that, the developer of bsnes does not have much interest in improving the performance (and especially it will never be made more performant at the cost of accuracy).
It can't be improved much without sacrificing either:
- Accuracy
- Making the code unholy mess (doing it even with tools exceeds Byuu's capabilties[1]).
[1] Mentioned in a post by Byuu himself on his forums.
Khaz wrote:
I really really don't want to risk being disqualified sometime later in such a manner.
Priority date for snes9x 1.43 was months and months ago. All the runs still aren't in, so there will still be a few snes9x 1.43 runs not even submitted yet.
Priority date for snes9x 1.43 was months and months ago. All the runs still aren't in, so there will still be a few snes9x 1.43 runs not even submitted yet.
Heh, can I just ask what a "Priority Date" is specifically? ie/ are runs on 1.43 that have already been accepted ever going to "expire"? I just want to be certain about that.
Heh, can I just ask what a "Priority Date" is specifically? ie/ are runs on 1.43 that have already been accepted ever going to "expire"? I just want to be certain about that.
The date before one needed to start a project using that emu.
And those runs are not going to "expire". Those can be obsoleted, but that can happen to any run, irrespective of the emulator.
Also, as hint: Putting out WIPs is very useful for getting feedback and establishing when the run was started (in case that is wanted for some reason).
I was aware that bizhawk and its ilk are very demanding, it just seems strange that it can bog down my computer where newly-released games on high-quality settings do fine. I know this is a really dumb statement so forgive me, but how hard can it really be to emulate an SNES?
Harder than you think to emulate with 100% accuracy.
The main reason is that the drawing to the screen is not done after all the CPU cycles for that frame are over - it is done in parallel. A truly accurate emulator must process the screen being drawn in progressive scanlines simultaneous with the CPU cycles advancing.
http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/ is a really great three page explanation of what bsnes does other emulators don't and why.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Even snes9x 1.43 runs won't be obsoleted based only on accuracy boost, if real gameplay improvements are not found. Accuracy doesn't beat TAS optimality. So unless some real improvement is found (either on snes9x 1.51, or on bsnes core), a published snes9x 1.43 run won't expire ever.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I was aware that BizHawk and its ilk are very demanding, it just seems strange that it can bog down my computer where newly-released games on high-quality settings do fine.
These settings are mostly about the graphics, which are done on the GPU. The bsnes core will only use your CPU. The only way an SNES emulator will tax your GPU is by using a shader.
What system do you have? For bsnes the fastest Intel CPU is the best (note that it uses only one core, though frontends may use more).
Khaz wrote:
I know this is a really dumb statement so forgive me, but how hard can it really be to emulate an SNES?
Quote byuu: "It is possible for a well-optimized, speed-oriented SNES emulator to run at full speed using only 300MHz of processing power. You will also end up with hundreds of obscure bugs. [...] So although bsnes runs ten times slower than ZSNES, it is literally up to one hundred times more precise. In truth, it is actually very impressive that this is possible at a mere 3GHz."
The hard part isn't emulating what it does, it's emulating it at the lowest level so that all higher-level effects appear automatically - sort of like raytracing can do things like perfect spheres without any additional coding but it's very slow.
Emulating at the lowest level means that all components are updated at every step of the system clock. The NTSC signal has a frequency of 227.5 * 262.5 * 60000/1001 Hz (~3.5795 MHz) and the SNES system clock is 6 times of that (~21.47727 MHz). Depending on what memory region is being accessed in an instruction, that access can take 6, 8, or 12 master cycles. ZSNES is one emulator that skips keeping track of these cycle counts. (It also fails when a hardware component interrupts the CPU in the middle of executing an instruction...) So your CPU has to execute more than 21 million emulation steps per second. If the CPU is 3.2 GHz, that works out to a maximum time window of ~139.68 PC clock ticks for 1 SNES clock tick. (Given that I've heard the speed penalty of emulation is generally considered to be about 1:100, we're still in the limit.) Don't forget that the emulator has to emulate sound and graphics too, and that your PC runs other programs in the background, but thankfully modern CPUs can do several things per clock cycle, have advanced pipelines and branch prediction, and can even use multi-threading.
For most games, the graphics subsystem is where a SNES emulator will spend the most time on. Determining the color of a SNES pixel is very complex, because the hardware designers gave the game developers many ways to influence the "rendering" pipeline. This has to be done at least 256*224 times per frame; twice that if the game uses transparencies. Most emulators "cheat" by caching the state of the video processors at the beginning of a scanline and using that for the entire line instead of querying the values once or twice for each pixel. This is why we have the fast "compatibility" version of bsnes which does the caching, and the "accuracy" version which does things the accurate way.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Khaz wrote:
I have "Automatically Backup Movies" checked.
The specific behavior of this feature is that before you do something destructive to a movie for the first time, it goes ahead and makes a backup. Therefore, your first recording won't be affected by this feature. However, when you resume recording in your next recording session it will backup the movie first, before doing the record. As such, it is still dependent on you to at least save something first.
Also, at any point in recording you can right-click and select "Backup movie", or "Save movie". Just like any program where you edit a file, saving often is critical!
As for your "Crash", most "crashes" in BizHawk are actually exception that it can recover from just fine (Just click ok). So if you had your emulator completely die, I'd like to know specifically what you were doing, and what the error message, if possible.
It sounds like it might be a good idea for the emulator to simply write a copy of the movie-thus-far to a temporary file somewhere periodically, as long as the movie file isn't grotesquely huge. This needn't impact performance as it should be trivial to spin off into a separate thread.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Surely the OS-relevant temp directory (/tmp for Linux/OSX, and something like /Users/username/Local/AppData/Temp for Windows IIRC) would be a safe place to put such files?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
As for your "Crash", most "crashes" in BizHawk are actually exception that it can recover from just fine (Just click ok). So if you had your emulator completely die, I'd like to know specifically what you were doing, and what the error message, if possible.
As I said, I wish I'd taken a screenshot of the error at the time. All I can tell you is there absolutely was no "Okay" option - it was definitely a complete crash. All I did was record for roughly 9 hours with lots and lots and lots of saving and loading states.
Thanks for all the explanations, it's been very enlightening. I guess the SNES just feels so long ago in computer terms, it's easy to start thinking it should be trivial by now.
Edit: Oh yeah. And my CPU is an AMD Phenom II "Deneb", 3.4 GHz
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
In theory, your movie may be restored from the latest savestate you did. Uncheck Bind savestates to movies, start recording a new movie, and just load the state. It must bring you to the frame it was saved on, and if you stop your movie then, it will be saved to disc. Didn't try that myself, should work.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
creaothceann wrote:
Khaz wrote:
Edit: Oh yeah. And my CPU is an AMD Phenom II "Deneb", 3.4 GHz
Well on my AMD Phenom II X6 1050T ("Thuban") I get ca. 71-76 fps on SMW's intro (when the screen isn't blank).
But are you recording a movie? In BizHawk, we enforce deterministic emulation when recording. Unfortunately, in the case o bsnes, this necessitates savestating every frame which has a healthy speed cost.
So the same error that happened to me the first time just happened again. I took a screenshot this time:
It just started running slower and slower and finally died. It finishes crashing when you click OK. Anyone know what the problem is?
EDIT: Well, I think I know why it crashed this time. There were still three other instances of it allegedly still running in the background, each taking right about 25% of cpu capacity, sooo that could explain it.
What I don't understand, in that event, is why it crashed the first time. This time I was testing a glitch in a game that causes bizhawk to just freeze, I guess when I "End Task" it in that state the process stays running. The first time I was just doing normal playthrough recording and had only ever opened one instance of 'hawk.
At least I have my workaround to continue glitch testing
It just started running slower and slower and finally died. It finishes crashing when you click OK. Anyone know what the problem is?
EDIT: Well, I think I know why it crashed this time. There were still three other instances of it allegedly still running in the background, each taking right about 25% of cpu capacity, sooo that could explain it.
What I don't understand, in that event, is why it crashed the first time. This time I was testing a glitch in a game that causes bizhawk to just freeze, I guess when I "End Task" it in that state the process stays running. The first time I was just doing normal playthrough recording and had only ever opened one instance of 'hawk.
At least I have my workaround to continue glitch testing
