Since i last wrote anything, my wife became pregnant and i became a dad late last year. That kind of put the fun programming side work stuff on hold for a bit. Although i can say becoming a dad is probably my greatest accomplishment and i wouldn't trade the time I've spent with my family for the world. I've spent a lot of my dad time with of course the family, but also cycling and training Brazilian Jiu Jitsu. Getting ready for my second comp in 3 weeks. The cliche really is true that software devs love BJJ for its problem solving workspace, however i tend to bring a brute force persistent wrestling style to my rolls. The old adage rings true, "you roll like your personality".

Professional life

In my professional life, I'm still a software engineer, in the last year i managed to be promoted to a mid level engineer and aboard a bunch of reshuffling of teams I've taken on a bunch of responsibility and feature leading which have left me feeling equipped for a senior engineer role in the near future. My current job has me in the weeds with Java which has been super fun. My latest work before paternity leave, were forking a massive open source repo and converting it into something we could use to save a bunch on licensing that had been changed from under us. That was super fun, as it was one of my first forays into leading a bigger dev team. I had the privilege of seeing the project out start to end, co-coordinating across teams and architecting the rollout of this library into product. As well as working on some cloud connector work with another newer senior engineer and getting him up to speed with our ways of delivering features at my company.

Personal Projects

I'm still messing with graphics programming, I've built a few proof of concept conveyor systems in c that work, but never took it further than that. I was focused on using Sokol as my helper library but kept getting drawn to lower level stuff like OpenGL and Vulkan. Just recently i finished howtovulkan.com and feel like i have a solid understanding of the end to end pipeline of how Vulkan works.

My latest personal project is back with OpenGL, and is currently learning about shaders and all the different fun that comes with that. I've been reading out physical simulations of CRT's using shaders, as well as OpenGL 4.6 and the compute shaders that were introduced in 4.3. I'm super interested in compute shaders for parallelizing particle based simulation systems.

Closing thoughts

I thought i'd finally write something now that it's early, my kids asleep and i get some time to do some personal project work before the day starts. I think the best thing for me is that although it may not feel like much got done in my personal projects, i think professionally in this time I've come a long way. The ability to lead and organize multiple engineers to complete a complex project, was always something i assumed would be out of reach for me. However i really enjoyed it. The expectation to manage multiple streams of context were super challenging but rewarding at the same time. It leveled me up as an engineer and allowed me to perform and be more effective in my day to day work.

Hopefully my next blog isn't 1+ years away.

Until next time.

Small update from me this week. I worked a bit on my renderer early in the week but spent the rest of the week aggressively training Jiu-jitsu. So what exactly did i work on. Well i had previously been toying with a framework known as sokol in c. It’s a graphics abstraction that handles cross platform compilation really well. I highly recommend you go and check it out.

https://github.com/floooh/sokol

floooh is a genius and their work on this project is really really cool. It’s been a joy working with sokol.

So what did you actually do?

Right, so i stood on the shoulders of giants. There’s this great game developer named Randy who uses odin and sokol and promotes it quite extensively. Check them out here. Randy provided a pretty good skeleton for rendering in odin using sokol. I spent the early parts of the week cleaning up his code and moving it to a multi file structure so that it can more easily be worked on.

I also edited the code to handle movement on both the x and y axis instead of just the x. Removed the gravity that was applied in the demo & spent a lot of time reading and understanding how rendering was done in sokol. It essentially just a nicer abstraction on OpenGL.

1. You set up an index buffer. In this case we’re drawing quads so the index buffer is set up to draw those.

    index_buffer_count :: MAX_QUADS*6
        indices : [index_buffer_count]u16;
        i := 0;
        for i < index_buffer_count {
            // vertex offset pattern to draw a quad
            // { 0, 1, 2,  0, 2, 3 }
            indices[i + 0] = auto_cast ((i/6)*4 + 0)
            indices[i + 1] = auto_cast ((i/6)*4 + 1)
            indices[i + 2] = auto_cast ((i/6)*4 + 2)
            indices[i + 3] = auto_cast ((i/6)*4 + 0)
            indices[i + 4] = auto_cast ((i/6)*4 + 2)
            indices[i + 5] = auto_cast ((i/6)*4 + 3)
            i += 6;
        }
        app_state.bind.index_buffer = sg.make_buffer({
            type = .INDEXBUFFER,
            data = { ptr = &indices, size = size_of(indices) },
        })
   

