Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
Nach wrote:
But is it a legitimate demand?
I see the demand mostly coming from people who are probably younger than a DMG, they probably never played these games on a DMG, they don't get how it subtly different.
It's coming from a variety of active contributors, and from having asked other staff members and people in chats, I haven't seen a single opinion against this demand.
To me based on most responses it seems people were largely unaware of the platform differences. Since they're unaware of the differences, I wouldn't expect them to have an opinion against. If you think they're identical, why should you be against it?
feos wrote:
The age of our contributors is completely irrelevant to the discussion.
The only relevance it has is that older contributors are more likely to be aware of the differences.
feos wrote:
The relevant part is that we agree to sacrifice accuracy, for example if it breaks determinism. Emulation is imperfect, so people just deal with subtle differences in some games.
Unlike some other systems though, the Gameboy and most of its successors is self contained, hence the Gameboy is more deterministic versus consoles that can be connected to a wide array of different televisions or get different pulse signals via the electric from your wall. It's in the exact opposite direction from the free-for-all that the PC platform is. Gameboy games are much less likely to see differences in play when using the same kind of model.
feos wrote:
Also, the obvious difference I'm noticing is we don't encode GB in shades of green. That's not authentic. Why is it encoded as shades of grey?
The Gameboy does not output anything in green. Its output is 4 shades of black/grey. The background of the Gameboy's screen is green, instead of white. What we're encoding as white is the transparent (non drawn) sections of the screen, which is on a white background.
And if you want to encode games using a different color for the background and each of the 4 shades, I really don't care, as long as the encode looks good. Encoding colors doesn't affect the game-play at all.
feos wrote:
Nach wrote:
Yet I don't see how that's a reasonable reason to use a platform the game was not originally designed for in our TASs.
I explicitly said it's not the reason to avoid GB TASing, and you keep treating it like it's a reason I mentioned. It was an explanation why it's widespread in RTA.
I'm sorry for misunderstanding your point.
feos wrote:
Nach wrote:
Unlike elsewhere, we place high stock on original legitimacy, at least we did till now. We know things aren't perfect, but haven't we always preferred playing things in the most accurate and legitimate fashion?
Sure. Also, at the top of Judge Guidelines we say:
Satisfy the audience's expectations.
Which means we should be hearing people out, checking if they have a point, and whether it's possible to update our approach without causing any harm. It's the kind of balance we should be aiming for.
It would be nice, but all I'm seeing in this thread is ridiculous attacks, and people who didn't even want to review information I provided, or finding every excuse under the sun to not believe that differences exist between platforms. If people cannot have a discussion in good faith, I don't even know what to make of anyone's expectations. How are we supposed to discuss to what extent we care about these kinds of differences, when most people here deny their existence?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
For reference, this started with this submission, from March of 2018. I was the one that accepted it (I was still senior judge at the time). And I remember discussion with various staff members about the movie (and its settings, particularly GBC-in-GBA, and how they interact with the rules) at the time, although I can't say precisely who were and who weren't involved at the time.
I was aware of the rules as written for Game Boy modes - in fact, I had written them just a few months before. And in fact, just days before, the rules were in fact updated to allow GBC-in-GBA without the need for special GBA enhancements - this was clearly updated with this method of console verification in mind. The one thing that was overlooked is that Pokémon Blue is a GB game and not a GBC game (unlike Pokémon Yellow), and so the part about enabling GB-in-GBC was (incorrectly) not codified in the rules.
It's not like Pokémon games were all that consistent with Game Boy versions, anyway - Pokémon TASes were divided all over the place with GB movies made with the Gambatte core, "SGB" movies made in VBA, and GBC movies for Yellow which were freely cross-obsoleted by Red/Blue on the other systems.
At the time, this didn't even look like it would be a controversial change. Console verification is a key aspect of TASVideos, and has been for many years. It is one of the targeted end-results for emulation accuracy, and that is something that has been highly prioritized across TASVideos and its rules for many years.
Quite simply, there was (and, in my opinion, is) zero reason to get in the way of console-verified publications for games such as Pokémon, just to stick to the version rules as they were originally written. To me, it was clear that running a Pokémon game in GBC was the optimal platform for it, as it had absolutely negligible downsides from a viewing perspective (no hardware revision-based issues to speak of, just a change in RNG which is invisible to the viewer), it had colorized palettes which provides a better viewing experience overall (and puts it more in line with the older VBA-"SGB" publications, and GBC Pokémon Yellow publications).
Now, regarding what should happen today, I reiterate the following points:
• GB-in-GBC should be an acceptable choice for Game Boy movies, owing to advantages such as console verification (which is important to us), and general lack of downsides. There's a lot of talk about imperfections across hardware, but in my mind, unless there is demonstrable evidence for a submitted GB game that it has issues in GBC mode (such as what's shown in Alyosha's post, for another game), this should not be grounds for rejecting a movie. And the rules should be updated as such, as they should have been back when the rules were updated in March of 2018, and how they have been de-facto enforced since.
• GB games that are run in GBC mode (such as this publication) should be labeled as GB rather than GBC. This is exactly to prevent the issue that brought Nach to this thread to begin with, the fact that it's labeled with a platform that makes it non-intuitive to find.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
I watched Donkey Kong earlier, and I saw some jumps which I've tried dozens of times and could never make them nearly as far, and suddenly it's looking like Mario is able to jump farther. Maybe those moves are possible under certain circumstances and I didn't try hard enough, but my first thought was it's a system difference. I don't know if we want to put out movies where you have to start questioning its legitimacy because of the console used.
Thank you to DrD2k9 for resyncing DK94 upon my request up to 5-4 where rng causes a desync:
Link to video
Those jumps are absolutely possible on DMG and the fact that it's a TAS means you might have trouble doing them real time.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Memory wrote:
Those jumps are absolutely possible on DMG and the fact that it's a TAS means you might have trouble doing them real time.
The jumps that were bothering me took place in 6-6.
I see DrD2k9 taking the most direct and obvious route possible, which I tried many times and could never accomplish. I had to come up with a different and less obvious solution. It's possible it requires frame precision to get the jump just right. But it seems impossible to me that the spikes can just be jumped with the key. I don't know that they're possible on a DMG, but I'd be happy if I was proven to be wrong about that.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
It's possible it requires frame precision to get the jump just right. But it seems impossible to me that the spikes can just be jumped with the key. I don't know that they're possible on a DMG.
Are you claiming this is an emulation inaccuracy?
[14:15] <feos> WinDOES what DOSn't
12:33:44 PM <Mothrayas> "I got an oof with my game!"
Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet
MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish
[Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person
MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol
Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
EZGames69 wrote:
Are you claiming this is an emulation inaccuracy?
I don't trust the run because it's running in CGB mode. I'm not claiming anything about it, all I know is that DMG games on CGB is inherently unreliable unless proven otherwise.
If I saw this same feat on DMG mode I'd assume it was due to DrD2k9's awesomeness.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Those jumps are absolutely possible on DMG and the fact that it's a TAS means you might have trouble doing them real time.
The jumps that were bothering me took place in 6-6.
I see DrD2k9 taking the most direct and obvious route possible, which I tried many times and could never accomplish. I had to come up with a different and less obvious solution. It's possible it requires frame precision to get the jump just right. But it seems impossible to me that the spikes can just be jumped with the key. I don't know that they're possible on a DMG, but I'd be happy if I was proven to be wrong about that.
It's actually possible to clear the spikes in 6-6 either direction both against and with the wind without using the wire.
When going left against the wind, it requires handspring jumps. Going right with the wind actually has a relative large window in which a standard jump will cross the spikes (9 frame window for both sets of spikes).
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
DrD2k9 wrote:
Going right with the wind actually has a relative large window in which a standard jump will cross the spikes (9 frame window for both sets of spikes).
I find there being a large window for the jumps here shocking. I've tried it many times, I could not do it. I had a friend call me up asking how to beat this level, how does he make the jump with the key? He couldn't make the jump either despite a lot of effort.
But if you're sure it's just a matter of precision, and it's fully legitimate, then fine, I accept.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Nice, thank you.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
I have a different question. For GB games that are supposedly not supported explicitly by GBC, it still somehow assigns colors in a meaningful way, it's not an utterly random mess. How is this determined on the hardware level? It's not full-color like actual GBC games are, but still looks sensible. Are there also GB games that have completely wrong colors assigned in the GBC mode?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I have a different question. For GB games that are supposedly not supported explicitly by GBC, it still somehow assigns colors in a meaningful way, it's not an utterly random mess. How is this determined on the hardware level? It's not full-color like actual GBC games are, but still looks sensible. Are there also GB games that have completely wrong colors assigned in the GBC mode?
It's software and hardware.
For the hardware side, you somewhat need to understand how colors work on the DMG and CGB. For the DMG, the background map, sprite palette 0, and sprite palette 1 are all assigned 4 colors... with those four colors being black, white, and 2 shades of gray. These are all technically separated, and colors can be swapped around (albeit it's limited because you're only really swapping around the 2 shades of gray).
However, for CGB enhanced games, this isn't used at all. For those games, the CGB allows full on colors with the background map and sprite palettes 0 to 7, and uses different registers for this.
But as I've said, this is for CGB enhanced games. Whether a game is CGB enhanced depends on what its header reports. If the header reports CGB enhancement, then the bootrom will boot the GBC normally and will use its standard coloring system.
But if the header reports the opposite, the bootrom instead boots the GBC into DMG compatibity mode, which along with locking out GBC only features (like double speed mode), it will also revert its coloring system to essentially the monochrome system the DMG has.
The bootrom will however actually assign actual colors to what would be shades of gray. And as I've said, the background map and sprite palette data 0 and 1 are all separated, so the bootrom is happily able to assign the grays for each of these with different colors (which is where some graphical issues might come from, since games might swap around the background and sprites around, which doesn't go that well).
For how the bootrom assigns colors, it's either with user input or the header. If the user doesn't do any input to change palettes on the bootrom, then it's determined by the header. (edit: I have no idea how it determines it via the header lol)
For user input, you can use a directional (or a directional + A or B) to choose palettes, resulting in 12 different combinations that can be choosen. This user input also happens to be a nice fix for any game that might have some weird palette on it, as the user can easily override whatever the bootrom is choosing from the header. There are also some palettes (like grayscale) that color the background map and sprites the exact same, which can also be chosen to avoid graphical issues.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
I have a different question. For GB games that are supposedly not supported explicitly by GBC, it still somehow assigns colors in a meaningful way, it's not an utterly random mess. How is this determined on the hardware level? It's not full-color like actual GBC games are, but still looks sensible. Are there also GB games that have completely wrong colors assigned in the GBC mode?
The CGB firmware includes a list of somewhat popular DMG games to auto set their palette. Aside from this, on boot, you can hold down a key combination to select a palette. One key combination is just black+white which should look fine anywhere, and you can play with the others to see if they look okay.
In some games though, if you don't manually select anything, it will indeed not look sensible. And as I said before, since it auto colors sprites different from background, in games where it was intended to blend together, that blend is now broken.
Edit: See this: https://tcrf.net/Notes:Game_Boy_Color_Bootstrap_ROM
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Pardon me if I'm attempting to give a different answer after that two other people already did it (very informative posts btw), but I feel that feos' question was trying to figure out a slightly different issue.
feos wrote:
I have a different question. For GB games that are supposedly not supported explicitly by GBC, it still somehow assigns colors in a meaningful way, it's not an utterly random mess. How is this determined on the hardware level? It's not full-color like actual GBC games are, but still looks sensible. Are there also GB games that have completely wrong colors assigned in the GBC mode?
The different coloration is assigned on the basis of which is the VRAM region that holds that graphic, and the GB's Object Palette setting (more info below). All GB and GBC graphics consist of three graphical layers, from bottom to top:
1. The normal background (also known as Background)
2. The window background (also known as Window)
3. The sprites (also known as Object Attribute Memory or OAM)
Now, the GBC assigns three different palettes to a GB game, depending of the following:
1. The first palette is assigned to both Background and Window
2. The second palette is assigned to sprites that are set to use the Object Palette #0 (OBP0)
2. The third palette is assigned to sprites that are set to use the Object Palette #1 (OBP1)
I know it may look weird, but even if the original GB doesn't have colors at all, it still allows two diferent grayshade palettes for the sprites. Since all sprites always have one transparent color out of the four grayshades available, it effectively limits the graphical possibilities. In order to circumvent this limitation, the GB gives to the programmers the ability to freely decide which color use for transparency, and have two different sprite palettes available for simultaneous use.
So in the end, yeah, I agre the colors picked by the GBC are "not an utterly random mess", but are still technically random, unless the game used falls into the list linked by Nach above.
Anyway, in a worst case scenario, the user is still able to manually pick the desired palette combo during the GBC BIOS sequence, for the better or the worse results. However, it doesn't help for cases of games that use the sprites as graphics to blend with the background layers, since it sometimes makes them stand out in an inappropriate way, hence the scanarios you posted previously:
It also doesn't help for cases where the sprites were originally supposed to be kept hidden among the background layer, as explained by Nach here:
Nach wrote:
There's another element also that in a way seems like cheating. The DMG only had 4 colors or so to choose from. Some games would hide enemies or breakable areas in the background/wall/floor, and you wouldn't notice it unless they attacked you, or you attacked it, as they blended together. When a CGB plays a DMG game, it automatically uses more than 4 colors, and purposely uses different colors for what is truly background and what is a sprite. Suddenly all those enemies or breakable areas (sprites) that were hiding suddenly stand out (from the background), and what it supposed to be a surprise is readily obvious. You can see enemies in advance that are supposed to ambush, you can know where to strike without any guess work. It dumbs down various games in certain areas.
For these reasons, I'd like to pick this chance to reiterate my proposal: since the GBinGBC mode may make some games potentially uglier to look than GB, I think it should be allowed only for Moons & Stars.
Joined: 11/13/2006
Posts: 2794
Location: Northern California
ThunderAxe31 wrote:
For these reasons, I'd like to pick this chance to reiterate my proposal: since the GBinGBC mode may make some games potentially uglier to look than GB, I think it should be allowed only for Moons & Stars.
That's even more arbitrary than banning GB-in-GBC outright. It sets a really weird precedent where you're essentially telling people that the deck is stacked against them. "These runs could be ugly and bad to look at, so they'll be less entertaining to watch. Anyway, you have to make it to Moons, the tier where runs are required to meet a minimum level of entertainment. Good luck!"
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
The CGB firmware includes a list of somewhat popular DMG games to auto set their palette.
It's Nintendo who's made that boot ROM, right? Sounds like they officially support those games in the "simple color mode", even if it's not 100% bugless.
Nach wrote:
In some games though, if you don't manually select anything, it will indeed not look sensible. And as I said before, since it auto colors sprites different from background, in games where it was intended to blend together, that blend is now broken.
Does this happen with explicitly supported GB games too?
ThunderAxe31 wrote:
For these reasons, I'd like to pick this chance to reiterate my proposal: since the GBinGBC mode may make some games potentially uglier to look than GB, I think it should be allowed only for Moons & Stars.
I just think it doesn't make anything simpler or better.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
Nach wrote:
The CGB firmware includes a list of somewhat popular DMG games to auto set their palette.
It's Nintendo who's made that boot ROM, right? Sounds like they officially support those games in the "simple color mode", even if it's not 100% bugless.
Nintendo made it yes, and they support them to an extent. All the Donkey Kong Land games have various bugs, yet they also have some coloring in that boot ROM. I also mentioned previously that I strongly suspect that the various black cartridge rereleases were made to fix some bugs on CGB, and still some of those games have their original release also appear in the boot ROM. The boot ROM itself also has its oddities, like it includes a palette for the E versions of Mega Man I, II, and III, but not the other regions which are nearly identical games. A lot of Nintendo's decisions here are just weird.
feos wrote:
Nach wrote:
In some games though, if you don't manually select anything, it will indeed not look sensible. And as I said before, since it auto colors sprites different from background, in games where it was intended to blend together, that blend is now broken.
Does this happen with explicitly supported GB games too?
Yes. Zelda which was mentioned previously has a maze with enemies masquerading among statues, which blends perfectly on DMG, but not CGB, and also appears in the boot ROM, and also got a black cartridge rerelease.
Personally, I just don't find the CGB to be accurate enough for games designed for the DMG/SGB. It might look nice, but it's often not the way the original game was intended. As I said previously, I don't mind if we put coloring in our encodes as long as it's sensible, but I don't think it's the mode the games should be played in.
If one wants to verify runs, you just need to mod the input to accept it from elsewhere. If you look on eBay, there's tons of Gameboy modding hardware that's being sold. You can find videos on YT of people showing off the various mods.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
That sounds a bit like VC releases of old consoles being TASed in Dolphin. Nintendo shipped an emulator inside the VC game bundle, and we're free to abuse bugs in that emulator, as it's part of the game now. And if we extract that game and run it on the original console emulator, it's fine too (unless it's the same as the original, non-extracted game).
Also now I have to ask if SGB also has any oddities in how it interprets things and assigns colors.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
That sounds a bit like VC releases of old consoles being TASed in Dolphin. Nintendo shipped an emulator inside the VC game bundle, and we're free to abuse bugs in that emulator, as it's part of the game now.
I find this to actually be the preferable way to play it, assuming it wasn't designed specifically for the quirks of Nintendo's emulator.
feos wrote:
Also now I have to ask if SGB also has any oddities in how it interprets things and assigns colors.
It includes similar logic to what the CGB includes to auto color games, but it also has extensive controls to edit the palette while the game is running. SGB even allows you to draw on the screen, like your own map, or hide the boss you're fighting, or other stuff.
If the game itself was designed for SGB it usually looks good. Although we had a discussion several years back where we noticed some SGB games were designed for the television aspect ratio, and other SGB games were designed for the DMG aspect ratio. It seems some companies/studios/teams preferred things one way, and others another. So playing it on the correct system you'd get perfect squares and circles and the other would give you rectangles and ovals.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
We're not banning VC relases, and I'm pretty sure we shouldn't. So the logical result is Post #472277Nach wrote:
It includes similar logic to what the CGB includes to auto color games, but it also has extensive controls to edit the palette while the game is running. SGB even allows you to draw on the screen, like your own map, or hide the boss you're fighting, or other stuff.
Have any SGB TASes on the site made use of this SGB-only functionality, current or obsoleted? I mean manually editing colors or drawing on the screen.
Nach wrote:
If the game itself was designed for SGB it usually looks good. Although we had a discussion several years back where we noticed some SGB games were designed for the television aspect ratio, and other SGB games were designed for the DMG aspect ratio. It seems some companies/studios/teams preferred things one way, and others another. So playing it on the correct system you'd get perfect squares and circles and the other would give you rectangles and ovals.
This isn't addresses in the rules, and it feels uneasy to try to guess developer's intent.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
Nach wrote:
We're doing that now?
We're not banning VC relases, and I'm pretty sure we shouldn't. So the logical result is Post #472277
That seems awful to me. We're going to obsolete original games on their original platform because there's a poor emulator that makes it run faster?
feos wrote:
Have any SGB TASes on the site made use of this SGB-only functionality, current or obsoleted? I mean manually editing colors or drawing on the screen.
Those features, not that I know of. But SGB games have other improvements like better sound via the SNES. I think we may have had a run or two which did that, but I could be mistaken. Donkey Kong on an SGB has the game adjusting the color throughout, and AFAIK, does this better than a CGB, and has better sound, it baffles me the game was submitted using CGB.
feos wrote:
Nach wrote:
If the game itself was designed for SGB it usually looks good. Although we had a discussion several years back where we noticed some SGB games were designed for the television aspect ratio, and other SGB games were designed for the DMG aspect ratio. It seems some companies/studios/teams preferred things one way, and others another. So playing it on the correct system you'd get perfect squares and circles and the other would give you rectangles and ovals.
This isn't addresses in the rules, and it feels uneasy to try to guess developer's intent.
If there's some original version of the game that exists on the original platform, then we know the developer originally designed it for the original platform. The later VC release may modify some menus to refer to the console it's now playing on, or it's in a language previously unreleased, maybe it includes additional levels cut from the original due to ROM cost constraints, and so on, but unless they put in other patches specific for the emulator it's running on, it clearly was designed for the original platform.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
That seems awful to me. We're going to obsolete original games on their original platform because there's a poor emulator that makes it run faster?
No one is saying that they compete for the same platform. VC is Wii, and if TASed in Dolphin it's published as a Wii movie, with whatever is special about that new bundle. An extracted game though, if TASed on its original platform emulator (the rules use N64 as an example), is published as an N64 movie.
Nach wrote:
Those features, not that I know of. But SGB games have other improvements like better sound via the SNES. I think we may have had a run or two which did that, but I could be mistaken. Donkey Kong on an SGB has the game adjusting the color throughout, and AFAIK, does this better than a CGB, and has better sound, it baffles me the game was submitted using CGB.
So if the hardware and software background behind default SGB colors is essentially the same as CGB, are there SGB specific problems comparable to CGB with the same (or different) games?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Those features, not that I know of. But SGB games have other improvements like better sound via the SNES. I think we may have had a run or two which did that, but I could be mistaken. Donkey Kong on an SGB has the game adjusting the color throughout, and AFAIK, does this better than a CGB, and has better sound, it baffles me the game was submitted using CGB.
Are we talking publications or submissions? Publications this can't apply considering every SGB TAS published used VBA's SGB mode (and on that note the last SGB publication was 7 years ago lol).
Also, even then you then have to realize the current SGB emulation available to TASes is really... outdated. Sameboy/BSNES on Bizhawk? Outdated as fuck, hasn't been updated to upstream in a long time. lsnes has better SGB emulation, and even then it's still fairly outdated and misses out on a ton of emulation updates from upstream. And even then I have no idea if the SNES sound emulation thing is even emulated for lsnes, or if it is on Sameboy/BSNES for that matter.
Also, the rules at its current moment are kinda guaranteeing DMG will obsolete SGB, as SGB enhancements add a ton of lag to a game and easily allows DMG to beat SGB in framecount. This lag is also why SGB is generally not ever used in RTA, except for games that don't even have SGB enhancements (where this added lag doesn't apply).
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
No one is saying that they compete for the same platform. VC is Wii, and if TASed in Dolphin it's published as a Wii movie, with whatever is special about that new bundle. An extracted game though, if TASed on its original platform emulator (the rules use N64 as an example), is published as an N64 movie.
So we plan for many games to just duplicate publish the exact same thing because we can relabel it Wii? Unless there's some significant in-game distinction, I don't see the point in us allowing this.
feos wrote:
So if the hardware and software background behind default SGB colors is essentially the same as CGB, are there SGB specific problems comparable to CGB with the same (or different) games?
CGB has more issues not just because of the color thing, but because of other changes.
The SGB is essentially a DMG on an SNES game cart, with the I/O fed into the game cart, and its own extra software for controlling that and added features.
The CGB uses different hardware for some of its components which will lead to all kinds of in-game differences. As I said previously, for most games, the differences won't really be noticeable, but there are differences.
For games where the differences really jump out at you, such as garbled graphics and sound, I think we pretty much all agree to play the game in DMG mode. But that's not my concern, my concern is the legitimacy where it's subtle. I personally won't trust a CGB run of a DMG game which does something which seems odd, unless proven otherwise.
CasualPokePlayer wrote:
Are we talking publications or submissions?
I was thinking of runs made with lsnes, perhaps they were never published, or were just userfiles.
CasualPokePlayer wrote:
lsnes has better SGB emulation, and even then it's still fairly outdated and misses out on a ton of emulation updates from upstream.
Back when I was assisting Ilari and some others with some of this on lsnes, we had some basic runs verified on a real SNES+SGB. Not saying it's perfect, but it seemed to handle some games just fine.
CasualPokePlayer wrote:
Also, the rules at its current moment are kinda guaranteeing DMG will obsolete SGB, as SGB enhancements add a ton of lag to a game and easily allows DMG to beat SGB in framecount.
The rules as they always have been focuses on game play. If we can attribute certain specific things to the platform itself, it can be ignored for the comparison. But in any case, that's missing the point, my point as it's been from the beginning is that running games on a platform it's not designed for has differences, and these differences should not necessarily be considered legitimate.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
So we plan for many games to just duplicate publish the exact same thing because we can relabel it Wii? Unless there's some significant in-game distinction, I don't see the point in us allowing this.
It's explained in the rule I linked.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
It also doesn't help for cases where the sprites were originally supposed to be kept hidden among the background layer, as explained by Nach here:
