Joined: 1/26/2009
Posts: 558
Location: Canada - Québec
feos wrote:
This is the best thing to actually hack into the emulator - plugin switch through command line or so.
I started to look at the svn to get a version that isn't brocken(the official doesn't even have all the files to compile)... So far, I think the code is somewhat chaotic, some dude where commiting stuff for psxjin, while gocha was commiting some good stuff for lua. Overall, this look like a mess, even if I'm sure these coder are actually some great guys :) Basicly when I compile with VS2008, I have to do this: Project properties -> Linker -> General -> Link Library Dependencies set No. Then if I'm lucky the svn version will compile, but I will get a another plugin configuration interface than the usual, but without any choice for the SPU. Also, I did some breakpoint debugging and I figured that the "configuration profile" is stored in the Windows Registry. The path for getting which SPU dll to use(thankfully not encrypted) is: HKEY_CURRENT_USER\Software\PCSX-RR\PluginSPU (Go to Start>Run>type"regedit" to look by yourself) Now, I just need to change these value before running a pcsxrr instance. I guess this should be working in the very end... but damn, there's still a lot of work to do and the testing part will be though :/ edit: The C# app might actually look like this
Site Admin, Skilled player (1237)
Joined: 4/17/2010
Posts: 11279
Location: RU
http://code.google.com/p/pcsxrr/source/detail?r=217&path=/trunk/pcsxrr/Win32/ConfigurePlugins.cpp SPU options got killed due to moving a single plugin to core and getting rid of all the rest. Trying to resurrect these options now... Where did you get the lua console build? The revision where selecting plugins works lacks some lua functionality. I wonder how does your lua build have these options being 130, while spu was muved in 120 already. EDIT: Managed to splice these 2 needs together. Here, it compiles in VS9 and contains the first fix against memleak (pointed by Nach): http://code.google.com/p/feos-tas/source/browse/trunk/pcsxrr EDIT 2: http://code.google.com/p/feos-tas/source/detail?r=549
applied Nach's fixes to savestates. memleak must be fixed now.
Now we will try to fix post-movie crash.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 1/26/2009
Posts: 558
Location: Canada - Québec
feos wrote:
Now we will try to fix post-movie crash.
Ok, looking foward to this :)
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
I'm awaiting debugging info of which file/line causes the crash.
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.
Site Admin, Skilled player (1237)
Joined: 4/17/2010
Posts: 11279
Location: RU
Can't complie debug build for some reason. Test your scripts on this version for now: http://rghost.ru/45732100 About workflow, the only real thing I guess is past-movie sync verification. You can add this to existing scripts for me to test. No need for real program for now as long as we have a proper build with no memleak. EDIT: With this build, all hashes are equal to 00000513858214, the tool doesn't work. Gosh...
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 1/26/2009
Posts: 558
Location: Canada - Québec
feos wrote:
Can't complie debug build for some reason. Test your scripts on this version for now: http://rghost.ru/45732100
This build seem to crash when loading a movie on my computer and yeah.. it's seem we can build a .exe, but I still got an error in visual studio before starting the app. So we can't start in debug mode. About the hash, maybe there's a problem with the screenshot function of lua? As for my pcsxrr-13c build, I got it on the google project some year ago. I'm pretty sure this is was gocha who made. It was removed shortly after and we can't get it in the deprecated list.
Site Admin, Skilled player (1237)
Joined: 4/17/2010
Posts: 11279
Location: RU
Mishashing seems to be caused by Pete's video plugin. Also, try this, or compile from my SVN: http://rghost.ru/45735386
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 1/26/2009
Posts: 558
Location: Canada - Québec
I got this build working with the nrage plugin, anything else will crash the emulator when starting up a game. Now, I'll check what's up with script... edtit: I just found a bug with your pcsxrr build, the lua console doesn't open when invoking it from the command line, but the script is still running in the background(pcsxrr-13c work fine thought). It's probably fine for now, but this might cause some problem later if we have to debug any issue.
Site Admin, Skilled player (1237)
Joined: 4/17/2010
Posts: 11279
Location: RU
That's because of the way I got both lua console and spu choice. I had to checkout SVN r216 and then just dropped all files from 13b source, replacing the matches. Since it compiled and worked, I had no complains. Probably the 13b source really lacks that command line feature.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 1/26/2009
Posts: 558
Location: Canada - Québec
Alright, well that's no big deal either, at some point I can simply save the log somewhere else by overriding print() in lua. Now, my only remaining issue is that the movie.name() and movie.length() doesn't work when starting from command line. Thankfully, I can simply read the .pxm by using some old code from the TAS Movie Editor project to get around this problem. More update soon...
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Wiki: Nach/PCSXRR What's New:
  • Memory leaks in save states removed.
  • Memory allocation overhead in save states removed.
  • File system overhead in save states removed.
  • Resource leaks in movie files removed.
  • Displaying Lua dialog when loading via command line fixed.
  • Allowing Lua movie functions when loading via command line fixed.
  • pcsx.exe, cdrTASiso.dll, and gpuTASsoft.dll no longer require external DLLs (zlib, libbz2, libpng, Lua, Dwarf2, libgcc).
  • PCSX build with better optimization.
  • pcsx.exe packed much much smaller.
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.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Now that I have a full dev platform and build setup for this, can someone tell me how to recreate the post movie crash, so I can debug 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.
Site Admin, Skilled player (1237)
Joined: 4/17/2010
Posts: 11279
Location: RU
You need to replay http://tasvideos.org/2621S.html at SLUS-00663 ROM and on the scores it crashes.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Just replay and wait 5 min?
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.
Site Admin, Skilled player (1237)
Joined: 4/17/2010
Posts: 11279
Location: RU
Even less after if ends I guess.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 1/26/2009
Posts: 558
Location: Canada - Québec
Look like I forgot the try some basic feature while testing this. I get this message when loading a regular savestate with this new build. Sorry about that :/
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Was the regular save state created with this version?
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: 1/26/2009
Posts: 558
Location: Canada - Québec
Yes!
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Odd. I wonder what caused this. Will need to research. Edit: I just noticed that somehow my fixes to the save states were reverted in the tree. I guess that makes half the what's new not even true. It also means that the issues here seem to be prior to my fixes...
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.
Site Admin, Skilled player (1237)
Joined: 4/17/2010
Posts: 11279
Location: RU
I messed up something while replacing files again. Please check, if this archive contains the true fixed files I must put instead of the current ones. It appears I just didn't replace Misc files taken from official source. Uh. http://rghost.ru/45805676
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 1/26/2009
Posts: 558
Location: Canada - Québec
Look like there's still a memory leak issue while using the last feos fix(svn r568)... Basicly at some point, lua will just stop working due to lack of memory and show a small error prompt. At least, for some reason it doesn't crash the emulator and we can manually restart the script to continue the workflow. The issue is probably caused by the savestate(again) and sometime it can result by a corrupted savestate, that might affect the while workflow. Thought, despite that "out of memory annoyance", the script still ran well and I was able to (re)-sync though the end of the movie. That said, here's the pcsxrr version+PcsxrrEncodeWofkflowV5.05. edit: I just did an another testing seance and it seem that memleak might also happen at any moment. So yeah, I'll check up for more info on a profiler tool. some (lua)profiler might worth a shot. But I'm also I'm thinking about forcing a garbage collector at some place in the code. Meanwhile, I might do more progress with my external C# app. I've been thinking of some easy way to get around of some of our main problem, but I need to investigate some more stuff first. Also, here's yet an another version :PcsxrrEncodeWofkflowV5.06. -Now we can configure some setting for a *required* busy-wait event... -Some fixes and clean up. -Plus I found a way to add a fantastic debugging tool from something I found in the wx tool library a while ago. Look at all these beautiful variables! Just press the "H" key to make this popup in the detection script. Maybe this tool can help us to see if lua is guilty of the (terrible) memleak sin :)
Site Admin, Skilled player (1237)
Joined: 4/17/2010
Posts: 11279
Location: RU
Aktan reported that we were doing it wrong all the time. It appears we don't need to jump farther and farther back for each savestate creation. More than that, if the fix point is really close to desync point, it may be at all skipped by our too long jumps. Say, if it's only needed to load the state 5 frame back, we will never be able to fix it by going backwards. At the same time, he provided the average gap between the desync point and the frame that fixes it. It is less than 15 frames. That means, we must make only ONE backup savestate before the desync, at frame (desync - 15). Then, if loading it doesn't fix the desync, we must save it 1 frame after. And this way we must go FORWARD by one frame each time. I suggest to save 2 basic variables once desync is detected: desync frame itself and the initial rollback frame (desync - 15). Describing for desync at frame 1000. 1. The latest auto-backup is at frame 500. Once desync at frame 1000 is found, we load backup and run emulation. 2.1. As it reaches frame (desync - 15 = 985), save state to slot 1. 2.2. Emulate next frame, save the state at frame (desync - 14 = 986) to slot 2. 2.3. Advance one more frame, save at (desync - 13 = 987) to slot 3. ........... I think we must use all 10 slots for that. Only then start verifying each state on eternal: 3.1. Load slot 1 in eternalSPU instance and verify hashes. If it fixes the picture, emulate ahead (step 6), otherwise do: 3.2. Load state 2, verify. 3.3. Load state 3, verify. ............ Repeat for each available slot. 4. If even state at slot 10 (frame 995) doesn't fix it, use it for rollback frame and create a few more states: 4.1. Save frame 996 to slot 1. 4.2. Save frame 997 to slot 2. 4.3. Save frame 998 to slot 3. 4.4. Save frame 999 to slot 4. 5. Load each of these states and verify. It MUST be fixed. 6. Proceed to the next desync.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 1/26/2009
Posts: 558
Location: Canada - Québec
feos wrote:
Aktan reported that we were doing it wrong all the time. It appears we don't need to jump farther and farther back for each savestate creation. More than that, if the fix point is really close to desync point, it may be at all skipped by our too long jumps. Say, if it's only needed to load the state 5 frame back, we will never be able to fix it by going backwards.
I alway use the nearest checkpoint to fix the desync at the exact frame. The script "never jump farther and farther" back. If that happen, this means that something seriously wrong happen.
feos wrote:
3.1. Load slot 1 in eternalSPU instance and verify hashes. If it fixes the picture, emulate ahead (step 6), otherwise do: 3.2. Load state 2, verify. 3.3. Load state 3, verify. ............ Repeat for each available slot. 4. If even state at slot 10 (frame 995) doesn't fix it, use it for rollback frame and create a few more states: 4.1. Save frame 996 to slot 1. 4.2. Save frame 997 to slot 2. 4.3. Save frame 998 to slot 3. 4.4. Save frame 999 to slot 4. 5. Load each of these states and verify. It MUST be fixed. 6. Proceed to the next desync.
Sadly, step 3.2 to step 5 are useless... they will never happen. Despite you want to load me to load savestate from a irrevalent "previous desync". Although, I believe that pcsxrr have some serious problem by the fact I alway use the slot 1 to do my stuff and pcsxrr might get confused because of that. If there 2 instance want to load/save at the same slot at the same time, this is where thing can start to go wrong. So yeah, I'll probably just add somes rules for using different slot for each instance or try to use some smart way to cycle them. That said, it's very easy to get confuse on how thing work. I may have to produce some flowchart to describre what's going on.
Site Admin, Skilled player (1237)
Joined: 4/17/2010
Posts: 11279
Location: RU
Why won't they happen? And by going back I mean going 11 frames back during "suspending process", checking earlier frames states.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 1/26/2009
Posts: 558
Location: Canada - Québec
feos wrote:
And by going back I mean going 11 frames back during "suspending process", checking earlier frames states.
This is what I call "busy-wait". It wait for get the detection script to make a new savestate. I know that busy wait is usually bad, but if I use a normal wait function from lua, window will think the pcsxrr process is freezed. Also, if I use an another kind of busy-wait that doesn't process frame. PCSXRR will send prompt to kill the lua script. Also since I'm still pretty sure we should run the sync script in kkapture if we want to get real encode. What I suggest if that we get a new lua function that just call a sleep function from pcsxrr. If Nach is to busy to add this, I'll do it myself this weekend.
feos wrote:
Why won't they happen?
I'll draw something later...