Joined: 10/27/2004
Posts: 1978
Location: Making an escape
I guess I'll be the first to bug report.
The WIP uploaded a few days ago has a lag counter; this is good. I can't set a button to toggle the lag counter on and off, and I can't pick where the frame/lag counter are; unless I am missing something, this is not good.
Neither the WIP nor the non-WIP seem to interface with snes9xwatch very well. An older version worked fine, but now I'm getting a blank with garbage where the ROM information should be.
Keep up the good work.
Edit[/b]: Ah, fixed the snes9xwatch issue. User error.
Edit The Sequel[/b]: Oh hey, a hotkey for the lag counter! *happy dance*
Yet Another Edit: Sound issues in the newest release: much of it sounds muffled, and any change to the settings mutes the sound until you restart the program.
A hundred years from now, they will gaze upon my work and marvel at my skills but never know my name. And that will be good enough for me.
The latest revision (just committed r94) compiles fine, but doesn't run for me on Linux. As soon as I try and run it, it segfaults. GDB isn't of any help (it doesn't even get to main()), neither is strace (although I can't really work with the latter). Through test with an older copy (that still works), I found out that x11.cpp seems to be the one at fault, but I have no clue as to why this is the case.
Between those two builds, quite a few changes were made on my system: GCC was updated from 4.2.1 to 4.3.2, I got a new Xorg server (1.5 instead of 1.3), mesa was updated, the proprietary nVidia drivers I'm using were updated, stuff like that.
Bisqwit's snes9x from the MakingAVI site still compiles fine and works, same for the latest SVN revision of snes9x-1.51.
If anyone has any idea or patches, I'd really appreciate it.
gdb outputstrace output
/edit: After some more tests, it turns out that gcc is screwing me over. Compiling unix/x11.cpp with with gcc 4.1.2 doesn't result in segfault and runs perfectly fine, while compiling the very same file with the very same parameters with gcc 4.3.1 makes it segfault. What I also found to be really weird is the size difference: x11.o is ~264KB with 4.1.2, yet only ~126KB with 4.3.2.
compiles fine, but doesn't run for me on Linux. As soon as I try and run it, it segfaults.
I think I found that awhile ago. Fixed it locally, but I guess I should have sent in a patch. In the future, I'd be glad to do so, but I don't know exactly how SVN works, or if I have the necessary permissions.
But basically, someone goofed in x11.cpp around 1025:
READONLY_MOVIE_TOGGLE,
FRAMEADVANCE,
SEEK,
LUA_CONTROL,
FUNC_LAST = LUA_CONTROL /* update this to match the last token */
};
FUNC_LAST is set to SEEK in the SVN code, causing a segfault elsewhere in x11.cpp.
I'm not sure how to explain your difficulties, or the GDB output you posted, other than that maybe you didn't use debugging symbols when you built.
but I don't know exactly how SVN works, or if I have the necessary permissions.
As of now, you don't have the permissions. You can always update the your local working copy to the public one with "svn up" when you're in that directory. With "svn stat" you can get a list of files that were modified (M) or are new/unknown (?). Run "svn diff file1 file2 dir3/file4" to get a diff-like output of your local changes.
Anyway, your patch really fixed this and neither do I know how or why gcc 4.1.2 ignored this and ran fine, but I'm really glad it runs now. Thanks a lot!
Dromiceius wrote:
I'm not sure how to explain your difficulties, or the GDB output you posted, other than that maybe you didn't use debugging symbols when you built.
That's the beauty of it: I replaced "-O2" with "-g" in the Makefile when I got that output.
/edit: just committed r95 with your patch.
A lot of desync fixes. Older versions cannot read the new savestate. Also, a new sync flag is added to SMV. Most SMV editors might not care about the new flag byte. Be careful, or you might experience a desync.
Improved Lua engine.
Fixed noise generation.
Added 4-point gaussian interpolation.
Added lag counter and modified frame display around.
Win32: Added several settings from snes9x.cfg to GUI.
Win32: Redesigned menu overall and added some new settings.
Win32: Merged OV2's new sound code.
Notes
"Clean FastROM setting" must be always checked, unless if you were going to continue your old work.
Sync Sound issue under multicore CPU might be gone, might not.
_________________
*1 It's not added to the downloads section yet, since it's not quite easy to remove libs from the latest source code, and it makes compiling harder.
Snes9x v16 in Linux desyncs on playing back demos(and maybe just desyncs in general). Tested Cpadolf-SM-100%.smv with Super Metroid (JU) [!] ROM. It desyncs at the fight with ridley somehow. The reason I know this is in Linux only is I downloaded v16 in my Windows Virtual Machine and played the full demo back with no issues.
Sorry that I can't provide more info, I don't know how the demo actually breaks.
I haven't tested that particular run myself, but I know of at least 2 others that desync almost immediately. According to gocha, the emulation should be done in the core, i.e. platform-independent. But there are still some little hacks like sound sync and fake mute that have different/missing implementations on the *nix port. If you want to give it a shot, feel free to commit a patch :)
Lua: embedded LuaBitOp as a better/common bit operation library.
Lua: added/changed a lot of functions. It has become like Gens a little more.
Lua: windows: added Lua console.
Win32: added Gens compatible RAM Watch and RAM Search. Old search is still left. You can convert old watchlist by using it.
Win32: added trace logger. (ported from bsnes, thanks byuu)
Update Logs
2009-11-23 15:48 JST (r123) - Replaced the file. Hopefully Lua no longer affects to AVI recording.
_________________
*1 It's not added to the downloads section yet, since it's not quite easy to remove libs from the latest source code, and it makes compiling harder.
v17 crashes when you try to start it if it was in fullscreen mode when you closed it. The only solution I've found is to delete the .cfg file. Just throwing this out there in case another revision is done.
Joined: 8/15/2005
Posts: 1943
Location: Mullsjö, Sweden
I know that the the development on 1.43 has stopped, but as people are still using it (Including myself) and that is still an acceptable emulator, I can just as well write some bugs and hope that they might be fixed.
When you make and load save states, if you aren't using frame advance, the game may speed up heavily for no reason. This is no problem when TASing though, but it's highly annoying and should simply not be this way.
But what is an problem, however is that sometimes when you load a save state, the screen will go black for the next frame, and half black the next, causing the game to lag once. This can also happen when you are watching a movie, causing it do desync.
An example when this happens in Donkey Kong Country (There are many other situations as well) is when you pause the game. While it is paused, make a save state, load it and the game will lag.
Sometimes when you TAS other places, you simply "aren't allowed" to load a save state sometimes, as it will just lag.
This is a huge problem and if someone know why it happens and can fix it, this would be much appreciated.
Also, I'm talking about the latest 1.43 version, v17.
Joined: 6/21/2006
Posts: 401
Location: Japan, Nagoya
New version of snes9x-rr of both 1.43 and 1.51 are released.
http://code.google.com/p/snes9x-rr/downloads/list
The purpose of this release is mainly to fix the unreliable Lua timing things. Because of deprecation of Snes9x, I wanted to write a migration help script from Snes9x to BizHawk, but I wanted to fix some of Lua unreliabilities before I start working on it.
There are no emulation changes, you can use the previous version when the new one has a new stupid bug.
Apart from that, I was quietly developing snes9x-rr 1.54-dev on github. It has some nice feature such as more Gens-like Lua engine but I have already lost my motivation and I guess the development will be almost paused. If you are interested in the latest development of snes9xgit-based snes9x-rr, tell me and I shall gladly add you to the project.
https://github.com/snes9x-rr/snes9xChanges
Check SVN commit log for more information.
Add movie "finished" state.
Fix a sort of 1 frame delay problem, mostly.
Lua: fix joypad get/set function. (that was terrible)
New version of snes9x-rr of both 1.43 and 1.51 are released.
http://code.google.com/p/snes9x-rr/downloads/list
The purpose of this release is mainly to fix the unreliable Lua timing things. Because of deprecation of Snes9x, I wanted to write a migration help script from Snes9x to BizHawk, but I wanted to fix some of Lua unreliabilities before I start working on it.
There are no emulation changes, you can use the previous version when the new one has a new stupid bug.
Apart from that, I was quietly developing snes9x-rr 1.54-dev on github. It has some nice feature such as more Gens-like Lua engine but I have already lost my motivation and I guess the development will be almost paused. If you are interested in the latest development of snes9xgit-based snes9x-rr, tell me and I shall gladly add you to the project.
https://github.com/snes9x-rr/snes9xChanges
Check SVN commit log for more information.
Add movie "finished" state.
Fix a sort of 1 frame delay problem, mostly.
Lua: fix joypad get/set function. (that was terrible)
Win32: fix AVI, HUD and Lua drawings of interlaced games.
What happened? I always wonder why any rr version past 1.52 has been killed off? The SPC700 emulation improvements are what make these tolerable to use; anything prior makes the games sound like crap.
What happened? I always wonder why any rr version past 1.52 has been killed off? The SPC700 emulation improvements are what make these tolerable to use; anything prior makes the games sound like crap.
Not really "killed off". 1.52 and 1.53 are definitely accepted for submissions and even saw occasional submissions. But I think the lack of tools made them quite unpopular.
What happened? I always wonder why any rr version past 1.52 has been killed off? The SPC700 emulation improvements are what make these tolerable to use; anything prior makes the games sound like crap.
Not really "killed off". 1.52 and 1.53 are definitely accepted for submissions and even saw occasional submissions. But I think the lack of tools made them quite unpopular.
Makes sense, but it sure as heck seemed like it. I'd use the other Snes TAS emulators, but since they use Bsnes 0.87-based cores, they kill performance on my IdeaPad Y570...Well, you get the picture. Here's hoping someone continues to support 1.52+. lsnes and BizHawk might be too much for the Core i7 2670QM to handle.
lsnes and BizHawk might be too much for the Core i7 2670QM to handle.
I think CPU like that ought to get at least 1.5x of real time on most games with compatibility core (enhancement chips slow things down, and SGB is really terrible speed-wise).
Of course, this is much slower than snes9x (even the later versions, which are much slower than the earlier ones).
lsnes and BizHawk might be too much for the Core i7 2670QM to handle.
I think CPU like that ought to get at least 1.5x of real time on most games with compatibility core (enhancement chips slow things down, and SGB is really terrible speed-wise).
Of course, this is much slower than snes9x (even the later versions, which are much slower than the earlier ones).
Most games will go full speed, but audio synchronization issues (audio popping)still exist when trying to sync with 60 Hz monitors ... Oh, well. I'm wondering why BizHawk can't use an Snes9x 1.53-based core in an alternate release. Two flavors of BizHawk would be most excellent, but it'll never happen (wishful thinking on my part). Yes, Snes9x 1.52+ is not as accurate as Bsnes, but most TAS video people won't even tell any major differences anyway. After all, people still re-record with Snes9x 1.43 an 1.51, which is sad.
most TAS video people won't even tell any major differences anyway.
I did. There was lots of things that lagged due to console limitations of the game on Bizhawk that don't on Snes9X.
Accuracy in an emulator is important in a TAS. If things that don't lag in the TAS of an old emulator but does on the console makes people question why it doesn't. That's why accuracy increases, so it never comes to that problem. With people making new routes or methods to deal with lag.
audio synchronization issues (audio popping) still exist when trying to sync with 60 Hz monitors
Have you tried the latest bsnes and RetroArch builds? They have new techniques for synchronizing; if they work better for the majority of people then maybe they could be adopted.
audio synchronization issues (audio popping) still exist when trying to sync with 60 Hz monitors
Have you tried the latest bsnes and RetroArch builds? They have new techniques for synchronizing; if they work better for the majority of people then maybe they could be adopted.
Oh, no I haven't, all I see on this site http://themaister.net/retroarch.html is version 0.9.7, but I doubt that's the version with those A/V sync techniques you mentioned. Do you know where to get up-to-date precompiled SVN builds? Any version of Bsnes I've tried past 0.87 have been giving me nothing but trouble (since the Performance core was dropped a long time ago), not to mention, I'm not terribly fond on how the GUI functions or how it's used.
I thought my CPU was sufficient, but I guess not. Does RetroArch have TAS capabilities, too?
Edit: I'm doing something wrong, I choose the core, launch the game, but the GDI window doesn't launch. Directories get configured but they don't save when you exit.
Yeah, 0.97 is the latest. Where did you extract it to? Maybe it works when run as administrator.
These are my steps:
- download 0.9.7, extract it and run retroarch-phoenix.exe
- select "menu | RetroArch | Update RetroArch"
- click "Check version"
- select "SNES / bsnes / 089 compatibility" ("Full" checkbox checked) and click "Download core"; click "Yes" in the message about using the core
- go to "menu | Settings | Video" and enter the frequency I get with FreqTest 1.6 (for bsnes I use this)
- in the Audio window, switch to XAudio (on Vista/7)
- (plus some unrelated settings like bilinear filtering and 4:3 aspect ratio)
- in the main window, select the ROM and click "Start RetroArch"
EDIT: Maybe change the graphics driver?
Yeah, 0.97 is the latest. Where did you extract it to? Maybe it works when run as administrator.
These are my steps:
- download 0.9.7, extract it and run retroarch-phoenix.exe
- select "menu | RetroArch | Update RetroArch"
- click "Check version"
- select "SNES / bsnes / 089 compatibility" ("Full" checkbox checked) and click "Download core"; click "Yes" in the message about using the core
- go to "menu | Settings | Video" and enter the frequency I get with FreqTest 1.6 (for bsnes I use this)
- in the Audio window, switch to XAudio (on Vista/7)
- (plus some unrelated settings like bilinear filtering and 4:3 aspect ratio)
- in the main window, select the ROM and click "Start RetroArch"
EDIT: Maybe change the graphics driver?
Did all that, force enabled the program to use the nVidia GPU driver, nothing. Even after telling where to point the main directory, the directory settings never save upon exiting the program. In fact, none of the settings I change in the video, audio, etc windows save, they all reset to default. WTF? Man this sucks balls, I can't use this program without it giving me hell. None of the configurations ever gets saved, even after running it as Admin.
Once I launch the ROM, it opens a second instance of the emulator and fails to load the GDI window for said core.
I might as well screw the whole effing thing. To hell with it, I'll create a new directory, this one may be corrupted.
