Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
Evan0512 wrote:
I found out that the Nintendo DS has more lag than the Wii U VC
The Wii U VC is Nintendo's garbage DS emulator running on the Wii U. From Pokemon RTA circles, it's been tested and it's been found to be the least accurate when it comes to timing, even worse than DeSmuMe 0.9.11 (which is already fairly bad here).
Evan0512 wrote:
running on the Nintendo DSi mode results in the same lag as the DS
The game is not DSi enhanced, so it runs under DS compatibility mode on the DSi, so the DSi should not any kind of improvement in this regard.
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
You are not supposed to use Wine/Proton with BizHawk (they are not officially supported, and the Linux zips wouldn't have the Windows native libraries BizHawk bundles, rather just the Linux variants). You are supposed to use the EmuHawkMono.sh file, which launches EmuHawk with mono (and you are expected to install the mono "complete" package with your distro package manager).
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
For Gambatte, the cycle count has 2097152 cycles in a second, which usually has 35112 cycles per frame, which corresponds to when vblank occurs. Except not all ""frames"" have that since the game is able to "turn off" the LCD and PPU, which completely throws out any PPU timings (since the PPU goes to "sleep" and doesnt drive the LCD at all), and thus vblank never comes until the LCD & PPU is turned back on (once it's turned back on, it starts back from the beginning at line 0). Gambatte thus might have "short" frames when the LCD is turned back on, since it ends a frame whenever vblank occurs or 35112 2MiHz cycles have passed, whichever comes first.
A cycle count is only actually known at the end of the movie, so it cannot actually be saved unless you're at the end of the movie (and due to some jank reason this has to be done outside of TAStudio with the exported bk2; this has been changed in 2.10 anyways where exporting a movie at the end will produce a valid cycle count). Without the cycle count saved, the site will just parse the movie assuming ~59.7275 FPS (which won't produce the right time, potentially being very off depending on the game).
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
(reposting from Discord)
It's important to remember flash player was originally intended just for movies. "Play" (forward/back/etc) are all intended as part of that movie flow. The difference with flash games is they hacked gameplay interactions with that movie format.
So with this, flash games are actually split into "movie clips" (literally called MovieClip) which typically loop waiting for some condition (or something along these lines), clicking these buttons means you're forcing the ""movie"" to go between different clips, instead of using the actual gameplay metric normally used to go between clips.
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
I would argue too this is not so much a "glitch," if we want to publish it, it should not be labeled as "game end glitch" (nor any other glitch labels).
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
I can't seem to reproduce this issue for 2.9.1. A simple test in SoulSilver of moving 1 step, saving, then rebooting the core shows the save indeed has me moved 1 step.
Are you absolutely sure you're on 2.9.1?
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
Could you screenshot the window of this "squashed down" PSX game?
BizHawk primarily does not use libretro like RetroArch. The cores are all included and tightly integrated with BizHawk, 3rd parties can't just make cores like you can with RetroArch.
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
1. I'm surprised Game & Watch games are working at all since our MAME core is Arcade only. Also very odd they only work with Open Advanced, you are actually on the latest BizHawk version, correct? The core is deciding the aspect ratio here too so I would assume it would be actually correct.
2. You are not supposed to load with the .bin file, you are supposed to load with the .cue file. The .cue file tells the emulator where the .bin file is, possibly where other .bin files are at, and how the .bin file is structured with its tracks and whatever CD modes are used. This is the standard across emulators dealing with cue/bin, at best an emulator might be "smart" and use the .cue file next to the bin (although the .cue files are supposed to contain a file path to the .bin, so this is kind of wrong regardless) or maybe generate some .cue file to use with the .bin (which is rife with potential issues since it has to make assumptions about the .bin file that could very well be wrong). Not sure what you mean by the "aspect ratio is off," the aspect ratio presented with default settings would be given using the core's numbers, which would have the correct PAR and such.
3. C64Hawk isn't perfect, although using T64 isn't giving you any favors, as that's an incomplete format (we don't actually support .t64 in the core; you should be using .tap files rather): https://github.com/TASEmulators/BizHawk/issues/1501
Not sure why .CRT would give any particular issues (it's just a cartridge), perhaps just some other compatibility woes with C64Hawk here.
VICE port is already a request: https://github.com/TASEmulators/BizHawk/issues/2002
4. Libretro has "experimental" slapped on for a reason: it's nothing more than a curiosity to use them in BizHawk. Some cores don't work due to us not implementing all of libretro's bells and whistles and some don't work due to relying on unspecified behavior with RetroArch.
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
If a movie is loaded then that's a completely different matter, you already have input constantly available anyways. Although if that's not clearing out the input in that case that's probably a bug in itself?
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
RetroEdit wrote:
Loading a savestate should discard any presses that would be applied the next frame (i.e., the power press).
To be clear, it is a press which applies to the current frame, which is just yet to be emulated (it probably should be cleared, although other places (i.e. Basic Bot) would need testing to avoid issues).
You've loaded a savestate; your rewind buffer is going to be clear.
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
RetroEdit wrote:
CasualPokePlayer wrote:
I'm saying when loading a state it should "forget" that I inputted a hard-reset.
Loading a state should rewind to the exact situation I was in before.
Savestates do not hold your current input.
From a bit of casual testing, I can see the menu press is custom and independent of other interactions like virtual pad.
It uses ClickyVirtualPadController, which is used with a few other things (Basic Bot, TI83 Keypad UI, FDS Disk Controls). Basic Bot notably would seem to rely on such button presses not being cleared on Load State judging from its code.
Even so, consider the other way around: if you press the Reset button, savestate, advance some frames, then loadstate, should the Reset button be pressed on the load state? If we want to restore everything exactly the same as the savestate, including inputs, then the answer would be yes. I would say it should not be done.
If you press the Reset button by accident, there is already a method for undoing inputs you did not intend to do: rewind.
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
HappyLee wrote:
Memory wrote:
My goal for tasvideos is for people to be able to find the TASes they want to find. It doesn't matter how niche the game is, I want people to be able to find it. I'd prefer to find solutions that don't take us back to when people were rightfully calling tasvideos elitist.
What's wrong being elitist or being called elitist? Since we have the publication system, it's natural to value quality over quantity.
Just setup a new section where people are free to submit anything, apart of the current publication system.
Elitist itself has very negative implications. In this case too, it's not so much about "quality" in so it's making arbitrary rules on what is considered "quality." Your game isn't Mario/Zelda/Pokemans? Rejected for being bad game. Your TAS isn't entertaining to whatever tiny amount of "elite" people bother to comment on submissions at all nowadays? Rejected for not entertaining. That's the general implication with "elitist" here (of course, some of this is more complicated in practice, but that matters not for being called "elitist").
We also already have a system for people are free to "submit" anything: the userfiles. And now we even have Playground. Except these are all just not publications, why bother putting things in here if it's not going to be published under the "elitist" ruleset, always put in a "lesser" place against the "elites." So many people just won't interact with the site at all.
Of course too, I would still strongly think the new site had a major role in submission volume in the first place: it made people more comfortable signing up to this site, since it wasn't some weird web 1.5 http only site. The initial tier revamp and rules rewrite did not really change the fundementals of the rules, only with time did they change, if anything it initially happening could be seen as the site becoming less elitist, thus increasing submission volume.
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
low quality submissions
No
less-known/low quality games
Vault existed back then and would accept many of these games just fine. Especially keep in mind, many of Vault's old restrictions were still kept in place in Standard all the way until mid to late 2022: the most major of them being the "triviality" clause which was not eliminated until 2022-12-31, so cannot be a factor in this rise of submissions.
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
Why you find it unsustainable now?
5x submission volume really mainly has it unsustainable. In the long term, the rulesets still might make various TASers not want to submit to the site (although with Alt/PG changes, it's mostly now just down to IL runs not having a definitive spot and that's arguably more technical of an issue if anything).
The submission volume increase isn't something we can magically fix, people are not signing up to be Judges and Publishers, and if anything, we've been lowering the barrier for people to help by introducing the Reviewer role (effectively a half-judge non-staff role) and having the new sync verification workflow done here. Raising the barrier for having people help us would not help.
Why submission volume is so much higher could be a variety of factors. It began with 2022's record number of submissions. As such it's likely a combination of the new site (we're now no longer on the old http only web 1.5 site), and perhaps the tier revamp and rules rewrite (although, I would argue this if anything just mostly just made people more willing to submit rather than actually allowing said submissions to be accepted otherwise: a similar effect the new site would have).
More people are comfortable signing up for TASVideos and submitting TASes, therefore more submissions have to be handled. This hasn't translated properly to staff numbers, leading to a crowded workbench we try to handle the best we can with volunteer efforts.
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
tastudio should probably not throw exceptions when loading bad states/branches.
TAStudio is not throwing exceptions here, it is the core throwing such for being given bad states/branches. If this happens here, there isn't a good graceful way to handle such (ignoring the exception would just lead to even more exceptions down the line, not to mention the core is likely completely hosed at this point), the best that can be done is to try to save whatever progress is present.
I'm saying when loading a state it should "forget" that I inputted a hard-reset.
Loading a state should rewind to the exact situation I was in before.
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
CasualPokePlayer wrote:
Of course, the issue is for some of these TASes, appropriate credit is not provided, some of these TASes appear to try to claim authorship of TASes which this person definitely did not author, and some just have credits removed.
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
As I stated before, FireRed/LeafGreen/Emerald busy loop to wait for VBlank (that is what I meant by "vblank wait busy loop"). This was a change from Ruby/Sapphire, which actually halt. Ruby/Sapphire just use RTC for seeding RNG anyways, they don't use the hardware timer for this.
Also, nevermind what I mentioned about the "single check for a flash ID takes multiple frames," that's just for reading the flash ID, which is done once. The only difference between the Macronix and Sanyo IDs here is the Sanyo ID will end up going through the while true loop an extra time (the cycle difference possibly just ending up resulting in the same position of the busy loop triggering VBlank, leading to no difference)
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
Checking my Emerald cart, it appears to be using a Macronix chip (reporting an ID of 0x09C2). GBAHawk appears to report 0x1362 (Sanyo's ID) however (at least according to source code, my quick multiboot rom just says 0xFFFF so I assume it's not emulating a flash chip in that case). So not sure how RNG happened to sync (maybe the difference in cycles had it so eventually the vblank interrupt would occur in the same place within the vblank wait busy loop? Not sure how that's even possible however, considering a single check for a flash ID takes multiple frames? also Macronix is checked first so I would guess there would be a few frames less with Macronix here?).
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
Plain 0xFF everywhere is more a common pattern among emulators for simple deterministic uninit RAM. It's better than using plain 0x00s, which some games might end up seeing as valid savedata (while that wouldn't happen with 0xFFs). Actual cartridges before they're ever opened would just have junk in SRAM, "random with patterns." Some emulators might try to mimic more realistic uninit SRAM, but many just don't bother and use 0xFFs everywhere (which is "safer" anyways).
Emulator Coder, Experienced Forum User, Judge, Published Author, Skilled player
(1080)
Joined: 2/26/2020
Posts: 847
Location: California
Clicking hard reset in the menu just presses the '"Power" button for the current frame. It's still going to hard reset if you load a savestate on that same frame.
