It is currently Mon Jul 24, 2017 9:45 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Fri Sep 09, 2016 8:30 pm 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 299
Location: us-east
So I took a couple days to tackle a problem I had to deal with a couple of times: Fitting complex images into the 256 tile limit.
What I basically tried out was an automated version of the process I end up do manually. Randomly search for 2 similar tiles that are unique in the nametable and merge them in some way.

In this program similar tiles are pairs of tiles that have the least number of pixels changed, and merging is randomly selecting the pixels from both tiles

Example image NES screen sized image with way too many distinct tiles (471)
Image
Source: https://twitter.com/azumakiyohiko/status/495548119048679426

After merging tiles together until there's only 256 unique ones.
Image

Results vary due to random pixel selections between tiles. Not the best of quality, but looks on par with the worst JPEG compression. In any case I figured this hack of a tool might be useful to someone. It's input is the output of tepple's pilbmp2nes.py


Attachments:
compress-nes-image.py [2.06 KiB]
Downloaded 48 times
Top
 Profile  
 
PostPosted: Fri Sep 09, 2016 9:22 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5421
Location: Canada
Two ideas that might improve results:

1. Instead of just "number of changed pixels", multiply this number by the number of times that either tile is being used in the image. That will give you the total number of pixels changed in the whole image, rather than just the number changed in the individual tiles. (Also might guide the merging process; i.e. where pixels differ, take more from the one that is used more.)

2. Use a 3x3 neighbourhood to weight the importance of pixel changes. e.g. if you're about to place a black pixel into a 3x3 region of white pixels, consider this a greater change than placing a black pixel next to a group of black pixels just extending an edge, etc. This might let you favour changes that don't stand out as much? (Also gives you a way to choose which pixels to keep from the two merging tiles.)


Top
 Profile  
 
PostPosted: Sat Sep 10, 2016 10:03 am 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 299
Location: us-east
Suggestion 1 about counting the pixel changes of the whole image helped a lot. What is measured now better matches what's changed. Combined with the suggestion to bias the merge changes, this now does subtle changes to more tiles rather then big changes to less.

Image

I not sure how to work in suggestion 2. I did try something with a 3x3 region, but I must of severely messed up the weights because the result was garbage.

The way I see the problem is that tiles with opposite edges and corners are matched together, but every time I try to fix the random edge dots, the overall picture gets worse. I'm starting to think the random dots are actually a feature and the best compromise for reducing the tileset.

A thing that I might try another day is to factor in a manually made mask that prevents select pixels from changing. So that some crucial details, like faces, are preserved.


Attachments:
compress-nes-image-2.py [2.41 KiB]
Downloaded 47 times
Top
 Profile  
 
PostPosted: Sat Sep 10, 2016 12:38 pm 
Offline
User avatar

Joined: Mon Oct 06, 2014 12:37 am
Posts: 174
JRoatch wrote:
So I took a couple days to tackle a problem I had to deal with a couple of times: Fitting complex images into the 256 tile limit.

Example image NES screen sized image with way too many distinct tiles (471)


471? That's honestly not too bad. With fullscreen scenes like this, I say screw the limitations!

I tend to limit my RPG's *ahem* "cutscenes" to 448 tiles, with a timed $00/$10 background split, to use more on-screen tiles. The rest is used for sprite overlays, to enhance the scene. It's all done by hand, on my end, though.


Top
 Profile  
 
PostPosted: Mon Nov 14, 2016 12:32 pm 
Offline
User avatar

Joined: Sat Nov 26, 2011 8:31 am
Posts: 100
Location: Brazil
Thanks JRoatch for creating (and publishing) this!
It's fantastic and is already helping me a lot with a NES project.

User NESRocks is also using this - and even created a .BAT to make it easier to use (just drop the BMP file to convert.bat).
I'm attaching it here.

Are you planning to release a version that also removes the duplicated tiles?
It can be done on NES Screen Tool, just asking for curiosity.

Thanks! =)


Attachments:
bmp2nescompress.zip [9.17 KiB]
Downloaded 39 times
Top
 Profile  
 
PostPosted: Mon Nov 14, 2016 12:45 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7105
Location: Jongny, VD, Switzerland
Looks like this really rocks ! Drawing such a scene limited to 256 tiles should be hard, a bit of automation can always help.

Also, for those pointing to the possibility of doing raster effects trickery to bypass the limitation, I'd add that there's a million of reason why you'd want to stick to vanialla 256 tiles and not want to deal with PPU register writes midframe at all.


Top
 Profile  
 
PostPosted: Mon Nov 14, 2016 2:30 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 656
Location: Gothenburg, Sweden
A masking feature sounds like a very sensible option to be able to use.

Currently, i'm doing this completely manually.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

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