Inide RPGs.

Gamezebo.

Indiegamemag.

Gaming Nexus.

In the meantime, you can check out the Minion Master website for more information about the game!

int main()
{
	RAND tRand;
	RandInit(tRand, time(NULL));

	unsigned int nRandom = RandGetNum(tRand);
	printf("%u\n", nRandom);

	return 0;
}

This is the code that the compiler generates for RandGetNum() in x86:

; Comments added by me
; For reference: v = 36969 * (v & 0xFFFFFFFF) + (v >> 32);
; edx:eax contains v
0137101B  imul        eax,eax,9069h  ; Multiply low part of V by 36969
01371021  add         edx,eax        ; Add multiplied low part and high part

Holy crap! That’s just TWO instructions for the whole thing! That’s even better than the 64-bit version! Speaking of which, what does that look like now?

; Comments added by me
; For reference: v = 36969 * (v & 0xFFFFFFFF) + (v >> 32);
; rax contains v
000000013F881024  mov         rdx,rax        ; Copy v into rdx
000000013F881027  shr         rdx,20h        ; Set rdx to the high part of v
000000013F88102B  imul        eax,eax,9069h  ; Multiply the low part of v by 36969
000000013F881031  add         edx,eax        ; Add multiplied low part to high part of v

Hmmm… That hasn’t changed much at all from the looped version we saw earlier. In fact, it’s exactly the same set of operations: move, shift, multiply, add. Something interesting does come out of this, though, and that is that the 32-bit code and the last two instructions in the 64-bit code are identical, which means that the preceding two instructions in the 64-bit code are just “ceremony”. That is, they’re getting the right data into the right registers for the later operations to “just work.” In the 32-bit code, the high and low parts are already split up by definition, since the only way to operate on a 64-bit register using 32-bit instructions is to split it up into two 32-bit registers. In the 64-bit code, there is an easy way to get the lower 32-bits of a register (rax is a 64-bit extension of eax in the same way that eax is a 32-bit extension of ax), but no built-in way to get the upper 32-bits other than copying the value and shifting it right.

Ultimately, we have to trust that the compiler has some understanding of what the code is doing, and how to translate that into efficient and correct machine code. It can be surprising, though, just exactly how much understanding the compiler has about what’s going on and what the best way to organize the code is. The whole point of these last two posts has been to delve into what the compiler is actually doing (don’t be afraid of the disassembly window!).

Your code is going to be running on a real computer, and having an understanding of what the computer is actually doing and how the code is executed is part of what makes a great programmer. It can be interesting, educational, and fun to see what code the compiler is generating.

Here’s a C-style version (but still compiled with C++ compiler):

// This is based off of George Marsaglia's post to Sci.Stat.Math
// http://www.bobwheeler.com/statistics/Password/MarsagliaPost.txt
// This is the Multiply With Carry random number generator, modified
// to use a single 64-bit seed to create a 32-bit RNG, rather than
// gluing together two 16-bit RNGs (and thus two seeds)

// Default V value is the conglomeration of the default Z and W values from the Marsaglia MWC RNG
#define DEFAULT_V_VALUE 0x159A55E51F123BB5

struct RAND
{
	unsigned long long v;
};

inline void RandInit(RAND& tRand, unsigned long long seed)
{
	if(seed == 0)
		seed = DEFAULT_V_VALUE;

	tRand.v = seed;
}

// Gets a number in the range [0, UINT_MAX]
inline unsigned int RandGetNum(RAND& tRand)
{
	tRand.v = 36969 * (tRand.v & 0xFFFFFFFF) + (tRand.v >> 32);
	return tRand.v & 0xFFFFFFFF;
}

// Gets a random number in the range [0, Max) (that is, from 0 to Max-1)
inline unsigned int RandGetNum(RAND& tRand, unsigned int nMax)
{
	return nMax ? RandGetNum(tRand) % nMax : RandGetNum(tRand);
}

// Gets a random number in the range [Min, Max]
// You will get weird results if Min is greater than Max
inline int RandGetNum(RAND& tRand, int nMin, int nMax)
{
	return RandGetNum(tRand, (nMax - nMin + 1)) + nMin;
}

