itch.io

There are a number of ways i think you can do this.

A) using the right mouse button, drag a tile from the tileset onto the metasprite canvas. This tile is now added to your sprite at the position you drop it. This is great for when you want to add one sprite at a time.

B) Selecting one or more sprites on the list, you can click the "Dup" button just below. This duplicates selected sprites; whichafter you can configure their positions and Tile ID:s as desired. 

C) Going to Menu > Metasprites > + Options > + merge to existing data; subsequent Make [ctrl+m] actions will merge the newly made metasprite with your old one. Some positional rearrangement is usually in order straight after. 

(C) Sounds the closest to what you were describing, though I'm listing all of them in the order I tend to use them. 
And just in case, were you looking for something different than one of those methods?

Ahh, it's a little confusing i'll admit. Those options are only for text export. The category bar between saving as binary and saving as text is supposed to indicate that, but it's not super evident. Neither is it the first time this is brought up, haha.

Also worth noting; whenever a .map binary is saved; the last 4 bytes tell the dimensions of that map; counted in tiles. 
.nams on the other hand, as standardized by NES emulators, are always 32x30 - so 960 bytes for tile ID elements, 64 bytes for attribute cells.

Ah, thanks. The 'smaller than what i usually work with' size condition narrows it down where to look, and sounds plausible too.
I haven't been able to replicate it yet, though. 
Was the file you saved to also an .nss? or something else? 
Let me know if you encounter it again (though it sounds like having opened it in a new program instance may have flushed the issue away - which is good for you but troubling for me haha). 

Thanks for the report.

Access violation issue:
-With screen size, do you mean canvas size [ctrl+alt+n], or viewport size (eg alt+w etc)?
-What is/are the actions you performed right before getting the messages? Helper subquestions:
--if using the mouse prior to the errors, where in the interface (and presumably on the canvas) did you click, and with what tool / button combination?
--if using a command/menu action, which one(s)?
--the usual cause for access violations in the past has been trying to place something out of bounds, render something out of bounds, or there's a mismatch of bounds when redoing/undoing (shouldn't happen anymore, but mentioning it anyway just in case), and there hasn't been enough safeguards against it. There can be other causes, but if this rings a bell, let me know. 
-If you can send me the file(s) that have been having trouble so i can try to replicate it, that will problably help too. 

Grids:
Regarding grid sizes, 1 or 2 custom grid size is definitely something i can put on my list of potential todos. It's basically the list i draw from whenever I look for if nice-to-have features have grown more convenient to implement since last I looked (ui changes, code support, etc).

For multi grid clarity, they do a bit of contrast-separation when several are checked, but it's been on my list to make that separation a bit stronger for when lots of options are checked. Double-line is probably not going to happen, but i'll keep the suggestion in mind.  
I would recommend having 2 or less grids checked at a time as a habit; with the exception of screen/32x30 which doesn't get in the way as much. 

