nesdev.org

Sik wrote:Also: the GBC resolution is smaller. This means that a sprite of the same pixel size covers a larger portion of the screen, and Shantae is designed around those sizes (meaning everything would look too small on a NES).

Actually, she's still rather big, and she looks more at home with the NES' screen display.



She even gives Astyanax a run for his money, and he's a big guy, for an NES player sprite.

OneCrudeDude wrote: I think the GBC could do 50 or so colors at a given time?

Sik wrote: As for palettes, if I recall correctly the GBC has more palettes than the NES does, so that's a downside too. I don't recall any palette raster effects (i.e. all palette tricks would be screen-wide), but it does rewrite tiles on the fly (e.g. brick parallax in some underground levels), so that has to be taken into account too. Also the palette in the background plane can be set per-tile, right?

The GBC has a total of 16 available palettes, 8 for the BG, and 8 for OBJs (sprites). The maximum amount of colors you can display on screen (reasonably at least) was 56 - 4 colors each for the BG, 3 colors each for OBJs - but writing to palette data during HBlanks could technically allow you to display more than 56. Every tile in the BG has an attribute that allows you to choose which of the 8 palettes the tile will use, so yes, they're set per-tile, unlike the DMG.

An NES mockup of Shantae would be challenging to say the least, mostly because of color-reduction as pointed out above. It's probably worth mentioning that this game was praised for its vibrant and detailed art and animation, even as the GBA was gaining traction.

@Macbee - That's some great work I haven't played Sonic 1 for the SMS in a long time, but you certainly made me do a double take.

Shonumi wrote:Every tile in the BG has an attribute that allows you to choose which of the 8 palettes the tile will use, so yes, they're set per-tile, unlike the DMG.

I assume you meant "unlike the NES"? (the original GB only had a single palette for all the background, period)

Rogue clone?

Sik wrote:I assume you meant "unlike the NES"? (the original GB only had a single palette for all the background, period)

No, I meant what I said. The GBC BG tiles could have their palettes set on a per-tile basis, hence GBC BG tiles are unlike DMG BG tiles, which had a system-wide palette. The GBC has no concept of a single palette that will be used by all BG tiles; the closest you get is Palette #0 being the default in VRAM since everything in the BG Tile Attributes is initially empty.

Shonumi wrote:the closest you get is Palette #0 being the default in VRAM since everything in the BG Tile Attributes is initially empty.

If the VRAM is uninitialized, then it is most likely not all #0x00.

And there is 2 kind of Game Boy Colour games (retrocompatible with DMG and not retrocompatible), I thought you were mentioning a difference between those 2.

Bregalad wrote:If the VRAM is uninitialized, then it is most likely not all #0x00.

It has a startup screen though. Doesn't it have to be initialized for that?

The boot rom definitely sets things up, but not all of VRAM is touched iirc. By empty, I did not mean 0x00 specifically, just that the values are meaningless. I was under the impression that VRAM was either filled with garbage data, a constant value like 0xFF but interpreted as 0 anyway, or a combination (garbage data with bits of constant values, all seen as 0). Since the GBC boot ROM does not alter all of VRAM, it should be possible to look at what's happening to uninitialized VRAM, at least in parts. I could whip up a test this weekend if anyone is interested.

EDIT - Actually, the GBC boot ROM appears to zero out some memory locations, perhaps as a convenience to the boot ROM and Nintendo's way of dealing with the garbage data for the game developers' sakes. I'll investigate when I get home. Sorry for causing such a technical tangent in this thread :p

RE-EDIT - Alright, so the GBC boot ROM is actually pretty nice. I gather that, except for the Nintendo logo tiles, it basically clears out VRAM before the game even touches anything. So immediately proceeding bootup, BG Palette #0 will in fact be the closest thing the GBC has to a universal BG palette as I stated before, since all tiles will point to that palette. As soon as the program starts writing to BG Attributes though, that can change.

Shonumi wrote: @Macbee - That's some great work I haven't played Sonic 1 for the SMS in a long time, but you certainly made me do a double take.

Thank you very much!
Today I tried to mockup the Mega Drive version of "Batman". I believe it could be a nice NES game.
I used a lot of horizontal dithering since it's proven it can blend colors on PAL televisions. I wish I could see how it looks on PAL.

That's a really impressive mockup!

The "bright" side is that the PAL chroma merging won't have much of an effect on your mockups, because there's little hue change from scanline to scanline. A little bit of color bleeds into the grey highlights.

The down side is that we haven't codified exactly what's going on with the 2C07's weird chroma shift on alternating scanlines, so it's not clear exactly what color the regions of alternating scanlines would look like.

lidnariq wrote:That's a really impressive mockup!

The "bright" side is that the PAL chroma merging won't have much of an effect on your mockups, because there's little hue change from scanline to scanline. A little bit of color bleeds into the grey highlights.

The down side is that we haven't codified exactly what's going on with the 2C07's weird chroma shift on alternating scanlines, so it's not clear exactly what color the regions of alternating scanlines would look like.

Thanks for the explanation.
Horizontal dithering is not my favorite type (it's very noticeable)- but at least it also doesn't create artifacts on NTSC (which is good).
I'm trying to create different patterns and so far only horizontal dithering doesn't look deformed on AV/NTSC:





Anyway, if someone from Europe wants to try it on an Everdrive here's the link for the mockup ROM: https://www.mediafire.com/?lz6fbwjvg7f99bf

Dithering using "wide" pixels might produce slightly less objectionable artifacts on NTSC. Compare all-horizontal to wide-pixel diagonal

Macbee wrote:I'm trying to create different patterns and so far only horizontal dithering doesn't look deformed on AV/NTSC:

For whatever it's worth, three 2A03 pixels make two NTSC color periods, and the 2A03 chroma phase shift repeats every 3 scanlines, so if you use a dithering pattern that's a multiple of three pixels wide (and three high), it will compensate as best as possible for that.

surt wrote:Rogue clone?

Reminds me of Ultima IV a bit.

Going the other extreme of sizing...I'd been thinking NEShack? Just how to fit all the data necessary on the screen.

I allocated a bit more space than I needed on the first pass for the main map, I found. Thanks to this and the permawalls ringing every level (except for some of the Planes) there are enough tiles in one CHR page to just plain draw what you want for the fullmap, not needing to go monochrome and walls-only as I did.

Now, for the actual inset, one can have the ASCII in up to 24 colors, if truly desired-as one can have some color choices on sprites, and others on BG, even the 69 light-radius tiles can be accommodated.

STATUS is where things like "Hungry" or icons therefor would go.

if you use a dithering pattern that's a multiple of three pixels wide (and three high)

The 3x4 tile grid for the map is going to look just horrible, isn't it?

Is there a public (windows) build of blargg's nes_ntsc demo anywhere? I was suddenly struck by how odd it is to be filtering other people's mockups.

Anyway, here it is, with "chroma error" and "luma blur" both turned up to maximum