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

Kavawuvi

Invader

73 posts in this topic
Quote

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.

Honestly? Tough shit imo.

Share this post


Link to post
Share on other sites

Members of Open Carnage never see off-site ads.

On 9/26/2019 at 6:55 PM, gbMichelle said:

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.

To answer your first question, here is what invader-bitmap does that tool.exe doesn't do:

  • invader-bitmap can use png, bmp, and tga files in addition to tif/tiff
  • invader-bitmap can let you create non-2D texture bitmaps as well as bitmaps with any available data format without you ever having to leave the command line interface
  • invader-bitmap can let you overwrite various other bitmap settings like bump height and mipmap count without you ever having to leave the command line interface
  • invader-bitmap can let you specify any data folder and any tags folder rather than using the current directory
  • invader-bitmap can create bitmaps that exceed 16 MiB

As for your other part of the comment, every single parameter used to generate a bitmap tag is stored in the bitmap tag. By doing this, you don't need to re-enter every single parameter every time you re-generate the bitmap tag. This is how tags fundamentally work, and deviating from this puts us in a situation where some settings get saved and some settings don't, negating the point of using tags in the first place.

 

The main goal is that anything made with tool.exe that is re-made in invader-bitmap should function identically. If it doesn't, I consider this a bug that needs fixed.

 

However, the opposite doesn't need to be true: something made with Invader does not necessarily have to work with tool.exe. For example, tool.exe will not process bitmaps that exceed 16 MiB. A 16 MiB limitation more-or-less limits you to these resolutions:

 

With mipmaps:

  • 4096x4096 - DXT1
  • 4096x2048 - DXT3/DXT5
  • 2048x2048 - 16-bit
  • 2048x1024 - 32-bit

Without mipmaps:

  • 8192x4096 - DXT1
  • 4096x4096 - DXT3/DXT5
  • 4096x2048 - 16-bit
  • 2048x2048 - 32-bit

 

However, invader-bitmap doesn't have such arbitrary limits. You can make 4096x4096 32-bit bitmaps, and Invader won't have any issue with them provided they are otherwise valid.

Share this post


Link to post
Share on other sites

Invader is now 0.13.0. It just so happens that this spooky version number happened on a spooky month. Here are the changes since 0.12.0:

 

Changed

  • invader-build: Changed how stubbed tags are created so tag extractors won't try to extract them
  • invader-bitmap: Errors if the tag contains uppercase characters in its path
  • invader-build: Errors if any non-stubbed tags contain uppercase characters in their paths
  • invader-font: Errors if the tag contains uppercase characters in its path
  • invader-string: Errors if the tag contains uppercase characters in its path

Fixed

  • invader-build: Fixed not fixing the render bounding radius if it was less than the bounding radius but non-zero.
  • invader-build: Fixed not setting the weight value for color change permutations in objects.
  • invader-bitmap: Fixed detail fade factor so it matches tool.exe's detail fade factor more closely if not exactly.
  • invader-build: Fixed certain sound permutation file offsets not being correctly marked as internal; this should fix some sounds that sounded fine when built with tool.exe but sounded corrupt when built with invader-build

Removed

  • 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.
  • invader-bitmap: Removed --sprite-spacing and used tool.exe's broken functionality, instead.
  • invader-bitmap: Removed the ability to set sprite budgets below 32 or above 512.

View the full changelog at https://github.com/Kavawuvi/Invader/blob/master/CHANGELOG.md

 

From what I've seen, people prefer these less frequent but longer update announcements, so I'll keep doing them like this since it's less work for me. The changelog and GitHub repo, however, will be updated as changes are made. So, if you need to read about the more recent changes, then be sure to check that from time to time.

 

As always, you can get the latest build at https://invader.opencarnage.net/builds/nightly/download-latest.html. These are automatically compiled and uploaded via a script on a local machine. These snapshots are built from the latest commit (at the time of building) on the Git repository which may include unreleased features, so these announcements can and probably will get outdated fairly quickly.

 

See you next month!

Tucker933, Sunstriker7 and ST34MF0X like this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.