If anyone wants to experience something like that today, just follow an introductory tutorial on Vulkan programming. Vulkan is a programming model that gives so much low-level control directly to programmers. As a result, this "Hello Triangle" example became (in)famous for its need to implement a skeleton of a full 3D engine in thousands of lines of code before you can render a triangle on the screen.
https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Base_co...
That tutorial is a general overview of all the possible boilerplate you would expect to see in a template project, and just happens to end in a triangle being drawn on the screen.
You could skip a lot of those steps. Is that 5 page section on constructing validation layers and fine tuning the debugger really necessary if your end goal was a triangle?
You can draw a triangle in Metal in thousands of lines of code too. And it’s common to have several hundred lines of pipeline descriptors, buffer management, and debug tooling before you even started encoding into your shaders. But it’s not necessary for _just a triangle_.
Drawing a triangle is not the end goal. That's nonsense.
https://github.com/ocornut/imgui/wiki/Image-Loading-and-Disp...
DirectX9 will even load the image for you, DirectX11 okay we get a few more structures to fill out, DirectX12 is where it goes off the rails and we are filling out a bunch of UNKNOWN DONT_CARE JUST_DO_IT. Then of course Vulkan is the one that gets the big fat "this probably won't actually work for you" warning.
I understand whats happening, but you know sometimes I just want to display a fucking image.
It's funny I always thought C gamedev would be hard, I just didn't think the hard part would be the "hello world"... I'm looking forward to actually building the game now!
(My experience is more like "the triangle that should take a day", but I still thought it was relevant as a kind of major milestone that puts you in a qualitatively new reality where now you have an actual working thing you can fiddle with.)
Now when I circle back to my full text search extension for Postgres I can do so knowing I can replace my naive inverted index with something that gives like a 10% performance gain but more importantly significantly reduced and CONSTANT memory profile.
On it's own however, it doesn't seem to do much and unless you're in the space you won't appreciate why this is an interesting implementation.
The code is public: https://github.com/iantbutler01/dart
The trick I've discovered is that maximizing self-interest eg: maximizing your recognization of efforts (and for everyone else working on the project) is the best way to deliver long-term actual customer value.
So you put out some hype in the org first, build your black triangles internally, and then when you connect customer value, then connect the hype with results.
I think a part of it is that humans, or at least those that make their way into management, are in large part very visual creatures. If you can’t show them progress in a traditional visual way you sort of have to figure out some contortion to show some visual thing to use as a proxy of progress to keep the faith. Sometimes it can be achieved through selling some abstract progress metrics about work remaining (most often entirely detached from reality) but that only works so long.
More often you end up knowingly spending a large percentage of resources on vacuous side projects solely because they demo well to management in the short term — it’s a distraction but a way to keep the faith and the resources. I find it funny how much time and energy we’re willing to waste to play the game — paying the souped up visual taxes for decision makers, while doing the real work independently, often in the dark because we know management will react short sightedly to the black triangles.
working on these sorts of building blocks for big
wins will often actually result in projects and teams
getting axed.
Had this experience at a previous position. My predecessor had implemented a solution that was extremely hairy, and took many hours to run in production.My manager (a software engineer himself, still involved in day-to-day engineering on this product) said that it couldn't be meaningfully bettered. But in the meantime, we were taking a beating from our primary customer upon whom we depended for ~75% of our revenue. I viewed this existing solution as a potential company-killer.
So I spent some nights and weekends hacking together an alternative. Got the run time down from several hours to thirty seconds using some basic caching and a basic tree structure... not exactly advanced black magic. It also required about 50% less code.
I excitedly showed it to my manager. I walked him through the code. He became angry for the following "reasons."
1. Instead of making the code smaller, he felt it made the code larger. This is because he failed to comprehend that my MVP "hey this is possible" prototype didn't actually remove the old solution. It was just an MVP! I explained this to him but apparently it didn't take.
2. He couldn't understand the underlying concept. Again, it was... a tree. Something you would encounter in a 200-level computer science course, at the very latest.
3. My code lacked tests. Again... this was a "nights and weekends" MVP.
Probably the single fucking stupidest moment in the history of my career. I am not a person who typically has communication issues with managers or coworkers. I was dumbfounded that he was dumbfounded and to this day I am absolutely baffled by this whole incident. Our relationship had been deteriorating somewhat but not to the extent that would explain his brain-dead and hostile response.
Unsurprisingly this lead to my departure from the company.
There’s the problem!
I’ve had this experience many times — people will internalise their limitations and assume that their best is the best possible. Etc..
When a junior employee just casually proves them wrong, calling the emperor naked, that makes them feel inadequate and even ashamed.
I’ve been involved in many similar scenarios. Often there is a history of meetings, consultants, vendor techs, etc… trying to fix the problem and then a grudging acceptance and business workarounds. To suddenly reveal all of that as a lie is to undo established history. It’s like trying to close down the Vatican and tell all the priests to go home because you found a “neat proof” that there is no God. To say that you’ll experience some disbelief and resistance to your ideas is an understatement!
I had one of these moments where I got a nightly report batch job down from 3 hours to about 5 seconds. The customer turned red in the face, screamed at me, accused me of lying and stormed out of the meeting room.
Turns out that guy had to stay back each night to make sure the job ran successfully and so that he could sign the print out officially. He’d accepted the impact on his personal life, after many arguments about his work hours with his wife, etc…
To have all that sacrifice and suffering instantly made superfluous!? Ouch.
I wish I could figure out, as a candidate, a good question to ask in order to suss out which kind of company is interviewing me.
> By the end of the day, we had complete models on the screen, manipulating them with the controllers. Within a week, we had an environment to move the model through.
The Black Triangle was a leading indicator of a payoff that began happening by the end of the day. Too many similar projects result in a constant string of promises that we are just about to turn the corner on velocity/capability if only we would let the engineers focus on this refactor for a bit longer.
In practice, "Black Triangles" projects are bets like any other. If they work out, they unlock faster velocity and the ability to deliver better features. Often they deliver nothing but a refactor to someone's idea of a better architecture, and are lucky to ever reach breakeven on engineering time.
...Maybe they shouldn't be making their way into managing engineering then?
To be fair, the lady in question, Jen, did come around in the next paragraph. However, it still highlights the extremely annoying problem of doing non-visual work under visual(-only) people -- one then has to actively create visuals.
This quote from Feynman expresses a similar idea: https://fs.blog/richard-feynman-on-beauty/
...What part of being a financial controller and acting HR is "managing engineering"?
I once worked for months on a modern front-end for an incredibly old legacy system. This was so technically challenging that we weren’t sure if it could be done at all, so a functioning demo was a huge achievement.
What the customer saw was that it was ugly: black and white, plain text, no CSS, no styling of any kind.
They completely ignored the technical milestone and spent an hour asking if we could rearrange the buttons and change the colours. Bike shedding, in other words.
Since then I would much rather show something that’s very pretty but completely broken.
Me: Look at this dot!
Mom: You put a dot on the screen?
Me: Yes! Now hit the keys! You can move it!
These days he works for a VR company, but his main creative activity has been writing sci-fi/fantasy/horror novels for some years now, and he has his own series.
PS. I was going to say this article was from way further back than 2014, but on reading the post it appears it was his own repost.
I only got as far as point cloud (the wireframe without the wires, heh). Want to continue the project and add lighting and texturing eventually.
My "big insight" (shower thought) that gave me the confidence to do 3D is that you don't need linear algebra. You can do it all with trig! A 3D rotation is just three 2D rotations!
It won't be very performant, obviously, but I'll take "my toy renderer runs slowly" over "it doesn't exist because I am struggling with linear algebra for the 7th time".
It's a lot more fun doing things the easy way! Even perspective is one line of code.
Haha I could not agree more
It was only after I wrote a couple of games that I realized that extracting this OS component would be worth the effort and after that making new games went substantially quicker.
Your analogy and definition is one reasonable viewpoint, that the OS is the thing that bootstraps software on top of hardware and provides access to resources like memory, filesystem, network, and display, but it’s also an incomplete definition. An OS provides a standardized environment for whatever processes run inside it. In that sense it doesn’t matter whether or not it’s contained in a different OS. Ubuntu doesn’t suddenly become not an OS when you run it in a VM, it still provides the Linux OS to the processes that run inside the VM. Windows doesn’t become not an OS if it boots on a hypervisor. Similarly, even if an OS requires another OS to run, when it provides a different environment or container, it’s still serving the purpose of providing a specific Operating System to the software it runs.
Some consoles used to not provide an OS at all, the game provided all of it. The developer was responsible for handling things that would (and should) otherwise be the purview of the OS or drivers, power loss, out of memory, cables yanked, etc., otherwise they would not be allowed to publish. Nintendo did this longer than the others, in my recollection of events.
The point was: to make a game function you have to perform the bulk of the functions that an operating system performs and the similarities are greater than the differences.
If you can't call those "OS"s, than what really is an OS?
I guess it's turtles all the way down.
> almost every serious game is a complete more-or-less real time operating system
Games tend to have very different requirements and different demands from the OS; they tend to regulate the OS to being (mostly) a hardware abstraction layer. In the late 1990s and early 2000s, it was a lot harder to run games on Windows NT versus Windows 9x because DOS was a lot better at getting out of the way of games.
Related concepts:
Egg of Columbus: https://en.wikipedia.org/wiki/Egg_of_Columbus
Hindsight Bias: https://en.wikipedia.org/wiki/Hindsight_bias