Devlog #1

Project Setup

This was supposed to be covered a separate devlog, however posting the devlog failed and I simply gave up. Anyhow, I set up the project in quite a simple way, hoping to minimize the amount of bloat in the vendor directory. The project uses C++, Vulkan (my two beloved technologies) and CMake, which is a first for me.

Renderer base

So far, I’ve made use of GLFW to create a window and then used Vulkan to create a window surface and prepare the swapchain. What the swapchain in plain terms is that it makes sure you dont have to wait for the next frame to be rendered with a blank screen.

Next Steps

The next obvious step would be a graphics pipeline, however this time I’m thinking of going straight into rendering particles instead of the regular triangle. That would require a different (possibly instanced) .
graphics pipeline, more sophisticated shaders and of course, a compute pipeline, learning which is the very point of this project.

-# ignore assert failed please

I worked on creating the server itself, making it work correctly. To do this, I used the <arpa/inet.h> header. This is my first time doing anything like this, I’ve never messed around with servers and such. The trickiest part was definitely setting up the firewall, since the site did not work on other devices. Serving different MIME types without hardcoding wasn’t the easiest either. Despite that, I really enjoyed doing this, and I’m sure that once I get the ollama API linked using curl, this will surely be a great project to put on my Resume.

Objects Render now!

• Added Circle rendering using unit circle scaling & translation
• Added Rect rendering by well, generating a rect
• Changed coordinate system from (-1,-1)-(1,1) to (0,0)-(width, height)
• Fixed crashing on exit by adding UserObject::Destroy()

How it went

Being fair, it was quite simple once I actually understood the math, which was the hard part.
All it took was scaling unit circle coordinates (which are sin theta, cos theta) by the radius and translating them by the center. Another difficult thing was figuring out how to correctly scale the objects, but I achieved that by scrapping pixel-normallized conversions and changing the entire coordinate system into a pixel-based one (for the scene at least).

A small tweak of how the objects are structured, I added the ke::nodes::UserObject to encapsulate shared behaviour between Node2D and Node3D, without passing said behaviour onto SystemObjects. Such behaviour is, for example: Drawing to the screen.

First devlog here, gonna recap what I’ve done after flavortown ended.
Mainly, I created an object hierarchy and a tree-based object structure. This allows for easy displaying and manipulating said objects in the future, and the inheritance covers common behaviours of the classes. This is the first game engine-specific feature I’ve added and will allow the user to interact with the scene more independently rather than me having to add specific ways for them to do so. This project is building upon what I built during Flavortown, and I’m glad I can share what I’m working on again.