// Returns a floating point number in the range [0,1]
inline float RandGetFloat(RAND& tRand)
{
	const float fInverse = 1.0f / (float)0xFFFFFFFF;
	return RandGetNum(tRand) * fInverse;
}

Or, if you prefer C++:

// This is based off of George Marsaglia's post to Sci.Stat.Math
// http://www.bobwheeler.com/statistics/Password/MarsagliaPost.txt
// This is the Multiply With Carry random number generator, modified
// to use a single 64-bit seed to create a 32-bit RNG, rather than
// gluing together two 16-bit RNGs (and thus two seeds)

// Default V value is the conglomeration of the default Z and W values from the Marsaglia MWC RNG
#define DEFAULT_V_VALUE 0x159A55E51F123BB5

class RandomNumberGenerator
{
private:
	unsigned long long v;

public:
	RandomNumberGenerator(unsigned long long seed = 0)
	{
		if(seed == 0)
			seed = DEFAULT_V_VALUE;

		v = seed;
	}

	// Gets a number in the range [0, UINT_MAX]
	unsigned int GetNum()
	{
		v = 36969 * (v & 0xFFFFFFFF) + (v >> 32);
		return v & 0xFFFFFFFF;
	}

	// Gets a random number in the range [0, Max) (that is, from 0 to Max-1)
	unsigned int GetNum(unsigned int nMax)
	{
		return nMax ? GetNum() % nMax : GetNum();
	}

	// Gets a random number in the range [Min, Max]
	// You will get weird results if Min is greater than Max
	int GetNum(int nMin, int nMax)
	{
		return GetNum((nMax - nMin + 1)) + nMin;
	}

	// Returns a floating point number in the range [0,1]
	float GetFloat()
	{
		const float fInverse = 1.0f / (float)0xFFFFFFFF;
		return GetNum() * fInverse;
	}

	// Gets a random number in the range [0, Max) (that is, from 0 to Max-1)
	unsigned int operator ()(unsigned int nMax = 0)
	{
		return nMax ? GetNum(nMax) : GetNum();
	}
};

Let’s write some code to use this RNG:

int main()
{
	RAND tRand;
	RandInit(tRand, 0);

	unsigned int nRandom = RandGetNum(tRand);
	printf("%u\n", nRandom);

	return 0;
}

Or, with the C++ class:

int main()
{
	RandomNumberGenerator tRand;

	unsigned int nRandom = tRand.GetNum();
	printf("%u\n", nRandom);

	return 0;
}

Next time, we’ll really delve into compiler optimizations, I promise!

Warning: we will be delving into assembly language, so be prepared!

Let’s start with some very simple code that uses our MWC RNG:

int main()
{
	RAND tRand;
	RandInit(tRand, 0);

	unsigned int nRandom = RandGetNum(tRand);
	printf("%u\n", nRandom);

	return 0;
}

Now, we’re interested in performance, so the question is: what sort of code does the compiler actually generate for this? Obviously, debug mode is not going to be very interesting for performance, so let’s compile in x86 Release mode and see what the compiler comes up with:

int main()
{
	RAND tRand;
	RandInit(tRand, 0);

	unsigned int nRandom = RandGetNum(tRand);
	printf("%u\n", nRandom);
00D11000  push        15AAA322h
00D11005  push        offset string "%u\n" (0D120F4h)
00D1100A  call        dword ptr [__imp__printf (0D120A0h)]
00D11010  add         esp,8
	return 0;
00D11013  xor         eax,eax
}

Wait a minute. What? Let’s translate that assembly language back into C code:

printf("%u\n", 0x15AAA322);

Wow, the compiler has completely optimized away the call to RandGetNum(). It has calculated what the output of the formula would be, and just replaced the result. What happens if we try it twice:

int main()
{
	RAND tRand;
	RandInit(tRand, 0);

	unsigned int nRandom = RandGetNum(tRand);
	nRandom = RandGetNum(tRand);
	printf("%u\n", nRandom);
	return 0;
}

The compiler generates:

01261000  push        0DEC01A79h
01261005  push        offset string "%u\n" (12620F4h)
0126100A  call        dword ptr [__imp__printf (12620A0h)]
01261010  add         esp,8
01261013  xor         eax,eax

Practically the same thing, just with a different constant. Let’s try a loop:

