File: Pokemon Mystery Dungeon - Blue Rescue Team (USA).nds
CRC-32: b6c4143e
MD5: 61373235da72064e8c058fae3c646916
SHA-1: 503edef4fe6088bca00616efcac3b13da90cd105
SHA-256: 4bdf72ce0dd7a19c66f49e840f046124994d719678e88a0814d0148f705d3e8b
Around frame 640, you will see a Pokémon walking up. The issue is that each time you play back the movie, a different Pokémon will appear! This obviously shouldn't happen in a deterministic environment. Note that DeSmuME doesn't have this issue, as it always spawns the same Pokémon (Eevee) when it starts from clean SRAM.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Ok, this post is only about the Sync Settings.
The window for the sync settings is entitled "NDS Settings", just like the non-sync settings window. It should be renamed to "NDS Sync Settings" for clarity.
The default user name is "MelonDS", but I highly suggest to change it to "TAS". Some games use this setting for displaying the player name in-game, and since there is a tradition of typing "TAS" as player name in a TAS, it would be a nice touch.
The default birthday values are 0 and 0. These are invalid values and may break some games. Let's have 1 and 1 instead.
When clicking on "Default" button, the default settings are right away saved and the window is closed, but wouldn't be better to just change the settings in the window and then letting the user deciding if saving or not? Just like the non-sync settings window.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
adelikat wrote:
Not the site's fault.
The .bk2 spec says there should be a isCGBMode flag in the header to indicate that it is GBC.
Including the latest release, 2.4, GBHawk movies do not write this flag.
It has since been corrected and the next release of bizhawk will properly write this flag.
I replaced the submission file for including the IsCGBMode 1 flag, but it's not helping. Why?
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
I'm afraid you're forgetting a crucial fact about GBI: its supposed output interface is a home television, not an RGB signal capture device.
There are endless different television models, each with their own standards and quirks, which means we can't really have any consistent reference. In fact, these discrepancies between different TV models were taken in account for the making of some games, for example Crash Bandicoot, for which the main character was decided to be colored as orange and blue in order to be more likely to appear more vibrant on most TV models used at the time.
We could argue that OLED and AMOLED monitors could be used for having arguably more accurate, repeatable results, except that these were invented about 1 year after that Game Cube was released. Oops.
And even if we decided that using an external capture device is a valid way of defining a standard, how would we decide which capture devices or settings are more accurate? Look at the two GBI screens you provided in the last post. How can you be so sure that the latter GBI screenshot is more accurate? Couldn't be that the former one is actually closer to what the original game developers intended? For example, the "Z Button : Options", in the upper right, looks way too much bright to me, after applying the Photoshop filter you used.
Blazephlozard wrote:
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.)
I agree that it may apparently seem inconsistent to use a grayscale palette for GB encodes, but guess what? GB is just like a TV, it doesn't give consistent results, so it's fine to enforce our own standard for it. Guess why? Well, take a look at this:
Since the user is able to regulate the contrast level at any time during play, it effectively means that it's impossible to define an objective standard palette.
Blazephlozard wrote:
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)
Again, just like GBI, the fact that GBA features retrocompatibility for GBC games doesn't mean that GBC games were developed for GBA. They were still developed for GBC, and the GBA retrocompatibility was just a little extra for making the game generation jump slower. It's true that some later GBC games occasionally featured GBA-only contents, but these were just basic routines checking if the console model is a GBA, and thus awarding the player with game contents that could still have been accessed via the GBC hardware just fine (in fact, you can still access them on GBC by using Game Shark codes).
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
I'm aware that the publication policy is to use the romanized title when the game was never released in the USA, but could we make an exception for bootlegged games? Pretty please!
If you think about it, since the game is unlicensed, there is no official romanization to begin with, so why enforcing it? That would effectively make the game less recognizable for both Chinese and non-Chinese people, so that's why I'm suggesting to use a translated title version.
Also (correct me if I'm wrong), there are different schools of thought about how romanization should be applied, so deciding how to romanize it independently would inevitably rely on arbitrary decisions.
As far as I can see, there are five possibilities:
口袋怪兽-白玉版
(the original Chinese title)
Kou Dai Guai Shou - Bai Yu Ban
(romanised version by Bootleg Games wiki, literally the only romanization found on the Internet)
Kǒudài guàishòu-báiyù bǎn
(romanised version by Google Translate)
Pokémon White Jade
(the name commonly used for referring to this game on the Internet)
Pokémon: White Jade Version
(the accurate translation of the original Chinese title)
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Yes, it makes sense. In a worst case scenario, we could make some live tests for improving the Gambatte or VBA Accurate palette, and I could contribute to that myself, since I own a functioning Game Boy Color.
Blazephlozard, in the post in which you compared the various palettes to a live photo, you said that "Under ideal lighting conditions, I do think a GBC screen's color shades look closest to Vivid's", but that's not what it looks to me from watching your comparison image, sorry. Also, I doubt that putting your Game Boy closely under a lamp could be considered as an ideal lighting condition, as that would be too blindly for being able to play comfortably.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
feos wrote:
What we can do tho is determining which palette corresponds to what device
Define "corresponds".
Out of the two options I analyzed, the first subjectively corresponds to what appears to be displayed outside of the device screen, while the second objectively corresponds to the internal raw graphic data. Which one does "correspond to the device"?
Since you mentioned that NTSC means Never The Same Color and that the system had variations, I think you're saying to ignore the image physically observed on the device screen, and instead base the palette on the raw graphic data alone. But that's the opposite of what you decided to do last time, since you choose VBA Accurate.
To me it looks like an acceptable strategy, for our Movie Rules. Lemme quote:
Movie Rules wrote:
Full completion criteria must be reached through in-game actions only.
Arbitrary code execution (ACE) is not allowed for any full-completion category for the Vault. Arbitrary code execution of ROM data, and memory corruption tricks to write to arbitrary memory are also not allowed.
If a game has a progress counter, it must be filled by actions that increment the counter in game-play. Modifying the progress counter through ACE or memory corruption is not allowed.
If full completion is counted by obtaining a set of items, these items must be collected through in-game methods. Using memory corruption to place items into an inventory is not counted towards full completion.
If full completion is counted by fulfilling a set of flags, these flags must be set through in-game mechanisms. Using memory corruption to set completion state flags is not allowed.
If a progress counter is filled by collecting a set of items or fulfilling a set of flags, all individual components of this set must be collected or fulfilled. Collecting or fulfilling the same component multiple times to inflate the progress counter is not counted towards full completion.
There are different ways in Pokémon Gen 1 games to obtain a Pokémon through in-game mechanics. Right off the bat, these come to my mind: wild encounter capturing, gift (eg: Eevee, Lapras, etc.), and casino coins exchange.
Since the speedrun you linked seems to be triggering an existing function from the ROM (the third I mentioned) then it would be using an already present in-game mechanic for obtaining such Pokémon. The fact that it's being triggered from an unintended situation doesn't matter much, as long as the Pokémon species are registered as captured via the execution of this function from the ROM, and not by modifying the Pokédex data via direct memory corruption or ACE.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Blazephlozard wrote:
What do people think about using Vivid tho 😳
VBA Accurate is still my favourite, just because it's the one that resembles more to an actual GBC. And it was you who convinced me of that: Post #455976
However, I can't ignore this argument in favor of Vivid:
Blazephlozard wrote:
if you hooked up a capture device to a Game Boy Color, it would output the same colors.
This basically means that all other palettes are just an hacked version of Vivid. And hacky solutions are bad.
Still, the Encoder Guidelines say that encodes should "appear, as closely as possible, as though the run was played on the original hardware", and the originally supposed hardware in this case was GBC. GBI is actually a later console that featured retrocompatibility for GBC games.
I also agree that we shouldn't crank down the brightness for GBA games, but that's because Nintendo specifically made an improved console, GBA SP, for fixing the brightness issue.
Reassuming:
VBA Accurate is a reasonably successful hacky attempt to visually imitate GBC colours.
Vivid is a faithful representation of the raw graphic data produced by the GBC internal video hardware, which also happens to match the visual output of a later retrocompatible official console, GBI.
Both options have their pros and cons, and I'm personally not sure which would be a better choice. Not that it matters much, as the final word on this matter it's not up to me.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
jlun2 wrote:
glitch less
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.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
There is something personal I feel like sharing, right now.
The thing is, when I stop and look at some people that constitute this community, I feel like an impostor. I do really like to TAS, but beside that, there is nothing else. Here I write scripts, yet I'm no programmer. Here I work with logic, but I even dislike math. I'm no nerd, even. I read some manga online, but I'm not really into the otaku life. Even when it comes to internet knowledge in general, I'm not nearly as much experienced as the average user on this site. But most importantly, I'm not even a real gamer. It's been about 6 years since last time I've really played a game. Now I can't really find any enjoyment into playing games casually anymore. And before that, there were few games that I really was into (Pokémon games Gen I,II,III, then Call of Duty 4 and Monster Hunter Tri). So sometimes I wonder if I really deserve to be considered as part of this community.
But despite all that, I'm still staying here, as long as I share even a part of the interests of this site. Because there are things here that I won't find anywhere else. First of all there is the TASing activity itself, and the fact that it's niche means that I can perform it extensively only within here. And beside that, here there are some of the most smart, open-minded, and kindest people I've ever met, so I really feel that the ambiance here is so much friendly that I can keep frequenting this place even if I have only one interest in common.
By the way, even though TASing is the main activity related to this site, I really think that other people beside me can be part of this site even if they don't like to TAS themselves. As long as there is anything in common, it doesn't matter what, I really think that it will be enough to justify the desire of being part of it, without any shame.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
It would be also nice to mention that Undertale 1.08 for Linux can be downloaded from a Windows OS by inputting this command in the Steam console: download_depot 391540 391544 5730345506996883260
Note that it's still necessary to have already bought the game on Steam, with the account used to log in, otherwise the download command won't work.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
EZGames69 wrote:
To change it, load up the DS menu (if you cant get into it, take out a game cartrige if one is inserted), go to options, and start-up. that should give you two settings for how to start up your DS. the first video I posted is Manual Mode, the 2nd video is Auto Mode.
Then it should really be implemented a movie command for unplugging the cartridge, so that the DS menu can be accessed even if the sync setting is set to make it skipped at the beginning of the movie.
ViGadeomes wrote:
Then the second option has to be the default setting. Also, whe it comes to RNG or date based events: you can change the date of the emulator within the movie which is better for playing back a movie.
Are you sure? From what I grasped in jlun2's post, the request is to be able to modify the date setting during the movie.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
EZGames69 wrote:
One thing that I am really curious about is how BIOS will work for movies. As in what starts of movies are going to look like.
Will they be something like this: https://youtu.be/mWnIkIYGWjA
Or something like this: https://youtu.be/yRTtXG4jsI8
I'd really prefer to have the second one as default setting. I hope it could be included as a sync setting, so that the behavior would be present in movies that start from clean SRAM.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
There is something that has been bugging me for a while, until I decided to actually look into it. I created a simple hello world ROM that is internally flagged to be a GBC game, but it doesn't set any palette color during execution. Yet, when I open it in most emulators, a bunch of seemingly random colors are initialized for the sprite palettes. However, they are initialized as all black when opening this ROM in GBHawk. I'm not sure which one is the more correct behaviour. Quoting from Gameboy Development Wiki:
Note: All sprite colors are left uninitialized by the boot ROM, and are somewhat random.
Are the sprite palettes really initialized randomly by the original hardware? If yes, then I agree to inizialize them as 0xFF bytes.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
TASVideoAgent wrote:
The console capture quality update noted in the previous TAS is now possible simply by using up to date GCVideo firmware and requires no filtering in OBS.
Does this mean that we can finally all agree on a more accurate palette for dumping GBC TASes? Because I'm watching side-by-side your published movie and this submission, and I'm noticing that the published movie appears slightly greenish compared to your GBI capture.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
There you go. The first one is the result of using i * 2, and the second one is the result of using i + 1. Data comes from MediaInfo Lite. The results are pretty much what I expected: a filesize directly relative with the change in video resolution.
Edit: ok, I think there is something wrong. I have no idea why, but it seems the results are the other way around.
Edit 2: and this is why I'm not an encoder. Someone please grue this.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Pokota wrote:
Have you done a size comparison on encodes using i*2 vs i+1?
I did. Read the bottom of my post.
Edit: well, I guess you were referring to file size. In that case, it's proportional to the height difference, which depends on platform original resolution. A GB encode gets about 60% smaller, but for GBA there is no difference, as both script versions give a height of 960 for GBA (240 * 4).
Edit: I didn't do a test yet, though. I'll give you actual data later.
Experienced Forum User, Judge, Published Author, Skilled player
(1278)
Joined: 9/12/2016
Posts: 1645
Location: Italy
creaothceann wrote:
"last" isn't strictly needed... Here's some code that automatically calculates the necessary zoom level:
Language: Avisynth
file_name = "video clip.avi"
AVISource(file_name)
i = Get_ZoomLevel(Height, 1)
PointResize(Width * i, Height * i)
function Get_ZoomLevel(int h, int i) {
# 720 lines enables Youtube's HD mode
(h * i >= 720) ? i : Get_ZoomLevel(h, i * 2)
}
That script gives a 8x upscale to Game Boy encodes, which is way excessive for getting the YouTube 720p Edit: nevermind, it's actually optimal as it is.
Since the user is able to regulate the contrast level at any time during play, it effectively means that it's impossible to define an objective standard palette.
