I'll look into autonumbering duplicates. Thanks!

Edit: Fixed. Copypasted metasprite labels will append a unique number ("_1" for example) instead of "_copy" in future versions.

Reports for crashes, unreadable files, misc bugs, and unexpected behaviour may go here.

v1.0.

1) Missing visual update while scrolling through the "scrollwheel roster" and plotting a line on the tileset canvas specifically. 
Moving the mouse slightly corrects the missing update. Works as intended in the CHR editor, for comparison. 
Discovered right after release, this will be corrected in the next update.

2) Shortcut conflict between "Import Bitmap..." and "Toggle Blue emphasis" (ctrl+shift+B). 
"Import bitmap" wins. 

Workaround: While main editor is active, and any tab *except* tiles is open, you can simply press B instead. 
Fixed and pending a new release.

Hi! I think you may have better luck with a tool called I-CHR, which can take a PNG sequence and interpret them as NES resources. It even bakes an NES ROM if successful!  
https://kasumi.itch.io/ichr

NEXXT is primarily a studio for creating NES graphics in it, and its import features are mainly for moving static images between other softwares and it.
So,  while possible, it's quite manual, repetetive and inconvenient when I-CHR can solve this task in a single action. 

Thanks! That clears it up. 
The output *is* the intended behaviour. It takes the attribute byte of each 4x4 tile region on the map and outputs it, going left to right, iterated top to bottom. This results in 4096 bytes representing the entirety of the map. 

I'll look into an action for just saving current selection. Pressing ctrl+a once, that means the currently viewed portion of the screen. 

Additionally, the file helped me find another bug: It seems the status readout bar provides wrong data element on maps that aren't exactly 1 screen wide. Thanks for providing the opportunity!

I'm not saying i'm putting your judgment into question. Apologies if it came across as that. It's just that i need to narrow it down and double check to make sure what the problem is behind the phenomenon of it, so to speak, and where it may be located. 

Hm. The file link says "special stage", but the file i'm getting clicking on it is the one containing your custom icons. Strange. 

In any case. This is another possibility: A canvas size of 256*256 means attribute data equivalent to 8 by 8 screens, that is 64 bytes * 64 screens. Or 4096 bytes in total. 

The .byte emissions in your screenshot seems to be 16 byte statements (correct) * 256 lines. In other words, 4096 bytes. 

It would seem to me the attribute data is correctly sized. 

That is, Unless you want the attribute data for a single screen, rather than for the total of your session.

In that case, you (currently) need to copypaste a screen-sized selection over to a secondary instance of NEXXT, whose canvas size is 32x30 or 32x32, and then export that to .asm 

Let me know if that's helpful. Meanwhile, I'll put it in my todo list to look over more options that could make this process faster and more intuitive. 

As of v.0.22 (now uploaded), the menu action is more appropriately named "save canvas as ASM" instead of "save screen as ASM".

I'm still not sure what's going on there. When i try to replicate the problem,  i get consistent results: 64 bytes of attribute table if exporting for a single screen, 128 bytes for 2 screens, and so on. 
First step, make sure you're using "save screen as asm". The "+ include names" and "+ include attributes" in the options submenu only govern the two actions belonging to the same subsection below the menu divider.

If that still fails, i recommend you send me the session file so i can have a look at what's going on. If there's a bug, the file will help me point me to it. 

Yeah unfortunately Somewhere around 8 by 8 or more screens performance starts to scale poorly. Especially the Navigator is problematic so i recommend using it sparingly on such large canvases, until i've found good ways to avoid redundant calculations. 

That the tileset selection should be affected by this is more than just a performance issue, though. I'll make a note to look into that specifically. Thanks for the report!

It's unlikely at this time, unfortunately. However, i've had positive reports on it working decently on Wine for MacOS and Linux users.  

There has been a few attempts to port it in the past and they've been more or less abandoned by its fork maintainers. NEXXT and its predecessor is built on an antiquated  framework that makes it troublesome to port.  I would like to say i might turn to the issue once i have little else left on my roadmap, but making promises that far into the future seems unsound. 

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. :) 

Hi!
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. 

Hi Yves!