Some explanation of the current selection of grid sizes is probably in order.
Their primary incentive to be what they are is connected to nes specific hardware features; which you often find yourself needing to design around:
- 2x is the dimensions of an attribute cell.
- 4x is the dimensions of a byte element on the attribute table describing 2x2 attribute cells. They're specifically meant to help design around these limitations.
- 8x is just a less dense way to orient around such blocks. 
-the screen/32x30 grid has some hardware-fixed relations too. this is the exact size of 1 'nametable', knowing its limits is often useful to calculate stuff, and having it on has implications for optional rules for 4x4 and 8x8 metatile placement that is enough commonplace (like only lay down and count 'half' a 4x4 metatile at the bottom seam - programmers often find this more doable since on the nes you can't just expect it to overflow to the next nametable, since nametables are interleaved with attribute tables). 

A parser/exporter tool to compress maps using metatiles as a dictionary is planned for for v4.x, but it's as of now not available. 
Since there's quite a broad range of popular options people will want to compress their maps in, this might take some time. 
Some people have written their own parsers in the meantime, which is simpler when you only have to consider one game's expected input. 

Metatile sets are stored as text, either in the .nss file, or as separately savable .mtt / mt2 / mt4 / mt8 files. This makes them a bit easier to parse. 
.mtt indicates a set of any and all sizes, while the 2,4,8 indicates it contains just one kind of metatile. 

Some usage tips:
-nexxt can automatically generate metatile sets from existing screen/map content. Press Rebuild (warning: this will overwrite existing metatiles). 
-look for the clonestamp label; press the 'on' button. this will replace the normal tile placement tool with a clonestamp / metatile placement tool. 
Normally, you'll want 'snap' to be on as well, unless you want to place metatiles off-grid and then Generate a new set out of those placements. 
-right clicking a metatile on the set canvas will find and step through matches on the map. I often use this to compare and clean up; replacing one instance with another, if i have to make the set smaller. 
-Under the hood, nexxt has no concept of a 'metatiled map'. This means you can move freely between tile and metatile placing without needing to convert to some other format, and you can even mix and match different metatile sizes for placement (hence the clonestamp terminology as far as placement is concerned). This is handy when constructing maps/levels, but it also presumes checking that your map matches a dictionary of metatiles at build time if you want to implement metatile compression. NEXXT is still lacking some would-be helpful functionality in that end step. 

I saw you mentioned RLE in the title. While there are circumstances where RLE on the NES can be useful, on maps it often quickly becomes more trouble than it's worth for slightly more ambitious projects, or things like scrolling/multiscreen levels, due to the limited cpu headroom for unpacking levels on the go. The exact threshold where it stops being helpful depends heavily on the game's design. Just thought i should leave a heads-up.

Using just metatile/dictionary compression is usually enough compression; while retaining random access, and stable cpu/mem footprint. 
Games that need to pack an extra lot into extra little sometimes do 2-factor dictionary compression, ie compress say 4 metatiles that commonly go together as a new keyword (sometimes refered to as a meta-metatile in the NESdev community),  but if you can avoid it it'll both be more performant and easier to complete. 

nexxtporter by Eigenvector32
https://github.com/eigenvector32/nexxtporter

A command line tool for extracting .chr, .nam and .pal files as you please from a NEXXT session (.nss). It can also generate .png bitmaps.

Putting this in your build instructions, you can make sure your NES project always has up to date assets from your working NEXXT sessions. This can allow for better version control than exporting assets manually from within NEXXTs GUI.

It turned out to be something simpler. In some cases nexxt manually prints out a 0 to a string to concatenate with other things, this was a case of mistaken condition as it turned out. :) 

It's been resolved (and the new line too), but will be a little while before i push a new version.

i'm having trouble replicating the bug with the extra 0 / overflow on the duration. could you send me a session file where this is exhibited on your end? feel free to send it to Larsson . Ellen86 [at] gmail . com 

Once i'm done with the next release, you'll find the temporary settings here:


And the permanent (startup) counterpart will be found in the Preferences; text export tab:

Thanks for the detailed report!

I'll try resolving the low byte operator- and overflow issue at my earliest convenience. 

Animation data was originally not intended to be included with single metasprites as the animation scheme is considered "opt in" and a lot of projects out there assume their own scheme, but i can see if i can include some kind of setting for that where it makes sense. That might take a while longer. 

Hi! Documentation and especially tutorials is lagging a bit behind, i'm aware and trying to do something about it as often as i can find the time to.

Sadly, there's only one of me, and since the project is free, i don't have the resources available to both develop it and make videos consistently. 

