Experienced Forum User, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
Some of the movement is definitely sloppy. Here's an example of a section that I very roughly improved:
https://i.imgur.com/9ZsyD00.gif (big file, open externally)
The pathing in the original run was very questionable in this example. (bad example, ignore) From looking at TAStudio, the analog stick movement was gradual and erratic. Also, the analog values top out at +-89 instead of the extremes of -128 and 127. My guess is that most sections were recorded unassisted with a controller.
Experienced Forum User, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
SelfDestructor wrote:
What's considered a long time on this site? I have some new ideas for RNG manipulations I want to try out as well when I got some spare time so I would guess maybe 2-3 months before I submit an improved run.
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
SelfDestructor wrote:
Cutting the movie at the credits is fine with me. :) As a beginner at this I wasn't completely sure where I should have ended the movie.
A speedrunner of the game has found some new possible time saves and animation skips in the last couple of days, so I will submit an improved run later on and I'll end the movie at the credits when I do so.
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
InfamousKnight wrote:
With dosbox, I don’t know where to set cycles, and libtas doesn’t advance frames. I did follow the other configuration like get-ticks though which is real obvious.
Any help?
Your DOSBox config file will be in ~/.dosbox. Look here for info on setting cycles. This might solve your frame advance problem.
Experienced Forum User, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
keylie wrote:
Thanks for doing all those testings! Error "stack smashing detected" was fixed in commit bc62551. Scummvm and chocolate doom savestates seem to work correctly now.
EDIT: The XIO error was fixed in commit de3a846.
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
GJTASer2018 wrote:
So which one of these options should be the recommended one if the DOS game someone is trying to TAS won't run in the (now-dead) Hourglass?
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
DungeonFacts wrote:
Any way to catch if it detects besides dumping a video? I don't mind if that's the case, but the game has a pointlessly long intro sequence, so it'll be moderately tedious.
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
DungeonFacts wrote:
I've been troubleshooting my config to get started on this, and I need some guidance from those of you more knowledgeable about the inner workings of this stuff. I have two issues I want to work out before I engage with the actual TAS work.
1. Memory
With Crystal Caves, I was able to skip the config.sys and autoexec.bat and jump straight into the game. With God of Thunder, if I do this I get a message saying I need an additional 2K of memory. If I let both run, I can launch the game, but the current FreeDOS image runs the installer, so I'm guessing I should either use a different floppy image or figure out how to tweak the existing one. I tried extracting the image to edit the config.sys and autoexec.bat, but for some reason when I tried recompiling the image using 7zip it was slightly larger than a floppy image. (Also, yes, I tried just adding more memory in the JPC parameters.)
Essentially, I need some guidance on whether I should compile my own disc image (and if so, if there's a good guide on making one), or if there's more to editing the aforementioned files than extracting the image and tweaking them in a text editor before re-inserting them. If there's no alternative to just letting them run, that's fine, but obviously saving the boot frames would be nice.
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.
2. Soundblaster compatibility
There's an old thread about SoundBlaster for GoT, but the only takeaway I got is that the game is pretty unreliable about detecting it. I noticed that the new FreeDOS image has "rem SET BLASTER=A220 I5 D1 H5 P330" in the autoexec, but even if I manually run the "set BLASTER=A220 I5 D1 H5 T6" recommended by the JPC guide, the game doesn't seem to detect it. It's bundled with a soundblaster testing tool which seems to detect it OK, but obviously if the game doesn't, then it doesn't do me much good.
Am I being sabotaged by the autoexec, or should manually running SET BLASTER correct that? Is there anything else I should do besides running multiple attempts and simply hoping that it eventually detects the card when I try to record?
I realize that you don't need sound cues in a TAS, but this game has such a great soundtrack and SFX that I consider them must-haves.
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
DungeonFacts wrote:
I have downloaded the game, and am currently troubleshooting how to get it running, because I get a message saying I need 2K more memory (even after trying to up the memory in the JPC parameters), or I can run it without SoundBlaster emulation, which is a travesty because the in-game sounds are *hilarious*.
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, Published Author, Reviewer, Expert player
(2509)
Joined: 5/21/2013
Posts: 415
Svimmer wrote:
Well this is more entertaining than I thought this game could be. You're surely also aware of Xargon?
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.
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.
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.
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.