PixelPerfectEngine v0.11.0-alpha release

[Hipreme]

On Sunday, 21 January 2024 at 01:24:22 UTC, solidstate1991 wrote:
> https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.11.0-alpha
>
> Two major changes are:
>
> 1) Implementation of the M2 format. Due to the lack of any 
> proper MIDI2.0 formats, I decided to implement my own, and also 
> added some additional function which allows it to be used for 
> adaptive soundtracks via scripting. Sometimes I call it a 
> "Turing-complete MIDI file" as a joke. Some functions are 
> missing, such as most of the macros that would allow it to 
> function as a de-facto high-level scripting language, with a 
> syntax similar to Lua, alongside with a lot of assembly-like 
> instructions.
>
> 2) Removal of the Lua scripting engine. It had hard-to-debug 
> errors, issues I resolved previously reappearing even though 
> the fix were still in place, etc. It'll be replaced with 
> something better, likely a VM that will allow it to execute 
> scripts written in various languages. I'd prefer to use a 
> preexiting VM, with QScript's VM being a potential candidate, 
> especially since I have other things to work on. M2 technically 
> has a VM, and reusing the experiences with it would be useful 
> for implementing my own, but I have limited time and other more 
> important features to implement.
>
> The final 0.11.0 version will have:
> * A better file dialog (a major headache inducing bug were 
> already fixed).
> * Resizable windows.
> * Resampling to higher sample rates.
> * Better path handling (currently it's very fragile, and tries 
> to look for assets in whatever folder the user runs the engine 
> from).
> * Logging.
> * I'll try to replace SDL with my own solution, iota. It 
> already has some preliminary x11 support, legacy Windows IO 
> works, but it's really hard to look up stuff, and many instead 
> suggest people to use either some bloated libraries that 
> feature stuff even the C standard library has, and/or has a 
> very legacy-style input/output handling (DirectInput and not 
> rarely DirectAudio use instead of their more modern 
> counterparts, etc). SDL has a lot of issues with documentation, 
> bloat, etc.
> * I'll also try to finally get the file compression for assets 
> working. I created the format DataPak, with has some tricks to 
> both speed up and lower the size compared to other solutions, 
> by using the dictionary compression mode of ZStandard (requires 
> the use of uncompressed bitmaps: compressing PNGs would be 
> really slow and ineffective, since they're already compressed 
> with the older ZLib algorithm).


Congratulations for the alpha release!
It is quite funny to understand that most game programmers starts 
using D because of SDL compatibility ,which is very common and 
they want to learn a language while still feeling security (no 
one uses D on jobs, but people uses SDL, so I can reuse 
experience in SDL for jobs), but, past some point, people just 
starts dropping SDL since its difficulty to build on all 
platforms, its bugs, inconsistencies, bloat and that it is in C 
while you're developing in D, thus requiring a C compiler, which 
will get pretty annoying (hello C for windows).

That apart, it would be really cool if we had a lightweight 
solution, completely in D with only bindings to what make sense 
(win32, x11, UWP, Android) and other things, like I've been doing 
in my engine