Invader

[ShikuTeshi 1,299]

So I'm unable to use the bitmap tool. Google wasn't much help besides telling me it's connected with zlib1.dll

[Kavawuvi 7,026]

10 minutes ago, ShikuTeshi said:

So I'm unable to use the bitmap tool. Google wasn't much help besides telling me it's connected with zlib1.dll

Thanks for bringing that to my attention. I've re-uploaded Invader with the new .dll.

 

Here is the missing .dll in question: libpng16-16.zip. You can copy this to the same directory as invader-bitmap.exe if you don't want to redownload the thing.

[ShikuTeshi 1,299]

I noticed Invader Bitmap doesn't like spaces. I'll have to rename the textures in this case.

But this is likely just due to having to specify a file name over bulk compiling a folder.

[Kavawuvi 7,026]

1 hour ago, ShikuTeshi said:

I noticed Invader Bitmap doesn't like spaces. I'll have to rename the textures in this case.

But this is likely just due to having to specify a file name over bulk compiling a folder.

I don't think that's an Invader issue. Are you using quotation marks for parameters with spaces?

 

For example: 

invader-bitmap.exe "vehicles\death vehicle of doom\bitmaps\death vehicle of doom"

 

[ShikuTeshi 1,299]

14 hours ago, Kavawuvi said:

I don't think that's an Invader issue. Are you using quotation marks for parameters with spaces?

 

For example: 

invader-bitmap.exe "vehicles\death vehicle of doom\bitmaps\death vehicle of doom"

 

You know what? Nope. I only had them around the bitmap. For some reason it didn't click with me.

[Kavawuvi 7,026]

Another update! Once again, this is just to invader-bitmap. Here are the changes:

 

16-bit color is now supported! This provides a lower-memory, uncompressed option for textures, thus cutting memory usage in half without compression artifacts. However, 16-bit color has much less color depth than 32-bit, and it has even less color depth if you use alpha. This can result in color banding as well as slightly different colors used in images.

 

For reference, here is how many colors you will get (with how many shades of each color channel you get):

• 32-bit without alpha: 16777216 colors (256 red x 256 blue x 256 green)
• 32-bit with alpha: 16777216 colors (256 red x 256 blue x 256 green) + 256 alpha
• 16-bit without alpha: 65536 colors (32 red x 64 green x 32 blue)
• 16-bit with 1-bit alpha: 32768 colors (32 red x 32 green x 32 blue) + 2 alpha (basically either no transparency or full transparency)
• 16-bit with 4-bit alpha: 4096 colors (16 red x 16 green x 16 blue) + 16 alpha

The following image contains two rainbow gradients: one as 32-bit without alpha and one as 16-bit without alpha:

 

 

The number of alpha shades will be determined based on the 32-bit version of the bitmap:

• If all pixels have 100% opacity, you will get the full color depth 16-bit can offer, 65536 colors.
• If all pixels are either 0% opaque or 100% opaque with nothing in between, you will get 1/2 the color depth, 32768 colors.
• If there are pixels that have anything between 0% and 100% opacity, you will get 1/16 the color depth, 4096 colors.

Note this applies to each bitmap, not the whole source image. If your source image contains bitmaps that have full opacity and bitmaps that don't, the ones that do have full opacity will still have 65536 colors.

 

To use this feature, pass --output-format 16-bit or -O 16-bit as arguments.

 

Note: Support for DXT compression and monochrome bitmaps are planned. Currently, only 32-bit color and 16-bit color are implemented for now.

 

invader-bitmap now writes the format used into the bitmap tag. This means that if you create a tag with invader-bitmap and choose to use tool.exe's bitmap feature, it will use the same format that Invader used. Also, I may make a version of invader-bitmap that reads this value if no format was passed as an argument.

 

[Kavawuvi 7,026]

Another update!

 

DXT1, DXT3, and DXT5 are now supported! These are lossy compression formats supported by Halo that can be used to compress bitmaps to very low sizes.

 

Here are the compression ratios you can expect:

• DXT1 (no alpha) - 8:1 (4 bits per pixel)
• DXT3 (explicit alpha) - 4:1 (8 bits per pixel)
• DXT5 (interpolated alpha) - 4:1 (8 bits per pixel)

Here is why you should NOT use this:

