Kavawuvi's Development Topic

[Kavawuvi 7,026]

Since I work on a lot of stuff, I figured it might be a good idea to talk about some of that stuff in a topic like this. I'll post screenshots and other stuff as I work, and you guys can comment on how bad you think the bugs will be.

 

Current Halo projects in development
 

Chimera

This is a mod for Halo Custom Edition which provides a number of fixes and/or enhancements to the game.

Supports: Windows, Linux (through Wine 3.0 or newer)
 

---

 

Invader

This is an open source set of programs that reimplement the Halo Editing Kit, overcoming a number of limitations the older HEK had while also taking advantage of modern systems.

Supports: Windows, Linux

Edited March 6, 2021 by Kavawuvi
Remove projects I haven't worked on in a while - reiterate older ones

[Kavawuvi 7,026]

Some may have noticed I do not have anything supported on macOS that is listed right now. This is because I no longer intend to release anything I make on macOS, and this can be summed up to three reasons.

 

The main reason is because Apple has announced that they are dropping 32-bit support (HaloMD is 32-bit) as well as deprecating OpenGL support (HaloMD uses OpenGL; when Apple "deprecates" something, it means they will eventually drop it). Essentially, this means Halo on Mac, as we know it, will be dead very soon. Developing for something that is going to be dead very much soon, considering few people will use it, is a waste of time.

 

A second reason is because my MacBook Air is basically dying now, and I cannot afford a new Mac, nor would I want to spend the “Apple tax” that Apple is known for dropping on their customers. This means that I cannot adequately test my software, and compiling for it becomes a hassle on its own. I could get someone else to test it like I have been doing with some builds, but this is also a hassle, too, plus few people actually would be able to.

 

Lastly, I do not support Apple’s practices as of late. I used to use their products, having grown up with an iMac and an iPod Classic and then graduating from high school owning a MacBook Air. However, they have changed greatly since Steve Jobs’s passing and not for the better. I cannot trust their products. I would say that they are walking down a path that could eventually be their undoing in the PC market.

 

In fact, that last statement could be said for Microsoft, too, especially with Windows 10 betraying my trust in more ways than even Apple did. I’d love to drop Windows support, in fact. Unfortunately, most people in this community use Windows, so doing that would be foolish. Also, I have to endure dealing with Windows 10 for another year at least for my own reasons, and that also annoys the hell out of me.

 

Anyway, back on topic: I don’t have the time, money, or patience to support macOS with my software. Therefore, to run any software I have compiled, you will need a Linux or Windows instance, either via dual booting or a virtual machine. Fortunately, much of my software is or will be open source, meaning you may be able to compile some software with little to no effort and run that on your Mac, but I will not assist you.

[Kavawuvi 7,026]

[Kavawuvi 7,026]

I decided to benchmark Invader by building tutorial.map. While this map is not representative of what most people build, it is the example map that comes with the Halo Editing Kit, meaning this is repeatable by anyone. Each number is based on an average of five runs after running it once to cache everything.

 

 

As you can see, tool.exe is much slower than Invader, taking over a second on average. This slowness will matter a lot more if you are building much bigger maps.

 

You may also notice that there are three different Invader numbers: one for Linux, one for 32-bit Windows, and one for 64-bit Windows.

• On Windows, the 64-bit version takes around 10% less time to build tutorial.map than the 32-bit Windows build. I probably won't release a 32-bit binary, anyway, because there's no reason to support it.
• The Linux build takes 54% less time than the Windows build, and it takes nearly 80% less time than tool.exe. That 54% reduction might be down to a number of things: a less bloated operating system, better I/O, and no Antimalware Service Executable most likely contribute.

[Kavawuvi 7,026]

[Kavawuvi 7,026]

[Kavawuvi 7,026]

 

[Kavawuvi 7,026]

Hey! I haven't really been posting much updates in a while and here is an explanation for the various programs:

• Chimera: I don't really have the time to work on it right now. This shouldn't be the case for much longer, though.
• Salamander: I'm currently waiting on Blender 2.8 to be released. Blender 2.8 has a lot of new things for it, including a far more intuitive interface for those used to other software. However, the Python API is not backwards compatible, so I feel supporting 2.8 is more important than 2.79.
• Invader: This is actually being worked on simultaneously with Dark Circlet as it heavily relies on Invader.
• xLAN: While there is plenty to do, it's in a working state with few major bugs and I don't have time to do things with it right now.
• Slipspace Launcher: Like xLAN, there is plenty to do but it's in a working state with few major bugs, so I don't want to expend any time on it right now.

I used to have lots of time for this stuff, but thanks to college, I have obligations I need to fulfill each week. Sorry, but that's life.

[tarikja 918]

omg Chimera is dead! Just like HAC2! :'v

[Kavawuvi 7,026]

Here's a little experiment: lightmap generation on multiple threads.

Tool's lightmap generation is single threaded, and hacking tool.exe to be multithreaded is next to impossible. What isn't impossible is running multiple instances of tool.exe at once. By doing this, each BSP for a map can have its lightmap generated in parallel. This means that there would be no time savings for one BSP, but two or more BSPs could see the time greatly reduced in theory.

To test the theory, I wrote a Bash script that, when given a scenario tag, quality, and stop threshold, will attempt to generate lightmaps for every single BSP tag in the scenario tag's directory. If anyone wants to use it, here's the thing:

 

Spoiler

#!/bin/bash
#
# Copyright (c) 2019 Kavawuvi
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
#
if [ "$3" = "" ]; then
    echo "$0 <scenario tag> <quality> <stop threshold>"
    exit
fi

# Set our variables and timer
start=$SECONDS
scenario_tag="${1////\\}"
count=$(echo "$1" | awk -F"/" "{print NF-1}")
tag_directory="tags/$(echo $1 | cut -d/ -f -${count})"
search="$tag_directory/*.scenario_structure_bsp"
total=0

# Go through each BSP and create a job
for bsp in $search; do
    if [ "$bsp" = "$search" ]; then
        echo "Cannot find any BSP tags in in $tag_directory"
        break
    fi
    
    filename=$(basename $bsp)
    wine tool.exe lightmaps $scenario_tag ${filename%.*} $2 $3 &> /dev/null &
    total=$((total + 1))
done

# Check if we have only 1 lightmap. If so, then don't make "lightmaps" plural in the below message
s="s"
if [ "$total" = "1" ]; then
    s=""
fi

running=$(jobs -rp | wc -l)

# Constantly check to see if the lightmaps are done. Show the progress
while :; do
    running=$(jobs -rp | wc -l)
    percent=$((100 - $running * 100 / $total))
    printf "Building $total lightmap$s... $percent%% complete.\r"
    if [ "$running" -eq "0" ]; then
        time=$(($SECONDS - start))
        break
    fi
    sleep 0.1
done

# Check if seconds is plural. Then show the time
s="s"
if [ "$time" = "1" ]; then
    s=""
fi

printf "\nCompleted in $time second$s.\n"

 

 

For the benchmark, I tested a10 (stock) using the "fresh" tags set. I set quality to 1 and tested both 0.9 (for a really short amount of time) and 0.001 (for a lengthy period of time). I also tested both single (one instance of tool.exe at a time) and multi (multiple instances of tool.exe at a time). Here are the results:

 

 

As you can see, there is a massive time improvement to doing it in parallel. With 0.9, it resulted in a savings of over 8 minutes, reducing the time by 76%. With 0.001, it resulted in a savings of over 4 hours, resulting the time by over 68%.

 

It is worth noting, though, that a10.map has nine BSPs. Maps with fewer BSPs will probably see a much smaller gap.