🇨🇦 Kyle Halladay

54 Followers
29 Following
226 Posts
I make graphics tech for mobile games, and dabble in engine dev as needed. Shared pointers must die. Random tutorials and thoughts @ http://kylehalladay.com
ah chicago. Winter cold finally let up, and we've now moved into thunderstorm season.
Wtf would a "Blockchain based gaming platform" even do?

on the one hand, I don't really want to worry about containers / Win32 threads, all that jazz.

on the other hand... my hobby projects are all namespaced functions and POD structs...even using vector feels odd. not sure I can handle even more cognitive dissonance.

debating whether I want to just say screw it and use standard library threading for my next vulkan experiment, or actually give a shit and use Win32 threads / ditch the standard library altogether.
I feel like the presence of a shared pointer as part of a class' member variables should be a compile time failure.
ffs. UE4's object count limit is ridiculous. It's 2018 and we still have to grapple with choosing the right size for a fixed, preallocated array of UObjects?

I see a lot of posts where people say they "know nothing about shaders"

If a website (or book) were to appear out of thin air that wanted to teach you something about them, what would you be interested in learning?

Has everyone settled on what the "right" way to handle matrix data in vulkan is?

Are push constants getting totally filled with model matrix data (this seems less than ideal?), is everyone keeping multiple large UBOs that store model matrices to minimize binding (or 1 large SSBO?)

or for the most part are things just getting their own unique ubo for their model matrix?

I'm looking for a way to write a memory allocator that will bucket allocations based on what system is using that memory (ie: have a bucket for UI, Animation, Gameplay, etc).

But the kicker is that I can't modify the call sites of any allocation, and the current allocator interface only asks for an alloc size and alignment.

I've had someone suggest manually walking the stack to figure out what's making the alloc call... are there any other options?

So uhhh... I may suddenly have a need for x64 assembly skills...

I've never done any assembly programming - what's the fastest learning path I can take?