Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(3 edits)

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?

(I apologize if my words may sound a bit distant, I considered that the text was too long, and I didn't want to overwhelm you, so I helped myself with an AI, to synthesize it)


Import Issues:

After recreating the problem, these are my conclusions:

Example: Reducing the Dr. Mario mini logo to 2 colors:

With BMP: Extending the canvas to 128x128 allows correct import with any configuration.

With PNG:

  1. Extra colors need to be added.
  2. Expanding the canvas is not enough.
  3. It only processes correctly with duplications and "pixel density threshold" activated.


Notes:

  • The image format affects the quality of the result.
  • The application may close if parameters are changed repeatedly after the first failure.


Workspace Navigation:

  • In retrospect, the Shift + Wheel shortcut is logical; I should have deduced it.
  • Horizontally, I have no issues, but vertically, at the highest resolution, I can't see the lower controls without hiding the taskbar. Even then, some options remain inaccessible.


Suggestion: A full-screen mode could be practical.


File Management:

When importing the PPU to NEXXT, the desired screen is not always in the main "tilemap" sector. This is not an issue when exporting in NAM, but it requires additional steps if you want to keep only that area in a session.


(This can become tedious at the end of a project, as you generally need to organize a considerable volume of alternative versions and backups of the main work, keeping only what might be relevant later, to make it more manageable.)


CHR Import from ROMs:

I admit part of the problem might be my difficulty in understanding the import tool. Here are some recent examples where I couldn't access the needed graphics:

  • Dr. Mario hack "NROM": Only the CHR of the sprites is accessible.



  • Dr. Mario (PRG1): I can only access half of the graphics.

  • In older versions, I never knew how to access the set of graphics shown in the capture.



CHR Import from NSS:

After the explanation, I consider the current options superior, especially because it sounds more practical to open a project from the explorer...


Is that an OAM dump?:

No, I didn't know it was possible to import OAM. I created a script that processes the animation code data of Dr. Mario in the format used by MSB (it practically just adds FF at the end of each sequence, so the code is identical to the game, with no compensation).

Note 1: Although the provided version has a couple of corrupt sprites and garbage data at the end, they do not affect the overall functionality and were corrected later.

Explanation: I used the closing code as a parameter to divide each sequence, as it was easier that way. The final corrupt data appeared because I had no way to determine if there were more sprite data than indicated in the main pointer table.


Note 2: I had to correct this outside the application, as it only allowed deleting the sprite content, not removing them. A similar issue occurred when reorganizing animations, opting to do it from my source code.


Bug Report:

I don't know how to replicate the issue, but it happened several times in NEXXT 3.0.0. I tried repeating my actions and intentionally making errors, but only by pasting the screen in the wrong place did I manage to crash the program.

It is worth mentioning that in this case, the system also crashed, something that had never happened before. I suppose it is related to how I forced the error. I attach the most relevant fragment of the video and a screenshot of the event viewer just in case.


If I'm not mistaken, that's all, I hope this information is useful! 😉

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:

I am continually amazed by the new features of NEXXT; they are simply fantastic! 🤩

Importing CHR from NES ROM: I apologize if my response is based on a misinterpretation of your words, but if you look closely at the screenshots, the graphic banks being ignored are not only sprites.

Additionally, it is quite common to find cases where the same CHR is used to store both background and sprite data.


Sonic NES | Castlevania 3Adventure Island 3

Lastly, I must clarify that I have not been successful in accessing the rest of the graphics with the procedure you proposed.

The format used by MSB: It looks promising, but I need to investigate further to understand it better, as I currently extract animations from the PRG ROM, thanks to the search tools provided by Mesen.

(2nd part) 

Import Issues:

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

Of course, here are the different variants of the Mini Logo:

Dr. Mario - Mini Logo (Images).7z [Mega]

Although it is unrelated, I also want to share a PowerShell script that I created with the help of AI. This script recreates the cleaning process I usually perform. Honestly, I doubt it will be very useful, but I am happy to have accomplished it 🤗

Clean_image (PS1) [Mega]

Thanks! Which software saved the 2-colour PNG? 

Fireworks 8

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. 

💖

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