More videos are coming eventually, but in the meantime, i recommend:
-keeping up to date with the changelog.txt, where all the features are thoroughly introduced in a chronological order. It can take some searching if the feature is old, but it's essentially all there. 
-make use of the cheat sheets and keep them close at hand: look for the Cheat sheets folder. They're also available directly on the side bar in the itch main page. 
-read the other help docs (you can find them in the Documentation folder: especially hotkeys_main_editor and hotkeys_CHR_editor are important)
-join the NESdev discord and make use of the graphics-workshop and graphics-assistance channels there. There are several longtime users there who can help and i try to check by as often as i can to answer questions personally. It's become the de-facto hub for nexxt users. 
-there are a few 3rd party NES development oriented tutorials that mention NEXXT and how to do specific things. I wish there was more of that, but some do exist.  

And lastly, while strictly voluntary, i encourage longstanding users to join my patreon to help fund making the tool better / its documentation better. Sometimes, i also post specialized usage articles there, though the patreon posts are as much about nexxt as about my own graphical work. The patreon-associated discord is yet another space i monitor for personal user help. 

Short explanation:
This is indeed how NES palette attributes work.  Working around it is part of the NES charm.
The 2x and 4x grids help a lot with planning it out.

Long story:
Inside the NES, there's 2 kilobytes for background placement data, which covers two screens at a single point in time. 
So, 1 kilobyte per screen. A screen table is then comprised of two separate tables: the nametable, which says which tile index (name in official nintendo jargon) is used where. This covers 32x30 tileplaces, and takes 1 byte per cell, so 960 bytes. You then have a meagre 64 bytes left to cover the whole screen with palette attributes. That's one byte per 16 (or 4x4) tiles! The NES's solution to this is let 2 bits out of the byte (representing subpalette 0,1,2, or 3) cover 2x2 tiles (a quarter of the bits in a byte for a quarter of the area the byte must cover), so the highest possible palette resolution is still 2x2 tiles (16x16 pixels) large. 

Now, there are some cases where the NES's internal background memory can be circumvented to provide for more detail directly from dedicated extra hardware on cartridge - the MMC5 mapper is famous being able to provide a single screen of per-tile attribute data) - but in practice, 99.95% or something like that games never do that due to a number of intricate concerns. Even the ones equipped with MMC5, it's surprisingly rare. 

Per-tile attribute support is planned for in version 4.x if i ever get there, but it won't be default behaviour as that's not what the NES is typically known for or able to produce, and the only physically available mapper right now that can produce those results (the Rainbow mapper by Broke Studio) only has partial emulator support so far. MMC5 is out of the picture since there are no available sources for new mmc5 chips. 

in the NEXXT folder, there's a folder called defaults. if there isn't one, NEXXT will create one on startup. 
In this folder, place your own palette and rename it nes.pal
this is or will be the file NEXXT is looking for when checking the "use external palette" option.

Planned for future versions, there will be a 'system palette browser' that lets you pick system palette without having to do these steps, but that's for some other day. 

Hello! A linux version is unfortunately far away from happening - nexxt is deeply entrenched in a windows only GUI, and i simply don't have enough time to both continue development, and develop linux/mac forks. 

It might happen in the far off future, but i wouldn't make any plans based on that. 

For now, wine is the best option for linux users.

Hi! 8x8 attributes and banked tiles are planned for (wether mmc5, rainbow mapper, or anything else), but it may take a long while. 
I'm struggling to find the time/finances to do significant features at this time, so i might have to take the financing of version 4.0 to kickstarter. I'm working it out, so we'll see!

done! you'll find it in menu>patterns in the next version. 

Thanks! It seems that while most graphics editors settle for PNG-8 for indexed formats regardless palette count, at least Fireworks will optimize for the unusual PNG-1 format. It's plausible some other editors i don't know of do that too. 

I've added handling for importing 1-bit PNG images, it's going to be in the next release. 

Thanks! Which software saved the 2-colour PNG? 

(3rd part)

"Bug Report:"

