Joined: 4/25/2004
Posts: 615
Location: The Netherlands
qFox wrote:
DeHackEd wrote:
Wow, anonymous fceu savestates are discarded immediately upon loading? Snes9x savestates persist forever. (Not true since once the savestate object falls out of use, the Lua memory garbage collector eats it, but it's close enough)
That's how they used to work in fceux. But now states are kept in memory unless you call persist. But I still think it's not so great that the states are destroyed on load. So I'd want that not to be the default behavior (but optional).
Due to some miscommunication this was not a feature but a bug and it has been fixed :p In retrospect it was a silly idea anyways. So FCEUX savestates also persist until the script exits, they just persist in memory and not on disk unless you call .persist() on them.
I wrote a Lua script involving writing large chunks of data into the memory (7045 and 26208 bytes), but next to it being very slow, it also pops up C stack overflow error messages.
Is there a way to improve the memory writing speed for large amounts of data? I currently use the memory.writebyte function in a loop, where the data to be written is declared in the lua script itself.
If not, is there a way to prevent the C stack overflow messages from appearing?
Can you send me the script you're using? Nothing in Lua should blow the C stack, unless you do something like infinite recursion via the various "register" functions.
Can you send me the script you're using? Nothing in Lua should blow the C stack, unless you do something like infinite recursion via the various "register" functions.
Are the registered functions called when the memory is written by the memory.writebyte functions? Is so, that could cause an infinite recursion in my script.
EDIT: I tried to prevent possible recursion but the error messages are still appearing. Here is the script I used, plus a savestate to trigger it (walk up into the teleporter).
Flow of control:
0. startBlock4 is registered for 0x7e4000 and will never get unregistered.
1. startBlock4 gets called by the emulator. stopBlock4 gets registered for 0x7ea43f
2. stopBlock4 gets called by the emulator. It unregisters itself from 0x7ea43f
3. continuing, it starts by writing to 0x7e4000 which involes startBlock4, reregistering stopBlock4 again
4. continuing, stopBlock4 eventually writes to 0x7ea43f and calls itself again and unregisters itself again.
Repeat steps 3 and 4 until Lua realizes there are 200 C->Lua->C transitions and instead runs error("C Stack overflow")
(GDB and Lua's own built-in debugger rock when used together)
Now, is this behaviour where memory.write* calling a registered function desired behaviour, or should Lua silently ignore attempts to write to memory by itself? Both have their merits.
That was the second infinite recursion in my script indeed. When properly unregistering the functions, the script no longer displays any error messages and executes much faster. Thanks for the help.
I suppose this behaviour of registered functions could come in handy, and it isn't too much trouble preventing infinite recursions by properly unregistering functions. So in my opinon you should keep this feature and maybe explicitly mention its behaviour in the API section.
The script seems great, but for some reason I get an error when I try to run a large movie. For example when I try to run Cp's 100% run and use the script a message appears saying "attempt to compare number with boolean." When I use the script on a short demo movie or something, it works fine.
edit: Well the error message seems like it has to do with using the lua script at the beginning of the game. If you turn it on later in the run it works..
should have noticed the actual problem sooner..
the code was mangled by having html enabled.
could be the removal of non-whitelisted attributes from html tags
the broken script appears to work for many iterations because "mode <18>= 4" is not evaluated unless "mode >= 12" is true
reposting with html disabled which fixed the code in preview
msgboxflag = 0
snes9x.speedmode("normal")
while not movie.mode() do
gui.text(8,40,"Waiting for movie" )
snes9x.frameadvance()
end
function msgbox()
msgboxflag = 1
end
function timerchange()
if msgboxflag == 1 then
snes9x.speedmode("normal")
msgboxflag = 0
end
end
memory.register(0x7E1C1F,msgbox)
memory.register(0x7E1842,timerchange)
while movie.mode() do
elevator = memory.readword(0x7E0E18)
mode = memory.readbyte(0x7E0998)
if mode == 8 and elevator == 0 and msgboxflag == 0 then
snes9x.speedmode("normal")
else
snes9x.speedmode("maximum")
end
if mode >= 12 and mode <= 18 then snes9x.speedmode("normal") end
if mode >= 4 and mode <= 5 then snes9x.speedmode("normal") end
if mode >= 20 and mode <= 27 then snes9x.speedmode("normal") end
-- 12-18: pause screens. change 12 to 11 if you want door transitions
-- 4-5: save data and option screens
-- 20-27: game over screens. change 27 to 26 to exclude reserve tank
snes9x.frameadvance()
end
snes9x.speedmode("normal")
snes9x.pause()
Wow. That SM script really enhances the experience. I turned off all the sound channels except #8 and turned on VARIAtions, and threw in a quick hack to shorten the screen transition skip. Replay would resume at normal speed with Samus in the middle of the next room. Kinda wrecks the continuity of the thing, so I figure this could be useful to someone.
if mode >= 11 and mode <= 18 then snes9x.speedmode("normal") end
if mode >= 4 and mode <= 5 then snes9x.speedmode("normal") end
if mode >= 20 and mode <= 27 then snes9x.speedmode("normal") end
if mode == 11 and lock ~= true then
snes9x.speedmode("maximum")
lock = true
for i = 0, 120 do
snes9x.frameadvance()
end
snes9x.speedmode("normal")
end
if mode ~= 11 then
lock = false
end
Is there a way write savestates generated by a Lua to the RAM instead of the hard disk? The reason I ask is because I noticed that the savestate creation and loading seems to be the bottleneck for most of the automation scripts I created. Handling savestates from the RAM would yield a significant speed increase I would think.
EDIT: I tried setting the savestate folder to a RAM disk, but that didn't result in any significant performance gain.
I also tried created a custom pseudo savestate functions, using the memory.readword/memory.writeword functions, but that wasn't much faster either and resulted in game freezes when called during lag frames (which was to be expected).
Is there anything else I can do to try and speed up savestate handling? Perhaps disabling savestate compression?
There is an updated binary in the downloads already which has had input.get and a bunch of other additions for a while now. At the moment this is "snes9x-1.43-rerecording-svn-r98.zip" or "snes9x-1.51-rerecording-svn-r67.zip" in the downloads list (depending on whether you want to use 1.43 or 1.51), the same as or only slightly older than the latest trunk version.
There is an updated binary in the downloads already which has had input.get and a bunch of other additions for a while now. At the moment this is "snes9x-1.43-rerecording-svn-r98.zip" or "snes9x-1.51-rerecording-svn-r67.zip" in the downloads list (depending on whether you want to use 1.43 or 1.51), the same as or only slightly older than the latest trunk version.
That should really be put onthe front page somewhere.
msgboxflag = 0
snes9x.speedmode("normal")
while not movie.mode() do
gui.text(8,40,"Waiting for movie" )
snes9x.frameadvance()
end
function msgbox()
msgboxflag = 1
end
function timerchange()
if msgboxflag == 1 then
snes9x.speedmode("normal")
msgboxflag = 0
end
end
memory.register(0x7E1C1F,msgbox)
memory.register(0x7E1842,timerchange)
while movie.mode() do
elevator = memory.readword(0x7E0E18)
mode = memory.readbyte(0x7E0998)
if mode == 8 and elevator == 0 and msgboxflag == 0 then
snes9x.speedmode("normal")
else
snes9x.speedmode("maximum")
end
if mode >= 12 and mode <18>= 4 and mode <5>= 20 and mode <= 27 then snes9x.speedmode("normal") end
-- 12-18: pause screens. change 12 to 11 if you want door transitions
-- 4-5: save data and option screens
-- 20-27: game over screens. change 27 to 26 to exclude reserve tank
snes9x.frameadvance()
end
snes9x.speedmode("normal")
snes9x.pause()
Is it possible to keep the audio synced when AVI recording with this script running? I've been trying it out with some of my Super Metroid SMV's and everything looks fine in Snes9x, but when I view the AVI recording the audio in it doesn't get fast-forwarded along with the video.
Edit:
Okay, so I was trying to get this to work and found that the audio desyncs in Snes9x 1.43 v15.3, in 1.43 v16 svn11, and in 1.51 v5.2, yet it doesn't in the 1.43 v11 beta15 versions that are included in the snes9x-lua-v0.05.7z and snes9x-lua-v0.06.7z archives linked in the first post.
There is an updated binary in the downloads already which has had input.get and a bunch of other additions for a while now. At the moment this is "snes9x-1.43-rerecording-svn-r98.zip" or "snes9x-1.51-rerecording-svn-r67.zip" in the downloads list (depending on whether you want to use 1.43 or 1.51), the same as or only slightly older than the latest trunk version.
That should really be put onthe front page somewhere.
That would be easy to do but I'm guessing gocha has some reasons for not wanting them to be featured downloads quite yet. They were renamed/updated to "snes9x-1.43-rerecording-svn11.zip" and "snes9x-1.51-rerecording-svn11.zip" since my last post, by the way... so just look for the most recently modified ones, I guess.
Joined: 6/21/2006
Posts: 402
Location: Japan, Nagoya
nitsuja wrote:
Xkeeper wrote:
nitsuja wrote:
There is an updated binary in the downloads already which has had input.get and a bunch of other additions for a while now. At the moment this is "snes9x-1.43-rerecording-svn-r98.zip" or "snes9x-1.51-rerecording-svn-r67.zip" in the downloads list (depending on whether you want to use 1.43 or 1.51), the same as or only slightly older than the latest trunk version.
That should really be put onthe front page somewhere.
That would be easy to do but I'm guessing gocha has some reasons for not wanting them to be featured downloads quite yet. They were renamed/updated to "snes9x-1.43-rerecording-svn11.zip" and "snes9x-1.51-rerecording-svn11.zip" since my last post, by the way... so just look for the most recently modified ones, I guess.
I didn't do that to avoid the confusion about the difference of savestate. IIRC, the new one cannot be read by old one, also, the new one could be changed in future update, possibly.
Anyway, as Nitsuja said, it's easy to put the latest experimental version on the front page. I'll do that if community wants me to do.
Edit: Scroll down to the bottom of this post for the newest version.
Here is an improved version of my old super metroid ghost script:
http://folk.uio.no/sigurdkn/ghost_play.luahttp://folk.uio.no/sigurdkn/ghost_record.lua
Aside from being more robust now, it also supports two new features: The ghosts can be displayed using a proper animated Samus (or anything else, really), and there is a minimap which shows the position of each of the ghosts globally. These features require the gd library for lua, though, so you will have to install that to get this to work. Here is a demonstration of the script:
http://folk.uio.no/sigurdkn/sm_ghost.mkv
This shows Cpadolf's in-game any% non-glitched SM TAS (normal Samus, white cross on minimap), his previous version (blue Samus and cross), and herooftheday's new and old realtime oriented any% runs (green and red respectively).
The settings used to produce this was:
As you can see, it is possible to choose which frames to display, and which to sync by. Here I have chosen the most interesting combination in my opinion, which is to sync by ingame frame, and to display only those frames. Additionally, I have chosen "room" offset mode, which resyncs all the ghosts to enter the room at the same time, which makes it easy to compare room strategies.
Please excuse the poor encoding quality in the demonstration video. Especially the crosses on the minimap are much clearer in reality than in the encode.
A few supporting files are involved: The ghost dumps must be generated by ghost_record.lua before they can be used in ghost_play.lua. Simply load ghost_record.lua in snes9x, start the smv you which to dump a ghost from, and exit the emulator when you are done. A file called "ghost.dump" will be generated, which you can rename to something more suitable.
For ghost graphics, you will need two pose definition files, which are harder to generate, so I'll provide an example here:
http://folk.uio.no/sigurdkn/poses.pnghttp://folk.uio.no/sigurdkn/poses.map
To create the colored ghosts in the example, I simply used a color filter on the above poses.png and used poses.map unchanged. This poses file is slightly incomplete. Some poses are missing, most notably the "exhausted" pose during the mother brain fight. A few map incorrectly, most notably the elevator pose. But it still looks pretty nice.
The minimap I used is this one
http://folk.uio.no/sigurdkn/minimap.png
Please give me feedback on this script if you miss something or can't get it to work. Even without the gd stuff, it should still be an improvement on the old versions with the old crashes Saturn complained about fixed.
Edit: Note: This script assumes that it is safe to draw outside the screen. This is not the case for old versions of snes9x, where this causes the script to crash. I recommend the newest versions for this.
Edit: As LagDotCom pointed out, I had mixed up herooftheday 2 and cpadolf 1. This is fixed in the text above now. The video has not been changed.
Edit: Here is a slightly updated version of the script bundled with some example ghost files and the maps/pose info needed (edit: now also handles resets relatively well): http://folk.uio.no/sigurdkn/super_metroid_ghost.zip
That video is goddamn awesome. Thanks for making this.
Although, aren't the Blue and Green Samus the wrong way round? I noticed there are a few time where only 'Real' and Green take the same route, but the one that follows 'Real' Samus around is Blue.
I have this message when running the ghost record script. What am i doing wrong?
...s\Snes9x 1.43 v15\Movies\Lua Script\ghost record.lua:9: attempt to call field'readbyterange'(a nil value)
Readbyterange is one of the newer functions in snes9x lua. It is not supported by your version. It should be in the svn version though. I could implement a replacement for readbyterange, but then I'd probably also have to add safeguards agains drawing outside the screen, etc., since that isn't supported in old versions either.
If you wish to test if readbyterange is the only issue with your old version, you could try adding this to the top of the file (not tested):
function memory.readbyterange(a,b)
local res = {}
for i = 0, b-1 do table.insert(res, memory.readbyte(a+i)) end
return res
end
It is nice to see someone trying the script itself, and not just the video, so I hope you'll get it work, even though you may have to upgrade snes9x.
Thanks for helping man, i added the informations to the top of the ghost record.lua and now i have this message:
...Lua Script\ghost record.lua:2:unexpected symbol near''
I use Windows XP and i thought the version of the emulator i'm using (Snes9x 1.43 improvement 15) was the newest. Where can i download a svn version of Snes9x 1.43?
Here is a pretty new one, at least:
http://snes9x-rr.googlecode.com/files/snes9x-1.43-rerecording-svn-r64.zip
If you use this one, then don't include the function I wrote for you above. If you can't get that one to work, then I can help you more effectively on IRC. Just join the #tasvideos channel on irc.freenode.net.