2. Then set up your pipeline with some shader specific data, set up a swap chain & bobs your uncle.

    pipeline_desc : sg.Pipeline_Desc = {
            shader = sg.make_shader(quad_shader_desc(sg.query_backend())),
            index_type = .UINT16,
            layout = {
                attrs = {
                    ATTR_quad_position = { format = .FLOAT2 },
                    ATTR_quad_color0 = { format = .FLOAT4 },
                    ATTR_quad_uv0 = { format = .FLOAT2 },
                    ATTR_quad_bytes0 = { format = .UBYTE4N },
                    ATTR_quad_color_override0 = { format = .FLOAT4 }
                },
            }
        }
   

   I’m glossing over a bunch here, but its the basic setup for a graphics pipeline.

   

   So what’s the outcome of this weeks work?

   A cute little guy who moves in the cardinal directions & some code that has been cleaned up to be extendable for tile loading and processing next week.

So what’s this weeks lesson?

There are far smarter programmers than you who have done the hard yards to understand very complex ideas in code. It’s okay to stand on their shoulders, learn from them and extend their work to work for you. It’s one of the greatest things about open source software! You should never feel bad for taking some code, extending it, learning from it, and morphing it to suit your own needs and learnings.

What did i get up to this week?

Well i really wrangled around with odin and raylib this week, while also working on some conveyor belt logic for a pretty rudimentary system.

This system had some good ideas. Namely how pathing would work. This was achieved by when placing a conveyor all the conveyors in the cardinal directions would update to see if they needed to change their target conveyor.

Here you can see that i’m drawing a line from each conveyor, to its logical target conveyor. You’ll also note that conveyor paths are independent. They’re not stored, we can just traverse a conveyor starting anywhere, and follow the target until it’s nil and then terminate.

Some of you keen eyed readers might notice these co-ordinates seem really stupid (they are). This is my first foray into graphics, game logic programming, traditionally coming from the corporate world and more of an OOP background at my current job. This kind of leads up to the big lesson i learnt this week…

If your foundation sucks, it’s really hard to write good code on top of it.

I learnt this the hard way when i spent more time struggling with my rendering and entity code than i’d like to admit. I kind of jumped the gun, got a bit excited to program some conveyors and didn’t realise how crap it was to always go back and fix things because they weren’t in place properly.

I can say though i learnt some cool ideas about conveyors this week, and game programming in general. I learnt how an atlas works, how textures are loaded and handled in raylib and how awesome it is to program in odin.

What are my key takeaways from this week?

I’m going to strip back this project and tackle one problem at a time. If i want to stop fighting with my renderer, i need to make it more complete. This means dedicated calls like draw_sprite() which can take an entity object of my choosing and render to the positions defined in it’s structure. I also need to have a better understanding of screen space and world space. I’ve started to understand it, but am unsure if when i draw a rectangle using raylib that im drawing to screen or world (I will test this).

If anything i’ve learnt i need a solid foundation before i can get to the fun stuff. Having a robust rendering solution isn’t super glamorous, and it’s keeping me away from the fun programming.

There’s some great cool things i did this week though. I learnt how to check neighboring tiles and update them based on changes to their surroundings. I also learnt a very rudimentary linked list based pathing system. Also picked up odin and raylib for the first time and gave it a solid crack.

Am i super proud of this work? no. Am i happy i did it. yes.

I learnt a lot of valuable lessons in software planning. Sometimes its okay to cowboy it, you’ll get where you need to go. But at the start of the project, is not the place to cowboy it.

Thanks for reading

Odin.

Favourite Language?

C.

Language i work in?

Java

Where im from?

Australian developer interested in game development from scratch. Currently working on a factory automation RTS.