Minecraft
Platform Deployment
Releasing a project to the world is not that easy as one may think. We need to make sure that the end user will have an easy interaction when installing our program.Testing
Tests are used to determine a semi-validity of your implementation. However, it is useful to ensure that parts of your program does what it is supposed to, and that the whole program actually does things as expected. The biggest problem is how to test. The rest is just making sure it actually tests the right things.Re-implementing from old program
Sometimes it is good to port algorithms from older code bases. And while it could be fun, if they are not compatible it might result in weird ad-hoc code. Refactoring to reduce duplication is necessary.Internal Optimizations
Optimize a complete algorithm is harder than it sounds, but with the right tools and correct mindset, it is possible to achieve noticeable improvements. In this case, memory handling is the most obvious fix.Better Compatibility
I realized that I missed to add support for certain features in Minecraft save format, so I spent a couple of hours doing so. All of this adds better compatibility with Minecraft.Library Optimization
Optimizing your program can be tricky, but sometimes you can blame on the libraries you use, and look for alternatives that could help you.Cross Compilation
Making applications that works over several platforms is hard, but in this case it was more related to the build system. There are some practices regarding the build system that should be taken into consideration, especially regarding dependencies.Task Batching
Fixing a the issue of being able to utilize more threads in a system required an unexpected technique. Adding it might not make it more optimized, but at least it will reduce noticeable overhead and allow it to process more tasks in parallel.Block Color Config
I happened to see a boosted post on Mastodon, where someone mentioned that most programs handle their configs badly, basically generating full configs, maybe with commented out options and defaults, which upon updates will be rendered worthless if they change. I responded to how I handle my configs, and suggested an alternative solution, which I implemented.
The first version of PixelMap 0.x had all configs statically added to the program, meaning they cannot be changed after the program is compiled. Later on I designed a block color format, where a config file could be added and therefore change the colors of the created images. PixelMap 1.x had the block color file added per default, but if it wasn’t provided, defaults were transparent, meaning the resulting image could be completely transparent.
Thread local
I managed to reduce the total time to 14 times native by integrating thread_local for Lua states. I will probably stop pursuing this further as now I probably need to micro optimize Lua the integration itself. Could be that as it does not output correctly would be a potential reason why it is slower too.
Worth noting is that the Lua rendering is not completely implemented as it currently does not work with blending. Just need to integrate ray tracing first, but that should be rather quick.