int main()
{
	RAND tRand;
	RandInit(tRand, 0);

	unsigned int nRandom;
	for(int i=0; i<5; i++)
	{
		nRandom = RandGetNum(tRand);
	}
	printf("%u\n", nRandom);
	return 0;
}

The compiler generates:

011B1006  push        9722BEA6h
011B100B  push        offset string "%u\n" (11B20F4h)
011B1010  call        dword ptr [__imp__printf (11B20A0h)]
011B1016  add         esp,8
011B1019  xor         eax,eax

The same thing! Wow. In fact, the Visual Studio compiler will follow the rabbit hole down as far as 10 times. After that, it gives up and starts to generate code. So, if we take i up to 11, then the compiler generates the following for the inside of the loop:

; Comments added by me
; For reference: v = 36969 * (v & 0xFFFFFFFF) + (v >> 32);
; ecx:eax contains v
01271017  mov         edx,9069h   ; Move 36969 into edx
0127101C  mul         eax,edx     ; eax contains the low part of V, so do the multiply
                                  ; and store the result in edx:eax
0127101E  xor         edi,edi     ; Clear edi
01271020  add         eax,ecx     ; Add the high part of V to the multiplied low part
                                  ; of V
01271022  adc         edx,edi     ; edi is 0, so this adds the carry flag from the
                                  ; eax+ecx operation to edx
01271024  dec         esi         ; decrement loop counter
01271025  mov         ecx,edx     ; Move edx (our temp register) into ecx (the high
                                  ; part of V)
01271027  jne         main+17h (1271017h)  ; loop

Neat! Excluding the loop instructions (dec/jne), our RNG boils down to six instructions in x86. It’s worth noting that, although 64-bit operations are nontrivial in 32-bit assembly code, this algorithm is particularly well-suited for it, because it only operates on 32-bit pieces of the 64-bit number.

Of course, that’s really just a pleasant side-effect. At its core, this really is a 64-bit operation, so let’s compile the same code for x64 and see what happens:

; Comments added by me
; For reference: v = 36969 * (v & 0xFFFFFFFF) + (v >> 32);
; rax contains v
000000013FB91020  mov         edx,eax         ; Move the low part of V into edx (and
                                              ; thus into rdx)
000000013FB91022  shr         rax,20h         ; Shift rax right 32, making rax contain
                                              ; the high part of V
000000013FB91026  imul        rdx,rdx,9069h   ; Multiply the low part of V by 36969
000000013FB9102D  add         rax,rdx         ; Add the multiplied low part to the
                                              ; high part
000000013FB91030  dec         r8              ; decrement loop counter
000000013FB91033  jne         main+20h (13FB91020h)  ; loop

The 64-bit version is even cooler: just four instructions, each of which maps exactly to an operation in the formula.

If we ever had any doubt as to whether the MWC RNG is efficient, this definitely puts those doubts to rest. We’ve also seen how the compiler can track down constant operations even across looping constructs.

Next time: It gets better

Enter George Marsaglia, in a posting to Sci.Stat.Math on January 12th, 1999. (Either that, or December 1st, 1999, depending on how Bob Wheeler writes his dates.) In that post, he puts down 17 lines of code that implement 8 different RNGs. That sounds really promising, at least as a starting point. Let’s pick one of those and run with it and see where it takes us.

The RNG that we’re going to be using as our basis is Multiply With Carry (MWC). Let’s isolate Marsaglia’s code for just the MWC RNG:

#define UL unsigned long
#define znew  ((z=36969*(z&65535)+(z>>16))<<16)
#define wnew  ((w=18000*(w&65535)+(w>>16))&65535)
#define MWC   (znew+wnew)
static UL z=362436069, w=521288629;
void settable(UL i1, UL i2)
 { z=i1; w=i2; }

Hrm. The first obvious problem is that this RNG uses a static context. Fortunately, it’s small and simple enough that we can fix that on our own by taking z and w and putting them into a struct or class. But before we go down that rabbit hole, let’s examine what this code is actually doing:

We’ll start with the MWC macro. MWC adds the newly-generated Z value to the newly-generated W value. Fair enough. What do those do? The first thing you’ll notice is that there’s a pattern to the Z and W updates, so we’ll take apart the algorithm for the Z/W update:

