Ace17

> The most impressive one so far is making a port of a ~100 KiB Linux a.out i386 program to a native Windows PE i386 executable, despite not having access to its original source code or even decompiling it.

This is indeed really impressive!

(direct link: https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html )

You mean, having wrapper classes over the C primitives?

Wouldn't this defeat the purpose of having an immediate-mode API ?

Quite the opposite IMHO : when your program interacts with a user, you cannot panic the program each time something unexpected happens. Here are some examples of unexpected conditions:

- "Null pointer dereference"

- "Out of memory"

- "Disk is full"

- "File does not exist"

- "File does not exist in cache"

- "File exists but is corrupt"

- "Access denied"

- "Connection reset by peer"

It's pretty obvious that all of the above is generally unwanted most of the time.

However, putting them all in the same bag labeled "error", and forcing them to be treated the same way might be counterproductive. Sometimes you might want to panic. Sometimes you might want to retry. Sometimes you might want to ignore!

Now, if your program isn't interactive (such as a compiler), halting on any error might be a choice. But you still have to provide contextualized and accurate error messages, which is easy for the case "File does not exist", and a lot less easy for the case "Out of range index".

Technically, `throw` is `goto somewhere`.

> But as natural as causal reasoning feels to us, computers can’t do it. That’s because the syllogistic thought of the computer ALU is composed of mathematical equations, which (as the term “equation” implies) take the form of A equals Z. And unlike the connections made by our neurons, A equals Z is not a one-way route. It can be reversed without changing its meaning: A equals Z means exactly the same as Z equals A, just as 2 + 2 = 4 means precisely the same as 4 = 2 + 2.

What about Prolog ? How is it not a counter-example of this ?

> I was curious to see how the self-correcting mechanisms of science would respond [...] > I was disappointed by the response from Southwest University. Their verdict has protected [a fraudulent researcher] and enabled him to continue publishing suspicious research at great pace.

The self-correcting mechanisms of science can only correct knowledge. Those mechanism work mainly by requiring the research works to be checkable by others. Self-correctness emerges by the accumulation of checks on the same topic, all leading to the same conclusion, and by the progressive retractation of bad research ... not by the elimination of "bad researchers".

Efficiently "correcting" people, whatever that means, is a different beast. Such a mechanism belongs to an administrative entity who can emit decisions - and, by construction, who can make errors.

> You learn how to use it, but you don't learn the proofs behind it?

Which makes sense, at least firstly, considering that understanding a proof is a lot easier when its conclusion is already familiar.

It depends on how the physics engine has been integrated into your game/engine. The book "Game Coding Complete" shows how to isolate a 3rd-party physics engine so you can switch implementations.

Of course, every physics engine behaves a little differently from the others, so, if you game is physics centered (pinball, racing), switching implementation might result in a slightly different game - but having the core of your game depends on the implementation details of some 3rd-party library might not be a good idea anyway.

In general, the more you sprinkle your code with dependencies to 3rd party libraries, the less control you have over the resulting product.

Your point still stands, though, for some very low-level "utility" libraries like boost or the STL, or any standard library replacement , and more generally, libraries holding "vocabulary" types.

> You do not live in a video game. There are no pop-up warnings if you’re about to do something foolish, or if you’ve been going in the wrong direction for too long.

In the good old times most video games weren't like that.

It's a pity that those times are gone, to the point video games are now used as such a comparison point!

Facebook and Google anyone ? :-)

``` In this sense, the lock in lock-free does not refer directly to mutexes, but rather to the possibility of “locking up” the entire application in some way, whether it’s deadlock, livelock – or even due to hypothetical thread scheduling decisions made by your worst enemy. That last point sounds funny, but it’s key. Shared mutexes are ruled out trivially, because as soon as one thread obtains the mutex, your worst enemy could simply never schedule that thread again.

[...]

A final precision: Operations that are designed to block do not disqualify the algorithm. For example, a queue’s pop operation may intentionally block when the queue is empty. The remaining codepaths can still be considered lock-free. ```

I don't get it ; how could "locking a mutex" not be considered as an "operation that are designed to block" ?

Would somebody be kind enough to tell me what am I missing here? Thanks !

Your hypothesis would explain a decrease in sales ; but can it explain an increase of negative reviews?

