you're still releasing resources - so you might not become faster overall but you can compute more in the same time later if necessity arises (althougth that might be somewhat premature but can be good for library code - so it becomes more applicable in different environments)
and there are some rare but tricky scenarios like:
hardware is mobile phone:
app seem to be bottlenecked on arithmetics according to the profiler, so it feels obvious to start optimization there
in reality what happens - hardware has limit on power, so it can't give full power to CPU, GPU and memory all at the same time
since app uses too much memory - it has to redirect power there, also memory emits heat, so CPU becomes throttled
By optimizing memory, everything runs colder -> CPU gets more power, can run sustained higher frequencies - app becomes faster
nothing really prevents you from defining global allocator in Zig
and having explicit allocator in standard library is actually a good thing, cause it's quite a common case in game development to use arena allocators which are being freed once per frame - so you don't really need to reinvent your data structures in Zig
I do have some concerns about Zig because it also introduces some friction for correctness sake like requiring to always use all variables, explicit casts everywhere - I want some compiler toggle to disable all of that and focus on problem but unfortunately it's not there
I am playing with Zig now and haven't really formed my opinion about game development specifically but I like it a lot so far
this is very computationally expensive to do such operation (to understand that teeth is completely occluded by something else like mouth)
this is called occlusion culling and usually it brings a lot of problems on its own (it's CPU intensive and you need to apply it smartly only where it helps)
and even if this occlusion culling would be cheap, the way how it is usually done requires precomputing a lot of data - so occluders are static geometry
since character head is skinned mesh - so dynamically changes every frame based on joints positions - that will be another level of complexity
We recently started to use Dear ImGUI in our custom game engine. Before we used Unity which has its own immediate mode gui solution.
And I have hard time to switch. I don't know if I don't understand how Dear ImGui work yet in comparison to Unity's one but it feels so limited.
So main difference is that Unity is multipass (it calls your gui drawing code multiple times per frame) and because of it it supports horizontal layout, vertical layout, custom layout modifiers, styles and it is easy to use
in Dear ImGUI I am struggling to write stuff like:
layout 3 controls horizontally, allocate fixed size for first and last one and use all left space for middle one
or
layout next N controls vertically of unknown height and use this background color for them, then layout another set of controls and use different background style for them
I am not the person who was actively working on integration it into our engine, so maybe it's the problem of not having documentation on our wrapper...or me not understanding very basics of it
You just need to find activity interesting for you
I used to do sedentary lifestyle most of my life until I found rock climbing 2 years ago
I go rock climbing to a gym 2-3 times a week now. I go there because I WANT not because I have to.
This did tremendous job to my health and overall fitness. And this is sustainable in the long term because I don't have problems with motivation.
So my advice — find your sport, any physical activity you are interested in. If it becomes boring, don't hesitate to change it.
You don't need to be a sportsman and become good at something, you just need consistency to move your body , so care about your motivation. Good body will come naturally after some time.
We actually had Github banned in Russia once or twice for short periods of time (like hours or days). Because of some repository contained joke text about how to commit suicide.
you're still releasing resources - so you might not become faster overall but you can compute more in the same time later if necessity arises (althougth that might be somewhat premature but can be good for library code - so it becomes more applicable in different environments)
and there are some rare but tricky scenarios like:
hardware is mobile phone: app seem to be bottlenecked on arithmetics according to the profiler, so it feels obvious to start optimization there
in reality what happens - hardware has limit on power, so it can't give full power to CPU, GPU and memory all at the same time
since app uses too much memory - it has to redirect power there, also memory emits heat, so CPU becomes throttled
By optimizing memory, everything runs colder -> CPU gets more power, can run sustained higher frequencies - app becomes faster