Alright, I figured that I should probably post an update, since there probably some people waiting for the script to be finished and the new
PSX Mega Man X6(or Aktan already made it?) run seem to be waiting for his encode and it wouldn't be acceptable to keep relaying on time-consumming way to produce encode again. I really don't know how I'll manage my time, so I can't garanteed how long this gonna take. I'm just a dude that got way to many stuff to do... but I'll still try my best to help out.
So here's an update:
After
serials severals
experiments with the
Lanes library, I managed to make a function that redraw the screen. Sadly it might not been used in the syncCheckpoints script since I found an another and easier way get rid of the frame duplication problem without having to relay on lua multi-threading. But since, I already made the code for that redraw function, I'll still leave it there in the project and it might still been used for the double instance setup. As I said, I think the double setup is the only way to get an "automatic workflow".
Thankfully, the script doesn't have that much work left to do. I basically have all the piece of the puzzle... I just need to be put them together and test the whole thing.
For the communication between the pcsxrr instance, I ended up going for the
LuaXML API, that give some basic tool for both writing/parsing a status file. One status file should be used for each pcsxrr instance and at some point one instance would send a request for the other instance to produce a specific checkpoint, etc..
Using XML should work, but I've been interested by the lua
ØMQ API, as well. It offer to send data by using socket instead of using file for I/O. I really don't know if that could have been working correctly, thought.
Also, I just remembered something that could be terribly annoying. If my memory's right, sometime the Eternal SPU plugin will desync
more or less often while using kkapture in same time. I'll need to investigate more about this, since I'm still unsure how I used to cause such issue the happen and if this is avoidable(maybe forcing the pcsxrr speed to normal?).
As for the video plugin issue pointed by Aktan for the
loading screen(I guess this is what he mean), I gonna admit that this confuse me quite a bit, since so far I relay a lot on the "TAS Soft Graphics plugin 0.2" to produce accurate screenshot with the "TAS Sound Plugin 0.2". The final "checkpoint list" of savestate might then been innacurate if the screenshot are somewhat corrupted, but think this problem is more relevant as an emulation and there's a limit on what we can fix in the encoder corner. That's said, that made me thinking that there also the "
TAS OpenGL Graphics Plugin 0.1" that is supposed work better for few game. I guess it could be interesting to see if the plugin could be used partly or completely for some encode...
Update:
PcsxrrEncodeWofkflowV4.07
If anyone is interested, I guess I could make some Google project or GitHub repo for this.
