Is anyone else having problems setting hotkeys (primary hotkeys for the first controller to be specfific (I have tried others, too, of course))? It always closes down without an error message.
Sounds like it crashes with segmentation fault or hits some internal error but doesn't handle it or something...
What is the exact action that causes it to crash? Clicking to change the key? Changing those checkboxes in dialog? Changing the key class (alphabetic, numeric, editing, etc...)? Changing the key? Clicking OK (if so, with what values)? Clicking Cancel? Clicking Clear?
Also, does doing similar things with adding a keybinding (keybindings tab, add button) cause lsnes to bomb?
Presumably knowing when exactly it bombs would help figuring out what goes wrong...
Edit: Found a crash bug (probably not the same one, requires a joystick):
Have some joystick axis to be set to anything except disabled.
Set some hotkey to that axis (if axis pair type, either direction will do).
Go to joystick configuration, flip that axis between pressure type and axis pair type (or set it to disabled).
Go change the hotkey you set (the key will be blank)
Without changing the key or the class, hit OK.
lsnes will crash (due to trying to set invalid key as hotkey).
In general, clicking OK with key entry box blank (obtained by any means) will crash lsnes.
Oh. It's actually when I press the "Close" button on the configuration window.
And yes, setting a key in the "bindings" tab crashes lsnes, too.
I made a video: http://dl.dropbox.com/u/48454461/lsnescrash.avi
I've been attempting to build lsnes on Debian squeeze. Squeeze only has gcc 4.4, and the manual indicates that >=4.6 is required, so I started by installing 4.7. It looks like this actually doesn't work, though: I ran into
bsnes/nall/string/core.hpp:10:3: error: ‘make_string’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
In file included from /home/jake/bsnes/nall/string.hpp:29:0,
from /home/jake/bsnes/nall/dl.hpp:8,
from /home/jake/bsnes/snes/snes.hpp:24,
from ../../include/core/bsnes.hpp:5,
from lsnes-dumpavi.cpp:1:
/home/jake/bsnes/nall/string/cast.hpp:179:35: note: ‘template<class>
nall::stringify<T> nall::make_string(T)’ declared here, later
in the translation unit
Which is mentioned here as an incompatibility between 4.6 and 4.7. It also indicates that 4.7 has a compatibility mode that can be invoked with -fpermissive, and turning that on changes all the previous errors to warnings, but now I'm hitting
loadlib.cpp: In function ‘void load_library(const string&)’:
loadlib.cpp:25:22: error: ‘getcwd’ was not declared in this scope
and now I'm not sure how to proceed.
A patch to the code to fix the out of order function thing for 4.7 would be nice; failing that a mention in the manual that it will be necessary is probably in order. And of course, I would welcome any advice on how to overcome this latest obstacle :)
EDIT: Adding "#include <unistd>" to include/core/loadlib.hpp resolved that particular part of it, but now I'm running into some odd trouble inside boost:
misc.cpp:255:31: required from here
/usr/include/boost/exception/exception.hpp:399:44: error: use of deleted function \
‘boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector\
<boost::filesystem::basic_filesystem_error<boost::filesystem::basic_path\
<std::basic_string<char>, boost::filesystem::path_traits> > > >\
::clone_impl(const boost::exception_detail::clone_impl<boost::exception_detail::\
error_info_injector<boost::filesystem::basic_filesystem_error<boost::filesystem::\
basic_path<std::basic_string<char>, boost::filesystem::path_traits> > > >&)’
/usr/include/boost/exception/exception.hpp: In instantiation of ‘void boost::exception_detail::clone_impl<T>::rethrow() const [with T = boost::exception_detail::error_info_injector<boost::filesystem::\
basic_filesystem_error<boost::filesystem::basic_path<std::\
basic_string<char>, boost::filesystem::path_traits> > >]’:
This seems less likely to be lsnes's fault, but I'm pretty confused about why that "include <unistd>" was missing. And if anyone happens to know what's up with boost here, that would be great.
A warb degombs the brangy. Your gitch zanks and leils the warb.
I in some way had to patch the master branch in order to compile it with gcc 4.6.3 on Gentoo Linux. bsnes/target-libsnes/libsnes.cpp was complaining about GameBoy not being declared (as a namespace, I presume); however, including <gameboy> fixed this.
What baffles me is how lsnes manages to generate slightly more than 100% CPU load on a core i7 980X and is thus not always running smoothly. If it's of any use, I'm using wxwidgets for the GUI and Portaudio for sound (mainly because the SDL GUI seemed unusable and I didn't have the motivation to look up a correct value for --system=xxx in the source code).
Anyway: Thank you very much for making me believe in Linux TASing/TAS avi dumping again! It's been a blast seeing something compile (and run) on this box without having to boot VirtualBox. win32 devs, please don't take this the wrong way ;)
On a side note: How about support for newer versions of libsnes like 0.88 or even 0.89? I couldn't say if those version were any better than 0.87, but I'm sure there's at least some reason they've been released.
/edit@Personman: I'm using boost 1.49 and didn't have any problems compiling in that regard. If you need a (64bit) binary, drop me a note.
I in some way had to patch the master branch in order to compile it with gcc 4.6.3 on Gentoo Linux.
The master branch is quite broken. The branch that should be used is rr1-maint.
ShinyDoofy wrote:
bsnes/target-libsnes/libsnes.cpp was complaining about GameBoy not being declared (as a namespace, I presume); however, including <gameboy> fixed this.
target-libsnes means bsnes v087 (earlier ones have ui-libsnes).
I should look into this.
ShinyDoofy wrote:
What baffles me is how lsnes manages to generate slightly more than 100% CPU load on a core i7 980X and is thus not always running smoothly.
Bsnes accuracy core is very heavy. And the >100% CPU load is because lsnes multithreads (I have seen average CPU usage of ~200% when dumping).
Compat core does not seem to be any less accurate, except for some graphical glitches in few games, but is 2x faster.
Oh, and I got Turska's Chrono Trigger TAS to sync on compat, despite the extreme timing requirements.
ShinyDoofy wrote:
On a side note: How about support for newer versions of libsnes like 0.88 or even 0.89? I couldn't say if those version were any better than 0.87, but I'm sure there's at least some reason they've been released.
libsnes v088 and v089 don't exist.
In addition to seemingly not being buildable as a library (which would mean some patching work), bsnes v088 and v089 alter the internal interfaces quite a bit. So getting those to work would pretty much need the work to split the interface to emulation core out of emulator core.
That is one of the major goals for rr2 version, unfortunately it is quite a bit of work.
Seeing as you merged rr1-maint into master, I did some git pull'ing and ran into lua issues on the master branch, namely lua_callback_do_unsafe_rewind being undefined when linking. It seems you have neglected to update the signature in lua's dummy.cpp. This simple patch fixes it:
Seeing as you merged rr1-maint into master, I did some git pull'ing and ran into lua issues on the master branch, namely lua_callback_do_unsafe_rewind being undefined when linking. It seems you have neglected to update the signature in lua's dummy.cpp. This simple patch fixes it:
Should be fixed now, thanks.
ShinyDoofy wrote:
About the GB namespace before: Somehow the forums don't like stuff in angle brackets. It was supposed to #include [gameboy/gameboy.hpp].
IIRC, selecting "Disable HTML in this post" should help with that.
I've not really taken the time to read alot of this thread in general, but Ilari I was wondering if you have any plans to change the GUI a little? It looks very, well vague... compared to alot of the other emulators, and that itself isn't a bad thing.. I kinda like how it's different.. but things like setting up controller buttons (I do mean for the controller itself, not a joypad, I'm using a keyboard) and hot keys were very very confusing to me. Was wondering if things like that could be made a little simpler in the future as it was rather time consuming compared to pretty much all emulators to even set it up.
it seems like the wxwidgets version doesnt save my controller config, while it saves the config of for example "Load, Save, Movie..."
(I'm using the latest version: lsnes rr1-Δ8ε1 and i'm on Windows 7 64 bit if that means something)works now
edit: and i wanna say something about the memory watch...
- if you load a previously saved "memory watch file", it says #syntax (illchar) at every watch (yeah, it did show properly before i saved and loaded it)fixed in lsnes rr1-Δ10- it would be nice to have a function to delete watchessetting the expression to nothing is deleting the whole watch
- maybe it could be a bit easier to show simple ram addresses (not like C0x007e007bzb)
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
It would be nice to have some kind of tutorial for lsnes. I needed about one hour just to find out how to configure the keys. And the wxwidgets version doesn't work for me, maybe because I use two keyboards, the SDL version seems to handle that nicely.
An easy-to-use GUI would be nice. In the meantime, here is a little tutorial for those who want to give this emulator a try:
How to configure the controllers
- start lsnes-sdl.exe at least once
- open %appdata%\lsnes\lsnes.rc with some editor. for example notepad++
- look for for the lines starting with "bind-key"
- edit those lines, for example this way:
bind-key w +controller1up
bind-key a +controller1left
bind-key s +controller1down
bind-key d +controller1right
bind-key kp6 +controller1A
bind-key kp5 +controller1B
bind-key kp8 +controller1X
bind-key kp4 +controller1Y
bind-key kp3 +controller1start
bind-key kp2 +controller1select
bind-key kp_enter +advance-frame
bind-key pause pause-emulator
You can find out the correct key names in section 10 "Modifier and key names" of manual.txt or manual.lyx
How to start a game
- if your ROM doesn't end with .sfc: use SNESpurify to convert your ROM
and now, either:
- start cmd.exe
- cd into the emulator directory
- enter lsnes-sdl.exe --rom=<YOUR ROM HERE>
or:
- start lsnes-wxwidgets.exe
- click "Pick..." to choose your ROM
- click "Open ROM"
- click "Start" to create a new movie, and to start the game.
You can add this tutorial to the manual, or package it with the next release of the emulator, or modify it in some way.
- if your ROM doesn't end with .sfc: use SNESpurify to convert your ROM
Should not be needed (unless it is a bad dump, some really weird copier format or one of those weird double-headered ROMs).
Well, I haven't tested that. but I know that bsnes requires such a conversion in many cases. Anyway, I think the idea behind SNESpurify really makes sense to me. The emulator shouldn't have to handle all those obscure headers at all, because they are not present on the original SNES cartriges.
Thanks for v13 Ilari, the new build runs great.
However, for some reason my rerecords went way up. I think they should be 13K, instead of 93K. See the file below. Is there an easy way to edit this in the file, or should I just remember that overage when I submit?
http://www.mediafire.com/?y7nv8yyblvg79hi
However, for some reason my rerecords went way up. I think they should be 13K, instead of 93K. See the file below.
WTH? Looking at the data the file has about rerecords, the compression is OK, but the data itself has clearly gotten corrupted multiple times.
Basically, it looks like the project rerecord data file had a framing error [1] (reading junk from movie rerecord data would produce completely different type of corruption[2]).
The way that file is read/written should guarantee absence of framing errors, even if simultaneous writing corrupts records.
Syncwise, syncs for me.
The contents of file named %APPDATA%\lsnes\45e1f031c1007bda02038cbaf3b38a7fc022f7e1.rr could be useful in figuring out the order of events... ZIP / 7-zip (especially the latter) should be able to compress that file nicely (please don't use .rar, I can't unpack that).
[1] This type of corruption manifests as numerous records that are a shift of runs of other records appearing. This is exactly what is seen. Except that there isn't just one shift. There are multiple shifts (which would mean it has gotten frame-shifted multiple times.
[2] This type of corruption would very likely cause numerous runs of consecutive records, some millions of entries in length.
Ilari, here is the file you were asking about. I used a .zip compression since I only have winzip on this machine, but I can download a program with .7z if needed.
http://www.mediafire.com/?ie7i53z8zbvw884
I should also mention that rewinding the video and starting from an earlier spot (i.e., because a previous route wasn't working) tends to add around 400 rerecords. Not sure if it's due to the same issue or not, but it sounds like your [1] described.
Sorry if these problems are unique to Shadowrun, I'm not trying to be difficult.
Ilari, here is the file you were asking about. I used a .zip compression since I only have winzip on this machine, but I can download a program with .7z if needed.
Got it, thanks.
Basically, looks like earlier lsnes versions had buggy rerecord counting. The buggy versions worked correctly with movies from buggy version. But non-buggy version goes pretty crazy loading buggy data.
I tried to get non-corrupt estimate of rerecord count, getting 15708.
TheHepper wrote:
I should also mention that rewinding the video and starting from an earlier spot (i.e., because a previous route wasn't working) tends to add around 400 rerecords. Not sure if it's due to the same issue or not, but it sounds like your [1] described.
I don't think it is the same issue...
Found two other bugs:
- Read-only mode still overwrites lots of things it should not.
- Rerecord count display is buggy.
The latter can make it seem that rerecord count jumps around, even if it increments at 1 per load.
I also noticed, that there is no way to show what the emulator thinks is the rerecord count without saving and loading again.
I added task list entries for these three issues, will fix [EDIT: fixed in rr1-maint, will be in the next release].
TheHepper wrote:
Sorry if these problems are unique to Shadowrun
I don't think even the earlier desync problem was unique to Shadowrun.
These recording count issues are definitely not anything game-specific.
I downloaded the new build, and I think the rerecord issue is fixed. That is, rewinding and resuming a section of the movie recorded under v14 correctly added 1 rerecord. However, I gained around 2K rerecords after downloading v14 and resuming from a section recorded under v13. Below is my current movie file and the updated 45e1f file if you are interested.
http://www.mediafire.com/?rrli7qmi8y4sokzhttp://www.mediafire.com/?nk4ogjc96h6wiwlIs there a way to update the movie file with the correct rerecord count? If possible, I think this would be preferable to explaining in the submission text why the movie file has 79K additional rerecords.
Also, while I like the new memory watch features, if you have more than 12 watches on one list, it starts to push down the "Other status:" rows. (i.e., with 14 watches you cannot see the SPD% row).
Lastly I noticed the new build runs a bit faster. I see speeds in the 130-140% range when turboing now, so that's a nice improvement.
EDIT: Oh god, I screwed something up bad. The last 5 minutes of my run are worthless now, so an updated rerecord count is pointless.
I downloaded the new build, and I think the rerecord issue is fixed. That is, rewinding and resuming a section of the movie recorded under v14 correctly added 1 rerecord.
The issue corrected was just a display issue, not issue with underlying counting.
TheHepper wrote:
However, I gained around 2K rerecords after downloading v14 and resuming from a section recorded under v13.
Yeah, artifacts from data being corrupt. Basically, records are duplicated after emulator is restarted, up to 32 times for a single rerecord.
TheHepper wrote:
Is there a way to update the movie file with the correct rerecord count? If possible, I think this would be preferable to explaining in the submission text why the movie file has 79K additional rerecords.
Well, it would be possible to fix just before submitting (based on the .rr file and the movie file).
The rerecord count estimate so far seems to be 18635, but I am not completely sure that is accurate (I would need to check that there are no suspicious common prefix lengths).
TheHepper wrote:
Also, while I like the new memory watch features, if you have more than 12 watches on one list, it starts to push down the "Other status:" rows. (i.e., with 14 watches you cannot see the SPD% row).
I added "memory watch to dedicated window" as a TODO (that would let watch more addresses in one go).
Bit of a hacky idea that would work with current version: Set display scaling to something larger than 1x. That makes the window bigger, so more rows fit (since status panel does not scale with display).
And of course, there are Lua scripts too (idea for feature: Take in memory watch file and output a Lua script for watching)... Those can watch many more addresses.
Feature request Lua function to parse those lsnes memory watch expressions like C16zC0x7e0071zw*C16zC0x7e0075zB/+
This should basically be a one-liner to implement, because lsnes can already parse these statements.
Feature request: Lua function to parse those lsnes memory watch expressions
This should basically be a one-liner to implement, because lsnes can already parse these statements.
Well, not quite a oneliner (mainly due to having read/write values from/to Lua and Lua function boilerplate[1]), but still very simple to do.
(lambda functions for the win).
Also revealed a crash with certain kinds of memory watch expressions and a bug in my IRC announce script. :-)
[1] Granted, the boilerplate is only 1 line of code in itself.
