Angelus blog

Yesterday I experienced another bunch of fun while using my laptop. My normal working environment is a desktop with an AMD graphics card, while choosing a laptop it was important for me to get some Nvidia GPU so I could test code on both machines. This was a smart decision as there are so many differences between them. This time I encounter another one. History Like always a little bit of the background: while doing tooling you need to think about nice interactive objects selections. The beginning was rough as I decided to use a physics ray-trace system to execute picking. This was a simple system where I was sanding a ray thru the world and tried to pick objects that collide with it.  The issue was: every object needed to have a collision body  it did not work very well with objects that had an alpha mask  did not support geometry that was deformed in shaders. I did not like any of these limitations so I decided one day to change the whole thing. I took this time a different approach.

This is one of the recent issues that I was tracking This issue is pretty simple but because of that, its solution is not so trivial. So let's dig into it. The resource center is a standalone app that: Is a remote file system server  Integrate with Version Control System (currently P4) Is a resource server that is responsible for building resources Manage remote resource builders.  Manage the creation of game build Have UI which allows to browse the file system and trigger compilation of resources and build.   All communication uses TCP/IP sockets and most operations are async for performance reasons.  Recently I was doing changes to speed up the remote file system. I decided to switch all calls into async processing. While doing that I was put in front of the decision: Should I put all processing of connection read/write operations to a single thread? or maybe I should create a separate thread for each of them? I naively decided to go with a single-thread idea.  The whole code loo

In  Part 1  I described the configuration system in the engine. In Part 2  I described the reason and thoughts behind the topic: Designing intuitive API that makes sense. Now time for Part 3. This time we will analyze changes in script and reason behind it.  Compute shader script Let's start with the simplest compute shader script that doing anything : Compute {      ShaderFile  =   "sys://Shaders/ComputeShader.glsl" } New version: Compute {      Shader .Bind ( "sys://Shaders/ComputeShader.glsl" ); } This may look like a small change but it brings consistency to script. From now on there is only function style calls with ';' at the end. Defines Let's now add Define to script. In original format this would look like this: Compute {     Define ( "MY_DEFINE" )      ShaderFile  =   "sys://Shaders/ComputeShader.glsl" } The new one is more flexible and allows to do it in 3 ways: 1st: Compute {      Shader . Define ( &

In Part 1  I described how my configuration script system works. Part 2 will focus more on the real reason why I decided to write this post: Designing intuitive API that makes sense. The more I code and work on complex systems the more I see how important good API is. There is of course 1001 articles describing how to do that and if you are searching for one of them you are not in the right place.  My focus will be on my personal evolution in a way how I think about API. Whole thought came from improving compute shader scripts. They had a really simple form: Compute {      Define ( "MY_DEFINE" )     Reg (0) = UserImage (0, "Write" , 0)      Reg (1) = UserTexture (4)      Reg (2) = UserTexture (5)      Reg (3) = UserTexture (6)      Reg (4) = Texture ( "sys://Textures/Texture.dds" )      Reg (5) =  UserTexture (7)      ShaderFile  =   "sys://Shaders/ComputeShader.glsl" } This was nice but defining N users texture regis

This may sound weird in days where everything needs to have some kind of UI but the recent time I spend upgrading some of my configurations scripts. My current workflow is to define parsing rules and generate from them parser. To give you an idea what I talk about this is simple rules for the logging configuration file: %name     = LogConfig   %% .input : /* empty */        | LogAllow .input        | LogBlock .input        | AllLogBlock .input        | AllLogAllow .input ; LogAllow        : 'LogAllow' '(' $(CStringID) ')' ';' ; LogBlock        : 'LogBlock' '(' $(CStringID) ')' ';' ; AllLogBlock        : 'AllLogBlock' '(' ')' ';' ; AllLogAllow        : 'AllLogAllow' '(' ')' ';' ; %% It allows me then to parse a file that looks like this: LogAllow("Crash"); LogAllow("Assert"); LogBlock("Scripts"); LogBlock("Audio&qu

Interesting topic for a post came recently to my mind when one of my friends commented on me taking a day off from work to relax as: "Anyway, you will wake up that day and work." This was, of course, comment on me developing LBA remake in my free time. What is interesting about it I'm not fully sure what to think about it. Because how what I doing in my free time is different than other people's hobbies? On another hand how it is different than what I do in a work? What is a hobby? All of this thinking brought me to this simple question on which I don't have really a definite answer. In the end, what is a hobby for one person can be a work for others. There is a lot of examples of that:  riding a bike, skateboarding, painting, drawing, writing stories, creating graphics, woodworking, restoration of items, fixing electronics, traveling, singing, dancing and even stuff like cosplay.  All of that and a lot more can be a hobby but at the same time, it c