Doing anything repetitive with a large amount of data by virtue of knowing about for-loops. There have been so many times where people wanted something done to a million users/objects/whatever and were surprised that I got back in 5 minutes. One of them even muttered the words "I thought that would take you all day", when actually 3 of the 5 minutes were spent getting a cup of coffee.
> How to workaround too little RAM problem? Let’s load pixel graphics if player is far away and call it mip mapping<p>Hold up, mip mapping is not a way to save RAM in fact it consumes more RAM because not only do you need to have the full-size texture in RAM you also need to keep smaller copies in RAM.<p>What it does save on is memory <i>bandwidth</i>, because you don't need to sample from the full-size texture for objects that are far away. And it improves visual quality, since you can use expensive scaling algorithms to produce high-quality downscaled copies.
<i>laughs nervously while trying to get performant 2D rendering of large tilemaps in their first game</i><p>I can barely begin to imagine all the pain involved in creating AAA games. Decades of whitepapers to read and build upon only to get to a point where consumers aren't downright angry at the quality of graphics being given to them.
> <i>1981 A first 3D game called Tempest is published</i><p>Battlezone is actual 3D, and 1980.<p>I'm not saying that is first, either, just that 1980 < 1981 and that Tempest is more of a form of 2.5D. (I remember it being an interesting, fast-paced game with good sound, but fundamentally it's just Space Invaders rolled into a tube.)<p>> <i>How to workaround too little RAM problem? Let’s load pixel graphics if player is far away and call it mip mapping:</i><p>MIP mapping is not primarily a RAM problem solving device. It's a way of precomputing the shrinking of texture images for when they appear in the distance, so that they don't have to be antialised on the fly.<p>Thus is a CPU saving device, and requires extra storage. However, not much more! The half-size texture needs only 25% more storage, and the quarter-size another 6.25% or so.<p>The renderer has to consider the depth and index into the appropriate scale of the texture. I don't remember all the details, but I see to remember that it's dynamic. Like when the textured surface is in deep perspective, the distant pixels are derived from the smaller scale data, while the near part from the larger scale.<p>It could save RAM if we can avoid the detailed textures for objects that require them and are all far away. I.e. lazily load the detailed texture as the objects are approached, and free the memory when they recede again.
"Create an account to read the full story."<p>What game developers are good at is not making slow programs. Everything else, from point of sale to web pages to phone apps, gets slower and slower.
First of all ray tracing was invented well before real-time rendering.<p>Second of all, all these difficult things are difficult things that game ENGINE developers are responsible for tackling nowadays.<p>In the 90s and early 2000s, most of the people building engines were laying down games at the same time, which is very much akin to building a railroad while running the train. For most folks (like me; I'm developing an indie VR game on the side) this is all handled by Unreal, Unity, or Godot.<p>I've tried to build a simple game engine in the past... you wind up reinventing the wheel a lot...
The think about programming that always gets me, is how things that sound very hard, can be very easy...<p>and things that sound very easy, can be very hard or impossible.
Debugging. It takes hours to pinpoint exact cause of anything more
complex than a toy program, especially when the bug
requires a combination of factors to manifest.
In most situations its much harder to debug code
that you didn't write, but it appears as if debugging
is "easy" because people do it on their own code.<p>Bonus(appear easy to do, but are actually hard):
Micro-optimizations that target a specific platform:
a combination of CPU-compiler-OS factors.<p>Porting software: There are tons of subtle unportable things
and assumptions that hide under the surface.<p>Rewriting X in Y:lots of footgun and like inexact
translation in natural languages can cause subtle bugs.<p>Makefiles and shell scripts: they look so simple,
but try debugging a moderately complex makefile
or shell scripts. Bash is especially sinister example.<p>Anything that talks to a closed/blackbox API or close-source library:
the dependence on code that you can't debug in general.<p>Maintaining software in general as it grows in complexity.
Um… programming?<p>Honestly, grab a random human and sit them next to you while you code a bubble sort algorithm or a prime number finder to see what I mean.
Can I say how much I hate Medium these days? Remember when it didn't suck and was doing such a good job of not sucking that all sorts of very serious people created Medium accounts to start blogging? What the hell happened, Medium?<p>I started reading this story, got about halfway down, and the story stopped and I got this big centered H2 reading "Create an account to read the full story."<p>Fine, I want to read the rest. I create an account. I go back to the story. Now the story still stops at the same place but the big centered H2 has changed to "Jorgi, read this story from Tom Smykowski — and all the best stories on Medium" and there's an "Upgrade" button. That was not our deal, Medium! You said I could create an account to read the full story.<p>So I click the button and it takes me to the signup page, of course on the "pay annually tab," with a small white button on a white background that reads 'monthly' for other options. Fuck you, Medium.