slipher

I don't think the current state of the interface is too terribly bad. Using `float*` as the interface at least has the advantage that it can be compatible with pointing...

Presumably the vectors come from the cgame. The engine must not make any assumptions on what comes out of there.

It means that "fixing code that generates NaN" is not an option. The engine should be prepared for any value coming from a cgame trap call.

We could change it to `isfinite`. The compiler doesn't warn on that and I assume that infinite vectors don't need to be valid either

Maybe we should turn off the finite-math-assuming flag in the engine for this reason. I think when writing the previous comments, I didn't understand how doing any operation on a...

#2299 was fixed so it seems we don't need it.

We now know how to detect floating-point overflows (#770 proposes making this more convenient). I don't believe there are other bugs associated with that. I cleaned up sgame to not...

I think it's probably safe to build *our engine* with a new compiler. In most cases a dependency on newer libc only appears if you actually use a new function...

Is there any evidence that the mover bug is actually related to a `nan > x` type condition? It could be one of those bugs that just randomly triggers or...

According to Git history, alien sense blips and old human radar could only detect entities in the PVVS.