Invader

[Kavawuvi 7,026]

25 minutes ago, DSalimander said:

I wouldn't say there's a lack of interest but rather you're covering all the bases so well that there isn't anything to do but like your posts. As is with your past projects, most bugs reported are already known and praising for the sake of showing interest can get old quick. Keep doing what you're doing.

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.

[Kavawuvi 7,026]

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/

[Sunstriker7 698]

Shout out to my main man Stubbs

[Kavawuvi 7,026]

I made some changes since Invader 0.10.0. Normally I would've waited until October or so to post these, but they're breaking changes. Here's 0.12.0.

 

Added

• invader-bitmap: Added --filter-blur (blur filter size); this will blur the bitmap using a filter
• invader-bitmap: Added --filter-sharpen (sharpen amount); this will sharpen the bitmap using a filter

Changed

• invader-bitmap: Switched to the Xbox P8 palette. This palette is probably worse, but the original Halo Editing Kit as well as Mozzarilla support it, so it's easier to use.
• invader-bitmap: Now stores dithering and mipmapping settings in the tag
• Modified the project license terms to strictly GPL version 3

Fixed

• invader-bitmap: Fixed blurring and sharpening values in the tag not being retained

tl;dr - P8 uses the Halo Xbox palette instead of the Stubbs palette now. Also, the "or later" clause has been removed from the license from Invader.

 

Update: I removed --mipmap-blur and --mipmap-sharpen and replaced them with --filter-blur and --filter-sharpen, and they now affect the bitmap rather than the mipmaps. I acknowledge that this is broken, buggy behavior as this is not at all what the descriptions in Guerilla say, but Bungie's assets relied on this behavior.

 

This also does mean that if you extract a bitmap and you intend to remake it using invader-bitmap or tool.exe, you should change these values to 0 before doing this, as this cannot be undone unless you have the source image.

 

[Shelly Herself 221]

This project frustrates me, because every time something new cool and useful is added it just gets removed. :/

[Kavawuvi 7,026]

17 minutes ago, gbMichelle said:

This project frustrates me, because every time something new cool and useful is added it just gets removed. :/

 

If you're referring to this

Quote

invader-bitmap: Switched to the Xbox P8 palette. This palette is probably worse, but the original Halo Editing Kit as well as Mozzarilla support it, so it's easier to use.

Besides future versions of Chimera as well as Dark Circlet, nothing supported it. Also, MosesofEgypt wasn't going to add a trivial way to switch between using Xbox P8 and Stubbs P8, thus there was no good way of testing the P8 bitmaps to make sure they worked as expected besides using the out-of-the-way bitmap extractor in the MEK.

 

If you're referring to this

Quote

I removed --mipmap-blur and --mipmap-sharpen and replaced them with --filter-blur and --filter-sharpen, and they now affect the bitmap rather than the mipmaps. I acknowledge that this is broken, buggy behavior as this is not at all what the descriptions in Guerilla say, but Bungie's assets relied on this behavior.

I consider anything that negatively affects existing Bungie assets to be a bug, since it basically made it so it was impossible to recreate those bitmaps.

 

If you're referring to this

Quote

invader-bitmap: Removed --filter-blur and --filter-sharpen. Tags that have these values set will still have the filter(s) applied. However, for newer tags, you should use an image editor, as you will get similar or better results.

I felt there wasn't any need to have these settings as an image editor can do the job a lot better than Invader could, but anything that had it set via Guerilla or past versions of invader-bitmap would still work as expected.

 

If you're referring to this

Quote

invader-bitmap: Removed --sprite-spacing and used tool.exe's broken functionality, instead.

Sorry, but I cannot rely on the sprite spacing value in the tag to be accurate as tool.exe only writes to it, not read it. Also, Guerilla doesn't let you edit it, either. Lastly, if you make a 2D texture in tool.exe and change it in Guerilla to be a sprite sheet and this value is still not set (0), it'll result in a sprite sheet with 0 spacing, causing bleeding. There wasn't any good way to get around this.

 

If you're referring to this

Quote

invader-crc's forging CRC functionality was removed in favor of invader-build since it lets you forge a CRC at the same time as building a map

I think that modifying existing cache files should be avoided whenever possible, and this is forging a CRC would do. It is far better to forge the CRC when building the map. If you absolutely need to forge an existing map's CRC32 and invader-build isn't suitable to your purposes, then Refinery is better for this stuff.

 

[Shelly Herself 221]

Quote

- invader-bitmap: Removed the ability to set sprite budgets below 32 or above 512.

At least with this one you could allow for a switch that lets you use sizes bigger than this

 

[Kavawuvi 7,026]

Just now, gbMichelle said:

At least with this one you could allow for a switch that lets you use sizes bigger than this

It wouldn't save in the tag, though. The tag's enums for sprite budget allow for only 32x32, 64x64, 128x128, 256x256, 512x512. Therefore you'd have to pass this value every time.

[Shelly Herself 221]

If you used a better compression scheme that looked better that would also not save in the tag. If you can recreate what you made with your tools using vanilla tool, what is the point of your tool?

 

To be clear, compatibility with legacy is good, but I don't think we should be limiting ourselves to that all the time. The whole draw for this project for me is to be able to do stuff that I've been manually purposefully avoiding tool to accomplish, but automated. Edit: Even if it means adding an extra switch to my command.

Edited September 26, 2019 by gbMichelle

[Vaporeon 189]

Extra options that do not preserve themselves in the tag data leads to an issue where bitmaps could end up being changed inadvertently, for example if you used a script to run through the data directory and rebuild every bitmap it finds.

 

I have to agree that sticking to how tool works when it comes to building tags from data is very important.