Yes it's true: when using the .map format, attributes are continous. (It sort of has to be that way because every engine (or programmer) tends to decide for themselves what the most appropriate way of handling it is. This can be done in cpu time processing (masking the redundant bits & merging from a large block of data; conditionally), or in data storage, and in several ways which is up to each project). 

If you'd like to store your screens as nametable chunks of 32x30, with complete attribute tables for each, i recommend scrolling to the edge of each new screen (easiest done via the navigator; F6) and then go to the menu; File > Canvas (nam or map) > Save as screen (32x30);
rince and repeat. 

For *viewing* attributes aligned to the 32x30 grid while you create, having both the "scr" button (hotkey H) and the "x4" button (hotkey L) down while Grid visibility is on (hotkey D) will align the attribute grid to the seam of each screen/nametable.  

Future versions might contain more methods to extract attribute data in various ways from maps, but it's sort of a mid-low priority feature since most programmers like to extract data their way anyway, often directly from the session file.

-Screen aligned x4 grids
-Flex-pasting tiles (paste to fit box selection boundaries)
-Exporting subpalettes to text with session name and set in its label

For more details, check the changelog of entry 0.20.0.

Unfortunately, this a bit out of scope both for NEXXT, and for my own personal expertise. 
The only further advice i can give would be join the SMW central community, and to browse through its resources: https://www.smwcentral.net/

Hi! I'm not aware of one at this time (which isn't to say there isn't one, but i haven't heard of it).  Unless this changes, i'd probably use a generic, well-featured pixel art tool like Aseprite in indexed mode, and rely on converting the assets instead. 

You can use NEXXT *somewhat* for simple 2bpp mode background graphics for the SNES too (for example mode 0 graphics, like SMW uses), but you can only edit one layer at a time then. And you need to supply your own system palette to replace the default one. 

YY-CHR has multiformat tile editing that works for the SNES as well, but it doesn't have the best layout capabilities, so it's virtually no good for level design. 

I might expand NEXXT to deliberately cover some areas outside the NES in the future (that doesn't act counter its main objective interfacewise), but for now all attention is on making it better for NES graphics use. 

That makes sense, and should be a minute. I'll add it to the next version! Thanks for the idea.

New in nexxt 0.18.3 - give unused (or duplicate) tiles an ID pattern.

a) menu > patterns > Find unused (or Ctrl + U)
b) menu > patterns > generate > Fill tiles with numbers
c) Deselect (Ctrl + Shift + A)  

Although this has been answered on my private discord, i thought i should address it here too in case someone comes across with the same question:

-For NESmaker users, i think the easiest method is using the .chr import feature instead
-Right now, if not wanting to do that, you can define an emulator palette (192 bytes)  as black, red, green, blue on the 4 brightness tiers and put it as nes.pal in NEXXT:s home folder. Then, go to palettes > system palette > external [...]. Then you can export that as BMP. 
-A system palette browser is on the roadmap. It's a medium-priority feature. (Examples of higher priority features is a metatile tool & a working metasprite animator).

Content:
-Opening the new Navigator [F6]
-Scrolling the camera with the navigator
-Double click to zoom in and out.
-Showing the new Screen Grid
 -Making a large, multiple screens spanning selection and performing a Cut (Ctrl+X) on it. 
-Using the camera box lines as a moveable guide for selections
-Drag-swap a large portion of the stage to another place
-Editing Metasprite Labels in the Metasprite Manager
-Moving metasprites, along with their Labels, up and down the list
-Quickly having a peek at new settings in the Preferences dialog (Ctrl+P)

Ah yeah, it's in the main folder of the new version, but i forgot one might read it *before* downloading! haha. 
Here's the excerpt. 

======

0.16

======

New features:

-------------

New Drag Selection actions: 

These 4 actions work equally on the tileset and screen canvas:

• Move selection box: within selection; shift + right mouse, then begin drag.
• Swap tiles: within selection; right mouse, begin drag.
• Move tiles: within selection; right mouse, begin drag, hold ctrl. 
• clone tiles: within selection; right mouse, begin drag, hold ctrl+shift.

These three are signified by the white selection box staying in place; while a gray "destination box" gets dragged around.

Dropping the destination box above the selection box cancels the action. 

"Scan" with active tile cursor:

