Color A Deer

[pubby]

COLOR A DEER
For those who thought Color a Dinosaur wasn't shitty enough.



In this ROM you color a deer and then you close your emulator and wish you were doing something better with your life.

[BioMechanical Dude]

This is simply amazing! Game of the Year 2016!

[Jedi QuestMaster]

Make an NES version of this: https://www.youtube.com/watch?v=qlirTrakTbE

[dougeff]

If your target audience is young children, then it's too hard...specifically, too many small areas with ambiguous color. It should be only 8-10 areas that you need to correctly color, and then get like a big dancing star animation that says "you did it".

And color seems a bit limited, even for NES.

But, conceptually, not a bad idea.

[tepples]

Nice tech demo. Where'd you get the outline?

Could "too many small areas with ambiguous color" be filled by defining regions that are linked together? If a region is linked to other regions, and you fill one region, it'd automatically fill the others. A user who doesn't want linking could disable it later in the menu.

For example, in the present drawing, I can see these regions being linked:

• Main fur
• Fur counter-shade (belly color)
• All four hooves
• Both antlers
• Tree trunk parts
• Tree foliage parts
• Grass close behind the deer

[rainwarrior]

palette_a_deer.nes

[Bregalad]

I challenge you to do the same with at least 4 colours (black not included), and on NES

[tokumaru]

Color a Dinosaur offered a lot of silly patterns to compensate for the lack of color, didn't it?

[Guilty]

Color a Dinosaur offered a lot of silly patterns to compensate for the lack of color, didn't it?

Sure did.
So, Pubby? Where's our silly pattern crayon?

[pubby]

To briefly describe the technique, I'll say it first begins by hand-coloring the outline image to look like this:

The requirements of this coloration is that each 8x8 tile contains at most 1 red-colored region, 1 blue-colored region, and 1 green-colored region. This allows the ROM's flood-fill algorithm to work with precomputed 8x8 tiles instead of checking pixel-by-pixel.

Could "too many small areas with ambiguous color" be filled by defining regions that are linked together? If a region is linked to other regions, and you fill one region, it'd automatically fill the others. A user who doesn't want linking could disable it later in the menu.

Yes, this could be done by modifying the preprocessor program, but I'm not interested in doing it.

I challenge you to do the same with at least 4 colours (black not included), and on NES

This is possible by changing the regions to be 16x16 (and finding a simpler outline image), but I'm not interested in doing it.

So, Pubby? Where's our silly pattern crayon?

Adding a single pattern crayon would be easy because there's room for it, but adding more would require shrinking my RAM buffers which is kinda a pain and so I'm not interested in doing it.

Nice tech demo. Where'd you get the outline?

http://www.fsa.usda.gov/Internet/FSA_Fi ... lrbook.pdf
It's public domain.

[tepples]

To briefly describe the technique, I'll say it first begins by hand-coloring the outline image to look like this:

The requirements of this coloration is that each 8x8 tile contains at most 1 red-colored region, 1 blue-colored region, and 1 green-colored region. This allows the ROM's flood-fill algorithm to work with precomputed 8x8 tiles instead of checking pixel-by-pixel.

Interesting. Would it be equivalent to say "each 8x8 pixel tile may contain pixels from no more than three connected regions"? Or is the RGB a tighter bound?

Could "too many small areas with ambiguous color" be filled by defining regions that are linked together?

Yes, this could be done by modifying the preprocessor program, but I'm not interested in doing it.

Do you plan on releasing source code so that other interested people can do it?

Where'd you get the outline?

http://www.fsa.usda.gov/Internet/FSA_Fi ... lrbook.pdf
It's public domain.

Thank you. Now other developers of coloring book engines will at least have a data set to test against. I seem to remember bunnyboy mentioning a Color a Dinosaur sequel called Power Coloring, for instance.

[Macbee]

Pretty cool! =)

[tokumaru]

The requirements of this coloration is that each 8x8 tile contains at most 1 red-colored region, 1 blue-colored region, and 1 green-colored region. This allows the ROM's flood-fill algorithm to work with precomputed 8x8 tiles instead of checking pixel-by-pixel.

