Unity3D threads – measuring performance

Hey everybody!
Sometimes people ask me about delayed actions or threading in Unity3D and usually I suggest to use coroutines since they are suitable for the most cases I faced with.
But sometimes we need to use true threading and make some calculations faster, A* path finding for example.
So I decided to make a fast-written performance comparison of traditional code execution vs. threaded version. I searched for some simple threads managers and found this really simple Loom class from whydoidoit accidentally.

I did a simple test app for different platforms (I attached archive with apps and sources at the end of this post) and found some results pretty interesting.
All my code is trying to do – is just to make CPU think a little while working with huge array of Vector3D instances (10 000 000 for Desktop platforms and 1 000 000 for mobile platforms):

private void Run()
{
	const float scale = 432.654f;

	for (int j = 0; j < arrayLength; j++)
	{
		Vector3 v = vertices[j];

		v = Vector3.Lerp(v * scale / 123f * v.magnitude, v / scale * 0.0123f * v.magnitude, v.magnitude);

		vertices[j] = v;
	}
}

This is a simple dummy code as you can see.
I added simple Ant model (hello, Away3D examples authors! :)) with rotation at Update() to the scene in order to see how app can freeze while running this ugly code in main thread.

JTMLjQ0

I did few tests of this code as I mentioned previously, both in sync (straight execution in main thread) and async (running it the separate threads) modes, here are results I’ve got (S – sync, A – async):
Continue reading

Found a typo? Please, highlight it and press Shift + Enter or click here to inform me!

Share Button

AIR vs. Unity3D. Who’s faster? (Update 1)

Update 1: uploaded some sources (look at the end of article).

Hey there!
Yeah, it’s been a while blahblahblah.. To the point! =)

Sometimes I’ll highlight actual files from the archive, attached at the page bottom.

Sometimes I see Flash developers interested in the Unity3D lately, and I – one of them actually)
I work with Unity for a while already and all I can say – it’s fantastic experience! So cool to learn C# language (I hope other Flash devs make wise decision to code in C# as well), to learn new community and people, to meet a lot of new challenges and to look at 3D world from a new point at all!

Many Flash developers are still uncertain they should try Unity and spend their time learning this brand new world though.. And in some cases it’s built on top of the AIR and Unity3D performance differences obscurity. So I’ll unveil portion of this differences in this article to help those Flash developers make a choice (whatever what they choose)!

All examples I’ll compile with AIR 3.6 and Unity3D 4.1 and I’ll try to keep similar functionality and look of these examples to let them compete.
I’ll test builds on the pretty slow Samsung Galaxy Tab 10.1 and make some tests on the desktop as well.

Intro

Okay, let’s start from comparing empty builds.
To measure FPS in unity3D I’ll use hand-made FPSmeter working with GUIText.
In AIR builds I’ll use different FPSmeters, usually in-built to the frameworks I’ll use.
Well, let’s see to the built apks (I built Captive Runtime in AIR and usual release build in Unity3D):
Continue reading

Found a typo? Please, highlight it and press Shift + Enter or click here to inform me!

Share Button

Flash 2D Physics engines fast comparison: Nape (haXe) vs Box2D (Alchemy)

Nape: 6.1 r49 Release for FP 10+ (built with haXe)
Box2D (Alchemy, WCK): last build from GitHub (pulled 09.11.11, built with Alchemy)
Flash Player: 11.0.1.152 Release 32 Bit Standalone (Projector) – Desktop
AIR: 3.0 – Mobile

I’ve tested these engines both on Desktop (Win 7, Core i7 Q740, 1.73 GHz per core, 16 GB DDR3-1333 MHz) and Mobile (Android 3.1, Samsung Galaxy Tab 10.1, overclocked to 1.4 GHz per core).
Continue reading

Found a typo? Please, highlight it and press Shift + Enter or click here to inform me!

Share Button