**[Will's Journal](../index.html)**
(#) **2024/09/16: 3 Months, New Engine, AMD issues**
It has been a while since my last entry. What happened to me is not unlike what happens to most people who keep up a blog in their spare time. I got a job. It's a job in a local "indie" game development company which I started about 2 and a half months ago. This footprint is fairly clearly visible from my GitHub activity page.
Because my game development background is mostly in Unity, I had to do a lot of learning and catching up because the company uses Unreal Engine. Fortunately, I have a fair amount of familiarity with c++ due to my graphics programming adventures.
The job is pretty good, the people are friendly, the work environment is comfortable, and the work is reasonably challenging. It doesn't pay extraordinarily well, but that's just what it's like in Indonesia.
What really excites me is that they expect to have me work on graphics programming tasks after my current assignment.
While I'm excited, I also have some self-doubt with regards to my ability, but I'm hoping that I can catch my knowledge up to the current state of graphics programming before then.
(###) **Will Engine V2**
After the initial 1.5 months of activity, my brain had adjusted to the new lifestyle and I picked my game engine back up. As part of the job, I was given a new desktop to use which is an absolute beast. It sports an AMD Ryzen 9 7950X CPU and an AMD Radeon RX 7900XT GPU.
Miles above what my old crummy laptop setup could achieve.
So I clone my engine over to this new computer and after fixing up the bad hard-coded links from the Visual Studio solution, I got a few errors. No big deal, I expected some pains moving over to a new computer. Can you believe, the AMD GPU doesn't support shader objects! A core component of my
game engine is not usable! Absolutely devastated, I thought about it for a while and decided: considering how the architecture of the current engine is fairly poor, I think now is a good time to rewrite the engine.
After the experience of transporting the project, I had also decided that the project would need to be easier to deploy, and looked into using CMake. CMake is foreign to me, and even now after using it for the new engine, is still very much magic. Some might say I'm hindering my ability to learn
but most of the CMake I've used is entirely generated by Claude.
I will admit it took a bit to get used to using CMake. In my new job, we used Rider because its integration with Unreal Engine was better than Visual Studio - and after a brief adjustment period, I am SOLD on all Jetbrains products. I noticed they also had a c++ specific IDE: CLion.
CLion has a fantastic integration of CMake and I confess that without CLion, CMake would have been infinitely harder to incorporate into my engine.
Additionally, using CMake also allows me to do automated CI through Github! Since I'm not going for gold with this, it is only set up to do a windows build and will alert me if the build fails. This significantly improves the reliability of the project should I want to deploy it in a different device.
And sure enough, this actually became relevant - but more on that in a later section.
The new engine has a fair amount of changes, including a new "Render Object" data structure designed to make instancing significantly easier to set up. Theres a bigger focus on general game engine architecture, such as a scene hierarchy which can be manipulated with Imgui as needed. Not quite fully ready,
but it's getting there.
The new engine is not quite at feature parity with the old engine yet, but I'm hoping that in a few more days it will be. Though progress hasn't been as fast as I'd hoped. Often I feel exhausted from using all my focus at my job, so my engine is only generally worked on during the weekends.
I've also made some significant improvements to my descriptor buffer wrappers that I feel improves clarity of the application of the wrapper. It is a fair amount easier to read than the initial version I put out in my descriptor buffer technical article, which I should really update.
The design of having 2 different descriptor buffer types: Uniform and Sampler remains as it is a limitation of the descriptor system.
Please feel free to view the code in [this commit of my Engine](https://github.com/Williscool13/WillEngineV2/tree/53436fdc868401d78b6b9bec1b3329544c83f6f4)
Of course there are still a few issues that I am not quite sure how I plan on tackling. Most game engines these days have multiple threads acting concurrently: Game, Render, Physics, etc. Currently my renderer operates on the same data as the game.
This isn't a problem right now, as the engine is single-threaded. But if I plan on separating them into multiple threads, I will need to figure out how to do this correctly.
(###) **AMD Issues**
While working on the new engine, I faced a significant issue with textures that stumped me for a solid week (well, not a full "active" week). Some of my textures showed significant artifacts along a mesh's edge.
Of course, I had initially thought I did something wrong in my code. I think it's a fair assumption - since Vulkan is usually very good with validation errors and will very quickly tell me if something is catastrophically wrong. I had changed, rubberducked, and pondered on this for some time before
finally suspecting that this may be a GPU vendor specific issue. My previous computer used an NVIDIA GPU and this one, an AMD one. So I had asked a friend to help me build and run the engine on their device.
It took a bit of setting up - she doesn't usually work in c++, and had never used CMake before. After a little bit of setup - installing Vulkan SDK, fixing an incorrect SDL2.dll, and fixed some working directory shenanigans: The engine finally ran! Except... Only a single frame was visible.
For some reason, her program crashes after the first frame was drawn on the line:
```````
vkQueueSubmit2(graphicsQueue, 1, &submit, getCurrentFrame()._renderFence));
``````
I think it has something to do with the graphics queue or the render fence, but without a proper full debug session it is hard to confidently assert. Nonetheless, the engine on her computer had successfully pushed a single frame - and behold:
It was clean! This verified my suspicions and I can finally search up a solution to this issue. After maybe 5 minutes of looking up, I stumbled upon this thread on [Reddit](https://www.reddit.com/r/vulkan/comments/15r6hza/bindless_textures_cause_artifacts_on_integrated/) which led to the following 2 articles
from [Anki 3d](https://anki3d.org/resource-uniformity-bindless-access-in-vulkan/) and [Adam Sawicki](https://asawicki.info/news_1608_direct3d_12_-_watch_out_for_non-uniform_resource_index), describing precisely something I had done in my own shader code. After implementing `nonuniformEXT`, my textures appeared as they should.
What an ordeal to go through to be simply fixed by a few lines of code.
(###) **Music**
I'd like to end this entry and all future entries with the albums I have been listening to over the past month. This month goes to The Beatles, Jack White, Dave Matthews, Blur, and a little bit of Mastodon.
[The Beatles - Abbey Road](https://open.spotify.com/album/0ETFjACtuP2ADo6LFhL6HN?si=Gx38Q09gQOS7706ONcwXdw)
[The Beatles - The Beatles](https://open.spotify.com/album/1klALx0u4AavZNEvC4LrTL?si=FkvzTmQhQHiF8Yv_XfhF0w)
[Jack White - No Name](https://open.spotify.com/playlist/0V5F580tsVT06OBVPZLEio?si=5af0d0114eed4257)
[Jack White - Fear Of The Dawn](https://open.spotify.com/album/46qeiLBu3KwqFQpJBT7t6B?si=rlOeAkGLSiGJOwJxWOWMoQ)
[Dave Matthews - Walk Around The Moon](https://open.spotify.com/album/2hCtza1F54WPNrX8MC1jRM?si=H0tXlrRXRKGeqm56eyigZA)
[Blur - The Ballad of Darren](https://open.spotify.com/album/0gIZSG9WUDO3TK0B5y7UtU?si=NWRkpT9FR16GCqXeaGKvfg)
[Mastodon - Leviathan](https://open.spotify.com/album/6khFoLWnJZDQvZ7Pijym3b?si=zTAEa9bXQmG_bFfp5FRf-w)
Please feel free to suggest me albums!
Email: twtw40@gmail.com