Does this mean you're changing all instances of a specific color in each tile using bitwise operations? What about detecting whether the paint should spill to adjacent tiles?

I challenge you to do the same with at least 4 colours (black not included), and on NES

This is possible by changing the regions to be 16x16 (and finding a simpler outline image), but I'm not interested in doing it.

You'd need 3 palettes to hold all possible 3-color combinations out of the total of 4 colors (+ black), but if painting a block causes a different palette to be assigned to it, other colors in the same pattern might need to be changed to match the new palette.

So, Pubby? Where's our silly pattern crayon?

Adding a single pattern crayon would be easy because there's room for it, but adding more would require shrinking my RAM buffers which is kinda a pain and so I'm not interested in doing it.

Personally, I'd implement the silly patterns by having the flood fill algorithm always consult the original flat image (which would be uncompressed in the ROM) to decide what colors to change and to build the bit masks necessary to manipulate the dynamic patterns. A simpler option might be to remember in RAM what each color of each tile has been recolored to, and apply all 3 transformations on top of the original tile data every time a tile is processed. This is more straightforward and has the benefit of not needing to read from VRAM. You can even implement a pop-up GUI by overwriting part of the picture, and restoring it once the interface is closed.

[pubby]

Do you plan on releasing source code so that other interested people can do it?

Here: https://github.com/pubby/coloradeer

I didn't intend for anyone to ever read the source and so it is rightfully rather terrible. There are close to no comments and the identifiers are both non-descriptive and misleading at the same time. But maybe you can figure it out.

To build, you'll need to first "make convert" and then run "./convert art/deer.png"
I never got around to automating this step in the makefile.

Interesting. Would it be equivalent to say "each 8x8 pixel tile may contain pixels from no more than three connected regions"? Or is the RGB a tighter bound?

The colored image gets converted to CHR data in a very straightforward way. CHR data can have 4 different colors and that is why my coloration uses 4 colors; R, G, B, and black. I would say that RGB is a tighter bound.

To modify the program to "join" several small regions together, I suggest adding new colors to form bridges between regions.

This maroon color would be considered black when converted to CHR, but otherwise it would be considered red.

A simpler option might be to remember in RAM what each color of each tile has been recolored to, and apply all 3 transformations on top of the original tile data every time a tile is processed. This is more straightforward and has the benefit of not needing to read from VRAM. You can even implement a pop-up GUI by overwriting part of the picture, and restoring it once the interface is closed.

This is what I'm doing. VRAM is not read from at all in the demo. By "buffer" I really meant "array"; each 8x8 tile takes up 1 byte of RAM, and since there are 1024 tiles this takes up 1024 bytes of space. Colors are encoded in 2 bits segments of these bytes, meaning only 4 colors are possible (3 solid and 1 pattern). However, you could increase the bits-per-color to 8 and still have enough room by combining duplicate tiles.

Does this mean you're changing all instances of a specific color in each tile using bitwise operations? What about detecting whether the paint should spill to adjacent tiles?

Changes to the pattern tables are done using bitwise masks against the uncompressed 3-colored image. The inputs are three replacements:
replace R with palette color XX
replace G with palette color YY
replace B with palette color ZZ
Where XX, YY, ZZ are two bits each and they form a byte stored in memory: XXYYZZ00

What about detecting whether the paint should spill to adjacent tiles?

Adjacent tiles of the same color are precomputed and stored in lookup tables (nbor_r.bin, nbor_g.bin, nbor_b.bin)
This takes 1.5 KB ROM space per image.

[Myask]

To briefly describe the technique, I'll say it first begins by hand-coloring the outline image to look like this:

Hmm...so we need images that are three-colorable (as opposed to the guaranteed four-colorable). [well, if we had freer paletting...]

Idea: Community-submitted (competitive?) images for it, for the multicart?

(Hmm, with 32KB CHR RAM, one could go full Oeka Kids and not care about unique tiles...)