ZDoom

I re-exposed pixel stretch as member variable in 996bddd.

If somebody wants to get rid of FLevelLocals and export level_info_t directly then he/she is welcome.
Until that moment let's keep existing interface consistent.

@Major Cooke: That was strictly in context of converting from Fixed point to doubles. Remember that bug with the model interpolation where all the models suddenly got real janky?

That was because the "float" structure was being overflowed. The same thing will happen with certain ACS-to-ZScript calculations.

From what I understand "double" is better on performance anyway so I tend to avoid using "float" at all, but if "float" is needed (such as passing uniforms to shaders in the GL renderer) they should be fine, depending on how they're used. (Float can only gracefully handle smaller numbers without precision loss)

Most of game engine uses floats for everything. Some can be customized to use doubles.
But it’s very common to pack 3 or 4 floats into one 128-bit SIMD type. Quaternion is the same as 4 component vector, matrix uses 3 or 4 such vectors, etc.
Doubles double memory requirements for such data and performance is often worse than with floats. The latter point is quite hardware dependent though.

I forgot that it actually deals with the renderer itself and all of those utilize floats heavily.

And how is this applicable to our topic? You need more than 6 significant digits for pixelstretch, right? I think two or three "ought to be enough for anybody".
Although if you plan to do lots of calculations with values of various range then it makes sense. But not if you are about to store one read-only value then it's not.
Generic suggestion like "do not use floats, use doubles" is the same as suggestions to "do not use 32-bit integers as they overflow quicker than 64-bit". Out of context this is plainly ridiculous.

Hmm... Well, I mainly say that because Rachael says don't use floats for zscript.

Rachael wrote:Remember to use doubles (I think ZScript supports them, right?) to store the final values. As you no doubt know, fractionals in ACS are fixed precision and are simply (xxxx.xxxx * 65536) when stored as its final value.

Don't use float because you will lose some precision. Floats can no doubt store the value, yes, but they do a terrible job of it.

EDIT: Added link to where I quoted her from.

Major Cooke wrote:Also also, that float in zscript should be a double, right?

No, C++ float and double both are fine to be exported as native member variables with ZScript's float type.

I didn't see you expose that until now.
Also I saw this and I thought that to be true.

Also also, that float in zscript should be a double, right?

I thought that the mentioned commit is self-explanatory. You had to search similar members in code, outsidefogdensity for example, and do the same.

I had no idea on how to do it that way instead of a function, honestly. By all means, do show how it's done. I'd love to learn how.

Leonard2 wrote:I still think the info type should be exported, anything else would just be a temporary kludge anyways.

Sure, please do it if you have ability to implement and test it.

I still think the info type should be exported, anything else would just be a temporary kludge anyways.

Mental's implementation looks better, IMO (no offense to Cooke!)

This should be done in a uniform way with other members.
Read-only field is more than enough here. Function is needed to do a lazy evaluation or calculate the value on the fly.

I originally wanted this as a member variable on the ZScript LevelLocals struct, but since info wasn't exported, I wasn't sure how that could be done. I'm happy with using it as a function, though it taking from level.info is probably a problem, yeah. If info could be exported, that'd be cool too - whatever works.