Should be fixed in new release, I'd appreciate if you can confirm!
Viewing post in Night Owl Adventures jam comments
Nice, it works fine now.
I kinda like the execution of this game. The darkness gimmick in general sucks, but the projectiles being light sources has a nice dynamic where you need to navigate around them but not too close. That's something certain other puzzle projects lack while designing their hazards.
Player controls are ok at best (slow acceleration and floatiness) and hitboxes could be a bit more generous because in stage 2 (I think) it didn't look like it should hit when trying to stand right on top of the light blocks.
And what's up with all that 1.6GB declared RAM usage? It doesn't look like it leaks memory so I can't imagine what kind of horrors are happening there.
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.
UPDATE:
I shipped a new build that now does MEM_COMMIT incrementally, this should not make any difference with regards to the actual memory usage, but it should be helpful if your system's page file is small or non-existent. If anyone is curious enough to look at the difference, they can use https://learn.microsoft.com/en-us/sysinternals/downloads/vmmap, the working set (i.e the amount of physical memory that's actually used) should still be the same (it shows ~32MB on my machine), while as the amount of committed memory should be much lower.
I also doubled the player acceleration speed and made the hitbox thinner (also, the game now always sets its working directory to the directory where the executable is located, regardless of where you launch it from).