Thinking about 999999 points, I notice the current submission uses Level 18 (which has 3 frames gravity instead of 2 frames) to be able to move horizontally enough near the top. Tetrises are worth 1200 extra points per level, so I wonder if starting at Level 19 can be worth it (probably having to use pauses to increase horizontal travel). The top row triple glitch is still essential surely, since it saves so many pieces.
There's a lot of great information on this page: https://meatfighter.com/nintendotetrisai/
Anyway, I've started the resyncing. My plan is to likely use the exact same build, but in many spots the order can differ. Like at the start, it places an I in column 2, O near the right, J far right, T slight left. None of these are on top of each other, so they can be done in any order, based on what takes the least RNG manipulation.
From what I can tell, the frame that the new piece spawns is what decides the next piece, with Down+Left+Right usually delaying one frame (sometimes zero), and pausing delaying at least 2. Do you know if there's something more to it than that?
I'll also keep an eye out for equivalent shapes (like this crude drawing):
It's off to a bad start right now, I'm matched up because of ending up RNG manipulating the same pieces Baxter did. But once the pieces aren't so close to the top, the soft dropping will save more frames, so I can hopefully use some new options then...
OK, I tried starting the run 1 frame sooner (which shifts ONE garbage block on the top row very slightly, as well as having different starting pieces) and built to the same shape, and am now 3 frames ahead! Hopefully more to come
The lack of music is a huge shame, and it can feel repetitive, but I'm incredibly impressed with the Lua script and the effort put into this improvement. The amount of collision abuse is definitely unexpected, and collecting the menu cursor is beyond unexpected. It's on the fence tier-wise but I'm voting yes, more for the effort and optimization than the game itself.
Alright, with your blessing I'll work on the resynced Mode B TAS soon.
I've been doing quite a bit of brute force Lua scripting recently (I'm 1.5 million runs deep in Pokemon TCG right now), but I can't think of a use for such things in Tetris, but I'm certainly interested. Though optimizing the soft drops won't have as big of an impact (there's barely enough time to do the horizontal movement it needs when it's playing near the top), if there's a brand new board setup strategy figured out, I'm open to helping execute it.
Yeah for sure "Mode B" can be impoved yet futher.
Actually i was hoped that my submission will become catalizator for beginning of new era of NES Tetris TAS :)
Great job Blazephlozard! Weclome aboard.
I ask judge to replace movie file to new and add Blazephlozard to list of authors.
There's no movie to replace it with yet; the soft dropping, and RNG manipulation, would have to be done from piece #1.
The "999999 points" TAS could be improved with this as well, but, the build options are so much more open-ended, I would hate to just resync the exact same piece order in that.
Someone was talking about TASing NES Tetris yesterday and I was accidentally prophetic...
The Mode B game's goal is to clear 25 lines. So, from a speedrun perspective, the fastest "Mode B" clear would be to just spam Tetrises near the top of the screen, same strategy as the 999999 points TAS. But from a stylistic perspective, clearing the board is obviously far superior, and with the hellish garbage the game gives you, makes it an extremely unique challenge compared to other Tetris TASes. So, for entertainment purposes, clearing the board is an important secondary goal.
An early input end is a fantastic way to save time in Tetris TASes without having to restart the entire thing. I love them because it takes special care to set up the board just right for the pieces to fall into place (literally).
As you said, it's possible that a faster run could be done using a different starting RNG (for a different garbage layout), but it's extremely hard to know for sure, and takes a LOT of effort to test each possibility. There could also be a much different build for this garbage layout, especially since this Tetris allows you to RNG manipulate what the next piece will be by delaying the current one. But considering Baxter's insane playaround TAS, it's safe to say he's quite good at building in Tetris.
One potential way a full rebuild could be faster is if it does more of its 13 non-garbage-clearing lines closer to the top, saving vertical piece travel. Another way is to minimize line clear animations, so less singles/doubles. But, the garbage is not placed in a way that makes either of these timesavers an obvious task, or even possible at all.
However, there seems to be one major timesaver that can apply to the exact same board build... It seems that soft drops are more interesting than you (or Baxter) may have thought. I wanted to figure out why, despite holding Down, the pieces were still moving at a rate of 1 row per 2 frames, yet sometimes, it would move down two frames in a row.
From what I can tell, after 3 frames of holding Down, the game will do a soft drop down one row, and reset the "frames until next drop" back to 2. This means if you hold Down, you may get one soft drop, but after that, no effect from holding Down, until you let go and hold the 3 frames again.
If this soft drop lines up with a gravity drop, it will only drop you one row that frame, so it has to be offset from the gravity drop. This leads to a pattern of 3 on, 2 off being the fastest I could find. Those 2 off frames are a great place to put horizontal movement without losing any time!
This does have the unfortunate result of completely desyncing all of the RNG manip. But I would guess that recreating the current build's piece order, but with optimized soft drops, would still save a LOT of time (relative to the length of the run, at least!).
There was also a 1 frame save I found on the final piece; you were moving the final piece left twice, then pausing to do one last manipulation. I moved the pause to in-between the two Left presses, allowing them to be done on two consecutive unpaused frames (a la SM64 pause BLJing). Saving a frame with a pause like this is probably only relevant for the final piece, since any other time, you're limited by the piece's vertical travel more so than its horizontal.
Anyway, as a proof of concept, I was able to save 24 frames by soft dropping and re-manipulating the final 4 pieces (it uses different post-input-end pieces as well):
http://tasvideos.org/userfiles/info/63491175011214274
Since the run is so short, resyncing with this new tech is definitely worth it. If you'd like to, go for it; if you'd rather not, I'm open to doing it. A collaboration could be helpful as well, if you'd like. The build is more key to the run than movement tech IMO, so I'd append myself onto the end authorship-wise.
I'm unsure if implementing this movement change without altering the pieces used would require a resubmission, or just an updated movie file.
Thank you for accepting it for Moons! It means a whole lot, I love this game!
I honestly don't know where to stand with the palette anymore. I'll show a comparison of the title screen here of the three options (not that it's indicative of the entire game, but it does have good key colors).
Accurate, Vivid, Libretro
I just think Accurate is too dark, and Libretro is too washed out (in particular, now the red is pink; I still think it could use a contrast adjustment).
Vivid honestly just looks RIGHT for this game, but I understand avoiding using Vivid considering what it can do to other game's colors. But, well, I can think of one piece of objective evidence to suggest perhaps the game's colors were designed for the RGB8 colorspace; the game's Pokemon logo yellow closely resembles the official logo's yellow!
In Pokemon Yellow, the 'highlighter yellow' shade that the Pokemon logo gets in Vivid suggests that the color choice was not at all with Vivid in mind. But perhaps TCG was?
I'm legitimately confused why this topic even exists, haven't we already gone over this in this thread?. heck, when I provided screenshots for this thread, I was only focusing on the title screens since they looked better with BizHawk GBA pallets, but I soon realized (and I mentioned this in that thread) that it doesnt look good for actual gameplay, and makes it darker than usual. I dont want that to happen with GBC as well, and I feel like the pallet is fine as it is. It's not as annoying as FCEUX's pallet.
It exists because the default Gambatte palette is provably awful. And despite me proving that 2 years ago, Spikestuff keeps using it. :V
Personally I'd say it should be the movie author's choice for what palette gets used, within reason. Since clearly there's multiple GBC palettes with successful accuracy comparisons, and multiple valid reasonings for using them, I can't see a catch-all policy. I would beg and plead that Gambatte is NOT the default anymore for when an author voices no preference, though.
GBC in GBA doesn't matter either way for 99% of GBC games (I think??), and can help with console verification. And it shouldn't be tied to Vivid, since as you said, if it does shift the palette it was likely with the intention of being for original GBA screen. Being a long-time GBP user, I still quite like the Vivid palette for a lot of games, but definitely can't vouch that its color output was the 'developer intentions' for ANY game after seeing the examples here, regardless of how good it may look game-to-game.
GBC colors in GB can help with visibility in some games (Donkey Kong Land) and just generally add a little visual polish (Pokemon R/B). So I think that should be author preference as well, within reason. But I never owned a GB, only GBC, so I'm biased towards that look. I could understand forcing a grayscale policy (though, console verification is still a reason to use GB in GBA).
Hmm, here's a quandary when it comes to attempting to match the screen's colors. Should a pure white not exist?
One thing that's interesting in TCG is that instead of white, the game uses a tan color in the background.
On a GBC screen, which is basically tan when off, this tan is nearly identical to white, with all current palette options having far too much of a difference between the two colors. It's easiest to see during the intro scene, which is white, then switches to tan for the Base Set pack and for the title screen. It also makes screen transitions less seizurey (not that white->tan->white->tan should trigger epilepsy, but there is a jarring change in color to be sure, that isn't visible on GBC).
One way to have constant transitions between tan and white is just to hold soft reset. I've filmed that here as best I can (there is a very very slight shift in colors, about matching what I see IRL), and this is what emulator palettes output:
https://youtu.be/6WRM-6hRrwYhttps://youtu.be/IR132o4bJQA
So, there's definitely a huge discrepancy between a GBC screen's "white" and emulator's white... But should that mean we display white as tan?
Surely developers intended their whites to be white; and our brain looking at a GBC screen can assume things matching the natural screen color are white, just like on a GB screen you know nothing is meant to be green. So perhaps tan should be changed to be closer to white, rather than the other way around?
But at the same time the reds/blues/yellows in libretro could stand to be slightly darker, so I don't think the RGB conversion formula could handle both...
I think libretro and +15 contrast are way too bright compared to live photos.
From watching Blazephlozard's comparison, I must admit that Gambatte is closer than VBA Accurate. Gambatte's colors are slightly dull, but that's just how actual GBC screen appears in real life.
Well, the objective isn't to match live photos, it's to match live eyesight, right?
Eyesight is subjective, misleading. I myself did mistakenly prefer VBA Accurate over Gambatte because it looked prettier, instead of trying to see which one was closer to reality. Confirmation bias at its finest.
I'm really curious to know how the Gambatte developers did come up with their current palette. I wonder if they did practical tests on real hardware, and how.
You're using your subjective eyesight to compare low-quality pictures of a screen to emulator screenshots... So why not cut out the middleman and just compare the actual screen to emulator?
And if you're really saying Gambatte is more accurate than VBA Accurate now over one shade of yellow being better despite its proven inaccuracies in other areas, THAT'S confirmation bias. Also you haven't mentioned the new shader...
It is definitely subjective, and only accounts for a few possible colors, but for the Pokemon Yellow title screen, libretro shader has clearly more accurate yellows, reds and ESPECIALLY blues than VBAA or Gambatte palette, even comparing to the photos and especially when comparing to the GBC itself.
Like, "Gambatte vs. VBA Accurate" shouldn't even be a topic of discussion, it should be "what adjustments should libretro get"
We need more eyes on this...
I think libretro and +15 contrast are way too bright compared to live photos.
From watching Blazephlozard's comparison, I must admit that Gambatte is closer than VBA Accurate. Gambatte's colors are slightly dull, but that's just how actual GBC screen appears in real life.
Well, the objective isn't to match live photos, it's to match live eyesight, right?
Ah, welcome to the horrible world of taking pictures of GBCs. Puzzle Challenge's intro is a great choice.
Well, I tried to take a few if that helps. I tried having more light and making the shadow balance it out in the second one. (My Chikorita scene ones sucked)
Personally, it still looks like a middle ground between VBA Accurate's dark tones and the current new shader's overly light tones might be just right
Yeah, that's probably a good idea. It is not related to judging.
Well, who else thinks TCG with 5 minutes less tutorial is Moonable? I do think main series Pokemon is fair to compare it to.
The only Pokemon movies in Vault are heavy glitch runs, and Gym Leader Castle. I do agree with Castle's judgement; the lengthy move animations in Stadium bog it down, and the rental system I would say also makes things less impressive compared to having an underleveled starter with bad moves that you have to manipulate around.
So a key similarity that the rest of the glitchless Pokemon TASes have are constant RNG manipulation using as limited of resources as possible, since resources = lost time. This TAS definitely does that, and at a faster pace than any of them thanks to the game's design. Fast is good, right? But is it TOO fast? I can follow it but I can't speak for anyone else...
Yeah actually Vivid is terrible, I change my mind oopsies. Well, I think it looks really nice for Pokemon TCG in general, but, using that game's tans and oranges to compare the palettes was evidently too narrow-minded. The Pokemon Yellow title screen examples have really opened my mind.
Pikachu is definitely not 'supposed' to be highlighter yellow, regardless of what the raw color data says.Vivid palette's RGB for the yellow there is 255/255/0, so it's a good benchmark for "this is the brightest yellow possible". (In addition, his cheeks are 255/8/8, and the Pika! blue is 0/0/140, providing benchmarks for red and dark blue)
But right now I would say none of the GBC palettes available look accurate to the screen then. If my big hub-bub might get a better palette made and accepted, hooray!
And yeah, I broke out the ol' GBC again, I have a better phone camera than I used a few years ago at least. But it is absolute hell to try to take a truly good picture, because your shadow gets in the way. That picture actually turned out pretty well, because it's a gradient from low, to mid, to high light. I would say approaching the high light area of the picture is what it actually looks like playing normally at a good angle. (around 2/3rds of the image from the left)
(click for large)
Right now I would say that yes it is a little too washed out. For example his cheeks are too close to pink instead of red. I applied +15 contrast in Photoshop and compared my screen directly to that result as much as I could, and found the Pika! blue, and red cheeks to be basically spot on; the yellow could maybe stand to be slightly less white (slightly closer to VBA Accurate).
The blue shadow of the Pokemon logo is particularly interesting to look at on Vivid and VBA Accurate, where both have it much more of a purple, but it's not purple whatsoever on a GBC. And overall Accurate is just too dark, in a way that makes it look off to me. I'm excited for this middle ground between highlighter yellow and mac and cheese!
Possible slight confusion in abbreviations, my captures (any with Z Button: Options) are the stock Game Boy Player software, so not "GBI". The GBP software does apply some blur/resizing to it, and possibly a contrast reduction it seems. Game Boy Interface is homebrew that still uses the GBP hardware (which is really just a GBA that plugs into a Gamecube) and provides a more raw output. (The contrast difference could also be just a matter of composite/s-video or my capture setup, compared to tikevin's)
But, it would be fine if there was a palette aiming to match the darker colors of that GBP capture for one key reason: It's only a difference in contrast. The VBA Accurate palette (and even more so of course, the Gambatte palette) changes the game's colors in a way that a contrast adjustment can not fix. That's what makes VBA Accurate look wrong, and makes me hate seeing this game using it.
I think the "GBA SP" approach is better than a "GBP/GBI" approach though, as it removes TVs from the equation. Either way, it is all GBA hardware, so it doesn't help with the "match GBC hardware" argument... If GBC had an official backlit release, would Vivid be the standard already?
Considering TASvideos ends up making RGB888 encodes, I don't see why there'd be an issue with using the game's RGB output as the basis for the colors in the most direct way possible... GBC is RGB555, so 5 bits for each color instead of 8, which should mean there can't be a 'perfect conversion', as some have to be slightly rounded up or down. But it's the closest, most logical approximation.
I'd be very very curious if anyone knows the origins of VBA Accurate's palette, and really all the palettes in general. Because all of them are just taking the color data the ROM code is outputting, and assigning a color to that in a presumably logical way, yes?
I would guess the Vivid palette is basically, "0b11111 = 0b11111111, 0b0 = 0b0, scale the rest the best you can", a typical RGB5->RGB8 conversion. What's done to the GBC's 5-bit color data to output VBA Accurate or Gambatte?
Looking into this more, I'm surprised by how well done this Wikipedia article is done: https://en.wikipedia.org/wiki/List_of_video_game_console_palettes#Game_Boy_Color
Most interestingly, GBA is also 15-bit color, further reducing any reason for GBC and GBA to have different encoding standards of how their color output is treated (since GBA's encodes seem to be accurate to the raw data in the same way GBC Vivid is).
Is GBC really only treated this way because it never got a backlit rerelease, and doesn't have a contrast option? Is there any other system encodes whose color data gets danced around?
I suppose I don't quite understand, because raw data seems to be what gets used for colors in GB and GBA encodes. So there's not much consistency here, even among handhelds.
In GB's case, well, it's really just white, black, and two grays, huh? So not much of a 'palette'. But still, there is no effort at all to emulate how a Game Boy game "looked to a human" on its original device. (Thank god.)
In GBA's case it seems their "Vivid" palette is the default, and I've never had an issue with it. I can try to compare that to console. I'm using Sabre Wulf as an example since I have it readily available and it does have lovely colors.
Game Boy Player output:
Encode:
Overall, I only see a shift in brightness/contrast between these two, with GBP being darker. But I'd say that's mostly a case of my capture setup / GBP compared to GBI being worse. Here's a good example of that, my capture compared to my example from Tikevin's output!
Here's the same comparison, but I applied Contrast +30 (Use Legacy) in Photoshop. Gets it pretty close.
So, I would say that my Sabre Wulf capture would look near identical to the encode, if my capture was at Tikevin's level. Close enough to not have a problem with it and say "this looks ugly", at least.
So, that means the palette used in GBA encodes, makes no effort to emulate the 'get the angle of your light source just right but everything's still dark and washed out' look. We all had to deal with that as a kid, and VBA Accurate (mostly successfully) does try to emulate that look for GBC. But there doesn't seem to be a precedent for handheld encodes to try to emulate that look. And emulating that look causes an arbitrary difference in colors that goes beyond a simple brightness/contrast adjustment.
If the argument is that GBA games are encoded as if they were on the best model of GBA SP, then I'd say there's a strong case that GBC games could also be encoded as if they were on a GBA SP, which I believe would be Vivid. (I don't own one to know for sure but from what I've seen and heard, their output should be the same as pixel-perfect GBI)
And likewise one could say GB encodes are done as if they're on a good GBA SP using the built-in Grayscale palette.
So it would create a coherence to Game Boy family encoding standards, using the greatest, officially made, handheld screen as the standard.
Moderator edit: Resized the images as they were breaking the page layout for some reason. Click on them to see the originals. — moozooh
Its entertainment value has been increased substantially (in my opinion) by using the new Duel Escape Glitch to skip the tutorial duel. It chooses not to use that glitch for any future duels, as a speed/entertainment trade-off.
🤔
That sounds like some abuse of the term glitchless more so than most runs that use the term lol
This submission doesn't need a label, so we can remove it altogether. Also, the major glitch movie has a proper label, so there is no risk for confusion.
Haha yes the category was just for April Fools
What do people think about using Vivid tho 😳
What happens after where the movie ends? Repeat, or permanent congratulations screen or such?
Neither. The game just proceeds to Tekken.
Hmm, if it does unlock a character, perhaps the encode can end on showing the character.
I'm quite interested in this kind of "game inside a game" runs and wonder how acceptable they are.
Well, I'm the one that actually achieved the 30 lines, and found new tech, so it should probably be me...
Hey, there isn't a run at all without a good starting RNG seed, that's waaaaay more important! And I had to place all the final pieces while you were ending your input!
It's off to a bad start right now, I'm matched up because of ending up RNG manipulating the same pieces Baxter did. But once the pieces aren't so close to the top, the soft dropping will save more frames, so I can hopefully use some new options then...
OK, I tried starting the run 1 frame sooner (which shifts ONE garbage block on the top row very slightly, as well as having different starting pieces) and built to the same shape, and am now 3 frames ahead! Hopefully more to come
Someone was talking about TASing NES Tetris yesterday and I was accidentally prophetic...
The Mode B game's goal is to clear 25 lines. So, from a speedrun perspective, the fastest "Mode B" clear would be to just spam Tetrises near the top of the screen, same strategy as the 999999 points TAS. But from a stylistic perspective, clearing the board is obviously far superior, and with the hellish garbage the game gives you, makes it an extremely unique challenge compared to other Tetris TASes. So, for entertainment purposes, clearing the board is an important secondary goal.
An early input end is a fantastic way to save time in Tetris TASes without having to restart the entire thing. I love them because it takes special care to set up the board just right for the pieces to fall into place (literally).
As you said, it's possible that a faster run could be done using a different starting RNG (for a different garbage layout), but it's extremely hard to know for sure, and takes a LOT of effort to test each possibility. There could also be a much different build for this garbage layout, especially since this Tetris allows you to RNG manipulate what the next piece will be by delaying the current one. But considering Baxter's insane playaround TAS, it's safe to say he's quite good at building in Tetris.
One potential way a full rebuild could be faster is if it does more of its 13 non-garbage-clearing lines closer to the top, saving vertical piece travel. Another way is to minimize line clear animations, so less singles/doubles. But, the garbage is not placed in a way that makes either of these timesavers an obvious task, or even possible at all.
However, there seems to be one major timesaver that can apply to the exact same board build... It seems that soft drops are more interesting than you (or Baxter) may have thought. I wanted to figure out why, despite holding Down, the pieces were still moving at a rate of 1 row per 2 frames, yet sometimes, it would move down two frames in a row.
From what I can tell, after 3 frames of holding Down, the game will do a soft drop down one row, and reset the "frames until next drop" back to 2. This means if you hold Down, you may get one soft drop, but after that, no effect from holding Down, until you let go and hold the 3 frames again.
If this soft drop lines up with a gravity drop, it will only drop you one row that frame, so it has to be offset from the gravity drop. This leads to a pattern of 3 on, 2 off being the fastest I could find. Those 2 off frames are a great place to put horizontal movement without losing any time!
This does have the unfortunate result of completely desyncing all of the RNG manip. But I would guess that recreating the current build's piece order, but with optimized soft drops, would still save a LOT of time (relative to the length of the run, at least!).
There was also a 1 frame save I found on the final piece; you were moving the final piece left twice, then pausing to do one last manipulation. I moved the pause to in-between the two Left presses, allowing them to be done on two consecutive unpaused frames (a la SM64 pause BLJing). Saving a frame with a pause like this is probably only relevant for the final piece, since any other time, you're limited by the piece's vertical travel more so than its horizontal.
Anyway, as a proof of concept, I was able to save 24 frames by soft dropping and re-manipulating the final 4 pieces (it uses different post-input-end pieces as well):
http://tasvideos.org/userfiles/info/63491175011214274
Since the run is so short, resyncing with this new tech is definitely worth it. If you'd like to, go for it; if you'd rather not, I'm open to doing it. A collaboration could be helpful as well, if you'd like. The build is more key to the run than movement tech IMO, so I'd append myself onto the end authorship-wise.
I'm unsure if implementing this movement change without altering the pieces used would require a resubmission, or just an updated movie file.
Accurate, Vivid, Libretro
I just think Accurate is too dark, and Libretro is too washed out (in particular, now the red is pink; I still think it could use a contrast adjustment).
Vivid honestly just looks RIGHT for this game, but I understand avoiding using Vivid considering what it can do to other game's colors. But, well, I can think of one piece of objective evidence to suggest perhaps the game's colors were designed for the RGB8 colorspace; the game's Pokemon logo yellow closely resembles the official logo's yellow!
In Pokemon Yellow, the 'highlighter yellow' shade that the Pokemon logo gets in Vivid suggests that the color choice was not at all with Vivid in mind. But perhaps TCG was?
Personally, it still looks like a middle ground between VBA Accurate's dark tones and the current new shader's overly light tones might be just right
(click for large)
Right now I would say that yes it is a little too washed out. For example his cheeks are too close to pink instead of red. I applied +15 contrast in Photoshop and compared my screen directly to that result as much as I could, and found the Pika! blue, and red cheeks to be basically spot on; the yellow could maybe stand to be slightly less white (slightly closer to VBA Accurate).
The blue shadow of the Pokemon logo is particularly interesting to look at on Vivid and VBA Accurate, where both have it much more of a purple, but it's not purple whatsoever on a GBC. And overall Accurate is just too dark, in a way that makes it look off to me. I'm excited for this middle ground between highlighter yellow and mac and cheese!
Encode:
Overall, I only see a shift in brightness/contrast between these two, with GBP being darker. But I'd say that's mostly a case of my capture setup / GBP compared to GBI being worse. Here's a good example of that, my capture compared to my example from Tikevin's output!
Here's the same comparison, but I applied Contrast +30 (Use Legacy) in Photoshop. Gets it pretty close.
So, I would say that my Sabre Wulf capture would look near identical to the encode, if my capture was at Tikevin's level. Close enough to not have a problem with it and say "this looks ugly", at least.
So, that means the palette used in GBA encodes, makes no effort to emulate the 'get the angle of your light source just right but everything's still dark and washed out' look. We all had to deal with that as a kid, and VBA Accurate (mostly successfully) does try to emulate that look for GBC. But there doesn't seem to be a precedent for handheld encodes to try to emulate that look. And emulating that look causes an arbitrary difference in colors that goes beyond a simple brightness/contrast adjustment.
If the argument is that GBA games are encoded as if they were on the best model of GBA SP, then I'd say there's a strong case that GBC games could also be encoded as if they were on a GBA SP, which I believe would be Vivid. (I don't own one to know for sure but from what I've seen and heard, their output should be the same as pixel-perfect GBI)
And likewise one could say GB encodes are done as if they're on a good GBA SP using the built-in Grayscale palette.
So it would create a coherence to Game Boy family encoding standards, using the greatest, officially made, handheld screen as the standard.
Moderator edit: Resized the images as they were breaking the page layout for some reason. Click on them to see the originals. — moozooh
