Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Wobmiar wrote:
Hmm... So they just released the possibility of doing multiplayer TASes... Is it possible to delay this submission a bit? I will want to try new things. I'll cancel it if I find multiplayer to actually be faster
There are some problems currently with that sort of multiplayer, being there is no way to dump the GBA part (so impossible to encode properly), and all we know is that thing should be deterministic in theory, but we don't know if it's deterministic in practice.
I wouldn't say you shouldn't try to look into multiplayer (having a field test would be great for checking determinism!), but these technical issues currently keep multiplayer unacceptable for TASVideos submissions.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
illayaya wrote:
For second quote, you can set certain number of days as you said. But it's not difficulty. More days just open for preparation for good bait so less days means harder difficulty but faster (You need to spend all days you set to end tournament) I guess.
Ah, so this submission is effectively the hardest difficulty (which the only difference in practicality is less days having to chug through in the inn). Thanks!
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Patashu wrote:
Ok, so... What even ARE the rules of this tournament? How do you win by catching one fish? Is the fish really that special?
I really don't know. I tried figuring out the scoring system but I did not have any luck, mostly due to the code being complete ass (the code doesn't even appear compiled when overall looked into, it just looks like extremely rushed code). What I know is getting some expensive bait = get some high scoring fish = win.
Also, at the beginning you actually can set the days the tournament can go on for (3-94 iirc?). I assume anyways that more days = higher difficulty. I use the lowest (default) day counter, so I assume this is essentially the easiest difficulty.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
This TAS is, interesting to say the least. Honestly borderline Meh/Yes for me, but I think I would have to go with Meh here.
I took a bit of a look with the execution, and I can say it looks quite optimized. I couldn't find anything particularly suboptimal with the TAS, you definitely did a great job with that bot of yours.
I did noticed an oddity of the "framerule" thing you mentioned. I appears that it's more just timing sensitive, doing something like delaying the middle of the puzzle solving or doing slightly different (but equivalent) solutions could reduce/add to the load times. Still, optimizing for this would blow up possible lag reduction solutions to an insane degree (and I guess technically sacrifices IGT for RTA for some cases lol), and the gain would be very minor, so probably not an issue for this submission.
The feedback on this submission seems lackluster (barely any feedback/not many positive votes), although since this is fastest completion, it can be published into the Vault anyways.
EDIT: Seems like some more Yes votes are coming in. I'm curious for people's reasons for voting Yes on this, considering the lack of forum posts explaining these votes.
Oh, I've also resynced this TAS with the GBA bios, for use in console verification. The "framerule" system ended up being wonky in GBA mode (probably just general timing differences between GB vs GBC/GBA), so I kept it optimized using the general delay action before load time (and interestingly saved a couple frames disregarding bios length, although this probably doesn't really count as real timesave anyways). An encode for the GBA resync can be seen here:
Link to video
If the author wishes, this movie file can replace this submission. I've also resynced the movie with the GB bios, if that is instead desired (interesting sidenote, the "framerule" system ended up being exactly the same despite timing differences with the unofficial built in bios vs real bios, don't know what this means other than GB is bs).
Oh, and the cycle count is also missing in this submission, so the movie file has to be replaced with something anyways.
EDIT: Also, why is the game version marked unknown in this submission? Shouldn't it be USA? fixed by author
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
lemon32767 wrote:
Side-by-side N64/BizHawk comparisons:
- This one is synced from timer start https://www.youtube.com/watch?v=8zsQ07FSwPQ
- This one is synced from title screen https://www.youtube.com/watch?v=YkDxpneA4i4
Note that BizHawk's timer seems to run slower than real-time, having desynced by about two seconds at the end. I'm not sure if it's something wrong on my end, I just used the movie clock lua script and dumped the movie with BizHawk's builtin AVI encoder.
BizHawk seems to count frames incorrectly, resulting in a much longer frame count than what is actually emulated. The dumps you did used Sync to Audio, which would skip frames to accommodate audio timing.
Interestingly, a Sync to Audio dump results in 15382 frames. This is 2 off from Mupen-rr. BizHawk and Mupen-rr seem to have very close timing when compared this way.
Edit: Also interestingly, the Sync to Audio dump almost matches exactly to a Mupenrr dump (only being off by 4 frames due to reasons I don't know).
BizHawk is probably right on frame count, the issue is mostly that some frames just dont produce audio at all, despite there obviously being stuff emulated at that time. These frames are just skipped by the Sync to Audio. I presume Mupen-rr is doing something similar and skipping these frames if just due to the similarities for the dumps (and possibly reflecting this in VI Count somehow).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Cool TAS! I liked all of the slide and kick action done, and while the dialouge was a tad slow, the plot being wacky as it was I feel cancelled that out. The commentary made it even better too. Very good job too on optimization! Though Vaultable, I do think that this is perhaps entertaining enough for Moons (given 0/5/1 votes and 4/1 positive/negative feedback). I definitely encourage other people to give a watch!
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Watched the movie. It's not absolutely terrible to watch, although it ends up getting rather repetitive and the game's length really hurts it there. So, I guess meh.
I looked into the game just a tad, everything seems to be very well optimized. Well done!
I did notice one minor thing however. You seem to go to the backpack at the level fadeouts. Sometimes this seems to be for picking an item while the fadeout goes on, but other times it seems to be a case of lag reduction. I've noticed that for the lag reduction (and assuming you aren't picking an item) the Pause menu can be substituted, which could have less lag. However, the gain is very minor and likely outright negated due later lag being thrown off. Not really worthy of rejection, but perhaps something to keep an eye on in case you want to squeeze just a little more timesave in.
Considering this is fastest completion, this movie looks well Vaultable, and considering the votes (4/3/2 No/Yes/Meh) and current feedback (3/1 Negative/Positive), that is probably where it will go.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
MrWint wrote:
I'm not even convinced it is faster with animations on to begin with.
gifvex actually measured that out (for another RTA category, unrelated to this submission), and Stomp is 11 frames faster with animations on instead of off. Of course, I doubt this changes anything, given factors you laid out along with 10 frame timeloss for each Tauros send out with animations on.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Samsara wrote:
TiKevin83 wrote:
[...]
[...]
Also to be frank, this feels more singling out "ACE" here, when there are plenty of non-ACE gegs possible (ACE just being the most common), and glossing over that reverse engineering/similarly technical feats could be needed when TASing, even ones which do not use glitches at all. There's also plenty of non-ACE glitches which could need even higher levels of technicality to be used effectively. Also implying you even need to understand the technical differences to appreciate the TASes (which is not always the case).
Regardless however, the creation of a "demo" tier could solve TiKevin's dilemma (reminder, the TAS you linked as an example would literally be "another Pokemon ACE TAS", and is particularly technical considering that's literally both GB and SNES assembly). Of course, it would need entertainment, so that somewhat solves the issues of "you need to understand technical differences to appreciate it."
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
I did some work studying the RNG of this game and how it affected the pipe room wait.
The length of the wait isn't directly taken from RNG, but rather there is some math behind it. The math is rather complicated, although it can be simplified to a very simple equivalent.
The game takes 2 bytes from the RNG, and modulos that by 512. This is the RNG value used from now on. The wait starts at 3000. If RNG is odd, then the 3000 is subtracted by RNG. If the RNG is even, then the 3000 is added by RNG.
So, this simply means that optimally we want the resulting RNG to be 511. However, there is another issue.
The RNG this game uses is 8 bytes from 0x1CE-0x1D5. It uses a fairly simple LFSR to cycle through the RNG. However, this particular RNG ends up only having 32767 possible seeds before it ends up looping back around.
Within these 32767 seeds, 511 is nowhere to be found. Nor 509, 507... etc etc. The best ends up being 383, which this TAS happens to get. This results in a wait of 2617.
tl;dr the shortest wait possible is 2617, which this TAS happens to get. It is not possible to my knowledge to shorten the wait.
Anyways, as for actual feedback. The game isn't too notable, although that doesn't make this movie really boring either. I liked it. A nice mix of decent music and interesting platforming. I would of personally liked it better if the English version was used, but ¯\_(ツ)_/¯.
The movie is acceptable as is (proper optimization, beats existing records, vaultable goal), although I am curious on the audience reaction. The current votes are 60% positive at 3/5/2, although the feedback on the thread so far has been positive. I am curious if anyone else feels positive towards this movie, or the reasons otherwise, and if it should belong in the Vault like the currently published movie.
1. That doesn't change the fact that BizHawk uses mGBA for its GBA core. The BizHawk frontend would be the bottleneck rather than mGBA's emulation core.
2. Code Breaker codes are unsupported by BizHawk, which is an open issue: https://github.com/TASVideos/BizHawk/issues/897
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Alyosha wrote:
Samsara wrote:
Uh, false alarm, I was able to resync the run near perfectly to standard BSNES while also improving the pipe room. I've updated the submission file and text to account for this. Judgement may continue.
To be clear, I was the one who reported sync issues to Samsara. I tried to play back the movie myself, but it did not sync at first. Replaying the movie did result in sync. Doing the save state integrity checker ended up with failure with fairly different states dumped. Seems like anyways the movie sometimes syncs, but there's some nondeterminism in there that can result in a desync sometimes.
EDIT: Just realized I used the English ROM on my first attempt and not the Japanese ROM, and I used the JPN ROM on later attempts. Did not realize that until now.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ninespaces wrote:
Memory wrote:
Because I'm unsure from the previous posts, would you prefer the published file be done with GBA bios or as is? TASVideos itself does not care but the console verification community uses GBA bios. I don't think it is exactly necessary for it to be the publication file however, but I'd like to know your preference.
I suppose GBA bios if that's easy enough to do? (I have no idea... sorry.) Otherwise "as is" is fine - no real preference. Thank you.
The GBA BIOS is very easy to do, the game appears to be super sync friendly so just adding in the frames it takes for the BIOS to run will just have the rest of the TAS syncing.
Anyways here's a resync to the GBA BIOS with the new improvement: http://tasvideos.org/userfiles/info/72472735744598841
And if you want the GB version anyways, here it is resynced with the GB BIOS: http://tasvideos.org/userfiles/info/72472755284576123
(note, the submission has a blank input at the end, so you might as well just replace it with one of these resyncs)
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
I looked into this TAS to see if it could be console verified. Unfortunately, it appears to desync in the latest dev build, and I've confirmed this is due to an accuracy improvement within that build (misc timing improvement). So without a resync with the latest dev build, this movie won't be console verifiable.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Mothrayas wrote:
(besides apparent poor compression of the original file)
That was my point, BizHawk's compression is extremely poor since it does not optimize for size, but rather speed. Manually recompressing the bk2 with 7zip with the highest compression settings (which was done for the spiked file) is needed before zipping it drops it down below the limit.
Also does not help that Deflate has to be used since that's the only thing the site can parse, which is not the best compression method. BZip2 (another compression method supported for zip) notably compresses text much better, being able to drop this submission to ~50KB, and even can drop TOCA to ~181KB, nearly below the file size limit.
(of course a lot of this is somewhat moot, it would be a better solution in the end to just raise the limit to a couple of megabytes, although I imagine site code might not make that so simple)
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
UnopenedClosure wrote:
Since you are no longer maining Totodile for the entire run, could you save time by manipping for lesser stats?
I did consider this. However, the manip for perfect stats only has 3 frames of delay, and Special is really the only stat where there is no disadvantage for lower stats, assuming it's kept odd for max HP, but I cannot maintain perfect atk/def/spd at the same time, or even get max HP to begin with.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
GJTASer2018 wrote:
I'm curious how this managed to break the file size limit when there's been PSX submissions longer in length than this before that didn't have that problem...
Except all the ones in BizHawk did. Blame BizHawk poorly compressing files (speed/size tradeoff, pun unintended).
With proper compression the movie does fit into file size limitations, although this movie is in need of spiking anyways (blank input), so that needs to be handled regardless.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
So the "confirmed" improvement did not actually save any time, and rather lost ~5 seconds.
However, the potential improvements did pan out, saving 14 seconds overall. The main improvement being switching to Rattata for my main Pokemon after Falkner. I'll post an encode and update submission text later.
http://tasvideos.org/userfiles/info/72417918038904443
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Alyosha wrote:
TiKevin83 wrote:
I implemented 41 TAS verifications as a test suite for Gambatte Speedrun, the goal being to note any deficiencies outstanding in Gambatte Speedrun and to encourage TAS verification as part of an emulator's automated test procedures in general.
https://tikevin83.github.io/gsr-automation-site/
That's pretty cool! Clever to feed back in the GBI inputs.
I wonder what happened to Oddworld II though? Any idea where it started breaking?
EDIT: looks like the movie still works in dev build (after adjusting for the new power up timing.)
Considering how Winnie the Pooh also ended up not syncing at all, it's suspected that there's some flaw with how GBI inputs are played back. Possibly due to Gambatte's runFor overshooting a bit too much occasionally (which should be correcting itself for future runFors, but that might not matter if input overshoots just once).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ViGadeomes wrote:
Hello,
I feel like this movie should be changed into Moons considering the global 7.2 rating of it.
The judge at the time considered it was worth a Moons but decided to put it in Vault because he didn't have arguments against people that didn't find the movie enough entertainning for Moons.
It's 6.5 average entertainment rating (it's up to 7.2 due to technical rating inflation). That is somewhat borderline for Moon.
However, that being said, I personally would vouch for this movie being Moons. This movie was fairly entertaining in my opinion, solving puzzles with a ton of precise movement to defeat/avoid enemies/fire.
mGBA and Bizhawk, sitting in a tree, K I S S I N G first comes love, then comes marriage, then comes the baby in the baby carriage.
