Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics


Featureful NES assets studio based off the classic "NES Screen Tool". It's the "famitracker" of NES graphics. 路 By FrankenGraphics

List of suggestions

A topic by Terwilf created Aug 24, 2022 Views: 440 Replies: 17
Viewing posts 1 to 9

Hi, first I wanted to thank you for giving support again to this great application, I know that maybe these ideas are silly or just unfeasible, but I did not want to miss the opportunity to share my experience, through my concerns 馃槈

  1. Open files by dragging and dropping.
  2. Make the window transparent in a native way for tracing.
  3. Load a larger CHR and be able to associate it with the sprites to be represented.
  4. Possibility to represent screens using breakpoints.
  5. Lossy compress by defining the amount of final output sprites.
  6. Lossy compression of a specific section of the screen.
  7. Compress graphics by color
  8. If there is a Tileset loaded, don't overwrite it, use the free space and reuse the matching sprites.
  9. Rearrange the Tileset data based on another imported Tileset.

(2) This is useful for using guide mockups and for applying palettes.

(3) In large projects, it becomes a headache to manage all the data.

(4) Many title screens use one or more breakpoints to provide more graphics:

(5) You can't always have the full CHR in the end game.

(6) Sometimes it is better not to compress all graphics, especially when you need to write in a common font:

(7) This technique focused on simple screens can practically double the Tileset space without losses, it consists of superimposing 2 different sprites in the same tile, using the colour attributes to hide one, showing the other and vice versa:

(8) When you create a title screen you generally do it thinking about integrating it with other resources, for example. the typography of the game.

(9) To conform to constraints, to reuse resources, or just to facilitate future edits to the graphics, it is sometimes necessary to adjust the Tileset so that it can be interpreted by humans:

Changing the subject, some time ago I designed these icons, maybe you will find them useful:

Pack Icons (7z)
Developer (4 edits)

Hi! Thanks for the suggestions, and nice work! I'll keep it in reference if opportunities arise. 
It's past morning and i need to get working on other projects, so please pardon some brevity on some of the points, but here goes:

(1) i'll investigate this if i come across an opportunity. With more important features on my roadmap this goes pretty low priority wise, but it may happen.

(2) is already in, though there's no menu item for it. Hit the [pause] key to make the editor semi-transparent. Then, i scale what i want to trace behind in a picture viewer or browser and place one of the canvases abovoe it. 

(3) Something like this is planned for. Though, may i suggest not trying to fit the full range of character animations in the same session? Even if the tool allows for up to 256 metasprite animation frames in a session, it's not recommended. It becomes a lot easier to manage if breaking it down to one or a few moves per session. 
Once animation features are in, it will be *a little* easier to manage large collections in a single session, but i will probably still recommend to break it up. 

(4) A scanline event emulator is planned for, but a bit down the priority list.

5) This is the artists' job, not the programs - It requires artistic consideration and intent to make such decisions, IMO.

6) i feel like this issue can be circumvened if you treat the logo as one asset for one session file, and the menu choices as one asset for another.  It's sort of the job of the NES program to put them together on-screen, and would bring better results than trying to mash it all into 256 tiles. If fitting it into 256 tiles (a reasonable target budget) still, it's better to design/draw/scale it with artistic means than trying to lossy-compress it. Lossy compression would just increase the amount of work that needs to be done to repair it, IMO.

(7) is already in. Use the bitmask toggles in the CHR Editor to draw/bucket/rotate/flip and most of all paste the 2 bitplanes individually. This way, you can merge and split graphics for use as 2bpp or "faux" 1bpp.  

When i convert 2bpp assets to layered 1bpp assets, i usually have at least 2 instances of NEXXT up. One for the source, then paste it to the desired bitplane of the destination instance. 
Note that most CHR Editor tools work on a selection bigger than what is viewed in its tile canvas. You can paste a full sets' worth of 1bpp data if you want to.

First of all, thank you very much for the prompt response, I would like to make a couple of considerations on two points of your return, since I feel that I have not been able to correctly express what I was trying to say, causing confusion.

Regarding point (5), I do not pretend that the application resolves my designs, so to speak, but to be able to take more advantage of a tool that already exists.

Currently, if I need to adjust my designs to a space constraint using lossy compression, the only way I can do it is by adding extra data that prevents it from taking up more sprites than I can spare in this process, the problem with this is that if they are not different enough from what I am compressing, they are optimized with the rest of the image, causing me to repeat this operation an infinity of times.

In conclusion, this process requires a great deal of manual correction, so I don't think it does the work for me, but it helps me know where to put my eyes when starting to make the necessary simplifications to adjust my projects. to the limitations of the system, so if you could define the lossy import being able to configure from the beginning "X" number of sprites, it would significantly reduce the workload of many artists.

