This is a regularly-occurring status update. More generally-relevant posts can be found under Features (see Creating a Game and Engine from Scratch for context).
This is the beginning of week 7.
What I have done
- Finished the intentional tearing demo, which I wrote a post about
- This was both satisfying and frustrating. I was happy to get something working that I had wanted to do for a long time but also disappointed that I didn’t get better results. I am also frustrated that I still don’t feel like I have as good of an understanding of swap chains and related flipping and timing as I would like.
- I finally gave up and moved on and will have to revisit some of this when I have more complicated scenes being rendered, but it felt a bit like accepting defeat
- Improved the code that waits when it happens on the Windows message queue thread
- Right now the entire application is single threaded, but a rudimentary mechanism is in place to detect the thread (what I am currently calling the “display thread”) and do a different kind of wait so that new messages can be processed if appropriate
- Render a triangle
- This was mainly just following the Microsoft Hello-Triangle example, and so not particularly impressive
- Improved the array view class
- This is my implementation of std::span, and the initial implementation revealed some problems when dealing with COM
ISomething*pointers, both because of pointer const complexity and because of inheritance - I wrote a bunch of tests of situations that I could think of and the class now works better. This presented a fun (thought frustrating) challenge to solve with C++ templates.
- This is my implementation of std::span, and the initial implementation revealed some problems when dealing with COM
- Add WinPixEventRuntime
- This is the first external code/library that I have included in the project, which is a little unusual for me. Usually I start with {fmt} and Lua in order to have logging and configuration available, but in the current case I am delaying dealing with any strings and so haven’t followed my usual pattern.
- This integration allows me to annotate captures in PIX for Windows
- Add precompiled header support in the build system
- Adding the ability to (force) include files wasn’t particularly difficult, and that was the primary motivator for doing this so that I could start writing and structuring code the way that I wanted to. I thought that going one more step with precompiled headers wouldn’t be too difficult but it ended up being more challenging than I had expected.
- MSVC has some interesting constraints that I hadn’t been aware of where any files using a precompiled header have to use the same PDB file. Most notably, this means that a single PDB file is created and modified in many different steps by many different files getting compiled, which didn’t fit in well to my build system model where every task graph node (i.e. file) was the result of a single sub task. I think that I figured out a satisfactory way around this, though.
- Add ability in the build system to query whether a sub task has a specific input
- This allows me to decide whether a specific application needs the WinPixEventRuntime DLL
- Add ability in the build system to query for the primary/obvious output target of a sub task
- This allows me to decide where to stage the WinPixEventRuntime so that it is next to an application executable
- Add ability in the build system to create files
- This allows me to programmatically create a header file that #includes the WinPixEventRuntime headers using the current version number, sharing code with the LIB and DLL files
Next Steps
- An obvious need is to add something to the build system to deal with shaders
- Right now I just have a manually-copied shader source file in the application root directory that is compiled at run time, which is obviously not ideal
- I am a little hesitant to start going down the path of figuring out asset building and loading, however, because I don’t have any string solution (recall that a goal of this project is to not use the standard library and to not use the general purpose new allocator, and so dealing with strings and paths is a big task to tackle)
- With that being said, I could at least create a new type of build system sub task that allows a command line to be run and inputs and outputs to be specified. This would make it possible to work with the shader close to what I’m doing now but not quite so manually, and seems like an ok first step.
- The other obvious task is to keep adding graphics features beyond the simple triangle and color-changing clears
- I might at least continue to implement some of the D3D12 “Hello” examples, to increase my familiarity with the changes of D3D12 compared to D3D11 and to give me more time and experience to start thinking about abstractions and how to structure an actual renderer how I would want to