It is currently Thu Nov 23, 2017 3:22 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Color A Deer
PostPosted: Fri May 20, 2016 4:49 am 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 211
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
Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Fri May 20, 2016 5:10 am 
Offline
Formerly AlienX
User avatar

Joined: Fri Apr 18, 2014 7:41 am
Posts: 133
Location: Bulgaria
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.


Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Fri May 20, 2016 6:12 am 
Offline
User avatar

Joined: Thu Sep 07, 2006 1:08 pm
Posts: 544
Location: United States
Make an NES version of this: https://www.youtube.com/watch?v=qlirTrakTbE

_________________
Ruling the World One Bean™ at a Time...


Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Fri May 20, 2016 6:17 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1832
Location: DIGDUG
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


Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Fri May 20, 2016 12:17 pm 
Offline

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


Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Fri May 20, 2016 12:53 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5833
Location: Canada
palette_a_deer.nes


Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Fri May 20, 2016 1:03 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7273
Location: Chexbres, VD, Switzerland
I challenge you to do the same with at least 4 colours (black not included), and on NES :)


Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Fri May 20, 2016 1:08 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10118
Location: Rio de Janeiro - Brazil
Color a Dinosaur offered a lot of silly patterns to compensate for the lack of color, didn't it?


Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Fri May 20, 2016 1:18 pm 
Offline
User avatar

Joined: Fri Apr 08, 2016 5:58 pm
Posts: 93
Location: California, USA
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?


Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Fri May 20, 2016 3:41 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 211
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.


Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Fri May 20, 2016 4:32 pm 
Offline

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


Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Fri May 20, 2016 4:39 pm 
Offline
User avatar

Joined: Sat Nov 26, 2011 8:31 am
Posts: 107
Location: Brazil
Pretty cool! =)


Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Fri May 20, 2016 5:33 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10118
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Fri May 20, 2016 6:20 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 211
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.


Top
 Profile  
 
 Post subject: Re: Color A Deer
PostPosted: Sun May 22, 2016 1:18 am 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
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...)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group