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

Administrator
  • Content count

    4,177
  • Joined

  • Last visited

Everything posted by Kavawuvi

  1. You can only bind two items, but you always have access to pegasus boots, shield, and sword. Most rooms use a fixed camera just like before. It's only the overworld and a few larger rooms which use the bounding box camera, instead. Yes. The layout of everything is mostly the same as the original game. I don't know if I'd buy a Switch just for it, but it is a really good game. Maybe check out Digital Foundry's review as they do a good overview of the technical aspects, if you're interested.
  2. Do you have fall damage disabled?
  3. Nice! You should consider using a service such as SoundCloud so people can listen to the sounds before downloading a >100 MiB archive of HEK tags. Also, that archive also has a lot of empty directories, so you might want to look at that to make sure you aren't missing anything. If you aren't, you should remove those so things are easier to navigate. Lastly, your topic could do with a description of the sounds. What inspired you to make your sounds? Is there a sort of theme? How did you make them? These are just some ideas for your description if you need any.
  4. Many maps being made today contain large amounts of bitmap, sound, model, and BSP data. As a result, these maps take a large amount of space. A common way to keep size down is to use DXT compression. This allows for bitmaps to take up as low as 1/8th their original size. However, this results in a significant, irreversible loss in quality in the original image. Something I've been doing is experimenting with lossless map compression. There are a few choices for good, lossless compression algorithms to use: DEFLATE (typically used in .zip/.gz) - Also used by the original Xbox for Halo Combat Evolved cache files LZMA/LZMA2 (typically used in .7z/.xz) Zstandard (typically used in .zst) The map I'm going to use is a10.map (189.9 MiB). This map was built with no dependency to bitmaps.map, sounds.map, or loc.map, and it contains the original Gearbox-compressed bitmaps and sounds. I'm going to be testing using libdeflate (DEFLATE), xz (LZMA), and zstd (Zstandard). DEFLATE and LZMA's default compression settings are level 6, with the maximum being 9. In this case, I'm going to be using level 3 and 9. I picked 3 over 6 for better performance rather than better compression ratio, and I don't have time to compress and decompress the same file 20 times at level 6 since I'm already spending a lot of time doing level 9. zstd's default compression setting is level 3. The maximum is 22, but levels beyond 19 require more memory, so I chose to use level 3 and 19. First, let's look at the most important thing: decompression time When it comes to decompression time, Zstandard is the best, adding only 0.27-0.35 seconds to the map loading time depending on the compression level you used. DEFLATE is also very good and doesn't vary significantly if you use any compression level. xz, on the other hand, is the slowest at nearly six seconds. Next, let's look at the second most important metric, compression ratio As you can see, LZMA is the best of the three, closely followed by Zstandard. DEFLATE's best is only slightly better than Zstandard's default. Lastly, here is the compression time When you use the lower settings, Zstandard and DEFLATE are both quite fast. In fact, DEFLATE's best is much faster than LZMA at level 3. Zstandard at level 19 is still considerably faster than LZMA. That said, compression time is not really important, as it's something you only have to pay for once: when you create the map. Decompression has to be paid for every time the map is decompressed. It's worth noting that these tests were all performed on one CPU thread. zst allows you to compress using multiple threads (though it seems diminishing returns are at 4 threads?), and this significantly improves performance. I did a test earlier today with all of the Halo PC maps that came with the game using Zstandard, and this is what I got. xz also lets you use multiple threads, but if you want better loading times, you'll want to split things into blocks so you can decompress them in parallel. This is basically required to make loading times bearable. Here is an old spreadsheet I made where I compressed the entire Refined campaign into blocks using LZMA. As you can see, loading times are actually pretty tolerable, even if you have only a dual core CPU. Waiting 3-4 seconds is much better than having to wait six seconds for a map to load. If you have four or more threads, though, then you'll generally see two seconds or less, and under two seconds with eight threads. Even so, this is still not quite the speeds of even DEFLATE on one thread. And you can also use multiple DEFLATE or Zstandard blocks, too, if you wanted. That said, it is worth noting that using multiple blocks also comes at a compression ratio tradeoff and requires more RAM - something Halo Custom Edition being a 32-bit program is in short supply of. So what are the takeaways? LZMA: Best in compression ratio by far Better than Zstandard at -19 in compression speed All of the above benefits hardly matter because you have to wait multiple seconds for the map to load tl;dr: Best compression ratio, Slow DEFLATE: Fast decompression Compression ratio isn't very good compared to Zstandard which is better compressed and is faster at decompression Best setting (-9) is only 1% better than Zstandard's default (-3) in compression ratio, but takes over 10x as long to compress tl;dr: Fast, Not very good compression ratio though Zstandard: Fastest decompression all around Fastest compression if trying to match DEFLATE's Can match LZMA's -3 compression ratio with -19, but takes 49% longer than LZMA to compress to that level Significantly better than DEFLATE's compression ratio with -19, but not quite as good as LZMA's -9 tl;dr: Fastest decompression, Decently fast compression speed, Good compression ratio, the "best of both worlds" so to speak You can create .xz and .gz archives in 7-Zip. 7-Zip does not support Zstandard, though, so you'll need a separate program for this or a plugin of some kind. Writing a program that compresses maps isn't particularly difficult. Also, it is possible to have the game automatically decompress the map, too, with a mod. Chimera, for a while, did this, as it supported an experimental format that used multiple LZMA blocks, and these were decompressed into a region of memory. However, this came with a drawback: it required a 1 GiB contiguous chunk of virtual memory just to hold the map, thus you had to patch the game to allow you to go above the 2 GiB limitation. 1 GiB is arguably not enough memory, too, as while today's maps are usually under half a GiB, tomorrow's maps could go over this limit, and making one is easy to do right now. The Xbox version of the game addressed its low memory limits by caching the uncompressed version. However, unless you have multiple compressed maps, then having a big temp file on your hard drive or SSD is going to negate the savings. Also, accessing the disk is slow and prone to stutters even on an SSD. This makes it questionable whether or not map compression is viable on Halo PC or not, as while it provides a significant savings sometimes even over DXT compression, it, first of all, requires a mod. It also requires either patching your game's executable while hoping nobody makes a 1+ GiB map, or that you have to have uncompressed files laying around taking up a lot of space.
  5. A bug was found where fast loading was not working in Halo Custom Edition. I've fixed this. chimera-20191019T225026Z.7z
  6. I posted this on the Chimera Discord as an announcement, but I figured it was important to put this here chimera-20191018T012014Z.7z Uh... Oops. My hand slipped!
  7. Heard this song on the radio earlier "Just an old fashioned love song playing on the radio" Kind of a meta line there.
  8. After some careful thought, I've decided to reverse a decision I made when starting Chimera on what is supported. As such, Chimera 1.0 will fully support the retail version of the game (AKA "Halo PC"). Currently, if you want a retail-compatible version of Chimera, you will have to compile it yourself, but I'll start posting builds of it in the future. The main reason for this is due to the graphics in Halo Custom Edition being even more broken than the retail version of the game, and these bugs are unfixable with my understanding of the game. Workarounds have existed for this, such as the Refined campaign's usage of model shaders instead of environment shaders, but this results in a less detailed, cut down appearance, similar to the difference between Halo PC's teleporters vs. Xbox Halo's teleporters. It is true that Halo Custom Edition provides a few features that retail doesn't have: Names over heads Gametype rules More servers and players Custom map support However, in singleplayer, with the broken fog, Halo Custom Edition provides an overall inferior experience to the retail version of the game, as well as multiplayer for people who do not use these additional features. Take a look: This means that, for the first time ever for the retail version of the game... The motion sensor won't be stretched when the widescreen fix is enabled. The main menu will be adapted to your aspect ratio when the widescreen fix is enabled. The console will be adapted to your aspect ratio when the widescreen fix is enabled. Zoom blur can be fully disabled without turning on DART or fixed function shaders instead of only partially. Mouse acceleration will be disabled by default. The sun will be fixed at higher resolutions. The vehicle camera centering can be fixed. The loading screen will instantly hide when joining a mulltiplayer server. And more!
  9. It looks so clean! It looks so much better than what they managed to do with Refined on Custom Edition. Thanks so much for taking the time to make this.
  10. Hold my Oreo cookie
  11. This one's a stupid one, but it made me giggle a little.
  12. This song is my jam
  13. Unfortunately I don't have much in the way of Skyrim screenshots on my PC, either. I come back to it every so often and then I get tired of it after a few hours. What sucks is that the game isn't actually bad. The base game alone has quite a few good hours in it, and the gameplay itself is quite engaging despite the bugs. Of course, since there are many mods out there, you can do a lot more with it than what Bethesda originally did. Unfortunately, Bethesda is terrible at fixing longstanding issues with even their most popular titles. They're so bad that it's expected that a Bethesda-developed game will be riddled with bugs. The quality of the game, itself, is also way too inconsistent. Some parts are genuinely good, some parts are a bit mediocre, and some are just bad or outright broken.
  14. Too drunk to find a good screenshot right now. Sorry.
  15. 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!
  16. Thanks for replying. My problem is that servers that have sightjacking disabled seem to be more prone to cheaters. I can't count how many times I've joined a server where there was someone who was possibly cheating, but because the server blocked sightjacking, I couldn't be certain about it. This is what ultimately resulted in me choosing to not implement whatever HAC2 does or should do to check if sightjacking is blocked. It isn't like I'd be able to trivially do this if I actually wanted to, anyway, because HAC2 is closed source. I think having to play on a server with cheaters because you chose to block one of the most reliable means of detecting cheaters isn't fair for me, either. Sure, I could go to a different server, but the choice of servers with players on them is very limited, and many of them block sightjacking, which is why I made this decision. If you need a bug fixed with HAC2, I recommend talking to msalerno1965 about it. He's the one who currently develops for HAC2. I'm sure he can help you out.
  17. Someone on the Chimera discord asked if Chimera's spectate feature (equivalent to HAC2's sightjacker) would respect SAPP's scrim_mode command which disables sightjacker, and I thought this was an important question. Here was my response: tl;dr - No. Chimera will not prevent you from using any of its features when SAPP's scrim_mode is enabled.
  18. 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.