thanks for reporting this. 
It turns out in this particular case, what happens is when you paste nametable to chr (nexxt accepting this is relatively new - it works by looking up what tiles the nametable references, and then copy those tiles to the new position in the tileset), having a copy selection larger than can fit 256 tiles will crash, because the copy buffer never was designed to handle copies larger than one tile set. I've increased the buffer to deal with 4x more tiles gracefully, and if you exceed  *that* it will simply warn you and not proceed. But this should be difficult to even encounter. 

So, this bug should be resolved now. 

(2nd part) 

Import Issues:

Please upload the dr. mario logo images that would not work here so i can analyze them

Thanks! I'll reply to just the issues i have a direct answer to for now, the others will require more research on my part.

"When importing the PPU to NEXXT, the desired screen is not always in the main "tilemap" sector. "
As of v3.0, you can select to import a specific nametable from a dump. 
Choose "PPU dump (options)..." from the menu, then pick your file as usual.

You will then be shown this dialogue. Pick the "nametable source" option that suits you best (likely "1 (@ $2400)" in your shown case).


CHR Import from NES ROMs:

Old versions of NEXXT (and nesst) assumed importing from an NROM game, even though it could import from some other mappers two, this held the interface back by always importing a pair of tilesets at a time. Not all games are organized that way. 

Later versions of NEXXT changed so you import 4k (256 tiles or 1 set) at a time. 
This also meant the right side field was redundant, and was repurposed:
-The left side is your NES ROM file, and "bank" chooses which set to load. 
-The right side represents a "set" in your current session, which is the target you're going to overwrite (if there's anything at all to overwrite, that is).