• With a simple left-click on the tileset, if you begin dragging, you'll "scan" the tileset; dragging the "Active tile cursor" along.
• This is a useful alternative method for navigating the CHR Editor quickly. 
• Combined with the toggle button "Selected only", it's also an effective method to get a better understanding of how tiles are used and in what quantity on the screen canvas. 

Show/Hide pixel grid (CHR Editor): 

• Toggles the grid on/off in the CHR Editor.
• Shortcut: [Ctrl+G]

Improvements & fixes:

---------------------

Box selections stay positive:

• Expanding a box selection north or west would invert the selection coordinates which was slightly iffy and had many workarounds under the hood 

to prevent further weirdness.

• Now, selections remain "positive" no matter which direction you drag it; keeping the origin coordinate stable.  

CHR Editor pixel grid now easier on the eyes: 

• In the environment where NEXXT is made, the canvas which the CHR editor is painted on relied on a MS Windows-controlled theme.
  This worked well enough up until windows 7 in classic mode, but in later OSes like win 10 (i haven't tested win 11), this background & grid  colour was too sharp. It's now set to an absolute colour of #CFCFCF which is easier to look at when its grid is on. 

Find/Remove unused bug:

• Discovered and resolved a NESST-old bug where the tool would not detect if tile 0xFF was unused, because that's the initial tile value of all 64 entries to all 256 metasprite lists. Now fixed by ignoring sprite list items of unused status (this is signified by a relative Y position value of 0xFF as well).

Ctrl+X/Ctrl+V bug:

• In the context of the metasprite editor, These actions would often delete and forget CHR tiles in addition to working on metasprites.
  This is now fixed and each works respectively on the context of what was last clicked on, as was the intention. 

View Selected Only bug:

• Now correctly displays selection while the CHR editor is in 2x2 edit mode.

Swap Pattern tables in selection [Ctrl+Alt+X] improvement:

• Now accepts multi-selected tiles (ctrl+click)
• Now properly sets Undo.

Tileset tab:

• Double clicking on the big tileset now correctly opens the CHR editor.

Swap tiles - now in plural:

• It's now possible to swap a box selection of tiles.
• In 2x2 edit mode, you automatically swap a 2x2 constellation of tiles by this action. 
• The destination of the tile swap is now clearly displayed with a gray "destination box" around the cursor.
  (right mouse button + begin drag)

Status readout:

• The readout now updates smoother while moving the cursor over the screen canvas. 

CPU overuse bug:

• the cpu ran needless routines continuously when holding alt or ctrl+alt, which contributed to lag when working on the screen canvas. Now fixed. 

Errata:

-------

As of 0.15, window forms now snap to the edges of your screen. I forgot to include this in the changelog.

In this topic i'll post Voice-overed & subtitled video tutorials and feature trailers. Here's the first off the workbench.

Removing unused tiles, sorting the remainder. 
Note that the metasprite automatically re-indexes its tile references. This is new in NEXXT.

• Using Brush
• Using brush with quantize mode
• Using brush with brush mask
  
  
  

Pen / brush can be toggled with [B] in CHR Editor, or with [Shift+B] anywhere. 

Quantize mode can be toggled with [N} in CHR Editor, or with [Shidt+N] anywhere.

Brush Mask Editor can be opened with [M] in CHR Editor, or by right-clicking [Brush] button, or with [Shift+F4] anywhere. 

Using colour protect masks, example 1:



Using colour protect masks, example 2:



Observe that the mask buttons can be controlled in group if you click on them with modifier keys. 
Hold the mouse hovering over one of the 4 buttons to read the options available in the status bar.

Swap tile places.

Select tile by reference. 

Box selection.

In this thread i'll post some short GIF clips where elementary actions are showcased. 
I'll post one each post so they may be commented in subthreads. 

These GIF:s are the byproduct of semi-regular documentation sessions i hold on my Patreon blog and its dedicated discord. 

  Quickly selecting colour and subpalette:

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.

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?

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. 

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!

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.

This bug is now resolved

Oh, thank you so much for that report!! I knew there was a bug this context introduced somewhere around 0.7, but didn't figure it out and then other stuff happened. I'll have it sorted out in the next build.

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.

Thank you!

everdrive n8 always was a bit finnicky  and i've never gotten a good grip on the different firmwares and their varying degrees of support - if at all materially reasonable in your case, i would've recommended using everdrive pro or powerpak instead. But since you have the n8 and maybe not one of the other two alternatives, let's see if we can troubleshoot this one. 

First off, have you used the BNROM or the GTROM version of project blue?  The BNROM version has the widest compatibility and should be the one you find in the main download folder. 

Secondly, just to rule things out - what system are you using the everdrive n8 on? Original NES?  Toploader?  Something else? (If so, which clone?)

Thirdly;
There might be an off chance that your firmware version doesn't support the possibility that BNROM games can be 512kB:s large (which they can, but no historical game used a size that large and there's a slight chance that the firmware doesn't take the theoretical max into consideration).  It actually sounds like it, since a gray screen would imply a problem with loading program banks properly. It probably tries to run the program from the wrong memory bank which usually results in a cpu lock (nothing dangerous) or  even some nonsensical accidental loop where data is interpreted as program code. either way, no graphics are loaded into chr ram, no specific palette is loaded into the ppu, and you get the gray screen. 

This could either be resolved by trying to hack the current firmware to accept a new definition (a bit outside of my knowledge, unfortunately), or trying other firmware versions. 

Optionally as a last resort, you can add GTROM support to your existing firmware by following these instructions. be careful to have a pristine firmware copy somewhere as backup before you do any edits. You'll need a hex editor such as HxD.

https://forums.nesdev.com/viewtopic.php?f=9&t=18841

if doing these modifications, you should be able to run the GTROM version of project blue on your everdrive n8. I think it's tucked away with the level editor download?



(Note that we've had some few reports of the game locking up for some unfortunate n8 users. It seems to be down to electrical circumstance with their particular setup at home. Just something to be aware of. In their cases, they've been able to play the game for a while but it eventually locks. the n8 is, unfortunately, running on the edge of electrical stability. But you should probably have experienced similar issues in other games by now, in that case. This doesn't seem to be your particular problem. )

OPERATION PROBLEMS:
===================

The game doesn't play:
-Everdrive users
Update your firmware to an newer version. But also read "the game randomly locks up" below for the full picture. 

The game randomly locks up:

-Everdrive Pro users
Update your firmware.

-Everdrive N8 users:
there has been reports of recent firmware updates randomly locking up games on some (not all) setups. The general advice is having the most recent firmware, but if you keep experiencing problems, you might actually try using an older firmware version, until this issue is resolved, and be on the look for future updates on krikzz forums. 

KNOWN CRITICAL BUGS:
====================
None so far in the current release. But if you find a softlock, please take a picture or a screenshot and report it to me, and i'll see if i can find a good solution.

KNOWN NONCRITICAL BUGS:
========================
I died on the last boss.  On my next try, the different sprite parts of the boss got scrambled.
This bug seems to be isolated to if dying on a specific frame while the boss is turning.
Although unfortunate; there are a few ingame workarounds.
-getting a GAME OVER reinitializes the boss so it behaves normally again.
-if getting a GAME OVER intentionally is not acceptable, standing on the right hand side of it makes it an easier fight than to the left.

COSMETIC PROBLEMS:
===================
There are visual sprite glitches, especially on some of the bosses
-this is normal. On some frames, the game has too much to do, from the sum of features it contains. 

Some NES games are structured so that they will wait an extra frame for all updates to finish, causing half-speed slowdowns for the duration of the logic overflow. Some other games avoid this problem by accepting that the visual updates didn't get quite ready, typically leading to artifacts such as the ones you are seeing in Project Blue.  Ultimately, it is a hard design decision, and we went with avoiding slowdowns over avoiding visual glitches. 

I beat the game, but the end screen doesn't look quite like i expected it to
-we're using a rare but useful hardware trick on the end screen to bring out better yellows, tands, warm colours, and desaturated blues. It sets the R and G bits simultaneously. 

As of 2020, most emulators (and subsequently most clones) don't emulate this behaviour accurately, compared to a real NES.
As a result, the visuals will vary more or less from emulator to emulator. Some emulators have fairly passable, if different results (most versions of mesen, for example look acceptable to me, even if it's not exactly as on the NES), while others are quite off the mark (all versions of fceux, version 0.9.8 of mesen, among some others). 

We've been informed that the makers of the AVS console are aware of this and have a fix planned for their next firmware update.