Page 18 of 19

Re: NES Screen Tool

Posted: Fri Mar 03, 2017 10:40 am
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

Re: NES Screen Tool

Posted: Thu Aug 10, 2017 11:29 pm
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

Re: NES Screen Tool

Posted: Fri Aug 11, 2017 1:12 am
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).

Re: NES Screen Tool

Posted: Fri Aug 11, 2017 3:05 pm
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

Re: NES Screen Tool

Posted: Mon Aug 21, 2017 5:25 pm
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.

Re: NES Screen Tool

Posted: Mon Aug 21, 2017 5:57 pm
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.

Re: NES Screen Tool

Posted: Mon Aug 21, 2017 6:10 pm
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.

Re: NES Screen Tool

Posted: Mon Aug 21, 2017 7:09 pm
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.

Re: NES Screen Tool

Posted: Tue Aug 29, 2017 2:57 am
by Diskover
The thing I think this tool is missing is the possibility of doing MetaTiles for the backgrounds

Re: NES Screen Tool

Posted: Tue Aug 29, 2017 3:09 am
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.

Re: NES Screen Tool

Posted: Tue Aug 29, 2017 3:17 am
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

Re: NES Screen Tool

Posted: Wed Mar 14, 2018 5:11 am
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.

Re: NES Screen Tool

Posted: Wed Mar 14, 2018 7:23 am
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.

Re: NES Screen Tool

Posted: Wed Mar 14, 2018 8:02 am
by tepples

Re: NES Screen Tool

Posted: Wed Mar 14, 2018 8:21 am
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.