To insert both a background set and a sprite set into the same session file (usually it's just easier to keep them in separate sessions, but you can), you would repeat this action twice, first loading one tileset from ROM into set A, and then, another into set B on a second round of import. 

"No, I didn't know it was possible to import OAM."
As of v.3, it "kind of" is - but there's no dedicated editing surface for raw oam. 
Instead it will be interpreted as a metasprite, which will often be impractical, since the metasprite editor is designed to work with relatively small objects (a player character, etc). 

A proper OAM editor is planned for the future.

"Dr. Mario in the format used by MSB (it practically just adds FF at the end of each sequence"
At least this part can be set in NEXXT so you don't have to do it externally:

Thanks for the detaoled report!

I'm going to reply to roughly half the points at this time, to keep it managable.

• "Fails if the image has fewer colors than expected, is too small, or, as in the screenshot, for unknown reasons."
  
  I need more details. Let's begin with how it's failing. Common modes of failure are:
  
  -silently ignore loading the asset.
  
  -expected and designed warning messages (ie. it says something like "must be at least this size large", "must be a multiple of 8", "must be 4bpp or 8bpp").
  
  -system error message ("access violation", "division by 0")
  
  -freezing
  
  -crashing (meaning, exiting unexpectedly)
  
  Then, i'll need to know which filetype (.bmp, .png, ideally what bitdepth, what dimensions. In fact, feel free to attach the failing file). 
  
  
• "Navigation locks up when importing images, except for vertical scrolling with the mouse wheel, making it hard to see the result."
  
  [ Shift + Wheel] lets you scroll horizontally; this also works while locked in the import dialogue. 
  
  That said, i'll make a note to see if i can loosen up more modes of scrolling.
  
  Additional tip: I recommend opening the navigator prior to importing, for a good overview.  It can be a bit tricky to find a good space for it on screen beforehand, but it helps.
  
  
• "You can export the visible screen but can't crop the canvas from the visible area."
  
  Sorry, I did not understand what this refers to. Perhaps i should ask: 
  What is it you want to do?
  
  Meanwhile: you can export the whole map, you can export the visible screen, and you can export a selection. You can't import to a selection. You can make positive selections on the canvas, but you can't "cut out" a negative selection from canvas.
  
  
• "It's not always possible to access all the graphic content of an NES ROM."
  
  I'm not exactly sure what circumstances this refers to, but there are a few known limitations:
  
  NEXXT currently only looks for graphics in CHR ROM, but some games store graphics in PRG ROM (for CHR RAM based games). These circumstances often have one or two, sometimes both problems: 
  -The chr data is compressed
  -The chr data is at an unexpected offset. 
  
  NEXXT currently doesn't have the advanced controls to deal with these cases, in which case i would recommend extracting them in YY-CHR or game-specific extractor tools first. 
  
  
• "It would be ideal to import CHR directly from other NSS files. "
  
  I'll see if i can add additional methods for this. 
  There are currently two workarounds:
  -Method 1: Just open a second instance (shift + ctrl + n), open the nss there, then copy the CHR over to your first instance. 
  -Method 2: use the Pipelines Assistant (shift + ctrl + F8): link up another session or chr file to your session, and toggle "view / edit" ON. While you're in this linked view / edit mode, several sessions share the same CHR bank, and all of them have editing privileges. This is advanced use, and you should keep backups to minimize mistakes, but this helps you have 1 canonical chr set for several assets. 
  
  
• Option to share CHR between instances. (7)
  See above point, method 2.  
  
  
• "The Metasprites screen isn't prepared for some real NES sprite cases, as seen in the screenshot where Mario's hand appears in the opposite sector, and other objects can be outside the visible work area."
  
  Is that an OAM dump? The metasprite editor can load such cases, which is new, but it's not designed to actually edit raw OAM. That is for a future tool which focuses on OAM overlays specifically. 
  Ideally, metasprites shouldn't have such extreme offsets as in that GIF. 
  
  
• " The worst error occurs when the work area focus suddenly shifts to the Tileset when pasting screen data."
  
  If you can record this happening, that'd be appreciated.
  
  Without knowing, i'm maybe guessing it could be this:
  The rule of thumb should be, as long as there is a nt/map selection, that takes priority. If you deselect the map (can be done with either the deselect command or by shift clicking the tileset, for example) , focus is automatically restored to the tileset. 
  
  ----
  
  As a request, could i ask you to go back and annotate under each GIF what context each is supposed to refer to/happen in?

As an addition to the previous answer, if you're curious about the inner workings of the NES palette. The picture processor produces hue differences 30 degrees apart. It just so happens that both the closest colours to pure red are 15 degrees "off" in either direction, so you have a cold 'royal' red and a 'rusty red', but no lego toy red. 

The difference in the tileset you're referencing, and the red colours you can see in NEXXT, is probably because the two have been using different emulator palettes. 

Some background:
On the NES, there is no 'true' RGB interpretation of its system palette, because it's generated in the analogue domain in a wholly different way. So instead, you have all these different emulator palettes that are different persons' interpretations of what they wanted the colours to look like.

Some are worse than others in terms of accuracy, and it can be difficult to trace the internet genealogy of bad palettes. FCEUX standard palette is one such inaccurate palette, though, which has some strongly misinterpreted colours, including a really vibrant slightly brownish red that mismatches the vibrancy of the rest, and that just doesn't exist on a real NES, among other problems. I can only guess, but that could be a possible source of the red you've seen in the reference tileset.

Now, some hands-on tips:
If you want to replace the system palette in NEXXT, take your favourite palette from an emulator (a .pal file, should be 192 bytes large), rename it "nes.pal", and place it in the same folder as NEXXT.exe. The next time you start it, it'll use that palette instead of its internal one.

Some personal recommendations are unsatured v6.pal and fbx_smooth.pal, which are balanced, and often bundled with popular emulators. 

Sometime in the future, i'm going to make this process smoother by having a built in system palette browser, but i can't give a timetable. 

Thanks for the report! I've been able to replicate it. Seems to be true for the "from cursor" action too.

I'll have it fixed for the next update.

First time i've heard of it. Alpha mask is a relatively new addition to the bmp format header and nexxt does not support it.

If i had to guess, that other tool you're using is interpreting the bitmap and superimposing the mask in absence of one, but it's just my guess. 

Thanks for the report - i was able to replicate it. I'll have it fixed in the next update. 
Workaround for the time being: flip 1 tile at a time and rearrange them manually. 

Hi, and thank you. 

Long story short, i love snapped half-windows, and i've thought about it. 
It might happen one day, but it won't be soon, due to a few technical roadblocks. 

Long version:

-NEXXT builds on the same legacy GUI library as NESST, and it hasn't received updates since the 00s. As it turns out, maximized forms encounter often encounter weird performance issues when this particular library meets the two latest versions of Windows, so i'm avoiding a situation where those issues can surface.
-The ui was designed statically, ie there aren't any dockable modules to place within a parent window. This makes development easier, but transitioning to a docked fullscreen environment would require extensive rework of all the forms. There's also the design issue that nexxt/nesst are made with using multiple instances in mind, so it kind of works best with cascaded windows anyway. Split-window would be a nice compromise to that, but again, there'd be significant rework involved.

The fix to issue 1 is to port the project from Borland Builder to Embarcadero RAD tools (its direct successor) but that entails lots of work and a costly license. 
For the time being, i'm focusing on more high-gain, low-risk features until enough reasons to port it have amassed (this is also an if, rather than a when. I keep it in mind, but it must become feasible for me first). 

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

Unfortunately, the GUI dependencies do not support porting it to mobile devices or other OSes.

Not presently. The command line will only open files in nexxt, and if opening a bmp it will import and open it with some default settings. 
More specific command line options are on the roadmap, but there's still a handful of priorities before it.

It seems to already be in it. You need to go to Preferences (ctrl+p), pick the Export tab, select "ask metasprite name" checkbox, and click "apply and save".

I'll look into storing it in the config. Thanks for bringing it to my attention!

The action only refers to CHR, that is, tile/pattern data. Each NES game uses its own convention to store nametable data (the table  that holds which tile goes where on screen) in various ways.
This is outside the scope of NEXXT, which focuses on creating original assets for new games (even if it can be used partially for romhacking too). 

To give some pointers where to go next, i suggest using FCEUX to figure the nametable for the titlescreen out:
1) In fceux, load your game.
2) Go to Menu > Debug > Nametable viewer
3) In Nametable viewer, hover the mouse over some easily identifiable tiles. Go left to right with the mouse as you note down their tile ID:s in a notepad. 
4) Copy the string of tile ID:s from your notepad. 
5) Again in fceux, go to Menu > Debug > Hex Editor
6) select View > ROM file
7) go to Edit > search...
8) Paste the string. If lucky, there's a match in ROM. Now you're very likely to have found the spot in the ROM where that nametable data is stored. You can compare the surrounding hex values with the contents of the nametable viewer to make sure. 
9A) If you're extra lucky, it's a raw nametable without any compression. In this case, you can use fceux hex editor to directly insert .nam data from NEXXT into the rom here. 
 9B) It's also common for title screens to be RLE compressed (or other compression method). Then you'll often find that a row of blank tiles is denoted 00 00 20 or some such, to save space. (00 is the escape character, 2nd 00 the actual character to put, and 20 (in hex) the number of same tiles to draw). 
10). Lastly, save a copy of your edit, and load that copy. You always need to reset or reload before seeing the changes in-game. 

Best of luck!

On another note; be aware that the "put CHR in game" action is Old Code(tm) that the original author of NESST implemented for his specific goals. It copies a whole 8KiB to the ROM, which usually is 4KiB more than you'd want in most cases. Now that i'm aware of this, i'm going to change it so that just the currently active (visible) tileset in NEXXT gets copied to the specified address in future versions.  

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.

v3.6.2 known bugs:

Critical bug while attempting to drag-swap a map portion larger than 1 screen out of bounds.
may corrupt work- and save data. Detailed description and troubleshooting / repair guide in this blogpost:

This bug has likely  been latent for years, but was discovered by a user just now. Will attempt a fix for the upcoming 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.