• DXT is lossy. You are trading image quality and detail for a lower file size, and this loss in quality is irreversible. Better compressors can lessen the impact, as can dithering (--dithering), but for most images, the compressed image will be inferior to the original.
• The detail loss from using DXT can be very high on low-resolution bitmaps. You will need to upscale the source image to a higher resolution to improve quality, and increasing the resolution increases file size, reducing the file size reduction you got from DXT.
• Modern graphics hardware will have no trouble handling larger uncompressed textures. Even the lowest end GPUs made today have 2 GB of video memory, well over the size of your map.
• Modern hard drives and even some solid state drives are now sold with over a TB of storage capacity. Your map's file size may only be trivial at best especially compared to modern games.
• Compressing your map to a .7z archive with the LZMA compression algorithm can allow you to distribute large maps with small file sizes.
• tool.exe can be patched to allow for larger bitmap sizes.

By using lossy compression, it is possible you are trying to fix a problem that isn't really a problem anymore while creating a problem that will always be a problem. Please consider using 32-bit color, or at the very least, distribute your tags as an alternative download to your map so people have an option to rebuild your map using 32-bit color bitmaps.

 

Anyway, here is what 32-bit color, 16-bit color, and DXT1 / DXT3 / DXT5 look like next to each other:

 

 

Note that DXT1, DXT3, and DXT5 have the same color quality and are not superior/inferior to one another. The only difference between them is in how alpha is handled:

• DXT1 does not have an alpha channel, thus it is half the size of DXT3 or DXT5. While 1-bit color-key transparency can be used with DXT1, invader-bitmap does not support this, and this reduces color depth.
  If you need support for transparency without reducing color depth, use 32-bit color, DXT3, or DXT5.
   
• DXT3 uses explicit alpha. This means the alpha, itself, is defined per-pixel, but the drawback is that you are limited to 4 bits (16 shades) per pixel. This means that there will be significant alpha banding for gradients, but things like the borders of shapes are preserved.
  If you want less alpha banding, use 32-bit color or DXT5.
   
• DXT5 uses interpolated alpha. The alpha is interpolated similarly to the color, thus alpha gradients won't suffer from the same banding problems as DXT3. However, the borders of shapes can potentially be blurred.
  If you need the alpha to be explicitly defined, use 32-bit color, DXT3, or 16-bit color.

Use --output-format dxt1, --output-format dxt3, or --output-format dxt5 to pick a compression format. If you ever need help on the syntax, use the -h / --help argument to list arguments or read the README.md file on GitHub.

 

[Kavawuvi 7,026]

Here's a small update:

• The .bitmap tag will be read for some of the values (format, mipmap count, etc.).
• The registration point is now set in the bitmap. I'm not entirely sure how to calculate this, so I'll be looking into updating this later.
• --input-format was removed. Instead, it will try all available extensions until it opens the bitmap.
• Bitmap sequences are generated. With 2D textures, this is primarily required for user interface widgets.

From this moment on, I will no longer be posting builds daily unless I'm fixing a critical issue such as a crash.

 

[Kavawuvi 7,026]

There isn't much to share today. I've just gotten in monochrome bitmaps, though these will require a later version of Chimera to function properly.

 

I'm considering updating the OP of this topic to reflect the current state of the project as well as have download links to the Windows build of the project. Linux users must compile from source for now, but from my experiences, this isn't hard provided you have the required dependencies installed. Also, since building my PC, nearly all testing has been on Linux, so you can be sure that if you compile it for Linux correctly, it will probably work better than the Windows build provided you're running it on a true Linux kernel and not WSL 1.

 

If WSL 2 ends up being easy to use and performs well (WSL 1 is not easy to use and performs poorly), I may start recommending people using that, too, but I'll still provide Windows builds for Windows 7 users.

[Kavawuvi 7,026]

Here's a small update

 

I added a new tool: invader-resource. This tool compiles bitmaps.map, sounds.map, and loc.map. You will need the HEK tags directory as well as a complete, extracted Halo Combat Evolved tags folder to use this. You can also use multiple tags directories like with invader-build.

 

There are a few applications for this:

• Smaller campaign maps, since some of the tags are now located inside of these maps rather than in the cache file
• Campaign maps that work across all languages of the game - I've built a d40.map that can interchangeably use any language assets provided you use a patched tool.exe to do this.
• Custom resource maps that retroactively apply to your maps (e.g. a 4K AI upscaled set of bitmaps)

 

Also, I changed the argument, --output-format, for invader-bitmap to --format.

 

Lastly, bitmap, sound, and unicode string tag compilation are now slightly more accurate. They should compile to exactly the same size tags as tool.exe would do.