[Doom64hunter]

Bump.

Another bug I found is that, if you try to export multiple tiles, and there's an empty space inside a range of tiles, exporting will simply stop at that space, rather than exporting all selected ones.

[Hudson]

This. Looks. Incredible.

Would you happen to have a link handy for a download? You are amazing.

[Dzierzan]

https://m210.duke4.n...rt-files-editor

[Mark]

I am viewing some art files and I see different solid colored blank tiles. Purple, black, blue, orange. Is that something goofy with the art files I loaded or is there some significance for that in Bafed?

Never mind. I loaded them in another editor and for some reason those blanks are colored in textures. Whoever put those art files together messed up. If I click on the black or purple the tile viewer shows blank. But the orange or blue show in the viewer as those colors.

Attached thumbnail(s)

• 

[m210®]

Build ART Files Editor v2.1 is released


* Export to DEF feature
* Config file (saves settings and last folder between sessions)
* Save all button/hotkey (saves open art and dat files)
* Shift tile left/right buttons/hotkeys
* Select all button/hotkey
* Ion Fury ART support
* Cryptic Passage AR_ support
* Signed int checksum
* Automatically open surface/voxel/palette DAT if found
* Open DAT files shown in the title bar
* Move tile browser to the top when new ART is opened
* Fixed view/surface cloning bug
* Fixed batch exporting if one of the tiles is empty
* When batch exported, tiles will have their tilenum in the name
* Fixed importing order of files with numerals in names
* Fixed toolips drawing behind canvas
* Other GUI changes

[fgsfds]

2.1 was reuploaded, exe version is now included too.

[Danukem]

Was the bug fixed where the tile offsets get erased when you import? I hate that when I'm replacing the art for a character, and I have to manually add back in all the offsets again. It worked correctly in the initial release and then got broken after that.

[Doom64hunter]

Trooper Dan, on 02 July 2020 - 10:21 PM, said:

Was the bug fixed where the tile offsets get erased when you import? I hate that when I'm replacing the art for a character, and I have to manually add back in all the offsets again. It worked correctly in the initial release and then got broken after that.

Doesn't seem like it, and copy-pasting also doesn't preserve the offset.

The other changes are great though, thanks a ton!

[fgsfds]

Not sure if it can be fixed for copy pasting, but I fixed it for importing. Wait for the next version.

[m210®]

Doom64hunter, on 03 July 2020 - 12:56 AM, said:

Doesn't seem like it, and copy-pasting also doesn't preserve the offset.

Because you can copy the tile from a photoshop and paste it to bafed, so the photoshop doesn't have the offset info

I just could to save an old tile offsets after pasted.

[m210®]

The new version of BAFed has been released.
* File list
* Drag-and-drop ART files
* Last opened files submenu
* Option to always fill tile in viewer
* Option to show tile borders in viewer
* Asterisk for changed files in the title bar
* Scroll wheel support for spinners
* Export to DEF (texture)
* Keep parameters after replacing (importing or pasting) a tile
* Integer zoom
* Fixed incorrect scroll bar behavior after resizing a window
* Fixed animation not resetting

[Jblade]

Nice, biggest issue I still have so far is I can't paste tiles directly from my art program into the art file without it removing transparency since I assume it auto converts to the Duke3d palette (which has 2 identical pinks so it's automatically changing the colour to the incorrect one) Any chance you can eventually add an option or toggle so it doesn't try and autoconvert? Also copying a tile to clipboard and pasting it into a program auto converts it to 16bit or whatever so the pink colour gets lost and replaced with black when I paste it into another program. Dukeres doesn't do either of those things which is the main reason I haven't fully switched yet.

[Seb Luca]

The editor that I use. GG !

[Doom64hunter]

Jblade, on 15 July 2020 - 11:52 PM, said:

Nice, biggest issue I still have so far is I can't paste tiles directly from my art program into the art file without it removing transparency since I assume it auto converts to the Duke3d palette (which has 2 identical pinks so it's automatically changing the colour to the incorrect one) Any chance you can eventually add an option or toggle so it doesn't try and autoconvert? Also copying a tile to clipboard and pasting it into a program auto converts it to 16bit or whatever so the pink colour gets lost and replaced with black when I paste it into another program. Dukeres doesn't do either of those things which is the main reason I haven't fully switched yet.

Neither of these are happening to me when using GIMP, at least when copying to and from an RGB PNG with transparency.

BAFed automatically converts transparency to color index 255.

EDIT: However copying from a 256 color indexed image with pink index 255 background color does indeed result in BAFed importing an image with a pink background, instead of a transparent one.

[Kyanos]

2 cents for free.

It should use the index only for importing 8bit art and ignore colors completely, or maybe at least it should be an option.

[Doom64hunter]

With 2.1+, newly created ART files are apparently saved with the "BUILDART" header format.
This is the same header that was used for Ion Fury's art file, and prevents these files from being opened with BAFed 2.0 or lower, or any other older ART file editor such as Dukeres.

Older eduke32 revisions will not recognize this format, as will DOS Duke3D or other ports. Is there an option to disable this? Apologies if I'm blind but I didn't see it.

EDIT: Apparently it is enough to remove the "BUILDART" string from the start of the file to make it recognizable by other ports or editors.

[Truck Stop Santa Claus]

made a vid on this pregame. I really am a fan
https://youtu.be/oNWDGL3ToRE

