nesdev.com
https://forums.nesdev.com/

Color A Deer
https://forums.nesdev.com/viewtopic.php?f=22&t=14257
Page 1 of 2

Author:  pubby [ Fri May 20, 2016 4:49 am ]
Post subject:  Color A Deer

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

Image

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

Attachments:
color_a_deer.nes [16.02 KiB]
Downloaded 164 times

Author:  BioMechanical Dude [ Fri May 20, 2016 5:10 am ]
Post subject:  Re: Color A Deer

This is simply amazing! Game of the Year 2016!

Author:  Jedi QuestMaster [ Fri May 20, 2016 6:12 am ]
Post subject:  Re: Color A Deer

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

Author:  dougeff [ Fri May 20, 2016 6:17 am ]
Post subject:  Re: Color A Deer

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.

Author:  tepples [ Fri May 20, 2016 12:17 pm ]
Post subject:  Re: Color A Deer

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

Author:  rainwarrior [ Fri May 20, 2016 12:53 pm ]
Post subject:  Re: Color A Deer

palette_a_deer.nes

Author:  Bregalad [ Fri May 20, 2016 1:03 pm ]
Post subject:  Re: Color A Deer

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

Author:  tokumaru [ Fri May 20, 2016 1:08 pm ]
Post subject:  Re: Color A Deer

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

Author:  Guilty [ Fri May 20, 2016 1:18 pm ]
Post subject:  Re: Color A Deer

tokumaru wrote:
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?

Author:  pubby [ Fri May 20, 2016 3:41 pm ]
Post subject:  Re: Color A Deer

To briefly describe the technique, I'll say it first begins by hand-coloring the outline image to look like this:
Image
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.

Quote:
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. :P

Bregalad wrote:
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. :P

Guilty wrote:
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. :P

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

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

Author:  tepples [ Fri May 20, 2016 4:32 pm ]
Post subject:  Re: Color A Deer

pubby wrote:
To briefly describe the technique, I'll say it first begins by hand-coloring the outline image to look like this:
Image
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?

pubby wrote:
tepples wrote:
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. :P

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

pubby wrote:
tepples wrote:
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.

Author:  Macbee [ Fri May 20, 2016 4:39 pm ]
Post subject:  Re: Color A Deer

Pretty cool! =)

Author:  tokumaru [ Fri May 20, 2016 5:33 pm ]
Post subject:  Re: Color A Deer

pubby wrote:
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?

Quote:
Bregalad wrote:
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. :P

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.

Quote:
Guilty wrote:
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. :P

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.

Author:  pubby [ Fri May 20, 2016 6:20 pm ]
Post subject:  Re: Color A Deer

tepples wrote:
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.

tepples wrote:
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.
Image
This maroon color would be considered black when converted to CHR, but otherwise it would be considered red.

tokumaru wrote:
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.

Quote:
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

Quote:
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.

Author:  Myask [ Sun May 22, 2016 1:18 am ]
Post subject:  Re: Color A Deer

pubby wrote:
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...)

Page 1 of 2 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/