itch.io

Thanks for playing!

The darkness gimmick in general sucks

Yeah, I understand how it can be irritating, but I tried to make it the least irritating I could while still having it be there (making everything predictable, having it not be a side-scroller so everything stays in the same place despite movement).

slow acceleration

Really? The acceleration duration is about half a second from idle to max speed, which I find to be reasonably responsive, maybe that's still too much for some players.

floatiness

The floatiness is intentional, I like having a lot of air control when jumping, but yeah, I can see how it feels odd if you're used to a certain kind of platformer.

hitboxes

I felt the same about them while making the game, they are "correct" in the sense that the pixels are actually touching each other, but it doesn't really feel fair. Maybe I'll tweak the player hitbox so that it's a bit thinner.

1.6GB declared RAM usage

In case someone is curious about this:

Most of that should not be resident and should never use up physical memory, in reality, the game uses about 40-50MB for everything, which is not great, but not terrible either, it's just not something I've spent time optimizing. A lot of virtual memory is reserved upfront for linear arena allocators, basically I just reserve a big buffer of virtual (non-resident) memory and I keep allocating stuff with it without freeing anything until I reset the whole thing, the small fraction of the reserved memory that I'm actually using is paged-in by the OS through page faults and becomes resident memory that actually uses system resources, I have two main arenas, one that gets reset every frame and another that gets reset every level. Currently, the frame arena alone reserves exactly 1GB.

This could be problematic on Windows  if your page file size is too small, since, as opposed to Linux, it doesn't overcommit memory, so if the program reserves 1GB, it has to guarantee at all costs that  1GB will be available and usable somewhere , which in practice means that it takes up space in the system's temporary on-disk page file, if your system for some reason doesn't have a page file, or the page file is too small or too full, it'll have no choice but to make the entirety of the reserved buffer resident in memory.

If you would like more information on this, see https://web.archive.org/web/20180402190240/http://ourmachinery.com/post/virtual-memory-tricks#obscenely-big-array.

There actually is way to emulate memory overcommitting on Windows by manually handing page faults (see https://learn.microsoft.com/en-us/windows/win32/memory/reserving-and-committing-memory) so that reserved memory only takes up virtual address space (of which you have terabytes on a modern x64 system) instead of also having to be reserved in the page file. Alternatively I could just incrementally do MEM_COMMITs as necessary behind a check in my Alloc function, or just lower the upper bound when reserving virtual memory, which I might end up doing.

it works fine now

I can provide more information on the issue in case someone reading this is curious or is also writing a Vulkan engine:

This turned out to be a pretty tame "bug": basically, the program was trying to call a null function pointer returned from vkGetDeviceProcAddr for a specific recently-added Vulkan function because it was not supported, I wasn't checking that the function pointer that was returned was valid because I just assumed the target hardware supported Vulkan 1.3 without even checking for that either, to fix this, I now check the return value of every call of vkGetDeviceProcAddr, and I make sure that the GPU that's used supports my target Vulkan version, this still wouldn't have been enough to allow the game to run in this specific case because the root issue is that the hardware or driver in this case does not support Vulkan 1.3, which I guess means that Vulkan 1.3 support is not as common as I thought, so I just spent some time lowering the minimum Vulkan version to 1.1 by using less recent features, which should be much more widely supported.