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.
My brother was given lines to write as a punishment in the early 80s. He wrote a for loop in basic and printed the result. The teacher didn’t know any better and was happy to accept the printout. Assuming he’d typed it all from scratch.
I had a colleague at a previous workplace who had studied game design at university unaware of what a for loop was when I showed him. It boggled my mind!
> How to workaround too little RAM problem? Let’s load pixel graphics if player is far away and call it mip mapping
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.
What it does save on is memory bandwidth, 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.
>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.
While that's how it's mostly used today, mipmapping refers to storing scaled-down versions of the same texture along with the original texture. You don't have to load all of them to RAM (or VRAM). You can simply store the mipmaps on a hard drive, and only load the required mip levels to the GPU, thus saving VRAM. This way, you are using mipmaps as texture LODs. Think about satellite images of Google Maps.
>What it does save on is memory bandwidth, because you don't need to sample from the full-size texture
Not exactly. It does save memory bandwidth, because you're sampling less texels and reducing cache misses, not because you're sampling from a smaller texture. You're simply not downscaling the texture on the fly, instead using precalculated downscaled pixel values.
laughs nervously while trying to get performant 2D rendering of large tilemaps in their first game
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.
Shouldn’t there be a "that" between "difficult" and "programmers" in the title to make parsing less ambiguous? I’m not sure if adding it would be grammatically correct
This. I feel fortunate that I didn't start out in tech - I didn't become a programmer until I was 30. I'd been working since I was 15 or so, so I'd had about 15 years of experience in various industries.
I think a lot of devs who go into comp-sci and land into tech right after college have very little understanding of how hard life can be outside of tech. This isn't an easy industry, but goddamn it's so much better than the vast majority of other options out there.
Programming isn't hard. It isn't easy either, but it isn't hard.
I think the thing about programming is that so much of the "old" world misunderstood how it was hard. There is a lot more creative process stuff involved with programming, and not nearly as much that is codified, that you need to study, as in other fields like physics. And so, it gives people wide leeway to footgun themselves. Just as much, going the other way, it puts a premium on the ability to think and reason in abstractions, to which point, we don't have as strong a "liberal arts" for the STEM world as we do for the literary / humanities / cultural world.
So yes, on one hand, programming is not as hard as physics (to make one example of it). But on the other hand, I knew a person or two doing research in physics who complained how much their work was held back because their colleagues didn't appreciate the effort it took to process all the data that came from their experiments. Folks didn't appreciate how critical all that code was to their research. We see this sort of dynamic replicated throughout the rest of the world.
I spent a summer in college working construction as a general laborer, making $20/hr. I was rich!! ...and every person on the jobsite said "stay in school, don't do this full time".
I've never experienced that same end-of-day exhaustion before or since doing construction (and I was a fit & healthy college student).
No matter how bad my day is, sitting at my desk and typing for a LOT of money, I know it's better than many alternatives.
> 1981 A first 3D game called Tempest is published
Battlezone is actual 3D, and 1980.
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.)
> How to workaround too little RAM problem? Let’s load pixel graphics if player is far away and call it mip mapping:
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.
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.
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.
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.
- it's a static perspective view, less complex than sprite based 2D
- it's implemented on a vector screen, where the cathode ray gun is drawing the lines instead of the software, not a bitmapped one
- almost everything can be precalculated and only vertex locations need be stored
Of course it's still a creative game, but not very hard to implement.
It should be noted that Battlezone wasn't actual 3D since everything happened on a fixed plane, but it had dynamic rotating shapes and the like so much more advanced.
> What game developers are good at is not making slow programs.
That isn't true. Many games, even really popular/enjoyable games, have really poor performance for what they do. And much of the performance that does exist is thanks to the people who work on the engine and not the game itself.
I'm not sure the average game-dev is any better at writing performant software than the average non-game-dev.
I do find it amazing how much leeway other industries have when it comes to performance compared to my native industry of gamedev. I'm constantly thinking about how to structure things to avoid dynamic allocations at all costs, reduce memory footprints, reduce branches, on top of balancing usual concerns like readability, extensibility, etc. This often means forgoing abstractions as often as is reasonable.
My coworker, bless him, who comes from a background in the financial industry once added a feature that involved making copies of 5 vectors of strings. Both the vectors and their strings were regenerated every single tick from c strings that permanently resided in memory, by way of multiple concatenations for each string. Profiling informed me we were now making some hundreds upon hundreds (sometimes thousands) of (re)allocations every 16.7ms. I diplomatically pointed out the wastefulness and he (partially) fixed the issue by changing 2/5 of the getter functions to return a reference. I could tell he was quite annoyed with me, and didn't really understand the issue. It's just allocating memory, how bad could that be?
First of all ray tracing was invented well before real-time rendering.
Second of all, all these difficult things are difficult things that game ENGINE developers are responsible for tackling nowadays.
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.
I've tried to build a simple game engine in the past... you wind up reinventing the wheel a lot...
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.
Bonus(appear easy to do, but are actually hard):
Micro-optimizations that target a specific platform:
a combination of CPU-compiler-OS factors.
Porting software: There are tons of subtle unportable things
and assumptions that hide under the surface.
Rewriting X in Y:lots of footgun and like inexact
translation in natural languages can cause subtle bugs.
Makefiles and shell scripts: they look so simple,
but try debugging a moderately complex makefile
or shell scripts. Bash is especially sinister example.
Anything that talks to a closed/blackbox API or close-source library:
the dependence on code that you can't debug in general.
Maintaining software in general as it grows in complexity.
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?
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."
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.
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.
WJW|2 years ago
jon_adler|2 years ago
echelon_musk|2 years ago
armada651|2 years ago
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.
What it does save on is memory bandwidth, 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.
atahanacar|2 years ago
While that's how it's mostly used today, mipmapping refers to storing scaled-down versions of the same texture along with the original texture. You don't have to load all of them to RAM (or VRAM). You can simply store the mipmaps on a hard drive, and only load the required mip levels to the GPU, thus saving VRAM. This way, you are using mipmaps as texture LODs. Think about satellite images of Google Maps.
>What it does save on is memory bandwidth, because you don't need to sample from the full-size texture
Not exactly. It does save memory bandwidth, because you're sampling less texels and reducing cache misses, not because you're sampling from a smaller texture. You're simply not downscaling the texture on the fly, instead using precalculated downscaled pixel values.
tomaszs|2 years ago
SeanAnderson|2 years ago
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.
ben_w|2 years ago
How large is a "large" tilemap?
And what is it that makes them particularly hard in the AAA space?
HumblyTossed|2 years ago
thiht|2 years ago
(Non native speaker)
saintfire|2 years ago
wly_cdgr|2 years ago
danielvaughn|2 years ago
I think a lot of devs who go into comp-sci and land into tech right after college have very little understanding of how hard life can be outside of tech. This isn't an easy industry, but goddamn it's so much better than the vast majority of other options out there.
lambdasquirrel|2 years ago
I think the thing about programming is that so much of the "old" world misunderstood how it was hard. There is a lot more creative process stuff involved with programming, and not nearly as much that is codified, that you need to study, as in other fields like physics. And so, it gives people wide leeway to footgun themselves. Just as much, going the other way, it puts a premium on the ability to think and reason in abstractions, to which point, we don't have as strong a "liberal arts" for the STEM world as we do for the literary / humanities / cultural world.
So yes, on one hand, programming is not as hard as physics (to make one example of it). But on the other hand, I knew a person or two doing research in physics who complained how much their work was held back because their colleagues didn't appreciate the effort it took to process all the data that came from their experiments. Folks didn't appreciate how critical all that code was to their research. We see this sort of dynamic replicated throughout the rest of the world.
jasonpeacock|2 years ago
I've never experienced that same end-of-day exhaustion before or since doing construction (and I was a fit & healthy college student).
No matter how bad my day is, sitting at my desk and typing for a LOT of money, I know it's better than many alternatives.
unknown|2 years ago
[deleted]
kazinator|2 years ago
Battlezone is actual 3D, and 1980.
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.)
> How to workaround too little RAM problem? Let’s load pixel graphics if player is far away and call it mip mapping:
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.
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.
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.
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.
dkjaudyeqooe|2 years ago
- it's a static perspective view, less complex than sprite based 2D
- it's implemented on a vector screen, where the cathode ray gun is drawing the lines instead of the software, not a bitmapped one
- almost everything can be precalculated and only vertex locations need be stored
Of course it's still a creative game, but not very hard to implement.
It should be noted that Battlezone wasn't actual 3D since everything happened on a fixed plane, but it had dynamic rotating shapes and the like so much more advanced.
Animats|2 years ago
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.
xboxnolifes|2 years ago
That isn't true. Many games, even really popular/enjoyable games, have really poor performance for what they do. And much of the performance that does exist is thanks to the people who work on the engine and not the game itself.
I'm not sure the average game-dev is any better at writing performant software than the average non-game-dev.
johnnyjeans|2 years ago
My coworker, bless him, who comes from a background in the financial industry once added a feature that involved making copies of 5 vectors of strings. Both the vectors and their strings were regenerated every single tick from c strings that permanently resided in memory, by way of multiple concatenations for each string. Profiling informed me we were now making some hundreds upon hundreds (sometimes thousands) of (re)allocations every 16.7ms. I diplomatically pointed out the wastefulness and he (partially) fixed the issue by changing 2/5 of the getter functions to return a reference. I could tell he was quite annoyed with me, and didn't really understand the issue. It's just allocating memory, how bad could that be?
cstrahan|2 years ago
https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
https://news.ycombinator.com/item?id=26296339
LarsDu88|2 years ago
Second of all, all these difficult things are difficult things that game ENGINE developers are responsible for tackling nowadays.
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.
I've tried to build a simple game engine in the past... you wind up reinventing the wheel a lot...
AndyNemmity|2 years ago
and things that sound very easy, can be very hard or impossible.
hermitcrab|2 years ago
kayodelycaon|2 years ago
https://xkcd.com/1425/
I also like the “uncrop” photo enhancement from Red Dwarf.
globalise83|2 years ago
countWSS|2 years ago
Bonus(appear easy to do, but are actually hard): Micro-optimizations that target a specific platform: a combination of CPU-compiler-OS factors.
Porting software: There are tons of subtle unportable things and assumptions that hide under the surface.
Rewriting X in Y:lots of footgun and like inexact translation in natural languages can cause subtle bugs.
Makefiles and shell scripts: they look so simple, but try debugging a moderately complex makefile or shell scripts. Bash is especially sinister example.
Anything that talks to a closed/blackbox API or close-source library: the dependence on code that you can't debug in general.
Maintaining software in general as it grows in complexity.
diydsp|2 years ago
diydsp|2 years ago
loloquwowndueo|2 years ago
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.
CobrastanJorji|2 years ago
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."
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.
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.
musicale|2 years ago
schoenobates|2 years ago
https://archive.ph/fh12P
IshKebab|2 years ago
tomaszs|2 years ago
zeppelin101|2 years ago