No offense but I've got no idea how this emulator possibly got accepted. Theres little to no documentation on how to use basic TAS tools. Setting the emulator up is complicated itself, but I guess it has to be for TASing PC games. But dont explain how to use the TAS tools? Like how do you rerecord? How do you end movie recording? How do you even tell that you are still recording? What about frame advance? Savestats? Did anyone look into the file formats? Ive got the feeling, that PCSX was the last emulator, which got accepted under large restrictions. There had to be a lot of work to be done before it got officially accepted by Bisqwit back then. There are many problems with this emulator, and just for having the ability to hopefully TAS some DOS games, I dont think this site should lower its standarts and accept this.
There is no offence in my post, i really apreciate the work done here. Ilari did an amazing job by adding the features, but I dont think they match the quality this site demands.
So, what? You'd rather have no emulator at all? Because that's the other option. Complaining that it doesn't meet your standards isn't helpful.
JPC is clearly sufficient for making some TASes, even if it's harder to use than most of the emulators on the site. Getting it out for public use will only accelerate the rate at which improvements are added.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Ilari should be doing it. But yeah, it's rather trivial as far as I can tell. I just took a peek at a moviefile that I just made. It's a textfile with events saved as plaintext using deltatimes for the timing, looks trivial to tweak manually.
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Phallosvogel wrote:
Like how do you rerecord?
Exactly as any other emulator - by loading an earlier state.
Phallosvogel wrote:
How do you end movie recording?
By saving a movie file at the desired end point; the site's parser will consider the length of the movie to be to the last input event.
Phallosvogel wrote:
How do you even tell that you are still recording?
The input stream is always recording; you can save a savestate/movie stream at any time.
Phallosvogel wrote:
What about frame advance?
Extra -> Frame Advance -> Start causes the system to advance exactly one frame on issuing a Start command (bound to 5 by default).
Phallosvogel wrote:
Savestats?
Extra -> Save / Extra -> Load (bound to the F keys and Shift+F keys respectively).
Phallosvogel wrote:
Did anyone look into the file formats?
Considering I needed to write a parser for the file format, we've obviously investigated it.
We did review the emulator prior to submissions being made here, or the code to accept movie files using it would not exist. It is true that it is less intuitive than some of the other emulators here, but it is still quite usable and it will only improve as more interest in it arises.
The default keys have the following bindings:
3 -> Enable pause on vretrace starting ("enable frame advance")
4 -> Disable pause on vretrace starting (disable frame advance")
5 -> Start/resume execution
6 -> pause execution
The first two can also be set from breakpoints menu. Note that these bindings are only valid when correct window (JPC-RR) is focused.
Phallosvogel wrote:
Savestats?
In addition to the functions bound by default to (shift+)Fx keys, one can save/load named snapshot (Snapshot -> save -> snapshot)/(Snapshot -> load -> snapshot). I usually do that at beginning and at end of stage and after any difficult section. It is also useful for gaining access to backups of savestate slots.
So, what? You'd rather have no emulator at all? Because that's the other option. Complaining that it doesn't meet your standards isn't helpful.
JPC is clearly sufficient for making some TASes, even if it's harder to use than most of the emulators on the site. Getting it out for public use will only accelerate the rate at which improvements are added.
Yeah, I wuld rather have no emulator UNTIL its rerecording features are bulletproof, as demanded by every other emulator around here. We waited so long for this, so we could still wait a little bit more.
And thanks for all the tips, but I cant get the hotkeys to work.
..and everytime I start up the emulator it starts recording?
Joined: 4/8/2005
Posts: 1573
Location: Gone for a year, just for varietyyyyyyyyy!!
I don't know if this is an emulator failure or something else, but trying to run the shareware version of Threat (free download here) produces this in the DOS shell:
Runtime error 200 at 11E8:0067.
I tested it with DOSBox and the game runs fine there.
(Threat is a top-down scifi shooter with various weapons and alien enemies. The game allows 3 players simultaneously, so TASing it should be a good idea.)
Phallosvogel wrote:
I wuld rather have no emulator UNTIL its rerecording features are bulletproof, as demanded by every other emulator around here.
After some tests I've made, it seems pretty bulletproof to me. Takes some time to learn, though. This has potential to be as good or even better than the other emulators used here.
Did you load the FPU module as instructed above? Some games require it. And some aren't polite enough to check if there is an FPU before trying to use it.
Joined: 4/8/2005
Posts: 1573
Location: Gone for a year, just for varietyyyyyyyyy!!
henke37 wrote:
Did you load the FPU module as instructed above?
Oh, thanks, forgot to test that, but after testing, still not working. I also tested it with your altdos floppy image, but the error message is always the same.
Oh, thanks, forgot to test that, but after testing, still not working. I also tested it with your altdos floppy image, but the error message is always the same.
Runtime error 200 is divide by zero. Errors due to missing FPU usually show up as endless loop of trying to use FPU messages with rapidly incrementing numbers or as exception 7 (DEVICE_UNAVAILABLE or some such) error.
This error is almost definitely CPU emulation error. Unfortunately that sort of emulation errors are usually real nasty to debug. Very probably secondary damage.
There's the infamous Turbo Pascal delay bug, but I don't think default clock rate of 20MHz is enough to trigger it...
I can view dumps in frameshow, but can't output anything with rawtorgb. I just get this error:
Can't uncompress data: incorrect header check
Edit: well this is embarrassing to edit a whole minute later.
I closed everything, changed my mind and popped up another command line. Put in the exact same settings but chose a new name for the output, and everything worked fine. Too bad I have no idea what to do with it.
The new lua function look great, but I think it could be usefull to keep some standard name just as is it for other emulator or at least the most important. Example: jpcrr.frameadvance() instead of jpcrr.next_frame() or make it working for both of them.
