Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
There are really no guidelines on this, but I'd say since you already know the improvements and have plans to implement them within a few months, then it doesn't make much sense to publish this run. If you change your mind at some point or don't find any improvements, we can un-cancel it.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
If you're going to submit a new run it would make sense to cancel this one, we wouldn't want to go through publication only to immediately obsolete it, unless you think this new run will take a long time to make. You can set the run to cancelled yourself or I can take care of it.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
SelfDestructor, just so you know, you can end the input earlier than you do in the movie. The rules dictate that the movie must reach an obvious ending, and I think in this case triggering the credit roll is good enough (the last input to trigger it seems to be at frame 80385). I normally wouldn't mention this but this adds over a minute to the movie time so it's pretty significant.
We tend to give authors some liberty over how they end their movie, so it's entirely up to you. Either way is fine, just let me know if you want to change it.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
I voted meh. From a technical standpoint, for the NES, this game is pretty cool. However, too much of the run is flying through space with nothing happening (and grating noises), and even the battles get samey after a short while.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
Thanks for looking into it. If this is all the information we have, then I think the disk version is allowable.
I should have communicated this in the first place, but I haven't yet found a disk image that matched the hash from your run. I did find a different one that synced anyway, and this is probably the difference in the loading times we're getting. I'm using the same BizHawk version you used. Your encode of the loading looks fine, so that's my mistake. If nobody can find the disk image you're using then that's still a problem, however.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
Is there any evidence that this game was ever released on a disk? Information for this game is extremely limited, there aren't even any pictures of it, but people who collect these games only have it on tape.
Also, after the program is loaded, the run idles at the prompt for over a second before running the program. This isn't evident in the temp encode because the loading section is omitted. I tried removing a bunch of the idling frames and the run still synced.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
EZGames, the run is pretty good overall, there's just one part I want you to revisit. It starts around frame 6900 (1:54 in the temp encode). It looks particularly ugly and I was able to cut 100 frames off of it:
Once you're able to land on the bottom right ledge (which you can do much faster by using the L-R trick to land over there earlier) you can clip into the left wall and just jump your way up. This is just a rough draft, it could possibly be improved more. Otherwise the run looks well optimized.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
Another consistent problem is the paths taken through individual screens. For example...
On the left is the original run, on the right is my improvement. For some reason the original run takes an unnecessarily wide turn around the enemy, when hugging the wall on the right is perfectly fine. 27 frames were saved in this small section alone. This example is fairly obvious to the naked eye, but there are many other small time saves to make throughout the run as well, and those can really add up.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
There's some pretty obvious sloppiness in the overworld travel. For example:
On the left is this submission, and on the right is my fix with a couple minutes of optimization, reaching the city 20 frames faster. Your run seems to head in the wrong direction at first and then turns to correct this. Am I missing something, why not head in a straight line? It's also possible to start turning earlier than you do in the run. This example is not the only instance of this happening either.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
My only concern with this run is the difficulty choice. In our Movie Guidelines we encourage TASers to use the hardest difficulty in their runs if it adds new content. In this case, the highest difficulty would add two more levels to the run and it would represent a more complete playthrough of the game. In addition, the collectibles and goals are in more interesting places, which the viewers may find more entertaining.
This run is acceptable as it is, but we can give you the opportunity to make a more complete run if you wish. If this run gets published and then you decide to make a run on the highest difficulty later, this run will be obsoleted and replaced with the new run (even if there are no improvements in the overlapping portions) because it would be more complete and may be more entertaining, while still being an any% run.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
Looks like an interesting script, really good work. I would say JPC-rr is not going anywhere, even when DOSBox TASing is a thing, since JPC-rr can do multiple button presses per frame.
As for DOSBox submissions, we should probably have this discussion in another thread, but there are already rules for CPU speed: http://tasvideos.org/MovieRules.html#DosMoviesJpcRr Although these would have to be slightly adapted for DOSBox. Using DrD2k9's formula, 20 MHz ≈ 3000 cycles. I think that the config file should be supplied in the submissions, and obviously no clock speed changes in the middle of the run (this pops up in the terminal so it will be easy to see).
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
Just a video testing DOSBox TASing...
Link to video
I had zero crashes in the making of this and after replaying it a few times, there doesn't seem to be any sync issues. The run is not very optimized so don't mind that, this is just a test.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
Thank you for libTAS and staying on top of these bugs. You're opening a lot of doors for new TASes.
EDIT: Updated the thread, all of these have working savestates now in the newest interim
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
That will depend on the game and the options available for that game. As long as the game runs accurately and the TAS syncs properly, then it could be accepted.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
With the release of libTAS I thought we could take advantage of all the Linux source ports and other software used to play games that were originally for DOS. libTAS is a much friendlier alternative to TASing in JPC-rr, being able to run games at full speed, having an intuitive mouse interface, and the ability to easily edit past inputs. Some of these games didn't run at all in JPC-rr and are now TASable. I'm going to go through and test some of these Linux alternatives, and I encourage others to test these out as well.
Many games can be installed through game-data-packager, provided you have the original game files, with many of them being untested in libTAS: https://salsa.debian.org/games-team/game-data-packager/tree/master/data
I will try to keep this thread up to date as new libTAS releases come out and more testing is done. Make sure you use the newest release when trying these.
General
Savestates: Working, although you should avoid loading/saving states between different resolutions. If you have Voodoo checked then savestates won't work in 1.3.4, use at least this commit.
Notes: The FPS has to be set to 100. Use "--config /path/to/config.cfg" in the command line to skip the configuration screen. No time tracking is needed. You will need to uncheck "Recycle threads" for some chipsets. Avoid using these GPUs: ATI Graphics Pro Turbo, Tseng ET4000, Trident TGUI9440, and anything that uses S3 EXCEPT FOR the S3 ViRGE/DX, which has been specifically patched to work in libTAS. Voodoo works as well under the latest commit.
DOSBox
Notes: Need to set fixed cycles in Dosbox.conf, otherwise it will run extremely slowly. Needs Runtime -> Time tracking -> Main thread -> SDL_GetTicks() to be checked.
If you want to submit a DOSBox run, it is likely that it will have to sync with all hotkeys turned off to ensure that the run was not interfered with via cycle adjustments. To do this, run DOSBox with the -startmapper command line parameter to open the key mapper, and then manually delete all the hotkey bindings.
DOSBox-x
Where to get it: https://github.com/joncampbell123/dosbox-x This is a fork of DOSBox that's more focused on accuracy and emulating different hardware, similar to what PCem is doing. Keep an eye on this one.
Status: Runs in libTAS.
Savestates: Working
Notes: Write a config file with "config.com -all -wc" and set the cycles to a fixed amount, otherwise it will run extremely slowly. Needs Runtime -> Time tracking -> Main thread -> SDL_GetTicks() to be checked.
ScummVM
Notes: A couple things to set up: First, run eduke32 and uncheck "Always show this window at startup". In the game, go to Options -> Display Setup -> Video Mode, then set Renderer to Classic (or else it will look like clown vomit in libTAS). Set windowed mode as well, as it defaults to fullscreen. In libTAS, needs Runtime -> Time tracking -> Main thread -> SDL_GetTicks() to be checked.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
I'm not too familiar with this game, but check if there's a settings menu within the game where you can configure sound and see if it'll let you pick Sound Blaster. If not, unfortunately you'll have to make test encodes to see if it's working.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
I think the default boot floppy shows you the option to step through each line in fdconfig and autoexec and decide which lines you want to run - if you're not using that, you can still press F8 while it's booting to do this.
I'm not sure what running two different SET BLASTER lines will do, but it can't possibly help to run the one in autoexec, so skip that when you step through it.
As far as the game detecting Sound Blaster, I've had this problem before. For whatever reason with some games, having the game detect it can be very finnicky in JPC-rr. I've had cases where starting the exe on the earliest possible frame results in the game not detecting it, but after waiting a frame or two and then executing the game will see it just fine. Once the game detects it, I've never had any issues with the game continuing to detect it throughout the whole run. It kind of sucks, but losing a couple frames during booting is much more desirable than not having good sound.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
Did you skip fdconfig.sys when booting? There are some memory-related lines in there, you should step through and say yes to everything in there (and just skip autoexec.bat if you want). If you already did that then I'm not sure why it says you don't have enough memory.
Experienced Forum User, Expert player, Published Author, Reviewer
(2388)
Joined: 5/21/2013
Posts: 414
I've played Xargon, it uses a slightly upgraded version of Jill's engine. Even some tech like the landing cancel still works. I'll probably do at least one episode at some point.