Future improvements

[Techokami]

Hey, I hope you haven't completely forgotten about this program!

I'm one of the people that worked on researching this format decades ago. I still have yet to actually make my own tool, but you've gotten pretty far, and hopefully you can get to the finish line and handle all files successfully!

Unfortunately there's a few problems, one of them is known, one of them is new, and one of them is a personal preference thing.

1. Missing support for compressed data. According to the repository readme, you've adapted existing Python code into C# for this program, so perhaps you can adapt this Python-based implementation of a decompression routine? Decompression support is huge; a bunch of files in Sonic Rush (like ac_itm_box.bac) make heavy use of this, and later games like Sonic Rush Adventure and Sonic Colors DS use it for storing cutscene sprites.
2. Missing support for linear graphics. So, the DS has two formats for graphics, tiled and linear. What this tool supports right now is tiled, that is everything is made of 8x8 tiles. But for sprites that are used in 3D scenes, like boss fights and special stages, as well as certain setpiece gimmicks, are in a linear format. This actually shouldn't be too hard to support; instead of drawing a sequence of tiles, you take the dimensions of the resulting image part and draw that as one big tile. So if the image part is 32x16, draw it as a 32x16 tile. Now, as for actually determining if an image part is tiled or linear... it's very likely to be one of the unknown values. I'm going to hazard a guess and say that it is probably Block 2 SubBlock 1's second longword. I suggest taking a good look at two files from Sonic Rush: ac_ene_eggpawn.bac and ac_ene_eggpawn3d.bac. The latter is used for the boat ride setpiece in Mirage Road Zone Act 2, it is in a linear format yet is otherwise identical to the sprites in the standard Egg Pawn's BAC file.
3. Color index 0 should be transparent. Some palettes will use pure black both as index 0 as well as a color in the image itself. This makes removing the background potentially destructive.

[follyfoxe]

Hi, thanks for reaching out! I have indeed, completely moved on from this project, barely remember the code. (Have been looking at it and I must say it is quite questionable)

However, I believe this is the perfect excuse for me to rewrite everything. Seems like a fun project to revisit! And now, regarding the issues you pointed out (Please keep in mind I'm not too familiar with the DS' inner workings)

1. I recall deciding not to implement compression support at the time, as I wanted to keep things simple. The implementation you linked me doesn't look that long (or scary) at a glance so I might give it a chance! And if I die whilst trying I can always rely on external libraries which support more format anyways.

2. I believe I understand what you mean by linear graphics, but do they also use color palettes or perhaps use raw color data, depending on some setting? Regardless, I'll take a look at those files when I have the time.

3. It appears I didn't handle transparency, but back then I didn't know any better. Thank you for pointing it out! Is color index 0 always transparent, or sometimes visible? If I understand correctly, there's a chance that the color at index 0 may be exactly equal to another color at a non-zero index, right?

Thanks for providing me with useful information; I'll see if I can put together a new version on my free time, can't promise anything though.

Hopefully this reply doesn't come off as too "explosive" but I am like that so why hide it.

Best regards, Folly :3

[Techokami]

For the second point, it uses paletted data with linear graphics. So you're basically drawing a single huge tile. For the third point, color index 0 is never actually drawn. Sometimes there's a color in the palette there, but it is never seen.

[follyfoxe]

For these last couple of days I've been working on a separate branch and all the points discussed should hopefully be working now. For linear graphics, using Block 2's unknown value seems to work fine, but further research may need to be done. There's also some other things I did

• Improved animation rendering: Animations are now framed, positioned and timed correctly (as far as I can see)
• Being able to zoom while previewing frames
• Being able to see the values that were read from the file in the properties panel
• Upgraded the whole project to net8.0

Additionally, while looking at files, more specifically at (ac_gmk_needle.bac) I saw that the part count value of some Frame Assembly (Block 4) subblocks was being read as a ridiculously big number (65537) So i decided to split the 4u value to two 2u words, and it seemed to give way more sensible values (matching the frames' Image Part count) But that leaves us with a brand new unknown value, and have no idea what it might me. For other files it's usually at zero, so reading it as a 4u didn't make any difference.

But I digress, just now I've released a new version with all of these changes. Please take a look If you have the time, I'd love to get some feedback!