Welcome to Open Carnage

A resource for Halo 1 modding and tech, with unique means of rewarding individual content creation and support. Have a wander to see why we're worth the time! EST. 2012


  • Content count

  • Joined

  • Last visited

About Kavawuvi

  • Birthday April 10

Extra Information

  • Gender
  • Contributed
    $100 (US) to Open Carnage
  • Raffle Victor

Computer Details

  • Name
    Dark Citadel
  • Central Processor
    AMD Ryzen 5 2600
  • Motherboard
  • Graphics
    MSI GeForce GTX 1070 Gaming 8G
  • Memory
    32 GB [2x 16 GB] G.Skill Ripjaws V Series
  • Storage
    500 GB Samsung 970 EVO
  • Power Supply
    EVGA SuperNOVA 650 G3
  • Case
    Fractal Design Node 804
  • Display
    Acer G257HU smidpx 25" 2560x1440 60 Hz
  • Keyboard
    MAX Keyboard Nighthawk X9
  • Mouse
    Logitech M510 Wireless Mouse
  • Operating System
    Arch Linux

Recent Profile Visitors

73,265 profile views
  1. With invader-bitmap now supporting every bitmap format, I felt it was worth writing a small guide on the different bitmap formats. If you want a quick technical overview as well as some tips, I recommend looking at Shelly's spreadsheet, instead: https://docs.google.com/spreadsheets/d/18ZBzUGmH8F3bqB2-0dPa9nnOtVl_liT1cnNLZaHn92c/edit?usp=sharing Meet the Formats When making a .bitmap tag, there are a few types of bitmap formats you can choose in Guerilla/Mozzarilla: "compressed with color-key transparency" or "dxt1" in invader-bitmap "compressed with explicit alpha" or "dxt3" in invader-bitmap "compressed with interpolated alpha" or "dxt5" in invader-bitmap "16-bit color" or "16-bit" in invader-bitmap "32-bit color" or "32-bit" in invader-bitmap "monochrome" (same name in invader-bitmap) There is a seventh option, but it it is only available for height maps if "disable height map compression" is not checked. This is called "P8 bump" which I'll talk about in a bit. For now, I'm going to talk about the file size limits as well as the compressed and uncompressed formats you can select manually. File Size Limits There are limitations when it comes to file size: Stock, unpatched tool.exe, limits to 384 MiB, while also resulting in issues with loading the map in Halo once you reach 128 MiB. Invader or a patched tool.exe is required for maps that exceed these limits. Stock, unpatched tool.exe cannot process textures larger than 16 MiB. Invader or a patched tool.exe is required for maps that exceed this limit. Halo is limited to 2 GiB of virtual memory. Even if LAA patched, Halo will still be limited due to being a 32-bit process. The primary reason for choosing formats is for space considerations. If you use 32-bit color for every bitmap, you will get the best quality, but the file size may be larger. If you use DXT for every bitmap, you will get the best file sizes but worse quality bitmaps. Uncompressed formats These formats all use explicit alpha and RGB. By explicit, I mean that each pixel's red/green/blue/alpha values are individually defined in the texture rather than being inferred from a set of interpolated colors/alphas. 32-bit This format is a no compromise format. You get the best image quality, but you also get the largest images due to each pixel taking up 32 bits. As a result, many of the stock textures are not 32-bit, and the game looks much better when re-making them in 32-bit. To put it in perspective, a 2048x2048 bitmap without mipmaps is 16 MiB - the maximum size bitmap tool.exe supports. With mipmaps, it exceeds that at over 21 MiB. This is the default format for newly created bitmaps in invader-bitmap. Pros Best image quality Explicit alpha Explicit RGB Cons Highest file size Environment maps require a mod (i.e. Chimera 1.0) to fix a bug of Halo making explosions blue Subformats A8R8G8B8 - 32-bit with alpha - This is used if not all pixels have 100% alpha. X8R8G8B8 - 32-bit without alpha - This is used if all pixels have 100% alpha, thus the alpha channel is ignored. tool.exe will also choose this if all pixels have 0% alpha, so be careful if you use tool.exe for 32-bit color. 16-bit This format is half the size of 32-bit, but it also has less color depth. Having an alpha channel further reduces color depth, with 1-bit alpha reducing color depth significantly less than 4-bit alpha. So, as a result, you can get banding with gradients. This banding can be improved with dithering, however. Pros Half the size of 32-bit Explicit alpha Explicit RGB Cons Somewhat reduced color depth Banding in gradients Subformats R5G6B5 - 16-bit without alpha - This is used if not all pixels have 100% alpha. A1R5G5B5 - 16-bit with 1-bit alpha - This is used if all pixels are either 100% alpha or 0% alpha. The green channel has half the color depth vs. R5G6B5. A4R4G4B4 - 16-bit with 4-bit alpha - This is used if there are pixels that don't have 100% alpha or 0% alpha. All channels have half the color depth vs. A1R5G5B5, with green having a quarter of the color depth vs. R5G6B5. Monochrome This format can be either 8-bit or 16-bit. If only alpha is defined and each pixel has an intensity of 100%, or only intensity is defined and each pixel has an alpha of 100%, then it is 8-bit. Otherwise, if intensity and alpha are separately defined, it's 16-bit. This is perfect for things like HUDs and HUD icons, as it results in no loss in quality. By intensity, I mean red = green = blue = intensity, thus it is grayscale. Sadly, this format does not work with stock Halo PC, requiring a mod (i.e. Chimera). Pros No loss in image quality for grayscale input Half the size of 32-bit OR half the size of 16-bit Explicit alpha Explicit RGB Cons Does not work with Halo PC without a mod (i.e. Chimera 1.0) Subformats A8 - 8-bit alpha - This is used if all pixels have 100% intensity. Y8 - 8-bit intensity - This is used if all pixels have 100% alpha. Alpha equals 100%. A8Y8 - 8-bit alpha + 8-bit intensity - This is used if pixels have varying alpha AND intensity. Compressed formats The DXTn formats are compressed in 4x4 blocks. These 4x4 blocks each have two 16-bit (R5G6B5) colors chosen by the compressor, and these colors are interpolated at runtime. As a result, different implementations can have slightly different results, and there is some loss in quality. Note that all of these formats store color exactly the same. Having a better compressor can result in better quality bitmaps (or more accurately, less reduced quality bitmaps), but it will almost always have some sort of loss in quality - often times significant. DXT1 This format stores only color and no alpha, instead being color-keyed. As a result, it is the smallest format, at 64 bits per block (4 bits per pixel). Since these formats all store color the same, if you use DXT3 or DXT5 and you have no alpha channel, DXT1 will be used, instead, to save space. This is the default format for newly created bitmaps with tool.exe. Pros 1/4th the size of 16-bit Cons No alpha channel; alpha is color-keyed instead Can have significant loss in quality Can have banding between blocks Cannot go below 4x4 or have mipmaps less than 4x4 resolution Less color depth than 32-bit (not including the interpolated colors which depends on implementation) DXT3 This format stores color as well as explicitly storing alpha in 4-bits per pixel, thus making it 128 bits per block (8 bits per pixel). Since alpha is explicit, shapes are preserved, making it arguably better than DXT5 for things like HUD elements. Pros Half the size of 16-bit Explicit alpha Cons Can have RGB banding between blocks Banding in alpha gradients Cannot go below 4x4 or have mipmaps less than 4x4 resolution Less color depth than 32-bit (not including the interpolated colors which depends on implementation) DXT5 This format interpolates both color and alpha. It is also 128 bits per block (8 bits per pixel). Since alpha is interpolated, gradients won't suffer from banding within blocks, but they may have fuzzier outlines. Pros Half the size of 16-bit Cons Can have banding between blocks Cannot go below 4x4 or have mipmaps less than 4x4 resolution Less color depth than 32-bit (not including the interpolated colors which depends on implementation) P8 Rather than compressing in 4x4 blocks, the image is converted into a 256-color indexed bitmap suitable for height maps but not really anything else. tool.exe and invader-bitmap use different palettes, as invader-bitmap uses the more superior Stubbs palette. Pros Half the size of 16-bit Each pixel explicitly chooses a color from a palette Cons Does not work with Halo PC without a mod (i.e. Chimera 1.0) Significant banding in gradients Color palette depends on implementation What is the best format for me? If you are not concerned about size, 32-bit is the way to go. It provides the best quality, being noticeably better than any of the other formats. 16-bit provides a nice middle ground, especially if you use dithering. DXT1/3/5, on the other hand, are for if/when you want to keep file size down. If you use this format, it is recommended you use the best compressor possible so you have the least amount of quality reduced. The compressor invader-bitmap uses is better than tool.exe's compressor, but it isn't as good as Nvidia's compressor. If you want your map to work with stock Halo PC, then you obviously cannot use P8 or monochrome. This is a shame, because monochrome is, objectively, the best format for things like HUDs as it provides no quality loss, while, although P8 isn't perfect, it's fine for bumpmaps.
  2. Invader 0.10.0 is now out! invader-bitmap has been massively overhauled. with supports for sprites, 3D textures, cubemaps, interface bitmaps, height maps, as well as the ability to make P8 bitmaps. Detail maps and 2D textures are also better, too. Also, dithering has been improved and is now available for 16-bit and P8 bitmaps. You can read the entire changelog on GitHub: https://github.com/Kavawuvi/Invader/blob/master/CHANGELOG.md Here are all of the changes since 0.7.2: Added A changelog is now used to track changes invader-bitmap: Added --usage (default, bumpmap, and detail) and --bump-height parameters invader-bitmap: Added support for bitmaps with color plate data invader-bitmap: Added support for cubemaps, sprites, 3D textures, and interface bitmaps invader-bitmap: Added the ability to specify custom spacing for sprites invader-bitmap: Added the ability to specify bitmap type in the command-line invader-bitmap: Added p8-bump support based on Stubbs the Zombie's palette Changed invader-bitmap: Spacing now attempts to sort both vertical and horizontal to see if sprites will fit in a sprite sheet invader-bitmap: Changed how spacing is stored in the bitmap to effectively match how tool.exe calculates its spacing invader-bitmap: Double multiply sprites now simply replaces the pixel like tool.exe rather than alpha blend into gray invader-bitmap: Usage and the p8 compression flag are now preserved invader-bitmap: Height maps now generate bump maps similar to tool.exe invader-bitmap: --detail-fade replaces --mipmap-fade and is now only usable on detail maps. invader-bitmap: --detail-fade now approximately matches how tool.exe does fade to gray invader-bitmap: Dithering is now available for 16-bit and palettized bitmaps invader-bitmap: Dithering now takes an argument: `<channels>`. Channels are letters (i.e. `argb`). invader-bitmap: Sprite spacing now affects the maximum number of mipmaps you can have with sprites invader-bitmap: Non-divisible by 4 bitmaps are no longer compressed invader-bitmap: Registration point calculation has been changed to better match tool.exe's calculations invader-bitmap: Alpha is now ignored when checking if a pixel is blue, magenta, or cyan Fixed invader-build: Fixed an issue with certain sounds not being played correctly, such as the "Come on! We've got to get the hell out of here!" dialogue at the start of the game invader-string: Fixed cutting the last character of every string Removed invader-bitmap: Removed being able to specify negative mipmaps to remove mipmaps As always, you can get builds from https://invader.opencarnage.net/builds/nightly/download-latest.html and https://invader.opencarnage.net/builds/nightly/
  3. blue-gen is something I quickly whipped up on request, originally being a Linux alternative to halospritedoer written in C. By request, it has been released for Windows, as well. What it does is generate TIFF sprite sheets from BMP/PNG/TGA/TIFF images to be used as input for invader-bitmap OR tool.exe. By default, it uses blue and magenta for the color plate data, but if it detects that you are using either color for your bitmaps, it will choose a different color for the color plate. There are two programs: blue-gen and Blue Genstone. blue-gen is a command-line program that does all of the work (see the readme for the exact usage). Blue Genstone is a graphical user interface for blue-gen. You can use blue-gen by itself, but if you use Blue Genstone, ensure that blue-gen as well as any dependencies (e.g. DLL files) are the same folder. Here's the command-line program in action: I also made a GUI for it as a proof of concept: And here's the Windows version which has been slightly updated: Download (Windows 64-bit): blue-genstone-r2.7z Source code: https://github.com/Kavawuvi/blue-gen
  4. As of Invader 0.8.0, invader-bitmap can now make sprites, cubemaps, 3D textures, and interface bitmaps. I've updated the original post with this. We're a little over halfway there for a full open source HEK replacement.
  5. Good job! While I probably wouldn't use this on my own servers (I feel it is part of the core Halo experience even if it is technically a glitch/bug), I can see why people wouldn't want it. Being able to reload a weapon without holding it is pretty stupid.
  6. My efforts towards this map parser have gone towards Invader. I'll probably go update the original post to indicate this.
  7. Praise is nice as an ego boost, but honestly, all I want people to do is test my stuff. I do get bug reports from people every few days ago, but it's rarely on here. Also, while it is true that I don't upload builds anywhere else, I've provided a means for people to get the latest build (which is automatically uploaded every day or so) without having to compile it themselves. Therefore, it is unnecessary make a reply to this topic for new builds. Before I started using this system, I was able to track how many people downloaded a certain build, and I found that nearly every build I posted had 0 downloads. This meant that nobody was testing the builds I was posting. Has that suddenly changed for nightly builds? Maybe, but it's unlikely. Each of these updates takes time to write. I have to go through the past source commits as well as look at issues that were resolved. Then I have to use that aggregate information to write a forum post in a way that non-programmers will understand. I really don't want to commit so much time into writing so many posts, as it seems like they just go nowhere. I'm still going to post updates for those who are interested in the project, but they're going to be more condensed and much less frequent.
  8. I haven't posted a full update in a couple days, so I guess I'll do that. I've posted Invader 0.7.2. Here are the changes since 0.5.0: An issue with invader-bitmap was fixed. invader-string has been started. Currently it only does string_list and unicode_string_list tags. HUD message text tags are not implemented yet. Some more hidden values have been calculated for machines. This probably won't fix anything, but for the sake of accuracy, I did it. When building maps that potentially use indexed tags (loc.map), invader-build will now compare the string data rather than comparing file size to determine if it matches what is in loc.map. invader-build no longer allows you to go beyond the number of bitmaps/sounds/loc tags used in stock bitmaps.map, sounds.map, or loc.map when building multiplayer maps, nor will it allow you to go beyond the Invader-extended tag set when building singleplayer/ui maps. This is to discourage people from creating a situation where you would need different, custom resource maps for different maps in your maps folder. This is also to discourage people from creating multiplayer maps that require custom resource maps - something which could theoretically happen accidentally when using a map downloader. Due to the lack of interest in Invader/this topic on this site, I'm not going to be posting updates here as often. Sorry! Continue to check nightly builds and the GitHub repository for updates, though.
  10. I fixed a bug with invader-bitmap. It wasn't setting the pixel offset value correctly.
  11. That doesn't help me. You need to explain what a timer/"partner respawn's in" is, and you'll need to explain what you mean by it not being steady. I can't help if I don't know what you're talking about.
  12. I'm an author? Does that mean people want a sequel to Bomb Walk?
  13. I'll try, but I can't guarantee this will be added.
  14. Here's a fix for the chimera_block_gametype_rules command. Download: chimera-20190830T024658Z.7z Map downloading is planned. No. The amount of time it would take to do this without disabling/removing any of Chimera's features, ensuring HAC2 support indefinitely, and making sure everyone gets Chimera updates in a timely manner would basically turn developing Chimera into a part time job that I don't get paid to do. Sorry, but you'll just have to use an older version of Chimera if HAC2 support is absolutely required. What do you mean?