Garhoogin
Expand common file formats
I just wanted to suggest a couple of additions to the list of common file extensions that'd work nicely. Right now the lists in filecommon.c only include .pal.bin when it comes to GRIT's raw formats. It'd be very useful to also add:
- .img and .img.bin for Tilesets/Characters
- .pal for Palettes
- .map and .map.bin for Screens/Tilemaps
This would enhance compatibility with GRIT-generated files and those used with NightFox's Lib. Trying to open these right now is a gamble on whether the app assigns the right file type to each file. As it stands there doesn’t seem to be a way to specify how a file should be opened, so perhaps an “Open As…” option could be added in the future?
As a side note, I actually tried to compile the app after adding these, and got the following error:
(Link target) ->
LINK : fatal error LNK1181: cannot open input file 'C:\users\patri_000\Documents\tcc\asm\lib\msvcrt-light.lib' [Z:\NitroPaint-2.9.6.2\NitroPaint\NitroPaint.vcxproj]
Apparently some specific msvcrt-light.lib is required? Not sure where I'd find this. In general, how difficult do you reckon it'd be to refactor the app for use in Linux? It's pretty much Windows-only right now, although I guess Wine is an option.
Hi,
Thanks for taking the time to write about this. I'm glad you find it useful, and would be willing to add these file name suffixes to the detection list. And yes, there currently is no "Open As" menu command, but I may possibly add this back in.
As for msvcrt-light, I'd forgotten I had the project set up to reference it at that specific path. You should be able to obtain a copy of the library here: https://www-user.tu-chemnitz.de/~heha/hs/msvcrt-light.zip/. While not strictly necessary to build, the build options used are set with this build in mind.
For Linux support... not any time soon. It should work under Wine (if not let me know!) without much issue. Over time I've made (slow) progress making some UI code more agnostic, but if you want something Linux native, I have a program ptexconv (https://github.com/Garhoogin/ptexconv) that incorporates the same color reduction core and is run from the command line.
I'll be busy tomorrow, but perhaps some time this weekend I can incorporate the additions to the file suffix list. If you need anything else, let me know!
Thanks for responding! I'll just wait for the next update since I'm not in a hurry. Still, was there an option to specify the file type to open in a previous release?
I was planning on mostly using NitroPaint for viewing/editing assets converted with GRIT since it's the most convenient way I've found, but it's good to know ptexconv is already an alternative for Linux. I use Windows as well anyway, so it's no issue.
As for testing NitroPaint with Wine; I checked it out and standard procedures like Open/Save seem to work fine, but 8bpp mode toggling seems to be somewhat bugged; the app crashes when trying to enable it while the tileset width is 44, or when trying to switch to a width of 22 while 8pp mode is enabled. For reference, I used one of the demo assets from NightFox's Lib that opens properly. This was tested on Wine-10.18:
Attempting to enable 8bpp mode at 44 Width:
Attempting to change Width to 22 in 8bpp:
That's pretty much the only technical issue I've seen so far though.
Ah interesting, I'll have to take a look at that then. It's very possibly not a wine-specific bug, so thanks for pointing it out.
In regards to a version without automatic file type detection, they do exist but are very old and predate most important quality of life features, and I don't think even supported opening raw data files yet.
Ptexconv is primarily oriented around constructing graphics data on the command line, rather than viewing ; so in that case, NitroPaint is the only solution I have to offer (unless you have others). As for why it's windows-only, I started this project a few years ago (2019 I think) and I was much less experienced in GUI programming, so built the app around the Windows GUI API for simplicity.
The core color reduction code should be platform agnostic now though, so a cross platform GUI could be written around it at some point.
Alright, so I've had time to catch up on some cleaning up I've been meaning to get to, and I've added the new file extensions support (https://github.com/Garhoogin/NitroPaint/commit/1d60b33f3e6585c89e47fdc1fa0581aad5427bf0), but am not able to reproduce the bugs you experience changing the bit depth and graphics size. I might have to wait until I have access to a Linux desktop with Wine some time next week to look further into the issue.
Alright, so I've had time to catch up on some cleaning up I've been meaning to get to, and I've added the new file extensions support (1d60b33), but am not able to reproduce the bugs you experience changing the bit depth and graphics size. I might have to wait until I have access to a Linux desktop with Wine some time next week to look further into the issue.
Appreciate it!
And I should have clarified; this bug happens when I use Wine but not when I directly use NitroPaint in a Windows VM, so I reckon it's likely related to Wine. Even then, the app in its current state should work fine by just avoiding using those specific dimensions when switching modes.
By the way, is there any particular reason .NCER files are supported but not .nce?
The main reason that no NCE support has been added yet is because they logically combine both the elements of an NCER and a NANR. The older code base was originally not able to accommodate this, but the newer design would. Pretty much now it's just because I haven't gotten around to it yet.
Good to know. I suppose just using .NCER and .NANR files for now is the best approach. Shame there's barely any way to mess around with those formats though.
Anyway, I'll close this issue since it's pretty much taken care of.
Are you writing a homebrew app that uses these formats? If so then NCER and NANR are probably better to use since they don't include the extra data used by the CAD software (extended attributes and the like, or a fake 2D mapping mode). I can look to add support for NCE files though, if that would be beneficial.
It's alright, I've just been exploring various options for sprite animations. It's easier to use NCE files for editing, but converting them into NCER+NANR files can pretty much only be done with the CLI converter right now, so I ended up looking for ways to make the process more straightforward. NightFox's Lib relies on raw binaries to cover spritesheets and palettes, but it doesn't seem to use any equivalent to NCER/NANR.
But I've also been looking into 3D sprites, and interestingly enough, using Squeezer to generate GUV files may be the way to go, although I haven't dug much into it yet. Still, that format certainly looks like it could be used with either 2D or 3D spritesheets. Do you think adding support for it in the future would be possible?
Dunno if there's any way to visualize it like an NCER file right now, but it'd be nice to eventually have our own alternatives to the proprietary pipeline.
If a file ties closely to the DS's graphics system, then adding it is a possibility. I'm unfamiliar with GUV files, so I would have to see documentation to know if that might be possible. If it doesn't relate well to the structure of an NCER (i.e. cell data bank, holding a collection of cells made up of OAM objects) then it would need a new editor.
For alternatives to the propriety formats, I've been working on some of my own, for my (currently private) library called Setosa. The formats are available in their tentative form within the program, but details are heavily subject to change. It implements currently an alternative for NCER, but none for NANR yet. These files use a binary block structure similar to NNS's file types, but with slightly less overhead.
From what I've seen of it, GUV (GL2D UVs) is just a format used to store coordinates and sizes. Squeezer can generate such a file when combining multiple images into one. At first glance it doesn't seem to have any particular dependency on the image being a texture, so using it for 2D spritesheets should be possible.
The BlocksDS tutorial on NitroFS gives a basic outline at the bottom:
https://blocksds.skylyrac.net/tutorial/intermediate/nitrofs/