"We’re so spoiled today. Every week a newer, faster processor is released. Hardware gets cheaper and we can just throw more chips at the problem."

I've been running a 3.5GHz CPU (with 4 HT cores) for nearly 10 years.

That's a lot of weeks. Surely, today, I should be able to buy a 10GHz CPU, right? :D

I agree: if you only consider extra revenue, it's not worth the extra effort.

And yet, GNU/Linux is supported by many commercial games: Amnesia, SOMA, SpaceChems, Towerfall, Braid, HyperLight Drifter, Shovel Knight, Undertale, VVVVVV, Hollow Knight, Overload, WarGame Red Dragon ...

So there must be something else there than extra revenue.

No GNU/Linux version, for such a geeky theme ?

The game uses Unity3D, it might only be a matter of ... recompilation :D

Source?

> Why would I want to solve puzzles with known answers that thousands of people have already solved?

For the same reasons you might engage in any entertainment activity.

Real-life still-unsolved puzzles are hard ; whereas puzzle games keep the difficulty under some control (except for the infamous boat puzzle in The Witness).

Real-life problems are hard because, often, proper domain modeling/formalization is part of the problem. Puzzle games generally don't have this 'domain modeling' part, they provide you with an extremely consistent set of rules, and you have to build a solution inside it. Sometimes this set of rules is partly implicit, and discovering it is part of the fun (e.g The Witness, Antichamber) ; but you never have to worry about the real-world and it's complexity.

You can't have a unified opinion here.

There are some pretty good public game codebases (Penumbra/HPL, Quake I/II/III, Doom I/III), there are some okay ones (RedAlert), there are also pretty awful ones (Duke3D, Descent).

Note that this seems to be completely independent from whether the game is good or not!

Yes, obviously. But the message seemed to say that the constant speed of light implied that the derivative of the velocity with respect to time had to be zero.

> Also if the light wasn't moving straight that would mean it's changing direction, which is the same as an acceleration, and a beam of light traveling thru a gravitational field feels no acceleration, because it's not accelerating.

You could have both a deviation (i.e tangential acceleration) and a constant speed.

From what I understand, once you accept that gravity isn't a force, the usual symmetry between the earth and the apple doesn't hold anymore.

The apple doesn't curve space-time as much as the earth does.

So is the universe.

Backward compatibility isn't a technical issue, it's a political one.

If only GNU/Linux systems have had half of Windows' marketshare, obviously some choices about breaking app-level compatibility would have been very different.

> You should never compare two floating-point numbers for equality.

... when their values come from an arithmetic computation.

Here's a counter example: Quake's collision code makes extensive use of `if(trace.fraction == 1.0f)`, which basically means "could the whole move be done without colliding?". This makes sense, because `fraction` is explicitly initialized to `1.0f`, and gets potentially overwritten with lower values in case the ray intersects colliders.

This could also make sense when dealing with clamped values, e.g:

``` const float ratio = clamp(some_computation, 0.0f, 1.0f); if (ratio == 0.0) { // ... } ```

In both cases, the zero or one being compared to isn't a result of an arithmetic computation ; it comes from an assignment with a known constant (e.g inside `clamp`).

The Assimp library can load FBX. Considering how well Frictional's code is architectured this should be pretty easy to fix.

Maybe keeping the devs terrified helps making terrifying games? :D

I found Kairo to be a little gem in this style.

> IIUC, the 20% slowdown happens with a build that does nothing, it's just the scons overhead.

That's the whole point of performance measurement for build systems. The overhead is precisely what counts here.

If you have many source files to recompile, the fraction of time spent in the build system itself is going to quickly drop to almost zero : build-system stuff is generally several orders of magnitude faster than compiler stuff.

So it would make little sense to compare build-system performance on full builds.

Imposter don't present themselves as such.

Efficient doesn't mean "fast". It means that it minimizes the ratio "energy_spent / goal".

So if we're going to talk about communication efficiency, we need to define what's the goal being optimized here.

If a manager wants to minimize the time spent dealing with one of the engineers and wants to see this engineer quit, then the "cursory explanation" can be considered "efficient".

If this same manager, instead, wants to maximizes the odds the engineer stays and improves her/his weak points, then the "comprehensive" explanation might be a lot more efficient, despite requiring the manager to spend more time at it.