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:

(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:

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.

Hi!

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!