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.
FrankenGraphics
Creator of
Recent community posts
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.
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).
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.
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.
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.
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.
- 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.