So I've thought long and hard about this, and reached some unexpected conclusions which will probably annoy many of you.
First of all, let me clarify what the SGB actually is, since there seems to be too much misinformation and speculation in this thread.
The Super Gameboy was a cartridge for the Super Nintendo which contained a complete set of DMG hardware with its I/O tied into the SNES cartridge bus, and handled by SNES software.
The SNES software could tell the DMG to play original DMG software seemingly through the SNES I/O, with the ability to change pallet, add on borders, draw on the screen, and a couple of other cutesy things. The game itself is almost the same.
However, there were plenty of games designed for the SGB (with an SGB emblem found on the gamepak/box), which did so much more. They started with custom borders and richer colors changing on the fly, but that was really just the bare minimum. Games could make use of all the controllers plugged into your SNES. So you could have several players in the SGB Bomberman games like in the SNES ones. The game would be able to check which platform it was running under, so if it wanted to, it could make in-game changes. It could also pass on SNES code to be ran directly on the SNES. SGB Space Invaders actually contains the SNES version of the game.
What level of support emulators provide for SGB varies emulator to emulator, the most complete one at the moment to my knowledge is the one in bsnes.
The DMG/SGB game in itself, is NOT emulated on the SGB hardware, it's running in a different mode. This mode may or may not provide significant differences/improvements over the vanilla DMG version.
Since the SGB version of the game is always enhanced in some way over the DMG version, it is preferred that our runs take place using that version, unless there is a good reason on a game by game basis not to.
For our primary encodes, we should make them accurate depictions of their output. While some of us may prefer seeing a game in HQ4x, NTSC, with alternate graphic packs, or other cosmetic changes, they are not true to the native output generated by the console itself. They're also highly subjective, and what one person loves will be hated by another. Some love NTSC filtering with scanlines since it seems "authentic" to them. I think it puts "garbage" into an otherwise clean video stream. If encoders want to make alternate encodes with different filtering options, that is their prerogative, and we should not stand in their way if some of the audience wants such an encode.
Now the encodes may be looked at as for those that can't playback the run in an emulator, but I find many other reasons to have an encode.
1) If I want to see a run, I can just play it, I don't need to find just the exact emulator version and game version to play the run in question.
2) I can play it on say my cell phone.
3) Actual video format of the run allows nice seeking around.
Make up your own additional reasons.
Now, what did the designers of Pokemon design it for, how it looks on a DMG, or how it looks on an SGB? The answer is in fact: both. They had to specifically program in how it should look on an SGB, so whatever we see there is of course intended (for some accurate definition of the meaning of "intended").
Now the border for Pokemon is quite boring and useless, but on the other hand, I quite like having the "color" in our encodes. The color in the game is also clever, as the color of each city actually matches the name of the city.
Grunt brought up a good point, showing the color but not the border would be a hack. Either we should go SGB all the way, or not at all. That's an opinion I can agree with. But I want to have my cake and eat it too.
Then all of this hit upon an argument and "solution" I recall from the original Pokemon encode we had years ago. It also mirrors the "video output" point I brought up above, as well as other thoughts I've had about the site in general.
As I said above, the output aspect ratio is not defined by the console itself, but by the device that displays it. Quite coincidentally, the output aspect ratio of an encoded video is not defined by the video, but by the program that displays it. The program may choose to obey an internal recommendation on aspect ratio, but it can really do whatever it wants. Users can also force their own aspect ratios or resize the picture how they desire.
Keeping this in mind, we should make sure the primary encodes for our runs match the video stream being output, with the most accurate settings, and leave further changes up to the video players.
In terms of downloadable encodes, users can tell their program what they want. We should probably have a handy reference somewhere for commonly used settings. I recall for the original Pokemon run, we listed what MPlayer parameters to pass to crop the border from the output.
In terms of our streaming encodes, we can control how the output is displayed to some extent on our site as well. In our forum or wiki you can specify width and height when posting a video. That generally preserves aspect ratio though. We should probably add some JavaScript controls you can press to select some different aspect ratios on the fly while viewing. Since this is a player problem in the end, and not an encoding problem.
Feel free to get out your torches and pitchforks and attack me. In closing, I think Grunt's view of the matter is the one most true to what we should be doing, but I personally would like to get the best of all worlds if possible.
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.