Spherical forums Community for the Sphere game engine

New? Contact Us to register an account!

@casiotone - Is that an extension of Standard or is it something else entirely?

It's new, something I've been writing in CoffeeScript.

If there is really something wrong with GetPersonList, might it be worth replacing it altogether and maintaining a separate list to avoid any calls at all?

Edit: I've just realised that persons on maps would break this. Never mind!

Small suggestion: at the moment functions like GetSystemFont create a new font object every time they are called, loading the font each time. These should really be cached, otherwise scripts that call them in a loop will quickly run out of memory.

I think I figured out what that error was... it doesn't happen when you run from a fresh build. It happens if you try and run that build in your old Sphere directory - I'm guessing some of the old Sphere files are interfering.

BTW!

You should note that your testing methodology is meaningless and the sample size is also far too small - this is not the correct way to test randomness.

I made a simple test script to generate 10MB of random data:

function game() {
	var f = OpenRawFile("prng.out", true);
	for (var i = 0; i < 10 * 1024 * 1024; i++) {
		f.write(CreateByteArrayFromString(String.fromCharCode(Math.random() * 255)));
	}
}

Caveats: Math.random returns a floating point number between 0 and 1, but I want raw bytes, so I convert. This probably isn't perfect.

The 'ent' tool is useful for measuring randomness: http://fourmilab.ch/random/

It takes an input file and will run a number of tests.

$ ent prng.out 
Entropy = 7.988667 bits per byte.

Optimum compression would reduce the size
of this 10444516 byte file by 0 percent.

Chi square distribution for 10444516 samples is 82493.96, and randomly
would exceed this value less than 0.01 percent of the times.

Arithmetic mean value of data bytes is 127.5418 (127.5 = random).
Monte Carlo value for Pi is 3.155868268 (error 0.45 percent).
Serial correlation coefficient is -0.000395 (totally uncorrelated = 0.0).

We can see that the results are that: the Chi square test shows it isn't truly random (this is to be expected as it is a PRNG) but it does have high entropy, gives a good distribution and low serial correlation. You can check the website for ent for a better explanation of these values.

For comparison, here is the output on 10MB of data from /dev/urandom

$ ent urandom.out 
Entropy = 7.999982 bits per byte.

Optimum compression would reduce the size
of this 10485760 byte file by 0 percent.

Chi square distribution for 10485760 samples is 257.28, and randomly
would exceed this value 44.82 percent of the times.

Arithmetic mean value of data bytes is 127.4865 (127.5 = random).
Monte Carlo value for Pi is 3.141253335 (error 0.01 percent).
Serial correlation coefficient is -0.000208 (totally uncorrelated = 0.0).

And the output for /dev/random:

$ ent random.out 
Entropy = 7.999983 bits per byte.

Optimum compression would reduce the size
of this 10485760 byte file by 0 percent.

Chi square distribution for 10485760 samples is 245.35, and randomly
would exceed this value 65.65 percent of the times.

Arithmetic mean value of data bytes is 127.5263 (127.5 = random).
Monte Carlo value for Pi is 3.139946419 (error 0.05 percent).
Serial correlation coefficient is -0.000122 (totally uncorrelated = 0.0).

As expected these two have a better chi square distribution as they use hardware entropy sources.

I believe that the version of SM used in Sphere is using a linear congruential generator ripped from Java.

Anyway, a conclusion:

Unless you're doing cryptography in Sphere, the built in Math.random implementation really is good enough.

@Radnen:
Was just perusing the code and found a potential bug: you replace all instances of the word const followed by a space with var.  problem: this also replaces instances inside quoted strings, not desirable behavior.  Any way you could fix the regexp to only replace const at the beginning of a statement?  I'd do it myself, but regular expressions are black magic to me--I wouldn't know where to start.

This is still risky. You can't properly replace const without doing some real lexing of the source - any regexp solution is always going to cause problems.

Quote from: casiotone on July 22, 2013, 01:15:33 pm

I'm not sure if I have a different version or something but what I have, the triangle is just a simple Triangle call to draw on screen.

Well, I remember he made a compatibility version that probably removed that surface so it would work faster in the then dx8 and GL drivers.

It used to draw gradient rectangles to the screen, but the last version just loads a pre-generated image, with the generating code commented out.

/*	GradientRectangle(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, COL_LIGHT_GREY, COL_DARK_GREY, COL_BLACK, COL_DARK_GREY);
	var temp_back = GrabSurface(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT);
*/	
	// DEBUG
/*	temp_back.save("bgi_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
	Abort("bgi_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
*/	

function PreRenderBackground ()
{
/*	// Draw the main background
	GradientRectangle(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, COL_LIGHT_GREY, COL_DARK_GREY, COL_BLACK, COL_DARK_GREY);
	
	// Draw the top bars
	GradientRectangle(0, 0, SCREEN_WIDTH, mainFont.getHeight(), COL_LIGHT_GREY, COL_LIGHT_GREY, COL_DARK_GREY, COL_DARK_GREY);
	GradientRectangle(0, mainFont.getHeight(), SCREEN_WIDTH, mainFont.getHeight(), COL_LIGHT_GREY, COL_LIGHT_GREY, COL_DARK_GREY, COL_DARK_GREY);
	
	// Clock space
	Rectangle(SCREEN_WIDTH - mainFont.getStringWidth(" 00:00:00"), 0, mainFont.getStringWidth(" 00:00:00"), mainFont.getHeight(), CreateColor(0, 0, 0, 32));
	
	// Draw the Sphere icon box
	GradientRectangle(0, 0, sphereIcon.width, sphereIcon.height, COL_LIGHT_GREY, COL_LIGHT_GREY, COL_DARK_GREY, COL_DARK_GREY);
	
	// Draw the bottom bar
	Rectangle(0, SCREEN_HEIGHT - mainFont.getHeight(), SCREEN_WIDTH, mainFont.getHeight(), CreateColor(0, 0, 0, 128));
	
	// Store it and clear it
	background = GrabSurface(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT);
	Rectangle(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, COL_BLACK);
*/	
	// DEBUG
/*	background.save("bg_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
	Abort("bg_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
*/	
	
	// Load the appropriate background instead
	background = LoadSurface("bg_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
	
	return;
}

It probably at least compiles fine on Linux. I could give it a try, I now have a newer V8 built to try it with.

I've still got a lot of stuff to clean up so the git repository hasn't been updated yet. But it should compile easily!

I'm surprised you got surfaces working in such a short time in SFML. Which leads me to my next statement: I guess we have two sfml based Sphere engines. Yours may already be cross platform too!

I've unfortunately only got loading surfaces, blitting them, and drawing rectangles to surfaces implemented, so you're far far ahead of me! I imagine the more complicated surface features will be more of a problem. At the moment I've done it by storing an SFML sprite along with some information like current blend mode. Drawing on surfaces converts the sprite's texture to a render texture and back again so it's not very fast. I'm not sure what the best way to handle them is really.