[MC84]

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?

[Danukem]

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?

I have no idea.

Does the size of the .art file grow proportionally as each tile is added, or does it suddenly jump in size at some point?

[MC84]

Danukem, on 16 May 2023 - 11:33 PM, said:

I have no idea.

Does the size of the .art file grow proportionally as each tile is added, or does it suddenly jump in size at some point?

Proportionally... I deleted my latest batch of tiles and it went down to 23 Mb.. I guess the alternative is to define the tiles using a .def file right?

[Danukem]

MC84, on 16 May 2023 - 11:49 PM, said:

Proportionally... I deleted my latest batch of tiles and it went down to 23 Mb.. I guess the alternative is to define the tiles using a .def file right?

Yes, and I'm assuming they are already in or close enough to the palette or you wouldn't have put them into the .art file initially.

Your choices are:

https://wiki.eduke32...romtexture_(DEF)

and

https://wiki.eduke32...ki/Texture_(DEF)

But if you use texture, then you want to add the (undocumented) indexed token so that they will work with pals. EDIT: I don't know why but the forum refuses to include the closing ) in the hyperlinks which makes them not work, but obviously I am referring the the tilefromtexture and texture DEF commands

[Phredreeke]

Use the tllefromtexture command to define NEW textures. Texture is just to define a higher res replacement over an existing tile.

[dwtietz]

Just my personal preference, but I can't stand def'ing in tiles, and I only do so when I need to (like with skybox tiles). Def'ing in tiles is slow as Hell to process during game load time and it makes a "finished" product's file structure look like a dumpster fire. I like to pack as many tiles away into art files as I can, and the only real caveat I've encountered is to not let an art file grow any larger than about 120 MB or so; it'll still work in the game, but BAFed might not be able to properly display some, or any, of the tiles contained within it after you close it and try to open it again later.

[dwtietz]

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?

I don't think I've ever really encountered any issues like this before, but I'll admit that I don't pay particularly close attention to the file size as I'm adding in tiles unless I know that the file is already large. I'd say that I don't really start watching until the file is at about 100 MB before I start adding in anything new, then I watch it quite closely.

One thing I am wondering, although I don't know off hand if it would make a difference or not... Are you converting the image to the game's 8-bit palette (without full brights) using something like GIMP prior to importing them into the art file? I don't really know if that would make a difference or not, but that's just something that I always do before I import new tiles into an art file.

[dwtietz]

Looks like the colour depth of the source image shouldn't be a factor.

I just took 20 large, colourful images and saved them in separate folders as 32 bit, 24 bit, and 8 bit colour depth images. I also took all three of these folder's contents and converted them to an indexed (8 bit) palette without full brights and then imported each of these 6 folders into individual art files, and there was no impact on the size of the output art files that were created regardless of the source image colour depths:

[MC84]

dwtietz, on 17 May 2023 - 11:13 AM, said:

Looks like the colour depth of the source image shouldn't be a factor.

I just took 20 large, colourful images and saved them in separate folders as 32 bit, 24 bit, and 8 bit colour depth images. I also took all three of these folder's contents and converted them to an indexed (8 bit) palette without full brights and then imported each of these 6 folders into individual art files, and there was no impact on the size of the output art files that were created regardless of the source image colour depths:

Test Results.png

Yes I'm converting them to indexed through GIMP prior to import.

To give a specific example, I have one HUD art tile that is an indexed .PNG sitting at 8.42 kb. The current .art file is 36,834 kb prior to import. I import the HUD tile, re-save the .art file and it's now sitting at 37,165kb - a 331kb increase for an 8.42kb .PNG file.

Just to be extra certain, I ran that same .png file through Henrick's PNGoptimizer but it still leads to a bloated file in BAFED... I might just start with a fresh .art file, because all of my other art (most of it in the 128x128 range) doesn't have this effect on the .art file size.. (ie I've got some .art files that are pretty packed, but they come in at only 3-4mb....

So I guess when 3-4mb is my point of reference 35mb for a single art tile seems excessive..

[Danukem]

Phredreeke, on 17 May 2023 - 04:50 AM, said:

Use the tllefromtexture command to define NEW textures. Texture is just to define a higher res replacement over an existing tile.

Yes but you can put much smaller tiles in .art file and then use texture with indexed to replace them. The advantage of this is when working with large textures, the in game xrepeat/repeat/zoom is based on the tile size in the .art which makes it more manageable. Not as important if we are only talking about hud stuff though.

[dwtietz]

MC84, on 17 May 2023 - 12:59 PM, said:

Yes I'm converting them to indexed through GIMP prior to import.

To give a specific example, I have one HUD art tile that is an indexed .PNG sitting at 8.42 kb. The current .art file is 36,834 kb prior to import. I import the HUD tile, re-save the .art file and it's now sitting at 37,165kb - a 331kb increase for an 8.42kb .PNG file.

Just to be extra certain, I ran that same .png file through Henrick's PNGoptimizer but it still leads to a bloated file in BAFED... I might just start with a fresh .art file, because all of my other art (most of it in the 128x128 range) doesn't have this effect on the .art file size.. (ie I've got some .art files that are pretty packed, but they come in at only 3-4mb....

So I guess when 3-4mb is my point of reference 35mb for a single art tile seems excessive..

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.

[MC84]

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

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.

It's beyond me but I suspect that something like that might be the case!

[Reaper_Man]

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.