ZDoom

I need some math help. If I wanted to, for instance, convert A_Punch to an equivalent A_CustomPunch (let's ignore the issue with Berserk, for now), would I want to use random() or frandom() in the damage field? Will these even present different results in this scenario?

For reference, taken from the source for A_Punch:

Will these even present different results in this scenario?

Well, yes, because frandom churns out floating point numbers. You'd get results like 4.5, 4.7, 5.3, 7.2, 7.9 instead of 4, 5, 7 or 8, for example.

Yes, but those are then multiplied by 2, using (if I'm right...) integer math, which will turn the results back into integers. But what I'm unsure of is, does it round those values, or just truncate them? What's the endgame here, and which option is most faithful to the source code?

Also, A_CustomPunch only accepts an INT for the damage parameter, so it's going to be turned into an integer either way, isn't it?

Let's say you roll 4.5 with frandom. I'm not sure if the floating point value is truncated to integer before or after the multiplication.

If it's before: 4*2 = 8.
If it's after: 4.5*2 = 9.

The original codepointer would never produce an odd number such as 9. So if truncation happens after, frandom isn't "accurate"; otherwise it is. random will be accurate in any case.

Excellent, that's exactly what I needed to know. I guess I'll use random() when the parameter wants an INT.

However, if I'm trying to randomize something that accepts a float or an angle, then would I want to use frandom? I've been doing my best to teach myself how to read raw source, but it's still over my head, and I want to do things the way the engine would've done it.

Generally, I use random only for stuff that accept only integers - damage, inventory amounts, what have you. Everything else I use frandom.

Makes sense to me. I was just a little put off by how the raw source used frandom(), followed by integer math, and it made me uneasy about how it might affect the probabilities. It's been quite a few years since I dealt with the truncation of float-to-int conversion, and it's important to me that I match things as closely as possible.

Ed the Bat wrote:Makes sense to me. I was just a little put off by how the raw source used frandom(), followed by integer math, and it made me uneasy about how it might affect the probabilities.

Ah. You're getting confused by coincidence here.

frandom in DECORATE has a f for floating point, yes. But FRandom in the C++ code is a class, and the F there... Well, I'm not sure what it stands for, but it's not floating point; it's also used by some other generic classes such as FString and FName, as well as more obscure ones like FInternalLightAssociation, FLumpConfigFile, FOptionMenuItem, FPNGTexture, or FWin32Mouse.

The point is that FRandom in the source code is a class that gives random integer numbers. (Unless you use one of the class's dedicated floating point functions, but then it'll be blatant because these functions have names such as GenRand_Real1 and a quick grep through the code tells me this is only used in a couple place in one of the OPL3 emulators; but certainly nowhere in pure game logic.)

Aha! Thanks for that info. I was completely thrown off. Of course, that all stands to support what I said about my illiteracy regarding source code.

So, if I want to directly mimic internal functions like this, should I stick exclusively to random, instead of frandom in my DECORATE?

Also, I'm seeing random2() appear in the raw source. Is this another instance where the DECORATE function is completely unrelated? I'm getting in a bit over my head with this stuff.

Ed the Bat wrote:So, if I want to directly mimic internal functions like this, should I stick exclusively to random, instead of frandom in my DECORATE?

For mimicking internal functions, yes, but don't hesitate to use frandom if it suits your needs.

Ed the Bat wrote:Also, I'm seeing random2() appear in the raw source. Is this another instance where the DECORATE function is completely unrelated? I'm getting in a bit over my head with this stuff.

It is not, DECORATE random2 calls FRandom::random2.

Also, scarcely on topic, but are there still plans to migrate the game logic to floating points?

random2(x) is basically random(x)-random(x). The default value for random2() call is 255, so you can get a result between -255 and +255.