(7) Actually, the problem is not to do it, but to do it manually, I mean, to achieve this effect, just load the CHR in any image editor and superimpose one part of the tileset on the other using a slight transparency in one of the layers , to achieve the mixing effect, taking into account the blocks where one or another group of attributes will be used, of course.

But after the sprites are mixed, it becomes a real headache, putting together the final title screen, because the more data the layout contains, the more difficult it is to find each sprite and put it in its proper place with the correct attributes. .

Although in any case I am aware that this is my most unreal request, so I understand that it is not taken into account, I just wanted to clarify my point, greetings.



Just wanted to get back to you and inform that (2) is now exposed in the Window menu, following the update to 0.14.1.  I'll reply to the rest when i've read it one more time and made sure i've understood your usecase.


Hi again. I think i've understood. We seem to have a confusion of terminology in the communication. I was thrown off course by the mention of sprites - In NES graphics terminology, sprites strictly refer to the 64 hardware objects that are freely moveable on-screen. It seems like you mean importing background tiles, not sprites?

If that's the case, i believe what you ask for is already in NEXXT (and NESST). Se my example below. 
First, i have this fully populated scene, just for comparing the difference: 

So, i know this image works, but let's say i want to try to make it work in 64 tiles. Then i go to [File > Import > BMP as nametable in n tiles...]

This will throw a prompt box where you can fill in any number between 0 and 256. I took the preset 64. 
And here are the results:

If this wasn't what you meant, let me know!

That's exactly what it's about, sorry for the confusion, I'm self-taught in everything.


No worries! I should've thought about it another round before answering the first time, but for some reason it didn't occur to me this was what you meant. 

Throwing my 2 cents in here since there's already a thread for it. Is there a plan to allow for displaying the tileset in 8x16 mode when using 8x16 sprites? It's certainly not a dealbreaker that it currently doesn't, but it would make working with 8x16 sprites and making adjustments to graphics much easier. As of now, I usually refer to an instance of YY-CHR in tandem with NEXXT while building sprites so I have a better visual guide as to what's going on


I think i need further definition to be able to answer that. Do you mean that tiles would be represented on top of each other in the tileset as well, instead of the actual memory layout?

NESST & NEXXT has these 2 actions for drawing tiles as-if, and then putting them in order as NES PPU would expect them. Do these actions solve your problem, or would you still want something else?

Yeah, some screenshots might help clear things up

Here is a sprite of a snake with the tileset as it is in the ROM. The tileset is interleaved so it works in-game, but it makes the tileset view difficult to look at.

When I 8x16 deinterleave, the tileset view becomes legible, but the metasprite view is broken as a result.

It'd be nice to have an option where the metasprite and tileset views match each other when making 8x16 metasprites so it isn't necessary to keep toggling back and forth.


Ahh, that makes it perfectly clear. Thank you. Yeah, something like that should be possible to do. I'll probably make it a behaviour that's possible to edit and save via the configuration window, or possibly expose it as another toggle button directly. Probably going to take a little while to get it done bug-free but i'll put it high on my list.

Forgive me for making this inquiry through this medium, but I did not want to open a thread for a trifle.

In the original NST, I could export the attributes of my layout by doing the following:

But NEXXT, I can't find anything similar that only exports the hexadecimal data of the attributes, is there any way to perform this action?


There was a bug in one of the previous versions where these actions you're looking for didn't perform as intended.
This may be the source of your troubles. 

This has since been fixed, but i don't remember in which version, so be sure to download the latest. 

In either case,  you'll find the corresponding action under File > Canvas (.nam or .map) > Save screen as ASM ( or > Save screen as C header).
The options to toggle saving nametable data and attribute table data on and off is in the + options submenu, just below. 

I always keep my version of NEXXT up to date and I had already tried what you mention, but when I set up the file to export that data, the resulting file only contains this:



const unsigned char n01[0]={ };

Would it be possible to consider in the future a function to be able to copy this information to the clipboard, to make it more accessible?


That does seem like a bug. I'm not able to reproduce it, unfortunately. 
If you provide the session file, i can have a go at solving the mystery. 
In case you prefer to do it in DM:s, my discord ID is FrankenGraphics#3272

It's certainly possible to have a look at expanding some clipboard actions in that regard. I can't say when that might happen, but it's already an item on my todo list. :) 

It's strange, I can't reproduce the error, both the day I reported it and today when I sent the message it failed, moreover, before replying this morning I re-downloaded the application to make sure and even though I restarted the program a couple of times, configuring it to export only the attributes, the output file only contained what I mentioned. I really don't know what's going on.

Hi 'Franken Graphics' i have a suggestion, its possible to port "Nexxt" To Android?


Hi! As mentioned in the other thread, unfortunately this isn't possible for practical reasons.