Export level.info->pixelstretch to ZScript

[Gutawer]

As the title says, I need this exported to ZScript so that I can finish off a HUDMessageOnActor-like function (for ZScript) using a perspective projection matrix. It's working mostly perfectly, but I need it to react to the pixel ratio dynamically and right now I don't think that's exported. A LevelLocals.pixelstretch field would be nice for this.

[Major Cooke]

All done.

[_mental_]

One question: why was it done with a function while others are fields a.k.a. member variables?

[Leonard2]

I wondered this too and here's a comment from base.txt:

Code: Select all

// level_info_t *info cannot be done yet.

Perhaps now is a good time to export this type.
On top of this, the function returns information from level.info rather than from the info given by the instance itself, was that intended?

[Gutawer]

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.

[_mental_]

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.

[Nash]

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

[Leonard2]

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

[_mental_]

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.

[Major Cooke]

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.

[_mental_]

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

[Major Cooke]

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?

[_mental_]

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.

[Major Cooke]

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

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.

[_mental_]

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.