Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ThunderAxe31 wrote:
scrimpeh wrote:
It feels like we should have a rerecording-capable simulator for the PICO-8 itself by now. Oh well. I've been waiting for a TAS of Celeste Classic, and I really appreciated watching this. Very good work throughout. It seemed like all of the obstacles were more like suggestions.
I agree. It should be relatively easy to embed PICO-8 inside BizHawk.
No, not really. The "emulators" I find of this would not fit at all well in BizHawk (lack of core-frontend separation), along with probably not being easily waterbox-able (which lua aspect also makes questionable wrt waterboxing). Under a technical aspect it'd really be as easy as putting a Game Maker emulator in BizHawk, or some other game engine, as it's a game engine in the first place.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
What you're really asking is playing the game without input recording then resuming input recording. Something like that won't sync the next time you replay the TAS, unless there's some sort of hacky magic with savestates. You could have a segmented TAS with multiple movies files, with the later parts starting from savestates, which is probably the only workaround for what you want.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Makonede wrote:
Hey, so I've been working on a set of TAS tools for Cemu. It isn't released yet, and probably will not have savestates for a long time (if ever), but it will have basic TAS tools like frame advance, TASInput, and movie recording/replaying. Could Cemu get approved as a TASable emulator by using CemuTASTools once it's released?
A hard requirement to be approved for submission is being open source, which Cemu fails right there.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Fortranm wrote:
I used to be able to run a VS. Castlevania rom with SHA1:16348D4AD47E4DF366FB88A88AE8CDE927947D5E on NESHawk in 2020 and earlier, but now it gets stuck at a green screen and the actual game never starts.
I see that this rom isn't in the gamedb, and the "best" version in gamedb seems to be:
sha1:9EB3B75E7B45DF51B8BCD29DF84689A7E8557F4F U VS. Castlevania (VS) NES board=NES-UNROM_VS;system=VS;palette=2C04-2;
I found a rom with this sha1 value named mds-cv.u7 from within a MAME set, but Bizhawk shows "Multiple cores fail to load the rom" when it's opened.
This was on Bizhawk 2.7. The rom not included in gamedb can actually be run in the dev build, but the supposedly best dump included in gamedb still gives the same result for some reason.
The .u7 file appears to be headerless, so inclusion, the file with header is not identified despite running while the headerless file with the sha1 value from gamedb can't be run.
If a ROM is headerless, some info needs to be provided by the game DB in order to run the ROM. None of the VS entries on the game db provide this info, so the games do not run with headerless ROMs. Just use your headered ROM, it's probably the same as that headerless ROM anyways (you can see the headerless hash in the dump report status)
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
feos wrote:
ThunderAxe31 wrote:
But that's not what we do for GB/GBC/GBA games: we use the system naming depending on the game itself, not on the system in which is played.
Those are ways to run a game on an actual device. Originally the game runs on whatever device it was designed for, and then on some newer ones thanks to backwards compatibility modes. I don't know if it's possible to insert an NES game into a VS Arcade machine, or vice versa.
The Windows movie on libTAS is probably a better example here than GB/C.
Besides that, no you can't just run an NES game on a VS Arcade machine. No way to insert a cart (it's an arcade machine lol) and the VS is different enough where trying to put the ROM in without any modifications it would not work (mostly due to I/O regs being swapped around sometimes and special PPUs VS systems use).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
I'll just point out we have GB/SGB freely able to obsolete each other, we have GB games marked as GB when running under GBC emulation, also I'll pop up this libtas movie: [4496] Windows Backyard Baseball "Pick-Up Game" by TiKevin83 in 04:45.05
Arcade makes sense and we already have precedent for this.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ikuyo wrote:
In a completely unrelated point:
I think TASVideos should introduce a proper process for movie _depublication_ (or retraction). For depublication, I mean the action of delisting a currently published movie and potentially retracting its acceptance.
If we expect the webiste to grow and receive an influx of new movies in the future, we need to account for the fact that the current review system is not infalible. Movies that fail to comply with rules or Codes of Conduct (which, tbh, maybe we should look into adopting as well) but manage to make it past the review process should be able to be delisted and removed from publication, at discretion from Staff. I understand this is not really feasible given the current codebase, but since soon this website will have a better technical backbone, I'd hope such a process can be established.
There was already a lot of debate about it, http://tasvideos.org/forum/viewtopic.php?p=472406
You end up with "oh oopies some emulator inaccuracy (probably most common way for movies to be "invalid") means we're removing your movie" which is not a very fun concept to deal with, especially when the authors can't exactly anticipate that hey some years later we found out your movie is invalid because some glitch you used relied on bad emulator.
Also other problems listed in that thread, but that's a big reason why we shouldn't allow unpublications due to breaking movie rules.
(Also, obsoletion gives the wanted effect anyways and is what's typically used for "invalid" movies)
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Probably some weird cache thing, doesn't show up for me unless I'm in private browsing. Harmless enough anyways, and wouldn't happen when new site is up (which will be very soon)
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Fortranm wrote:
Maybe this publication shouldn't have those 4 "forgoes" tags if the game end glitch movie is now considered invalid?
A game end glitch is probably not impossible to have anyways. Eventually someone will probably make a game end glitch movie which doesn't end up relying on the emulator inaccuracy the published movie used.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Guernsey wrote:
I have a question about the BSNES v115+ core in BizHawk. I read once that the core itself was somewhat experimental in Bizhawk. I wanted to use it but what I would like to know if it safe to use?
Not sure what you mean by "safe" (if "safe" is "won't fuck up your PC" then yes it's safe and we would not ship a core that does malware level bs in any capacity for releases). "Experimental" more means unfinished/potentially has issues with sync/etc. That core in particular is perfectly fine and I see it getting released officially sooner or later.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Awosomeandy wrote:
I'm assuming PokerPlayer did the encode already? but that could be something else. I could do the encode if there is a source on how to do it, if it hasn't been done already.
I did it indeed; EZ's question was before I added in that encode.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Awosomeandy wrote:
Thank you!
aswell as making sure I set up this TAS correctly, also tried to make it less boring than my previous lol.
I have one quick question, will this TAS be shown as slower than McHazard, because it is a bit slower in real time? even though it's faster in game time?
TASes always get displayed with their real time from start input to end input. However, it will likely have the in game time in the description and a clarification on why the movie time seems slower. And for purposes of judgement, we care about gameplay improvements (which is the point of going for IGT in the first place), we don't fault the authors for more accurate emulation being slower.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
xRavenXP wrote:
Great to see Nintendo DS emulated by Bizhawk. Just a question: how to use the mic in Bizhawk's NDS core? I only know this function in DesMume, but in Bizhawk 2.7 I didn't find any settings for the DS microphone. I await response. Thanks.
There is no support for custom mic samples currently. All the core does right now is blast white noise constantly, which you can adjust the volume of using the Mic Volume axis. Custom mic samples will be implemented eventually.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Aardvark64 wrote:
Can we get Nach's side of the story and point of view on this?
Ping him on IRC and assuming he doesn't shrug you off immediately since you aren't senior staff he might respond.
Good luck even trying to get that anyways. He can respond here if he wants to, but I doubt he even will lol
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
DennisOnTheInternet wrote:
CasualPokePlayer wrote:
It's also ultimately a lot of work that only appeals to casual players, which may as well use upstream. TASVideos does not use internal upscaling for DS TAS publications, so there is no loss for the purposes of TASes submitted to TASVideos.
My reasons for using Bizhawk are related to some of the plugins made for it, and the generally wide range of console compatibility in a single program.
CasualPokePlayer wrote:
BizHawk limitation really. As far as it's aware, your mouse is at the edge of the screen. Blocking a Touch for these cases would require some more hacky code which is a mess. For TASing this probably isn't a real issue, as using the virtualpad would be better.
For casual players that actually have a benefit from using Bizhawk, this'll be a very noticeable issue that may turn them away from using the emulator.
I understand where you're coming from with the whole TAS vs. casual player aspect, whhere Bizhawk is more meant for TASes, but at least in my mind, casual play should also be facilitated.
Right, I see where this is coming from. The former is probably just outright not possible (and again, even if it is it ends up having many strings attached), the latter is something that could be done eventually.
Of course also note for casual use, you will need a very good PC, much better than upstream or even DeSmuMe. Due to waterboxing, BizHawk melon is forced to a single thread, JIT is not available, and as discussed earlier GPU stuff is probably not possible to expose without just crashing or something. This makes melon in BizHawk much slower than upstream and DeSmuMe (around 6-7x times slower, give or take).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
DennisOnTheInternet wrote:
I feel like in the port to bizhawk, there's no longer proper scaling like you could get on the OpenGL renderer in MelonDS. This makes games more pixelated, which isn't a bad thing per se, but can be a bother to some, including myself.
Scaling like that requires the GPU which is probably not possible to expose from within waterbox, and that also leads to GPU specific issues cough Mupen everything being black on intel igpus cough, general inaccuracies, and potential nondetermination (well, I don't know if games can read out from the raw buffer anyways, so maybe no real determination issues there).
It's also ultimately a lot of work that only appeals to casual players, which may as well use upstream. TASVideos does not use internal upscaling for DS TAS publications, so there is no loss for the purposes of TASes submitted to TASVideos.
DennisOnTheInternet wrote:
I've also noticed, clicking *anywhere* in bizhawk, including the settings menu and window title will trigger a tap on the DS screen (not sure where, but it registers as one, since it boots me out of the mario kart DS pre-game showcase)
BizHawk limitation really. As far as it's aware, your mouse is at the edge of the screen. Blocking a Touch for these cases would require some more hacky code which is a mess. For TASing this probably isn't a real issue, as using the virtualpad would be better.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Fortranm wrote:
CasualPokePlayer wrote:
Gen 1 is already a mess with its branching and the current "game end glitch" run really is only there because of high entertainment ratings allowing it in Moons (and I wouldn't be so certain that can even hold if an improvement just pops up). And the JPN glitch runs don't have that entertainment rating. There isn't a place for it in Standard really, so it probably can't be split off.
(Also, you're comparing apples and oranges by comparing the select glitch runs without ACE with English GEG no save corruption runs. ACE is not so hard to trigger with the select glitch and would be faster too, granted little point to trying when no place on the site for such a run).
As a matter of fact, the JPN Green movie from 2010 has 18/19 Yes votes while the Yellow movie from 2019 has 10/12. With all due respect, I don't see where this entertainment argument is coming from. In a case where only one of these can be kept, shouldn't the Green one be preferred especially when it's faster?
http://tasvideos.org/Samsara/MovieRulesRewrite/FullDraft.html
I'm bringing this up mostly because of "If the fastest time for a game is an ACE run, we also allow a separate any% branch that foregoes it." from the rule rewriting draft. I suppose it's meant to represent the interpretation of the current rules. Or maybe it really only covers ACE as an exception but not immediate save corruption completion?
I was looking at movie ratings and not submission ratings, which does show Yellow game end glitch slightly outperforming Green warp glitch. Although admittingly it's not by that much considering the lack of votes for Yellow and entertainment is still in the 6.x average for the latest movie (and the previous movie was 5.x average just like both Green warp glitch movies). Perhaps if considering entertainment ratings of even older movies in Yellow game end glitch's branch then it makes more sense entertainment wise (the previous couple of movies with Red/Blue had 7.x average entertainment ratings, but that went away with Yellow popping up, and hard to compare considering the differences between the movies).
Really this shows how fucked branching here is if anything.
Still, I'm not sure where this thing from the rewrite is coming from, I would assume it is talking about Major Skips and No Major Skips, which wouldn't apply here anyways (the "no major skips" run would be the branchless run, with save corruption fulfilling the major skips run). Note that the rewrite will NOT change any rules, if the rewrite is then that is something that needs to be taken out.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Fortranm wrote:
[Movie]1639[/movie]
More of a reconsideration of the obsoletion chain than re-judgement I guess. If the currently published heavily glitchy runs of Pokemon Gen 1 are there on the basis of "absolutely fastest" and "no save corruption (but with ACE)", can this branch be revived as "no save corruption and no ACE"? Especially when this is actually faster than the ACE run. Alternatively, simply "no save corruption" works too if we consider the initial Japanese release to be different enough from later Gen 1 releases to be considered separate games for this category.
Gen 1 is already a mess with its branching and the current "game end glitch" run really is only there because of high entertainment ratings allowing it in Moons (and I wouldn't be so certain that can even hold if an improvement just pops up). And the JPN glitch runs don't have that entertainment rating. There isn't a place for it in Standard really, so it probably can't be split off.
(Also, you're comparing apples and oranges by comparing the select glitch runs without ACE with English GEG no save corruption runs. ACE is not so hard to trigger with the select glitch and would be faster too, granted little point to trying when no place on the site for such a run).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
InfamousKnight wrote:
Next obstacle is the emu.frameadvance(). Since it's automatic, I can't freeze the emulator manually. If I omit emu.frameadvance(), it would crash the emulator. I guess that's because Lua is on the same thread as the emu is.
emu.frameadvance() doesn't prevent you from pausing BizHawk, it just gives back control to BizHawk and won't return to the script until the frame advances (so the script is paused while BizHawk is paused)
I can confirm sync.
And I give this a yes vote, good job :)