Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ais523 wrote:
At least some Nintendo games for the Game Boy have "delete save" functions that are intended to be used by an end user in some circumstances, and if I remember correctly, they work by overwriting the save RAM entirely with FFs. I think that's evidence that all-FFs is "intended" to be the/a blank state of the save file on Game Boy cartridges, and at least makes it reasonable to use on an emulator.
"some" being "Gen 1 Pokemon"
I've looked at many games to find something to save glitch, and all of them zero out save data and consider that as empty data. Link's Awakening zeros out save data, so does Super Mario Bros. DX, Wario Land 2, Donkey Kong Land 3, some Kirby game, some Pokemon Pinball game, hell even that Devil Island game I referred to. Gen 1 Pokemon is the exception with this as it FFs save data for some reason. Hell they got it right the next gen, which zeros out save data.
ais523 wrote:
It would be hard to figure out what the save RAM is on a factory-fresh Game Boy cartridge nowadays; there are few that have never been played, and on platforms where the save RAM makes use of a battery, the batteries would be dead by now.
imo the argument that the factory flashed FFs to carts is probably bullshit. Considering that you have to assemble the carts before you could do that and the process of writing FFs to SRAM is not exactly efficient to do at that point. It's fairly likely SRAM was just whatever "pattern" is left behind when it isn't powered (said patterns that Alyosha is referring to).
EDIT: Oh, the use of MBC chips would likely also make the process of flashing a specific SRAM state onto a cart more expensive. Considering once a new MBC comes out, whatever the factory is supposedly using to flash SRAM states might not work (the MBC2 comes to mind, along with other somewhat obscure MBCs).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
There's a bit of an issue if you want to argue for this to be a different branch:
Now, let's say this can be a separate branch. I don't think it would be able to be Vaultable, and would need to be subject to Moons. Which needs entertainment. Which the votes don't exactly show that happening.
A very small number of older games may not function properly on the Game Boy Color, Game Boy Advance, or Game Boy Advance SP. Common symptoms include scrambled images, missing graphics, or sound problems.
A very small number
Your source is literally saying they are edge cases.
Also Nintendo is really not the best source... considering how much bullshit they've said about how the Gameboy works, they are (somewhat ironically) not the best source to site for issues regarding the Gameboy.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Nach wrote:
Something which I saw years back.
There was flickering all over the place in the game which I never saw on my DMG.
I saw this before there was a YouTube or TASs.
So you are blaming flickering on a really old recording on it (apparently) being on GBC mode instead of perhaps just inaccurate emulation? Or even just a really shitty recording? Considering this during a time when GB emulation in general was really poor? When emulators in general were just shit compared to today's? Hell it could of been some god damn compression artifact from someone turning up the compression to extremely high levels.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Since one of these glitched graphic examples came from me, I'll just explain why it looks weird. This is really just a quirk with how colorization works. With the default green and red, the GBC colors the background map green and sprites red. So if you're seeing a mix-mash of these colors, it's really the game swapping around sprites with the background (which is a fairly clever way to get around sprite limitations and is sometimes used to avoid the flickering issue due to going over sprite limits). Hell, this is completely avoidable if you just set the palette to greyscale (or some other palette choice that colors the background map and sprites the same) during the bootrom (which is what I've chosen to do for my Prehistorik Man TAS, just due to the graphical fuckery).
Nach wrote:
I myself noticed in a Zelda encode flickering that shouldn't be there. But that's the more noticeable sort of thing.
Which Zelda encode are you specifically talking about? The only DMG Zelda game I'm aware of is Link's Awakening (not DX), and all TASes published/submitted used DMG mode, so I'm guessing some random TAS on Youtube?
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
I guess this eventually has to be asked, what about revision differences? You might find maybe in a rare case a game is broken on one revision but fine on another. Or perhaps some "subtle" difference is in there. They do exist, after all (and again, rare).
Should we start having modes emulating specific console revisions? Should TASes be forced to be locked out of revisions not present at the time? Should TASes be forced into the original revisions of these consoles at all times, or the latest revision of the console it supports?
It's dumb really. Of course for obvious cases you could have an argument for rejection, but this really isn't a good reason for most games, it's only edge cases where you end up getting broken DMG/CGB games.
Also, DMG emulation not really at the state CGB (and CGB in GBA) emulation is at, since most focus has been on the CGB (in GBA). And SGB... god the core is really old and hasn't been updated for a long while (it really needs to be updated sometime lol)
Also the exact case Tike is pointing out wasn't "DMG/SGB emulation being more accurate," it was just an emulation inaccuracy, plain and simple.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Memory wrote:
Nach wrote:
Also various DMG games have broken/missing sound on CGB.
Can you provide some examples?
There are some cases of this (but it isn't exactly common, and are more the exception rather than the rule, and they would stem from the DMG having square wave channels and the GBC having pulse wave channels... which on that note the GBA emulates the GBC's pulse wave hardware with its own hardware so lol).
Although, I guess somewhat to the support of Nach, there's also games that straight up do not work on the CGB. Well, two games, and it stems from them relying on a hardware bug with the DMG, which was fixed on the CGB, so they just crash on the CGB/AGB.
Even then, these are more exceptions, sometimes running DMG games on the CGB could make them worse, but generally I think running them on the CGB makes them better imo. The limited colorization can often make a game much more visually appealing. "Best mode" can essentially just become subjective at this point.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
FractalFusion wrote:
I haven't been following Pokemon save corruption recently (totally glitched runs just aren't my thing anymore), but I have a question. Did using glitch items (at least one which I believe allows you to execute RAM) ever factor into your TAS? I managed to find one on the JP version, but I can't remember if it was the same for the US version.
To be clear, 99% of the TAS is still MrWint's, this submission is just adding in checksum collision into the equation so the reset can happen a few frames earlier.
That aside, glitch items for the US version are heavily documented, and wouldn't be that hard to yoink the pointers out of the JPN version either (or any version for that matter). The bigger issue is just making a payload. The furthest we can go to (properly) complete the game would be in HallofFameRoomScript2. That's in bank 0x16. You won't be in that bank when you use an item, you'll be at bank 0x03. So the code would need to bankswitch, then actually jump the HoF code. There isn't some place where such a payload could be stored. And it really isn't better than what's used now: the map script pointer is changed so it points to HallofFameRoomScript2 (and the map number is changed so it'll go to bank 0x16).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
encode
Link to video
So regarding this movie's game choice, well you essentially used a prototype version of the game on top of technically a romhack of the game. So it probably wouldn't be Vault eligible. But for Moons, is it entertaining enough? imo the run was very entertaining, and it seems to be very different from Punky Skunk? (from quickly watching the old TAS anyways). So definite yes vote.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
http://tasvideos.org/userfiles/info/66377775510951160
Movie file with truncation. I'm not sure if you're actually aware of this, but timing ends on the last frame of input. You should be truncating your input. Your mashing is also very questionable on its own. Along with a lot of the run itself. Also wondering why you used 1.13.2 instead of 2.5.1. Windows 32bit user? Regardless, movie is sub-optimal as shown by Spike lol
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
NitroGenesis wrote:
I think this game is entertaining enough as a platformer on its own.
Honestly would believe that... but sadly it's objectively not true. The previous TAS was pre-vault, and when Vault came around, it got automatically placed in there due to its abysmal ratings. Although that was actually a mistake since it wasn't vaultable in the first place so it was replaced into Moons.
I guess to be clear, I believe this movie should obsolete the previous movies, any idea about some zips and zipless branch separation can't really be done just due to zipless not really worthy of its own branch due to its ratings.
Also for the JPN choice, I really didn't think there was much reason to use the English version. Story is boring imo, and I found out when making this that were some cases of religious symbols being cut out of the Western versions (for obvious reasons). The game is just going to Vault anyways so who cares anyways lol.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
I'm wondering why Hard mode isn't used, is there a good reason for picking the "Normal" difficulty over the hard difficulty? Typically hard mode should be preferred, although I don't know what hard mode actually does so I'm wondering if there was a specific reason for not using it.
VictorManuelMR wrote:
But can I still add a text, explaining why I chose each thing?
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
So in Gargoyle's Quest, right before you fight the final boss, you get the choice to "become the follower" of the final boss (yeah that cliche). If you select No, the game proceeds like normal where you fight the final boss with all your weapons/magic. However, if you choose Yes, the game actually punishes you for this by forcing you to fight the boss without all your weapons/magic, essentially forcing you back to level 1. While it might seem like it's impossible to defeat the final boss, well from some testing it should still be technically possible to beat the final boss, although it would take quite a while due to the way the boss fight is set up (roughly guessing 10-15 minutes? For reference doing the fight normally wouldn't be more than 30 seconds).
So I'm wondering, would choosing Yes in this case be considered "hard mode" for the boss and should it be chosen purposefully, or should No just be picked so 10-15 minutes isn't spent just doing the final boss.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
CasualPokePlayer wrote:
Playing through the movie in 2.5, it appears to desync, so there's probably a good chance the cause of the console desync is fixed in 2.5?
Ok this "desync" on 2.5 is just because there's just no input after frame 44621. There's just a ton of blank frames after that. I guess aloysha uploaded the wrong file?
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Warp wrote:
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.
Well, it is theoretically possible if crafted in some specific way to do so, just that said TAS would not work on emulator in the end but would work on console. For GB/C TASes, something of note that would differ would be how reads of disabled SRAM (or perhaps no SRAM exists, or some other quirky behavior like this that was recently implemented in GSR) would work. It's fairly understood how it works, the MBC just simply doesn't respond and doesn't send any data, so the read would pull out the last thing on the bus (which would be the last opcode executed). But this value could end up "decaying" into FF (notably, if said read was executed in RAM instead of ROM). And of course, this behavior also differs between consoles. For the Gameboy Player, read executed from ROM is last opcode executed, read executed from RAM (VRAM/WRAM/OAM/HRAM/etc) is FF. For the handheld GBA and GBA SP, it's the same, but for ROM reads the last opcode executed byte can have unset bits randomly set. For the GB and GBC, I believe it just always results in FF no matter what (although research on these consoles for this behavior is VERY limited so take this with a grain of salt). Some other caveats to this (like how pop/ret work out, and some others that really need to be researched), but it's not exactly implemented into emulators (Gambatte always returns FF on disabled SRAM reads and GBHawk returns 00 for ??? reasons). It could be actually possible to abuse this behavior in some glitchy runs, perhaps in some ACE runs or other glitches, and could maybe sync fine on console but not on emulator (this is mostly considering if the ACE is executed right at the end and it just goes to end sequence on console but doesn't work on emulator).
Of course, this is just one example on one system, but it does show it is possible, but practically impossible by chance and would need to abuse known but not yet emulated behaviors.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
feos wrote:
If not the possible full completion criterion in Ottifanten, I'd require that this movie is accepted and then obsoleted by Ottifanten. Ottifanten having more levels (I haven't checked yet) is also a good thing for a full completion kinda run.
I think that would be fair... especially considering nobody is actually going to TAS that game anyways lol. Also, yeah Ottifanten does have more levels (30 more for a total of 130 levels)
For the rules, I don't really know. Perhaps it is just being overthought, but perhaps some issues just arise since "inherently" can be subjective? Then again, this rule wasn't specifically designed for this case, edge cases be edge cases...
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
feos wrote:
Reached level 18, I have no idea how to beat it.
http://tasvideos.org/userfiles/info/66144640781107698
From what I'm seeing so far, the released game feels more like a hard mode, purely because there's no way to truly move diagonally. However that's most likely an oversight in the prototype version, because with it you can skip most of the puzzles. I think they just patched it away (as a bug), just like infinite lives and level select. The "completely different" solutions look like just the way it was designed to work originally, not like intentionally/inherently unique gameplay.
Easier gameplay isn't what we look for most of the time, especially if the game is an interim draft, and the official release is harder.
For level 18: https://streamable.com/yhvd2s
From the perspective of TASing... I can see how it could be seen as "hard." But in the perspective of RTA... I think Pinocchio is harder. The diagonal movement does allow you to "skip" puzzles somewhat (although corner exiting is more the extreme in this aspect), but the execution is usually not easy for a human (somewhat due to how touchy the controls are and how fast Pinocchio moves). In some cases, it's just near impossible for a human. Doing the puzzles the "intended" way is often much easier and safer to do, although for Ottifanten the slow speed can sometimes be crippling to this (although you could argue the opposite).
I do think there could be compromise though. I notice in Ottifanten there are these collectable baby bottles and these are tracked. I don't know what the hell happens if you collect them all, but I does mean Ottifanten should be able to actually have a full completion run. Pinocchio can simply be the go to version for fastest completion, with Ottifanten being able to be published in Vault too with a full completion run.
Now, let's say this can be a separate branch. I don't think it would be able to be Vaultable, and would need to be subject to Moons. Which needs entertainment. Which the votes don't exactly show that happening.
Yep, both of the new tests pass on console.
scx = 6
scx = 7
