Micha Mettke

Sooo tired of all these languages. Rust, Jai, Odin, Zig, C3,... Just give me struct, enum, union, basic types, if, for, while, switch and static arrays and I am happy. Everyone is trying to reinvent the world with their list of favorite features and perceived wisdom of what is right or wrong.

Also awe inspiring what our players are building in game

I don't often post about our game Enshrouded but seeing the great work our rendering team has done over the last years and the last patch is something to behold. Visually absolutely stunning. Especially since it is a voxel game which comes with its own challenges.

YouTube video by Graphics Programming Conference Realtime Global Illumination in Enshrouded

good talk, and some good solutions, despite the fact that i never hear about "Enshrouded", but could be just me & it is known game. The tech behind it sounds interesting.
Note: there are few more talks in the playlist about the same game renderer.
www.youtube.com/watch?v=57F1...

Absolutely hear you every time I implement it is bug prone and somewhat difficult to write the implementation (state-machine code, with all variables having to live in a context struct to be reentrant).

Always tried to think about that user comfort is more important than author comfort for APIs

API Design:Coroutine-APIs.md GitHub Gist: instantly share code, notes, and snippets.

Depends somewhat on the API and the problem to solve and if there are other resource requirements as well but personally I really like coroutine style APIs: gist.github.com/vurtun/192ca... (the zip example here is better than the json one).

YouTube video by Enshrouded Enshrouded - Pact of the Flame | Update 5 Highlights

Those detailing tools makin' me weak in the knees. Direct painting workflows FTW!

The #Enshrouded building system really is in a class by itself.

youtu.be/jXPG8Od_PzM?...

a man is standing in front of a shelf full of oxi clean ALT: a man is standing in front of a shelf full of oxi clean

Writing a Vulkan backend is a never ending "But wait there is more" meme of awfulness. Even with using 4 example from Github und AI.

Seeing all the great stuff you post Mikko about 2D SDF really calls me to implement more SDF outside circle as well :D.

Currently porting my App to Linux with Xlib and Vulkan and oh my god. Vulkan fits right into the usual Unix APIs. All orthogonal designed APIs are there but absolute no diagonal APIs. So just writing the code to pick a device and queue family turns into code screaming for bugs and inconsistencies.

Seems more like a fact at this point more than just a opinion :). Even read this sentiment from a younger dev influenced by Casey and Jon. He tweeted "The sign of a good programmer is having strong opinions and voices them as such". So equate being a good programmer with being an asshole.

Older devs (game adjacent now) looking down on new gen as not hardcore enough are full of shit.

My generation does old time consoles prog as a hobby. We would love to work on old consoles with time schedules of 6 month instead of 6+ years. Gamedev today feels like feeding dragons (hardware,content)

Senior Principal Programmer - PlayStation®5 Rendering API United Kingdom, London

This holiday season, give yourself the gift of wondering whether you'd enjoy working on the Playstation graphics stack and making life better for graphics programmers, because we're hiring for our rendering APIs! job-boards.greenhouse.io/sonyinteract...

This is what it looked like (left). Lots of different fonts, styles, row heights. Everything is a mess and hurts to look at for longer stretches of time. Meanwhile we use same row height everywhere (right). Same row height lets eyes get used to it and focus on the job and less on parsing noise.

Only exception are list elements with 3D previews or Images that need more visual space. Even then these we limit down to a multiple of our default row height to create visual cohesion. This constraint is the distinct reason why our editor looks very clean and easy on the eyes

As for different row heights. After investigating the old lumberyard editor and working on our editor we found out that it is very important not change row height. Especially for UI that is looked at for long stretches of time. All style and height changes are attention stealer and strain over time.

material_ui.c GitHub Gist: instantly share code, notes, and snippets.

Wrote my version with cutting here: gist.github.com/vurtun/2561f... to test it. Since all top level layouting is always header,content,footer I can do it intuitively at this point. I perfer to do the layouting first and then widgets. Sub-layouts always in function or scope to prevent messing up.

So far I haven't found a one fits all solution that fulfills both and is nice to use for either case. Either a lot of configuration has to happen to the higher abstracted API bloating everything beyond the more verbose API or a lot of defaulting is required that in the end becomes bloated as well.

The magic and ergonomics was always a bit of a balancing act for me. For quick UI for example debugging I prefer higher abstractions like the final example in my gist that combines layouting and widgets while for production level ui I always want full control and often very custom widgets

Oh also if not by function I try to make use of scopes to make it easier to notice bugs like that. Big advantage of layouting is that visually at least it is easy to see that something is wrong and scopes/functions helped me to find the source a bit faster

Btw I am always open to discuss or talk about anything related to ui and share my experience and have so in the past with a few people on discord. I am not very good at writing :)

It depends a little bit. I tried to split up my code so that every "big" split is basically its own widget and therefore function. So never try to layout everything at once unless I have to for a single row for example. So the number of rects to jungle is small. Still happend but fast to see and fix

I would be really interested in your specific example of complex layouting that is awkward to do with the rect cut API. Ironically Tau became spartan over time based on my experience of seeing more "complex" widgets breaking down under additional requirements in our editor.

What I personally also prefer is having an explicit rectangle parameter for each widget. So generating layout position and size is not coupled together with any hidden layout or ui system. Means it can come from anywhere

In my experience so far the value of per-calculating desired sizes is mostly interesting for text and at least for me holistically looking at complex UIs not really used outside of that. I think in our entire editor I see no real place were it is realistically necessary.

With rect cutting halt.software/p/rectcut-fo... at least for me I use two different widgets for labels. One I call "text" the other "label". Text takes as much spaces required while label only takes was is necessary. Also for have it for buttons. Never felt like I would need more than that.

For my own stuff I use this github.com/vurtun/tau/b... for flex box like behavior and use it like this: gist.github.com/vurtun/65fdc... which is really nice with C designated initializers. But honestly I not really used this once so far. Box-cut API is just so much easier.

Graphics Programming Conference 2024 - YouTube The Graphics Programming Conference is a three day event in November. We have keynotes from industry experts, presentations, and “masterclass” workshops with...

Graphics Programming Conference 2024 talks are up. Looking forward to learning the new Tomasz magic :) www.youtube.com/playlist?lis...

Being specified down to environment, language and limits is still an underestimated feature of C and major contributor to its success. Ironically the biggest downside is that often not specified enough. Yet no "modern" language did the same thing and rely on their implementation as "specification"

After a month of debugging, finally found the bug that caused cloth to explode. Biggest hint was lag but was expecting it on the client side but turned out in the end it was server lag of upwards of 250ms causing jumps that required teleport (in place) and a reset of cloth to skinned position.