[MC84]

Reaper_Man, on 18 May 2023 - 01:19 PM, said:

... You can test this by putting 1 of your large images in the first tile position, check the file size, then move it to the last tile position, and see if the size is different.

Or really, just use the DEF file format and texture / tilefromtexture your assets. It's superior in every way, weird personal hangups about "how the filesystem structure looks" included.

I quickly tried this and in both instances (first and last tile position) the .art file jumped from 3kb to 334kb, for an 8kb file. I think I'll just go with DEF approach unless M210 is able to find a solution in the near future. But if no-one else is experiencing this issue then the problem could be something on my end.

[Reaper_Man]

Out of curiosity, what were the dimensions of the tile you tested with?

[MC84]

Reaper_Man, on 18 May 2023 - 01:37 PM, said:

Out of curiosity, what were the dimensions of the tile you tested with?

777 X 437

[dwtietz]

MC84, on 18 May 2023 - 01:33 PM, said:

I quickly tried this and in both instances (first and last tile position) the .art file jumped from 3kb to 334kb, for an 8kb file. I think I'll just go with DEF approach unless M210 is able to find a solution in the near future. But if no-one else is experiencing this issue then the problem could be something on my end.

I don't think it's a problem on your end, or exclusive to what you're doing. The dimensions of the largest tile that you're adding is about the same size as the images I was testing with the other day where BAFed seemed be be storing roughly 3x (give or take) the amount of data than what should have really been required to store them.

[Reaper_Man]

Not sure how you figure that. If the image is 777x437, and each pixel is stored as an 8-bit value, then this image is stored in ART would take up ~331.5 KB, which aligns with what MC84 is seeing.

777 pixels/row * 437 rows * 1 byte/pixel = 339,549 bytes

[dwtietz]

Reaper_Man, on 19 May 2023 - 04:52 AM, said:

Not sure how you figure that. If the image is 777x437, and each pixel is stored as an 8-bit value, then this image is stored in ART would take up ~331.5 KB, which aligns with what MC84 is seeing.

777 pixels/row * 437 rows * 1 byte/pixel = 339,549 bytes

Ok, yeah... That adds up. I hadn't broken down the math requirements for storing the data. I was just looking at the face value of 2 MB of 8-bit image data in the png file format being transformed into 6 MB of 8-bit image data storage after being inserted into an art file. But yeah... these numbers make perfect sense.

[Reaper_Man]

That's because the PNG file format is infinitely better than an image storage format written by a high school kid in the early 90s, and one more reason that loading image data at runtime via tilefromtexture is a better method on basically every front.

[jimbob]

not sure if you take requests, but i'd like to set the darkness from within bafed, so i dont have to extract, reshade, import, test.

[Doom64hunter]

MC84, on 16 May 2023 - 10:43 PM, said:

I'm running into some unexpected behaviour - I've been importing a bunch of HUD artwork, all scaled at 777 x 437 pixels. The total filesize for the .png files come to approx 1.7 megs.... yet once imported into BAFED the .art file is over 35Mb?... Has anyone run into this issue before?

dwtietz, on 17 May 2023 - 02:15 PM, said:

Interesting. Even with my tests earlier today, I absolutely expected there to be some overhead when I imported an image that was already 8-bit since it stores additional information about the tile's image, like animation settings, x/y offset values, etc. So while I did expect the imported images to turn out being larger than the original source file, I was quite surprised to see that the 2MB of combined image files had inflated 3 times as much to being just over 6 MB. The dimensions of these test tiles were much larger than I would actually use, but still... I didn't expect to see it grow as much as I did.

Maybe the file structure has something akin to allocation units, and some image widths or heights still end up taking a lot more space than is actually contained in the image data by padding regions of the file with filler/junk data? I don't know for sure... Just a guess as to what might account for that.

Reaper_Man, on 18 May 2023 - 01:19 PM, said:

Bit depth of images or anything like that isn't really taken into account, as all image data stored in the ART file is 8-bit pixel data.

The additional bytes come from other array data of how the data is stored - tile dimensions and animation type and other fun stuff like that.

If I had to guess, what's happening here is all of the tile sizes are being padded to conform to the largest tile in the ART file. So for example if you have 255 tiles that are 8x8 and 1 tile that is 512x512, all of the tiles are being padded to conform to the max 512 x 512 size. That shouldn't be what it's doing, that isn't how the actual ART format is structured, but BAFed has some issues and this may be a bug or oversight. You can test this by putting 1 of your large images in the first tile position, check the file size, then move it to the last tile position, and see if the size is different.

Alternatively, you can setup extra ART files with just your large HUD tile ranges. It's a myth that ART files must be 256 tiles in size, they can be basically any length you want. That way, if BAFed is padding out the tile dimension array, it will only be a few dozen tiles instead of 256 that are affected.

Or really, just use the DEF file format and texture / tilefromtexture your assets. It's superior in every way, weird personal hangups about "how the filesystem structure looks" included.

No, the added size is not because of padding or metadata. The answer is very simple:

PNG files are compressed, ART files are uncompressed. Try resaving your PNGs as BMPs and observe that the filesize of the uncompressed BMP matches that of the ART file:



This is entirely expected, BAFed is doing everything correctly here.

Reaper_Man, on 19 May 2023 - 05:39 AM, said:

That's because the PNG file format is infinitely better than an image storage format written by a high school kid in the early 90s, and one more reason that loading image data at runtime via tilefromtexture is a better method on basically every front.

This is incorrect. Using tilefromtexture for every tile generally results in worse performance, as the game needs to look up each individual file from disk and is forced to decompress it before being able to use it.

This overhead is skipped when using an ART file. This is why Fury makes use of them as well -- it's not just for obfuscation.

[MC84]

Thanks for clearing that up - I had assumed that using large tiles with lots of empty space (to save me aligning the HUD animations) didn't add any weight to the .art file, seeing as my PNG files didn't show much difference whether they were cropped or left with the transparency. But I tested out some BMP files and they most definitely were effected by the larger image size. So my .art file with 150 tiles went from 50Mb down to 15Mb... which is still pretty bulky but it's a hell of a lot better.