Had a short discussion over IRC. I want to post to give some closure here.
Ilari wrote:
Even my laptop (much less powerful than my desktop, and even that is oldish) can run it at about 90fps if no exotic chips are involved.
Running the latest lsnes still isn't much faster. This computer is single-core. As for the specs, I'm somehow unsure about how to go about finding that out.
Ilari wrote:
on_idle? That shouldn't be hard (although one has to be careful not to waste CPU by spending too much time polling if such hook exists!)
Not really for the idea of an on_idle callback. But I'm not against it either. There are enough methods already available I can use without demanding processing power when there is no activity.
Still, this would mean that I have access to creation of repeating commands when there is no further activity with input devices. Even on this text here, I can simply hold down some letter and watch as it repeats typing it. Like holding a: aaaaaaa - There are no changes to the keyboard after the initial press, but it still repeats adding the letter several times.
At the moment, though, I don't foresee a major need for repetition or animation with emulation paused or no user input changes. Regardless, I suggest allowing the user to tweak the sleep value if this would be implemented. I also like how wxwidgets takes virtually no processing power while idling, and I hope the existence of such an option doesn't change that fact, during such cases where there is no lua running or the script doesn't contain on_idle.
Ilari wrote:
local SinceThenTable= {}
local Snoops= 0
function on_paint()
if #SinceThenTable < 1 then
gui.text(1,1,"Nothing!",0xFFFFFF,0)
return
end
local Y= 1
for i= #SinceThenTable, 1, -1 do
gui.text(1,Y,SinceThenTable[i],0x7FFF7F,0)
Y=Y+20
SinceThenTable[i]= nil
end
gui.text(180,1,Snoops,0xFFFFFF,0)
Snoops= 0
end
gui.repaint()
function on_input(b)
local str= "on_input, false"
if b then str= "on_input, true" end
table.insert(SinceThenTable, str)
end
function on_frame() table.insert(SinceThenTable, "on_frame") end
function on_snoop() Snoops= Snoops+1 end
Ilari wrote:
Eh, the way on_startup() currently works, it isn't useful. [...]
One thought that crosses my mind might be when you reset back to frame zero. on_reset does not get called when the user decides to go back to the beginning of the movie.
Ilari wrote:
FatRatKnight wrote:
A request: A callback for when a request to advance a frame takes place. [...]
The frame advance button has autorepeat, so one hold may advance more than one frame...
My main thought was that sometime after the screen gets painted, if emulation is about to continue for any reason, then check for the appropriate callback.
on_input alone might be enough for what I'm looking for, though.
Ilari wrote:
As to on_input() occuring twice but on_snoop() just notifying each button once, that's very strange. You are sure not even one button is polled twice (two on_snoops for one button), because that would explain two on_input()s (yes, I have seen game poll for just one button).
on_input() can legitly occur more than once per frame if game polls more than once per frame (some do).
I'll need to check if the logic is right...
I'm pretty sure on_snoop is telling me each button is polled once, and on_input is called twice. But we already mentioned some of this in IRC. I'm working on a basic input script and it told me each button is polled exactly once, and of course there's the above script.
But you've also taken steps to fix this by now. I'm glad to have pointed this out, in any case.
Even my laptop (much less powerful than my desktop, and even that is oldish) can run it at about 90fps if no exotic chips are involved.
Running the latest lsnes still isn't much faster. This computer is single-core. As for the specs, I'm somehow unsure about how to go about finding that out.
If it is single-core, no wonder it is so slow. No CPU chip that is even near modern performance is single-core.
FatRatKnight wrote:
Ilari wrote:
on_idle? That shouldn't be hard (although one has to be careful not to waste CPU by spending too much time polling if such hook exists!)
Still, this would mean that I have access to creation of repeating commands when there is no further activity with input devices.
At the moment, though, I don't foresee a major need for repetition or animation with emulation paused or no user input changes. Regardless, I suggest allowing the user to tweak the sleep value if this would be implemented. I also like how wxwidgets takes virtually no processing power while idling, and I hope the existence of such an option doesn't change that fact, during such cases where there is no lua running or the script doesn't contain on_idle.
Actually, one can take advantage of the fact that the presence or absence of such hook can only change when internal event queues are nontrivially run. And that requires activity when paused.
But there is second issue, which only happens if there really is a on_idle hook active:
How to know when to re-invoke it? Continuously re-invoking would obviously eat 100% CPU.
FatRatKnight wrote:
Ilari wrote:
FatRatKnight wrote:
The on_frame() callback is not called [...]
Hmm... Sounds bit odd. I take a look at this.
I made that determination with this script:
Ah, I think it is the ordering: on_paint() will occur first, then on_frame().
FatRatKnight wrote:
Ilari wrote:
Eh, the way on_startup() currently works, it isn't useful. [...]
One thought that crosses my mind might be when you reset back to frame zero. on_reset does not get called when the user decides to go back to the beginning of the movie.
on_reset is SNES reset. There doesn't seem to be a hook for rewinding the movie (should be added).
The first frame is frame one...
But there are are conditions that can cause frame counter value of zero:
* Before the emulator is fully up.
* Possibly in on_post_load hook.
* Possibly if the emulator thinks system core state is corrupt.
Oh, and there is a way nontrivial on_startup() can occur on both wxwidgets and SDL: Run Control file invoking some lua script or statement that installs on_startup hook.
FatRatKnight wrote:
Ilari wrote:
FatRatKnight wrote:
A request: A callback for when a request to advance a frame takes place. [...]
The frame advance button has autorepeat, so one hold may advance more than one frame...
My main thought was that sometime after the screen gets painted, if emulation is about to continue for any reason, then check for the appropriate callback.
on_input alone might be enough for what I'm looking for, though.
It seems that on_input() will always be called when emulator is resuming from normal pause (modal pauses are a different matter, but shouldn't concern Lua scripts).
Ah, I think it is the ordering: on_paint() will occur first, then on_frame().
It still feels odd, however, that I can run the script, hit the frame advance key once, and never see on_frame() called... According to on_paint, anyway.
Though, what you say make sense. on_paint would be called, but the script isn't running yet. Then on_frame would be called, but again, no script. Emulation halts here, awaiting further user requests. Then I start the script, and advance one frame. on_paint is called, notably without any indication from the on_frame routine, and acts accordingly. Then on_frame gets called. Then lsnes awaits my next frame advance request. Since on_frame was called, it put an indication of itself in my table. on_paint hasn't been called since then to empty it -- The next time it is called, on the second frame advance, I finally see the indication.
How difficult would it be to reorder this? From what I gather, it is apparently:
[frame boundary], [emulation], on_paint, on_frame, [frame boundary].
How difficult would it be to turn it into:
[frame boundary], on_frame, [emulation], on_paint, [frame boundary], or
[frame boundary], [emulation], on_frame, on_paint, [frame boundary]?
As it stands, any information that on_frame would provide is not yet seen by on_paint when the emulation halts. Only when on_paint is called again would the information be read; This is possible through gui.repaint() from lua (two gui updates per frame with this function in on_frame is not a good workaround), or advancing one more frame, and have the information it would provide be out of date by one frame.
So, I feel where on_frame is located in the ordering is a bit inconvenient. I've stated my reasons why I find it inconvenient. I can understand if there are difficulties in reordering this, as while it looks like a simple switching of the order things happen in, I'd be surprised if the only thing to do was to move a function call up one line.
In any case, I believe on_paint (and other display updates) generally should be the very last thing called when lsnes finishes processing whatever and goes back to being idle.
Next time you update this topic, I recommend changing the title to reflect the current version. I have one suggestion: "lsnes rr1-Δ4ε1: Rerecording with bSNES core". Hopefully it will give a nice sense of progress to anyone who wish to follow.
Another error spotted in rr1-Δ4ε1:
Hotkey modifications (alt, ctrl, meta, shift) in wxwidgets do not appear to be working properly. Setting a modification to be pressed is either ignored (set hotkey to e and shift to be pressed) or blocks the key entirely (set hotkey to q and shift to be pressed).
Besides that, wxwidgets doesn't like alt keys for the reason of those pulldown menus.
I have begun TASing attempts (Yoshi's Cookie) and it appears to be sync-stable so far. As things continue to develop, I may want to provide a variety of input lua scripts to help ease others into using lsnes. At the moment, I am holding on to one (if not PM'd already, it will be shortly sent), which although is only good for one controller, is a useful step forward as I get more familiar and the lua functions get better developed.
Next time you update this topic, I recommend changing the title to reflect the current version. I have one suggestion: "lsnes rr1-Δ4ε1: Rerecording with bSNES core". Hopefully it will give a nice sense of progress to anyone who wish to follow.
Will do (with apporiate version number).
FatRatKnight wrote:
Another error spotted in rr1-Δ4ε1:
Hotkey modifications (alt, ctrl, meta, shift) in wxwidgets do not appear to be working properly.
I actually discovered that bug earlier and already have fixed it in the repository maint. branch, so the next version won't have it.
Watch the video, it shows how much the timing differs between ZSNES, SNES9x and bsnes (note that in the beginning, ZSNES is sometimes earlier than SNES9x). Top row is the emulator output, bottom row is simply the difference to bsnes.
The no$sns column is included only to show what SNES features no$sns is still missing; getting an accurate frame-by-frame video output of that emulator is difficult because it has to be done via an external program (kkapture).
Currently developing MtEdit for lsnes and I spot a critical error in callback implementation that, for the most part, makes the entire script useless.
on_input(false) is called just prior to a successful state load. It is not called on the frame advance that may follow. The value of movie.currentframe() returned for on_input at this time is the value just before the state load.
End result: It is impossible for me to load the proper input and apply it following a successful state load.
It is also impossible for an input script to override input immediately following a state load. MtEdit requires the possibility of absolute control over the user's input, and TASing is all about state loads (among other things; MtEdit is a TASing script), the script's use is severely limited.
Despite errors in callbacks, lsnes does get user input without trouble. It gets this user input without calling on_input, for whatever reason.
Selecting "Run Lua script" and selecting some lua script does not clear out the previous script's functions. Intentional or not, this can cause some unexpected interactions between scripts.
Notably, I have a test script that sets on_paint to nil before state load, and to some specified function after state load or load error (I dislike on_paint's timing relative to some callbacks). Quite a surprise, then, that I should see this script's display when I run a different script and load state. Or see nothing if I have on_post_load in this new script.
A lua-side workaround is simple enough: Set all unused callbacks to nil. This ensures previous scripts generally stop interfering. Though, I'm still worried how the local variables in there are still taking up memory, however.
At least I'm aware of this behavior. I'm not necessarily calling it a glitch, but what it does is certainly not what I expected. Restarting lsnes is sure to clean out the lua mess that crops up, as well, so a fresh start works as intended.
Do you think the audio will sound less raspy in newer revisions? The most recent version sounds off to me for some reason.
Yeah, the audio should be fixed.
On the good side, dumps (for encoding) don't suffer from that problem (the .sox dumps are bit-for-bit, .avi is very close, especially 32040/32041Hz modes).
Watch the video, it shows how much the timing differs between ZSNES, SNES9x and bsnes (note that in the beginning, ZSNES is sometimes earlier than SNES9x).
Wtf, ZSNES fails even static images.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Ilari wrote:Yeah, the audio should be fixed.
On the good side, dumps (for encoding) don't suffer from that problem (the .sox dumps are bit-for-bit, .avi is very close, especially 32040/32041Hz modes).[/quote]
That's good, but I don't know jack squat on using lsnes. I assume I just dump the video in its native format, play it back, then select a codec I want to encode it to? What about using a joypad (I'm using an using a PSX to USB adapter)
That's good, but I don't know jack squat on using lsnes. I assume I just dump the video in its native format, play it back, then select a codec I want to encode it to?
The current versions use CSCD (Camstudio Codec) for .avi dumping (there are also some more exotic dumping formats).
That codec should be Youtube-friendly (can be directly uploaded).
the_randomizer wrote:
What about using a joypad (I'm using an using a PSX to USB adapter)
Use something like Joy2key (The build doesn't natively support joysticks, as there is no Win32 joystick code yet).
That's good, but I don't know jack squat on using lsnes. I assume I just dump the video in its native format, play it back, then select a codec I want to encode it to?
The current versions use CSCD (Camstudio Codec) for .avi dumping (there are also some more exotic dumping formats).
That codec should be Youtube-friendly (can be directly uploaded).
the_randomizer wrote:
What about using a joypad (I'm using an using a PSX to USB adapter)
Use something like Joy2key (The build doesn't natively support joysticks, as there is no Win32 joystick code yet).
Then the documentation will list the default keys, right? Joy2Key is a good program, though.
So I have to ask. Why name the emulator "lsnes"? Why not something that makes its' bsnes heritage more clear (like "bsnes-rr" or something)?
(I'm wondering since I noticed the change in preferred emulator notice on the front page to something I had never previously heard of, wondered why they chose some random unknown emulator over bsnes, then went to the forums and then figured out it essentially was a "bsnes-rr". I'm sure the name's going to confuse a bunch of people.)
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Tilus wrote:
So I have to ask. Why name the emulator "lsnes"? Why not something that makes its' bsnes heritage more clear (like "bsnes-rr" or something)?
Well, it's not bsnes.
It uses the core of bsnes, but the GUI and all these features on top have nothing to do with bsnes and are custom designed. Not even loading a file is handled remotely like bsnes handles it.
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.
Is it open source? I'm not trying to fling stones because I love the fact that someone finally used BSNES to make a re-recording emulator but this is one of the most unintuitive gui's I've ever had to deal with in any software =/.
Joined: 11/14/2005
Posts: 1058
Location: United States
Pasky13 wrote:
Is it open source? I'm not trying to fling stones because I love the fact that someone finally used BSNES to make a re-recording emulator but this is one of the most unintuitive gui's I've ever had to deal with in any software =/.
My sentiments exactly.
Ilari, is there any chance you cold create a more intuitive user interface for this? Kinda like the way the Snes9x GUI is set up? I think lsnes is the preferred emulator of choice on this site, but without a usable GUI, I doubt it will ever be adopted by the vast majority of TASers here.
Hum... Sorry, but how can i make this emulator to work? I mean, talk to me like you were talking to a 5 years old child. What do i have to double click??? I double click the "lsnes-wxwidgets" file and used the "..." to find the rom, clicked the "Open Rom" button, and then another window appeared with the title "Project Settings" and another one with "lsnes: Messages" title, but didn't saw any option to start the game. There's the option "Execute" in the "lsnes: Messages" window, but nothing happens there too. Was it supposed to work this way, or do i have to do anything else to load the game?
I double click the "lsnes-wxwidgets" file and used the "..." to find the rom, clicked the "Open Rom" button, and then another window appeared with the title "Project Settings"
The first time, select "New project", set correct controller types and hit start.
Subsequent times, pick a savestate to load and hit load.
Got it, but how can i configure my joystick? After opening the game i go to "Settings", "Configure axes" and there's a message saying: You don't have joysticks to configure! I tried selecting Gamepad, Multitap and Mouse and the same message apears every time.
Use Joy2key or similar program.
The current win32 builds don't support joysticks directly (this is a TODO).
And besides, that joystick configuration thingy is mostly useless.
EDIT: I implemented Win32 joystick support, but there is no release with that yet (will be in the next one). Also, that can't do pressure button detection, so joystick configuration might have some use...
Ok, thanks! I'll try that.
Edit: Nice, it's working now! Just two minor questions: Is there any key (or can i configure one) to fast forward the game? Also, is there a way to make the window bigger or in fullscreen mode?
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. Although, at one point I got a message, but I was stupid enough to not take a screenshot, and I can't seem to reproduce the error message, but I believe it was a runtime error.
I'm not using a gamepad - just a mouse and a keyboard. Re-extracting the archive doesn't help either.
I'm not good at troubleshooting, but I think I read somewhere that runtime errors could namely be caused due to some other process(es) in the background. But I really only have 15 processes in the background - and none of these comes from 3rd party software providers (i.e. they're only "default Windows services").
I'm on Windows XP SP3 x86.
emulator comparison via game intro (no$sns thread on nesdev) (no$sns thread on the bsnes forum)
