Wtf would a "Blockchain based gaming platform" even do?
Making dds textures via command line utils like it's 2006 ♪♫♬
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.
So it turns out I was doing something dumb in that Vulkan bechmark post I shared yesterday (not considering that I may have been hitting a perf bottleneck that was skewing results...)
I've since updated the tests, re ran everything, and posted an updated article on my site:
Hoooorraaaayy for extremely public mistakes!
Sigh... when you spend hours constructing a performance test... and then twitter points out a mistake you made that renders it all useless within about 12 hours of you posting it.
Not sad that I was wrong (I post things publicly so that people let me know when I'm being dumb),
but maaaannn do I wish I had spent less time getting those borked numbers.
In my free time, I've been building a quick test project to benchmark different ways of handling transform data in Vulkan.
I've posted a write up of the results of that benchmark on my blog:
Key takeaway - push constants don't scale as well as UBOs or SSBOs when you're talking about tens of thousands of meshes.
I feel like the presence of a shared pointer as part of a class' member variables should be a compile time failure.
(should note that test scene is the Amazon Bistro scene with no meshes combined)
Holy crap you really don't want a non device-local ssbo.
Doing some tests around transform data with Vulkan. HOST_CACHED SSBO for matrix data: 42.23 ms / frame. DEVICE_LOCAL: 8.38 ms/frame.
Neither of these is as good as (multiple) dynamic ubos, but still, holy crap that's a difference.
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?
My life right now is trying to get people to understand this:
How is everyone approaching setting content budgets with regards to loading times?
Seems reasonable to run some initial tests to see number of MB you can load on hardware in a certain amount of time, and stress tests to try loading like 10k small files at once, and different types of data to get a feel for what you can reasonably do, and set initial guidelines based around those numbers.
Has anyone approached this differently?
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?
Just spent way WAY too long debugging why depth buffering wasn't working... only to realize that I forgot to set a max depth on my viewport. fml.
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?
The guy interviewing here today apparently reads my blog.
I'm kind of a big deal.