Color A Deer

A place where you can keep others updated about your NES-related projects through screenshots, videos or information in general.

Moderator: Moderators

User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Color A Deer

Post by pubby »

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 522 times
User avatar
BioMechanical Dude
Formerly AlienX
Posts: 137
Joined: Fri Apr 18, 2014 7:41 am
Location: Bulgaria

Re: Color A Deer

Post by BioMechanical Dude »

This is simply amazing! Game of the Year 2016!
Greetings! I'm That Bio Mechanical Dude and I like creating various stuff like movies, games and of course chiptunes!
You can check out my YouTube Channel.
You can also follow me on Twitter.
User avatar
Jedi QuestMaster
Posts: 688
Joined: Thu Sep 07, 2006 1:08 pm
Location: United States
Contact:

Re: Color A Deer

Post by Jedi QuestMaster »

Make an NES version of this: https://www.youtube.com/watch?v=qlirTrakTbE
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Color A Deer

Post by 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.
nesdoug.com -- blog/tutorial on programming for the NES
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Color A Deer

Post by 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
User avatar
rainwarrior
Posts: 8733
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Color A Deer

Post by rainwarrior »

palette_a_deer.nes
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Color A Deer

Post by Bregalad »

I challenge you to do the same with at least 4 colours (black not included), and on NES :)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Color A Deer

Post by tokumaru »

Color a Dinosaur offered a lot of silly patterns to compensate for the lack of color, didn't it?
User avatar
Guilty
Posts: 93
Joined: Fri Apr 08, 2016 5:58 pm
Location: California, USA

Re: Color A Deer

Post by Guilty »

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?
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: Color A Deer

Post by pubby »

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.
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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Color A Deer

Post by tepples »

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.
User avatar
Macbee
Posts: 120
Joined: Sat Nov 26, 2011 8:31 am
Location: Brazil
Contact:

Re: Color A Deer

Post by Macbee »

Pretty cool! =)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Color A Deer

Post by tokumaru »

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?
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.
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.
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: Color A Deer

Post by pubby »

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.
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.
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: Color A Deer

Post by Myask »

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...)
Post Reply