Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
Now that we've fully derailed this train, can we get it back on the tracks please?
Bag of Magic Food wrote:
You can never say that someone missed your sarcasm, because they'll just say you missed theirs!
I stand corrected,
andymac, your sarcasm sucks.
That's probably the biggest hurdle. I am very, very big on release early, release often. And indeed I have no desire to maintain backward-compatibility at the expense of progress.
I'm at v048, and I think since bsnes started, there's only been one new release of ZSNES, and two of Snes9X.
It will probably make sense to make a feature-freeze branch at one point (say, after that cycle-PPU thingie gets finished), and only update it once per year or so. On one hand, it will let you update the main branch as often as you see fit, on the other, it will reduce the version conflicts to acceptable minimum.
Here's another approach: Separate the emulation core from the rest of the application and develop them separately.
The core to be used would be selected (via dropbox, config file setting, whatever) before playing or recording. You would be able to use one binary and set of configs to play any number of versions. When a movie is recorded, the core being used would be keyed to the input file, so viewers know which core to use. Since it's all transparent to the user, this frees you up as the developer from worrying about the frequency of releases.
I think this would be a good model for any fast-moving emu, e.g. MAME and MESS derivatives.
bsnes v0.051 released
Starting with this release, I wish to take bsnes in a new direction. It has always excelled in accuracy, as the only SNES emulator to offer a full 100% compatibility rate with all known commercial software. But over the years, it has also gained an impressive array of features and enhancements not found anywhere else. It is also the only actively developed SNES emulator with rapid, periodic releases. Its only achilles heel is the steep system requirements, which is quickly being overcome by aggressive new optimizations and steadily-increasing hardware speeds.
In an effort to make bsnes even more accessible to everyone, starting with this release, bsnes is now fully open source software, licensed under the terms of the GNU General Public License. I would like to work toward positioning bsnes as a truly general use emulator, and would welcome any help with this.
Specifically, I am looking for an interested Debian maintainer to package bsnes for Linux users; as well as for anyone interested in helping to optimize and improve bsnes as a whole. It also seems that many still do not know about bsnes, I'd appreciate advice and help on spreading the word. Please leave a message on my forum if you are interested.
I would also welcome and support any forks that target specific areas: a speed-oriented version, a tool-assisted speedrun version, netplay bindings, and so on. As part of this targeting, I've also released a custom debugger-enabled version, which trades a bit of speed in turn for best-in-class debugging capabilities.
Please check back here over the following few days, I'll be writing up documentation explaining all of the various unique features of bsnes, as well as detailed compilation instructions for programmers.
Changelog:
* corrected a small bug in HDMA processing; fixes College Football '97 flickering
* corrected ROMBR and PBR SuperFX register masking; fixes Voxel demo [MooglyGuy]
* DSP-4 driver AI bug fixed [Jonas Quinn]
* added save state support to the S-DD1, S-RTC, DSP-1, DSP-2 and ST-0010 co-processors
* fixed a freeze issue when the S-SMP encounters STOP and SLEEP opcodes
* Cx4 save states no longer need floating-point values, and are thus fully portable now
* added new custom file loading dialog; allows non-modal usage, screenshot previews and ROM info summary, among many other benefits
* added support for IPS soft-patching
* added blargg's File_Extractor library
* added support for archives compressed using 7-zip, RAR and BZip2; which is in addition to existing support for Gzip, ZIP and JMA
* state manager now properly updates the timestamp column on saves [FitzRoy]
* added OpenGL renderer to OS X port
* fixed system beep issue with keyboard input on OS X port
* fixed menubar visibility issue on OS X port
* fixed a Display handle leak on Linux port [snzzbk]
* X-video driver now releases SHM memory properly upon exit [emon]
* fixed Direct3D rendering issue that was blurring video on some cards [Fes]
* enhanced window positioning code for all platforms
* debugger is now GUI-driven instead of via command-line
* memory hex editor is now fully usable
* added PPU video RAM viewer to debugger
* added S-CPU and S-SMP tracing capabilities to debugger
* Qt version upgraded to 4.5.2, and compiled with optimizations enabled; runs faster but makes the binary slightly larger
* too many code cleanups to list
EDIT: the user manual is now up. Please have a look, perhaps there are features there which you weren't aware of ;)
[ Discuss ]
Well, I suppose you can invoke the "TAS mode" every time during movie recording (but not when the input is not logged in any way), but sacrificing precision in this mode would probably defeat the purpose of making a TAS emulator out of bsnes in the first place, wouldn't it? What are the disadvantages of your first idea?
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I really don't think this is going to be a problem. Some emulators (such as mupen64) are accepted by the site but have known desync issues. Without any experimentation, I don't think anyone can say whether the loss of precision is significant enought to warrant a "TAS mode". TASers are well aware of the issues of desyncs, and there are many techniques used that TASers can use to avoid them. Regular replays of the movie are done by many TASers to check for such issues.
Joined: 4/2/2008
Posts: 103
Location: The Netherlands
Instead of calling it 'TAS mode' you could always call it 'desync proof mode' and put a note in the manual about it being slightly less accurate. Then TASers can make the choice on their own.
Another possibility would be to put 'resync' events into the TAS files, so bsnes knows when a savestate was made and loaded and can synchronize its cores accordingly. Depending on the type of game and/or dedication of the TASer, this could involve a lot less actual synchronization (and it gives you a definite number of reloads-actually-used, if you wanted to know).
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
While I agree that 'resync' events could be used, it does defeat the purpose of movie files only having button input in them (Ignoring SRAM and savestates).
It'd be more productive to have someone that can have a real say on the issue to give input though. =P
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
byuusan wrote:
We could offer the standard movie mode that doesn't use sync points, which would be virtually TA-proof.
Virtually?
TA-proof doesn't really exist.
If the timing happens to remain the same between the two modes, the emulator could be hacked to add a convert a movie from TA mode to non TA mode.
Or you could run the emulator within a VM which has TA capabilities.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I'm not sure if this would work, but in my opinion, having a separate mode for TASing would defeat the purpose of using bsnes, because there would be a loss in precision, however small, and the whole reason to use banes is because of its infinite accuracy.
Anyway, my idea goes like this: when TASing, use the normal recording mode, but there must be some way to see if a certain save is problematic, and when this occurs, notify the TASer, or find a workaround such as saving a few cycles before or after.
Also, If you happen to know exactly how the save is problematic, then wouldn't it be possible to add some "resynch" data to the save, which could rectify any errors?
I'm not sure if this would work, but in my opinion, having a separate mode for TASing would defeat the purpose of using bsnes, because there would be a loss in precision, however small, and the whole reason to use banes is because of its infinite accuracy.
Why so? If it's better it should be used. Proving it has "infinite accuracy" might be a bit problematic anyway, so why not just settle with much more accurate than current approaches even if there's a minor loss in accuracy due to separate mode?
Not to mention byuusan mentions this special mode would have other benefits as well.
"Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your home."
( Pratchett & Gaiman: Good Omens )
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I'm not exactly sure which benefits you happen to be reffering to.
Also why should you settle for good when the best is in reach? But, hey you know what? It's byuusan's decision, not mine or yours.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
I agree. I'm pretty excited that you're working on this for bsnes.
Now how about implementing Nestopia-style opcode-level rewinding (not sure if it actually is opcode-level, but it seems to emulate in reverse using a saved history) while you're at it, hmm? ;) Ok, I realize that would be a little ridiculous at this point, considering all that I've read about how bsnes works on your site.
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
byuusan wrote:
Okay, I've added standard movie recording and playback. Works from reset or from any arbitrary point in the game (via embedded save state.)
The playback is very stable on first try, no desyncs on a playthrough of the first stage of Dracula X.
...
I'm not quite sure how many TAS tools I want to implement directly into my emulator; as one of my design goals is to keep the GUI clean and simple.
It sounds pretty good already. As for your second problem; shortcut keys?
This sounds really good! We should get to testing this, and hopefully replace snes9x as the default snes emulator here, as soon as possible. Once we have LUA in place (this should be easy to add ourselves, without bothering byuu with it), it should be better than snes9x in every way.
By the way: What is the resolution of the stepping in bsnes? Most of the time frame-stepping is enough, but as the Chrono Trigger movie showed, one sometimes wants instruction level stepping etc. too.
By the way: What is the resolution of the stepping in bsnes? Most of the time frame-stepping is enough, but as the Chrono Trigger movie showed, one sometimes wants instruction level stepping etc. too.
Answered on this page, look for byuu's earlier post above.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
