NES Screen Tool

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

User avatar
FARID
Posts: 499
Joined: Wed Apr 07, 2010 1:14 am
Location: Iran
Contact:

Re: NES Screen Tool

Post by FARID »

dougeff wrote: You can edit the palette, by loading the exe in a hex editor and searching for the palette array.
Awesome!
Thanks
Attachments
nesst_palette_swap.zip
(45.98 KiB) Downloaded 550 times
User avatar
Diskover
Posts: 219
Joined: Thu Nov 24, 2011 7:16 am
Contact:

Re: NES Screen Tool

Post by Diskover »

It seems that Shiru has re-updated NES Screen Tool to version 2.32

v2.32 03.08.17 - Sprite duplication, group flip, four palette slots, tile density sort, and more
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: NES Screen Tool

Post by FrankenGraphics »

Density sorting - That's interesting! The first use i see is finding tiles with low and/or similar content and test if one is redundant.

But in my mind, this sort of thing could maybe also be a useful/effective preconditioner prior to RLE compression (sorting by optimal lengths of runs are obviously even better, but it can't hurt that 0 heavy content is packed in one end).
tschak909
Posts: 142
Joined: Mon Jul 03, 2017 4:37 pm
Contact:

Re: NES Screen Tool

Post by tschak909 »

This tool is indispensable for my work on Wizard of Wor. Absolutely amazing. Hats off to Shiru for his work on this!

-Thom
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: NES Screen Tool

Post by FrankenGraphics »

I found a bug ...but it's seeded by photoshop. There could be a way to proof NESST, though. Description and workaround below:

Sometimes -in photoshop at least-, when saving images as indexed bitmaps, it silently stores multiple entries of the exact same colour.

NESST will read this as separate colour entries during import and try to 1) squash colour depth, resulting in scrambled/lossy patterns, and 2)
come up with multiple subpalettes to cover.

If you ever find that NESST scrambles your bitmaps/patterns, even though you've been careful to just store 4 indexed colours, here's a workaround:

1. Photoshop > file > export > save for web (legacy)
2. Select GIF. Select either selective or adaptive indexing. This will merge any dupes and solve the problem. There's a bonus feature to this, too.*
3. Save. Open. Re-save as bmp.
4. NESST imports will now work.

It seems the bug originates from using the colour swatch, if the colours of the swatch were picked with the eyedropper tool in another project window, but i haven't tested it extensively.

As for proofing NESST, checking for identical colour entries in index and ignoring the excess entries should work.


========
*As a bonus, the indexing mode will sort your colour entries. Adaptive mode puts the most used colour first, which is usually the bg colour, so that's good for NESST imports.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: NES Screen Tool

Post by tokumaru »

No need to save to GIF and re-save as BMP, you can convert your images to indexed color prior to saving, and work on them that way, using a fixed palette, without running the risk of using the wrong colors by accident.

You can go to image -> mode -> indexed color to palletize your image, using similar controls to those found in the "save for web" dialog.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: NES Screen Tool

Post by FrankenGraphics »

That's true. I was working in indexed mode already - Admittedly, it allowed for 12 colours when i first swapped to it, which gave plenty of room for the bug to manifest itself (NESST detected 6 colours + the bg colour, where only 4 were unique). Normally AFAIK in PS, if you allow for more colours than what is used, those excess colours will be discarded when saving, but this is apparently not the case if dupe entries somehow manage to sneak in.

In the save for web dialogue you have a better view of exactly what colours are stored and in what order, which was how i detected what it was that NESST didn't like. But swapping back to rgb and then to indexed once again is quicker, like you said.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: NES Screen Tool

Post by tokumaru »

I think that if you click on the "forced" drop-down and then on "custom" you can see the color table Photoshop generated for you, and you can manipulate it too.
User avatar
Diskover
Posts: 219
Joined: Thu Nov 24, 2011 7:16 am
Contact:

Re: NES Screen Tool

Post by Diskover »

The thing I think this tool is missing is the possibility of doing MetaTiles for the backgrounds
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: NES Screen Tool

Post by FrankenGraphics »

Shouldn't that be the job of a dedicated map/level editor? Not that i would complain if nesst was expanded in this direction. Just as long as it still would let me reference nametable cells to patterns without forcing the use of metatiles.

Maybe derive a list of metatiles based on the current content of the nametable; ignoring any duplicates? More elaborately, that list could in turn be used internally to feed into a 'stamp' type of tool.
User avatar
Diskover
Posts: 219
Joined: Thu Nov 24, 2011 7:16 am
Contact:

Re: NES Screen Tool

Post by Diskover »

FrankenGraphics wrote:Maybe derive a list of metatiles based on the current content of the nametable; ignoring any duplicates? More elaborately, that list could in turn be used internally to feed into a 'stamp' type of tool.
That would be great
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: NES Screen Tool

Post by FrankenGraphics »

Hey shiru, i was wondering if you could look into this?

-As of some recent version, NESST saves .chr files as 8kB by default. This causes inconvenience further down the pipe as 95% of the time, the other 4kB is just an empty fill. I was wondering if you could make it so that unless theres some actual content other than a fill on the "B" set, a 4kB file would be defaulted?

The current workaround for this is either
-saving each file separately rather than all three/four at once; which gives the option to set filesize for chr files.
-cut the superfluous 4kB:s in a hex editor
-use ca65 and pass a 4kB range for the .incbin directive (not an option in other assemblers).
-use powershell or bash to cut it in half

So there are options, but adds a step to the process and a bit of required vigilance compared to earlier NESST versions. If an 8kb file gets in by mistake and breaks a boundary, ca65 users will get a warning, asm6 users will see the file assemble silently but it won't run properly.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: NES Screen Tool

Post by dougeff »

You are probably going to have to contact him (email) directly.

If I could add a feature, it would be to allow the import graphics lossy to reduce the tile count to a variable # of tiles. Currently it stops removing tiles when it gets to 256, but the save as RLE function doesn't work unless you have at least 1 unused tile, so 255 would make more sense. And I can see situations where I would want to set it to...say 128, maybe.
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: NES Screen Tool

Post by tepples »

User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: NES Screen Tool

Post by FrankenGraphics »

I'll try that! thanks
dougeff wrote:Currently it stops removing tiles when it gets to 256, but the save as RLE function doesn't work unless you have at least 1 unused tile, so 255 would make more sense.
For this purpose, i think it is ok to decide for yourself which tile is most redundant, though? Especially with the help of the frequency and density sorter tools that were added in the last version.
Post Reply