HN user

Negitivefrags

6,790 karma
Posts4
Comments934
View on HN

I am not a fan of this take.

It's possible to not make an engine, or use a 3rd party engine. You just make a game. Use SDL or something. It's honestly easier and more fun. Definately don't use Rust.

It doesn't take two years.

The more you focus on making gameplay, and not making an engine the better. Which sounds like similar advice to "use an existing engine", but it's not, because using existing engines is also a pretty sad time. You can waste just as much time farting around in Unreal as you do making your own engine.

At the end of the day, most people are just not serious about making a game. Using someone elses engine, building from scratch, both will work if you are actually making a game and not just wasting time.

When the author said “bringing work home” they didn’t mean literally working at home.

They meant that they spend a huge amount of time feeling stressed about work situations at home.

I get the sentiment, but it's possible to go too far with the "It's always the process's fault" direction.

It's trendy in buisness culture right now to erase the individual. Zero accountability can also mean zero growth. I don't think it's honestly the most enjoyable situation to be in.

The way this position conforms to the interests of the capital class, and conflicts with those of the labor class, is a red flag.

If being in the office conforms to the interest of the capital class, it implies that WFH is inherently less efficient.

This is one of those things that I often find strange with work from home advocates. They seem to imply that business owners just want employees to suffer as a goal in itself.

People haven’t responded to your very first point, and I want to really stress it because I don’t think most people really get it.

Margins.

Game development doesn’t pay more because game development companies can’t afford to pay more.

Sure, an individual game dev company may make a lot due to the hit driven nature of the field, but the totality of the market simply makes less money per developer than big tech does.

In order for that to change, the market has to increase in size by appealing to a more casual audience, or existing gamers have to pay more. Not something I think most gamers would like. And these are the people who the workforce of game developers form from.

I guess the question is, since we know these things can happen, however unlikely, what mitigations should be in place that are commensurate with the harms that might result?

This isn't a defence of using LLMs like this, but this statement taken at face value is a source of a lot of terrible things in the world.

This is the kind of stuff that leads to a world where kids are no longer able to play outside.

Yes, there are a large number of ways to fall into traps that cause you to do a different series of operations when you didn't realise that you did. But that's still ultimately what all your examples are. (Except the NaN thing!)

I still think it's important to fight the misinformation.

Programmers have been conditioned to be so afraid of floats that many believe that doing a + b has an essentially random outcome when it doesn't work that way at all. It leads people to spend a bunch of effort on things that they don't need to be doing.

This is the kind of misinformation that makes people more wary of floats than they should be.

The same series of operations with the same input will always produce exactly the same floating point results. Every time. No exceptions.

Hardware doesn't matter. Breed of CPU doesn't matter. Threads don't matter. Scheduling doesn't matter. IEEE floating point is a standard. Everyone follows the standard. Anything not producing indentical results for the same series of operations is *broken*.

What you are referring to is the result of different compilers doing a different series of operations than each other. In particular, if you are using the x87 fp unit, MSVC will round 80-bit floating point down to 32/64 bits before doing a comparison, and GCC will not by default.

Compliers doesn't even use 80-bit FP by default when compiling for 64 bit targets, so this is not a concern anymore, and hasn't been for a very long time.

Cars are not popular becuase people pushed them. Cars are popular because the utility is undeniable.

This is true for any kind of transformative technology. Marketing and lobbying can only get you so far. If something has enough utility, it will be used regardless of what people say they want.

We use floating point operations with deterministic lockstep with a server compiled on GCC in Linux a windows client compiled with MSVC in windows, and an iOS client running on ARM which I believe is compiled with clang.

Works fine.

This is a not a small code base, and no particular care has been taken with the floating point operations used.

I've written a lot of code using that method, and never had any portability issues. You use types with number of bits in them.

Hell, I've slung C structs across the network between 3 CPU architectures. And I didn't even use htons!

Maybe it's not portable to some ancient architecture, but none that I have experienced.

If there is undefined behavior, it's certainly never been a problem either.

And I've seen a lot of talk about TLB shootdown, so I tried to reproduce those problems but even with over 32 threads, mmap was still faster than fread into memory in the tests I ran.

Look, obviously there are use cases for libraries like that, but a lot of the time you just need something simple, and writing some structs to disk can go a long way.

Well our game runs faster in DX12 under Proton than Vulkan under Proton.

Of course since Proton uses Vulkan to implement DX12, it means that our Vulkan implementation is simply worse than the one that Valve created to emulate DX12.

I'm sure it's possible to improve that, but it implies that there way to get the best performance out of Vulkan is less obvious than the way to get it out of DX12.

As a manager, this is 100% the answer. The people who do this are incredibly valuable.

At every performance review I tell all the people who don't do this that they need to do it more. None of them ever do.

For all I can tell, it's an immutable characteristic that 90% of people will never bring something up unless you ask them.

Hung by a thread 6 months ago

It's quite interesting to me the way that different "programming cultures" exist around debuggers.

If you grew up doing windows C++ development, looking at things in a debugger is your first step. You only resort to printing values if you can't immediately see what happened in the debugger.

A lot of other envioronment/language cultures are the opposite. Obviously both have their place, but I do feel like more people should use the debugger as the first step instead of the last.

Of course it’s the minimum standard, and it’s obvious if you view AI as a tool that a human uses.

But some people view it as a seperate entity that writes code for you. And if you view AI like that, then “The AI did it” becomes an excuse that they use.

At my company I just tell people “You have to stand behind your work”

And in practice that means that I won’t take “The AI did it” as an excuse. You have to stand behind the work you did even if you used AI to help.

I neither tell people to use AI, nor tell them not to use it, and in practice people have not been using AI much for whatever that is worth.

I think it's not unlikely that we reach reach a point in a couple of decades where we are all developing win32 apps that most people are running some form of linux.

We already have an entire platform like that (steam deck), and it's the best linux development experience around in my opinion.

I recently compared performance per dollar for CPUs and GPUs on benchmarks for GPUs today vs 10 years ago, and suprisingly, CPUs had much bigger gains. Until I saw that for myself, I thought exactly the same thing as you.

It seems shocking given that all the hype is around GPUs.

This probably wouldn't be true for AI specific workloads because one of the other things that happened there in the last 10 years was optimising specifically for math with lower size floats.

The person who runs the hotel isn’t doing it to house the homeless out of the goodness of their heart.

If a person abuses the shared kitchen, they get kicked out. This is a business. Maybe don’t do it next time.

And that is a good thing. It forces people to actually abide by the social contract.

And there will be people who can’t deal with that, and can’t live anywhere, but here’s the thing.

You need a first step on the ladder for people who are ready to actually enter society. Otherwise they never will.