• Split off the 32-bit value into two 16-bit values, which we’ll call L for low and H for high.
• Multiply L by the constant C (36969 for Z and 18000 for W).
• Add the result to H. This is your new Z or W value.
• Return the bottom 16 bits of the value. For Z, shift them over into the high 16 bits of the return value.

From this, we can determine that Z and W are 32-bit values, each of which represents a 16-bit RNG. The MWC RNG generates its 32-bit value by combining the two 16-bit RNGs into a single value in the high and low words of the value. Now that we understand that, what does it mean? It means that we have to pick *good* values for our initial Z and W, because if we don’t, then we really only have 16 bits worth of randomness.

It kind of sucks to have to pick two seeds for an RNG. Can we improve on that? How can we take Marsaglia’s original MWC RNG and improve it by just requiring one seed? Well, let’s look at what we determined about the Z and W values: each one is a 32-bit value that represents a 16-bit portion of the 32-bit RNG. Maybe we can extend that concept by selecting a 64-bit value which represents a 32-bit RNG. We’ll start by just updating Marsaglia’s code, then examine the process of making it practical for every-day use:

#define ULL unsigned long long
#define vnew  (v=36969*(v&0xFFFFFFFF)+(v>>32))
#define MWC   (vnew&0xFFFFFFFF)
static ULL v=0x159A55E51F123BB5; // 64-bit value compiled from original z and w as z<<32 + w
void settable(ULL i1)
 { v=i1; }

Beautiful! It’s tiny, it’s fast, it’s deterministic, it’s got decently long cycles…the only problem is the static context. Fortunately, that one is easy to fix. Let’s start by making a structure to hold the V value:

struct RAND
{
	unsigned long long v;
};

Now a function to initialize it:

#define DEFAULT_V_VALUE 0x159A55E51F123BB5
inline void RandInit(RAND& tRand, unsigned long long seed)
{
	if(seed == 0)
		seed = DEFAULT_V_VALUE;

	tRand.v = seed;
}

And finally, a function to actually generate a random number:

inline unsigned int RandGetNum(RAND& tRand)
{
	tRand.v = 36969 * (tRand.v & 0xFFFFFFFF) + (tRand.v >> 32);
	return tRand.v & 0xFFFFFFFF;
}

So there you have it! A small, fast, deterministic, long-cycled, non-static context RNG.

Next time: Exploring Compiler Optimizations

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main()
{
    srand(time(NULL));
    int nRandom = rand();
    printf("%d\n", nRandom);
    return 0;
}

Of course, this only gets you part of the way there. The problems with rand() are well-known and well-documented, but the brief summary is:

• rand() only provides you with a random number up to RAND_MAX, which, on many compilers (including Visual Studio), is 0x7FFF.
• rand() uses a static context. That is, I cannot have two separate Random Number Generators (RNGs) running at the same time with different seeds.
• Less interestingly for us, but still nonetheless true, rand() is not acceptable for use in cryptography situations

I could go on and on, but this post isn’t about what’s wrong with rand(). rand() is just a starting point. What we’re after is an RNG that is effective and efficient for use in games. Specifically, we need it to have the following properties:

• It must be small (memory-wise)
• It must be fast
• It must be deterministic given the same seed
• It must have a long enough cycle that any practical day-to-day use will not experience the cycles
• It must have a non-static context

Please note:

• If you need an RNG for cryptographic purposes, use a library that is cryptographically strong. I repeat, none of this subject matter applies to any security or cryptographic subject!

The quote-unquote “standard” wisdom prevalent on the Internet is “Just use Mersenne Twister and be done with it.” Hmmm… What is this “Mersenne Twister”? Wikipedia to the rescue! Wikipedia also has a link to the Mersenne Twister home page. So, let’s examine Mersenne Twister against the above requirements: it’s deterministic, long-cycled, and has a non-static context. All good things. The algorithm is simple and seems fast. However, we’re not going to delve into the speed issue, because my eye is immediately drawn to the following line at the very beginning of the pseudocode presented in the Wikipedia page:

// Create a length 624 array to store the state of the generator
int[0..623] MT
int index = 0

In other words, the Mersenne Twister context uses up 2500 bytes! That’s 2.5K for an RNG! Granted, a very good one, but still…2.5K! Surely we can do better than that.

Next time: how we can do better.