Using Odinlang's Tracking Allocator

Link the code in my game template: github.com/karl-zylinski/odin...
The template is a basic Odin + Raylib + Hot Reload template for quickly getting going with making games.
More info on Odinlang: odin-lang.org/
Talk gamedev on my Discord server: / discord

[@puzzlinggamedev]

I love these shorter and focused format videos in addition to the longer more detailed ones!

[@Whatthetrash]

This is very cool! Thanks for sharing it. I'll consider using something like this. :)

[@lopsidedpolygon]

:0
very helpful, thank you!

[@frostpitt]

Nice that you are enjoying Odin. For me personally, as someone who is very comfortable with C programming, it all begins with the memory and my style of programming is to allocate large chunks on startup and manage them via custom allocators. Things are never really freed until program exit. Instead, depending on the use case, things are "freed" i.e. made available again to be used. I tried to do the same with Odin and it ends up being quite...strange. Maybe that's just me feeling uncomfortable with Odin which is quite different from C.
What does draw me to Odin is the out of box Unicode support, strings, built in dynamic arrays and maps. I like pointer arithmetic so it will take me a long time to work with "slices". C's memory management is far simpler to use and so I still prefer C but every now and then I do try and re-implement what I am doing in Odin.
I also noticed that the Odin allocator only accepts int for sizes rather than C's size_t. Does Odin's int automatically scale to 64bit depending on your architecture? Personally I would have preferred to use u64 but Odin forces me to cast all ints to u64 then.

[@karl_zylinski]

You should be able to do the same with Odin. You can make a custom allocator that uses a pre-allocated memory blob. There are also arena allocators that can use pre-allocated memory blobs.
You are correct that int is same size as the pointer size on the platform. So int on a 64 bit machine is an i64

[@frostpitt]

@@karl_zylinski Yes, I am playing around with creating a few mem.Allocator { procedure: , data: }. as part of the global scope so I can just choose which allocator I want to use anywhere in the code base (frame_allocator, general_allocator, etc).