At Our Machinery, we’re strong believers in minimalism — we’re always trying to make things simpler and smaller. The more code you have in a project, the more you have to worry about. There is more to understand, optimize, debug, refactor, port, modernize, document, etc, etc. More code, more problems!»
This year was really exciting for us, to start working on The Machinery and in the process informing you about how we are thinking and doing things here at Our Machinery. As we mentioned on Twitter, all of us are taking the rest of the year off, because next year is going to be a big one for us and we want to make sure we get proper rest for it. In the meantime, we’ve listed out our blogs here for you so if you get bored over the winter break, you can read what we are doing.»
This will be the last post in my mini-series of posts covering some of the performance critical aspects of our Vulkan render backend. In my previous two posts I covered management of Descriptor Sets and Command Buffers. In today’s post I will describe how we deal with the creation and look up of
VkPipelines, and also touch on our system for dynamically changing render states.
A question I’m often asked by developers is, “Do I really need PR?” Another one I get a lot is, “Should I hire a PR person or firm, or should I just do it myself?” Here’s my thinking on these questions:»
The entity-component pattern has been around for a long time. By now I would say that it is widely considered to be the preferred way to write gameplay code. However, there is less consensus on how to actually implement an entity-component system and when you sit down to write it you face some interesting choices.»