Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
PikachuMan wrote:
fdafearfxre wrote:
I've gotten a glitch that made TAStudios almost unusable, and that is when I seek a frame bigger than the one I was in, it seeks the "frame I was in".
It's annoying, and it happened to me just now.
Especially on SNES and SGB where pressing rewind crashes the emulator and shows this:
Exception
System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.
at
[...]
The first issue is ticket #2392, and was fixed in 2.5.2 dev.
The second issue is known and tracked in ticket #2395.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
feos wrote:
If we invent some clause about the prototype being "better", then it also turns into a mess due to subjectivity of what people may count as "better". How do you check in advance exactly if the prototype you're TASing is better? And then, if it's better, a whole bunch of prototypes may end up replacing official releases, which reduces the overall legitimacy of our content, because playing a prototype is exceptional in itself! It's like playing a broken cart where you can do things no one else can do. It's probably possible to showcase in a Moons-only branch, but we can't afford that in Vault.
Is this problem exclusive to prototypes? I can imagine a situation where different official releases are in contention because one plays differently than the other.
In fact, I know games where major bugs were patched between releases (Donkey Kong Country SNES comes to mind, though it's not a Vault game).
However, I also think this may be a side-issue, since one response to this is that "prototypes are always treated as inferior, while different releases of a game can have more nuance".
feos wrote:
If you forgo diagonal movement, your solutions in Pinocchio will be similar to those in Ottifanten. I can't call the difference between 2 games inherent. It's not like you're forced to go through 50% of unique levels.
I'm still not entirely satisfied why both the prototype and the official can't coexist in this specific instance. It seems to me the gameplay differences are significant enough that the individual level strategies would require different navigation, even though the level layouts happen to be the same. It's not just "Pinocchio slowed down".
Ignoring diagonal movement, character agility, and the relative level speeds seems to me a somewhat subjective choice. After all, the rules don't say level layout trumps everything, any other differences between games can be ignored. If "inherent" means level layouts, the rules should say that. I personally think you can have inherent differences while still having the same level layouts.
A far more objective criteria in my mind would to compare how the relative tactics can be transposed from one game to the other. If it's just a matter of adding blank space between inputs, than the differences are trivial. If however, it actually requires different navigation, then considering them separate may be better. For instance: dodging enemies is clearly different, and I also think Pinocchio is able to jump farther and therefore navigate around the platforms in different arrangements. I would imagine there are very few levels if any where the movement could just be slowed down and exactly copied and be optimal for both games.
If at the end of the day, there are too many things that are similar, that's what it is, I suppose. But I can imagine there being independently released games that are also similar and I'm curious if we would treat Pinocchio and Ottifanten as cross-obsoleting if they had been separately released.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
RetroGameStream wrote:
Since the version 2.5.1 update I'm getting the error code 0xc000007b when trying to start a recording using FFMPEG.
It will download it and place it into the dll folder okay, but after downloading I get the error saying the application needs to close and it doesn't recognize the FFMPEG executable in the dll folder.
Fixed in 2.5.2. As a workaround, you can delete version.dll in the bizhawk folder.
(copying natt's post)
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
These might also be useful to reference: Post #14890, Post #15277, Post #16932
In general, I would say subpixels are just a subset of coordinate data relevant to certain games. Finding the coordinate data is what's broadly useful, since it allows you to make nonobvious optimizations.
If the game uses subpixels, you're then optimizing for the subpixel value rather than guessing based on what the movement visually appears to be. This generally allows more granular refinement.
One way I've used subpixel is when you're travelling vertically and your horizontal progression is restricted. With subpixels, you can cut close to corners without bumping into the corner. Basically the idea is, you use the vertical airtime where you're not really progressing to optimize the subpixel position for the next section of the same level.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
A resource I would recommend checking out is this site:
https://www.jeffludwig.com/finalfantasy/hacking/
Unfortunately, the site's navigation is a bit bad, since it doesn't present navigation between pages in the clearest way. The easiest way to find all the pages is to look at the FF1 Hacking Intro, Data Tables and Code Hacking sections at the top.
The site might be insufficient to directly get important memory values, since some of the specific details are lacking, but the general conceptual breakdown seems like it could be useful.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Warp wrote:
This feels a bit contradictory with the sentiments that TASes should at least theoretically be replicable, as is, in the actual console and that, for example, TASes that rely on emulator bugs or faulty emulation are not considered valid.
In the cases where a TAS does not sync in the actual hardware because the emulator does not emulate the hardware 100% correctly, and it's these tiny differences that are the problem, shouldn't this be considered the TAS relying to faulty emulation to work correctly, and thus technically speaking not fully valid?
Except this really isn't a contradiction, because the actual rule is not "do not have any inaccurate emulation in your submission", but instead: "Do not exploit emulation bugs". The rules actually also use the phrasing "we generally aim to publish videos that look like they could be played back on the original video game system". Functional similarity is the priority, not pure frame-for-frame matching (which of course may be complicated in many cases).
Technically speaking, emulation accuracy is only one consideration for validity on the site, and not an objective binary pass/fail system. A judge must evaluate whether the emulation bug is significant enough to warrant rejection. A run is not "technically" invalid when it's not emulated properly, because the site's criteria for validity does not include the requirement that the timing perfectly matches a console-verification.
Warp wrote:
Patashu wrote:
Except in the case where there is a logic difference between emulator and console (like a glitch that cannot be done on console that's exploited in the TAS), I'd consider the easier ability to reproduce, distribute and introspect a TAS in an emulator to be more useful of a quality than the modified version that plays back on console but not yet on any emulator, since far more people have the ability to interact with the former than the latter (though we should of course still make both available). Yes, the console verified file is more accurate but less accessible.
Given that, as far as I know, it's impossible to create a TAS without an emulator, I find the scenario quite unlikely that there would be a console-only TAS with no emulator version.
I think focusing on whether it's possible to create a TAS without an emulator misses Patashu's point. Patashu was not appealing to some hypothetical about a movie file that works on console but doesn't have an equivalent emulated version.
Instead, when considering a publication where we have a movie file that plays back on emulator and a console-verified version of that movie that is different, we should prioritize keeping the emulator file as the main publication file (while still keeping the console-verified version available). The emulator file is more accessible because anyone can run it and analyze it. The emulator file is also the file that has undergone judging and usually double-checking for sync by both the judge and the publisher.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Yeah, if you just search for values in the emulator itself, that won't necessarily be efficient, since the values can vary between screens.
If you can find the static pointers to these values (usually by debugging the game enough and having a fair understanding of the game's memory model), then it won't change from screen-to-screen, and you can display the values with a Lua script.
For some values, it might not be that complicated. For instance, the RNG state is always stored in 0x02001A18. However, the RNG state is not directly useful unless you have a pretty good understanding of the internal RNG mechanics, since RNG can be rolled many times in the same frame. With Lua, you get the RNG state by calling the function memory.read_u32_le(0x02001A18, "System Bus") (code lifted from my current script).
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Zamasu wrote:
Hi people, I have try to understand FF1 RAM Values from this site but I don't understand nothing.
I use VBA-rr emulator and Final Fantasy I & II rom.
VBA-rr is not recommended. I would recommend BizHawk instead with the more accurate mGBA core.
As for a battle display script, there is not one that I am currently aware of, but I hope to make one eventually. There are actually a fair bit of resources on Final Fantasy mechanics if you look around (more so for NES, but also GBA-specific details).
I do on the other hand have a code repository tracking my progress, and so far I have made a 15-puzzle prize predictor script that shows the exact prizes you will receive for a given puzzle.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
ktwo wrote:
For those of us that don't care much about the entertainment aspect of TASing, I guess it's unfortunately not possible to submit directly for the Vault though. So there will always be this mismatch in expectations when verifiers look for entertainment in movies that weren't submitted for consideration of being "objectively" entertaining in the first place.
I actually don't think this is a problem. In my personal opinion, it's best to TAS something you're personally interested in, instead of worrying too much about what tier it ends up in.
Even if you're pretty sure it might end up in Vault tier, the audience can sometimes surprise you. It's not a problem if a judge decides something is Vault tier because of the audience reception, it's the system working as intended. But it's also not a problem if a game turns out to be surprisingly well received and exceeds your expectations and end up in Moon tier. You never know.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
MUGG wrote:
I saw the entries were like this:
This must be a mistake, since I cannot find any statement that the glitch run is illegitimate nor that the longer run obsoletes the glitch run. Also I have never seen an older run obsolete a newer run.
Look at CasualPokePlayer's canceled glitch submission, and probably a comment on the submission discussion topic.
The "glitch" was determined to be a designed level select sequence.
Here's a link to CasualPokePlayer's canceled game end glitch submission: http://tasvideos.org/6846S.html and http://tasvideos.org/forum/viewtopic.php?p=498660#498660
A publisher should probably make a note on the publication and submission text of Jigwally's publication, though.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
A few things:
1) Savestates aren't compatible between cores, so trying to load a savestate created in a core different than the current core will not work.
2) Movie files can't be directly converted from one core to another. Instead, you can make a new movie and copy the input log over. If you use a tool like 7-Zip to extract your .bk2 (it's just a zip file internally), there's a file inside called Input Log.txt. You can also copy over fields from the Header like the Rerecord count if you want. Then once you're done, repackage all the files into a .zip, and rename the file extension to .bk2.
Note: if you're using TAStudio, you can simply copy the inputs directly by selecting and copying the input lines, and then pasting them in the new movie.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Yes vote.
I have to say I was initially skeptical that primarily using only one ability (wings) would retain engagement, but the variety of level designs and uses for the ability made for an entertaining watch.
I will do an exhaustive search for late menu/map/screen transition presses and get back to you on that.
Edit 2020-09-11: Still working on this, by the way.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
I resynced this to Gambatte because I was curious:
User movie #65874807770928717
As expected, I was able to save a miniscule amount of time by pressing inputs earlier because Gambatte's frames line up better with input polls*. This totaled to a time save of ~0.12 seconds. Note: my resync basically involved inserting blank frames to fix the frame-length differences in screen transitions; no gameplay alterations were made.
This also revealed to me this submission has a lot of superfluous inputs at the beginning and end of levels. Essentially, the first two green (non-lag) frames in each level mostly don't affect movement at all, and a few times the last inputs were completely unnecessary and marked as lag by Gambatte (perhaps the timing had altered in those cases). This is unimportant and mostly aesthetic, but my personal aesthetic preference is to have blank frames instead of inputs when inputs are unnecessary, especially so those who analyze the movie can see which inputs are actually important. I didn't bother to tweak these except for one or two at the very start of the movie because it would have taken more time; it was just something I noticed in the process of resyncing.
Also, there might be a frame or two to save even in the GBHawk submission movie directly by pressing A to enter the 2nd K. Rool battle sooner. Alternatively this might be a cumulative effect of other changes when I was resyncing to Gambatte? But it was a very distinct point where I actually deleted 2 frames in the Gambatte version (everywhere else, extra frames needed to be added to compensate for the difference between how Gambatte and GBHawk handle frames). I wasn't able to check this because I accidentally corrupted my .tasproj for the GBHawk version and don't feel like replaying it again.
----
* Gambatte's frames are based on when VBLANK occurs, while GBHawk forces frames with equal cycle counts. Gambatte also has a sync setting called "Equal length frames" which is the equivalent of GBHawk's behavior, but I had this setting unchecked for my resynced movie.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
PikachuMan wrote:
Spikestuff wrote:
Ah yes. Very descriptive. It's like we all have the same keyboard layout.
WHAT KEY. BE VERY SPECIFIC.
Also there are keyboards that DO NOT feature the Windows Key on the Right Side of the keyboard.
Yes that's true. This also applies to some Mac keyboards that doesn't have a second Apple key.
It is the key that operates the same as the right-click (the key crashes the emulator whereas the right-click doesn't) The key in question is labeled as Applications aka the App Menu key.
I have that key on my keyboard. I don't have this problem when I press the key (nothing happens when I press the key). Can you give more details on how to consistently reproduce the issue?
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Caveat: I am not a judge myself, either.
strizer86 wrote:
I wasn't sure if there was a clearly defined spot to check under the game itself, or to verify via the old TAS by SirVG. It's only a difference of about a second and half, but I just want to make sure I am accurate and know for future.
As MemoryTAS and Invariel commented right before me, the time according to the site is based on the calculated time from the input file length.
However, it sounds like you might be asking a slightly different question, which is how to compare your run to the previous TAS. In general, this is a slightly more complicated question, because raw time differences may be influenced by emulation accuracy. For instance, it is often the case that runs made on older emulators emulate less lag and are therefore artificially faster (the reverse can also sometimes be true). For the purposes of time comparison, timing differences between emulators are ignored. See http://tasvideos.org/MovieRules.html#ObsoletingAPublishedMovie for more details.
Because of the complexity, it is very difficult to make a perfect time comparison between runs, but there is at least some evaluation (For instance, a new TAS with identical or worse gameplay won't obsolete the previous TAS just because emulation happens to be faster).
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
In regards to the contest, adelikat has mentioned that there are many benefits to using 2.5, particularly for TAStudio. I concur (as I've personally been involved in improving TAStudio). Among these benefits are some performance improvements, and more significantly fixing a desync bug in TAStudio (ticket #2186). Add to that it is essentially impossible that a .bk2 that syncs in 2.5 will desync in 2.4, since Uzem (the Uzebox core) hasn't undergone any core changes since 2.4.
Therefore, I will personally be using 2.5 for creating my TAS, and I would recommend doing this to others if they don't want to put up with the problems in 2.4.
Ideally 2.5 would be officially supported by the contest, but Dacicus is on Windows 8, and has decided not to support BizHawk 2.5 because it cannot run on the Windows 8 OS. (Windows 8 is not supported by BizHawk 2.5 because Windows 8.1 is the most up-to-date version of Windows 8.)
So I will still exercise a modicum of caution and make sure my movie syncs in 2.4 before submitting it for the contest, but there is no requirement that the movie be made in 2.4, just that it syncs in 2.4.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
CasualPokePlayer wrote:
Anyways, I'm just going to put a case that I think can display the issues with letting save glitch TASes use uninitialized save data. Let's say there are 2 emulators with different patterns for uninitialized SRAM. One pads it with FFs, the other pads it with 00s. Both these patterns I would argue are perfectly valid for the purpose of establishing "clean" SRAM.
I disagree with this premise. I very sincerely doubt they are equally valid.
My ground here is a bit shaky because I don't know the specific examples for Game Boy but I assume they exist. My metric for deciding whether an uninitialized state is fair is whether there exist games where starting with one versus the other makes the game detect existing savedata even without the player doing any manipulation? If that's the case, I would argue this would provide evidence that a certain savedata pattern is not a regular uninitialized state for that cartridge.
CasualPokePlayer wrote:
Now it gets dicey when these patterns are abused with save corruption. One emulator could have a better pattern for one movie, the other emulator could have a better pattern for another movie. And, I would go as far as saying movies abusing these technically arbitrary patterns the emulator sets should be considered New Game+ (and thus ineligible for Vault). Your TAS actually displays perfectly why it should, you literally unlock everything because the pattern set the emulator effectively matches a New Game+ kind of SRAM. Again, the pattern set by an emulator is effectively arbitrary, a TAS specifically abusing this should not be allowed in my opinion.
(bold mine)
I really don't see how you can single out savedata as technically arbitrary, when there are so many other differences that can affect emulation accuracy.
I disagree with the assertion that are no better or more correct configurations, because, to my understanding, it's not like other types of uninitialized memory where it's nondetermistic based on how your console feels when you boot it up. Instead it's just whatever the manufacturer happened to ship with the cartridge. Which yes, could theoretically be inconsistent if the manufacturer was disorganized, but I would expect certain states to be considered more correct by the game.
Now I might be willing to entertain an argument that different games could potentially have different standards. But this is not the same argument that the state is "technically arbitrary" and can't be relied upon at all as a baseline state.
I know there are more correct save configurations for GBA emulation, to the extent that certain badly programmed GBA games will detect savedata if you setup the wrong initial state. I would imagine the same is true of Game Boy emulation.
EDIT: Here's the example I'm thinking of for GBA. Funny enough ThunderAxe31 commented there.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
NightWingMistHawk wrote:
When I try to run this version of BizHawk my computer (Windows 64x laptop) says it won't because it's detected viruses, specifically a Windows 32x Trojan. I tried reinstalling the prereqs but that fixed nothing. Do I just turn off my antivirus defender, or is there something wrong with my installation proccess?
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
nymx wrote:
RetroEdit wrote:
nymx wrote:
I have tried to debug this myself, but the BizHawk sln has an architecture that will take me some time to figure out. At this moment, I don't have spare time to dedicate development to this app. Hopefully soon.
Yeah, I've been contributions to BizHawk recently so I'm going to look into it now, and I should be able to find the code that raises the error. Solving it may be another matter entirely, though.
Huh...just curious, but if you happen to find a answer, do you suppose a binary file could be copied over to the existing 2.5 release? That way we wouldn't have to wait for another full publish?
Nevermind...If you find an answer...I can just publish locally.
Dev builds are regularly released, so you can grab one of those. If you want to cherry-pick commits for some reason, you can build it yourself.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
nymx wrote:
I have tried to debug this myself, but the BizHawk sln has an architecture that will take me some time to figure out. At this moment, I don't have spare time to dedicate development to this app. Hopefully soon.
Yeah, I've been contributions to BizHawk recently so I'm going to look into it now, and I should be able to find the code that raises the error. Solving it may be another matter entirely, though.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Yeah, I'm starting to realize this issue is significantly higher priority than I originally though it was when I encountered it a few months ago. It breaks certain TAStudio-specific Lua functions, and it's just arbitrary that it's broken for certain things.
My workaround is to generally avoid TAStudio when scripting and take advantage of the speed boost when TAStudio is closed. I do stuff TAStudio is good at while I'm not using my scripts.
But that doesn't make sense for certain scripts, so I sympathize.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
This specific issue you mention is known and documented in this ticket. You can check there for progress, if any.
In general, Lua is a tricky thing, and I find interactions with TAStudio to have problems. Hopefully that will be resolved in the future.
This must be a mistake, since I cannot find any statement that the glitch run is illegitimate nor that the longer run obsoletes the glitch run. Also I have never seen an older run obsolete a newer run.
