Monkey Speed Tests

Community Forums/Monkey Talk/Monkey Speed Tests

Anthony Flack

(Posted 2011) [#1]

So...! I just started messing around with the Monkey demo yesterday, and it's very nice and potentially extremely useful! Inevitably, though, I wanted to put it through some speed tests and find out what kind of sprite drawing capabilities it has before deciding what I can do with it.

And the results (in HTML5 at least) are quite concerningly slow for image drawing (rect/circle etc is faster). The computer I tested on is no slouch (64bit core2 @ 2.6Ghz) so I'm wondering what the practical limits of a browser game are.

My test results:

1x 640x640 sprite = 11ms
100x 2x2 sprites = 6ms
100x 64x64 sprites = 20ms
100x 128x128 sprites = 50ms
100x 256x256 sprites = 140ms

Plus, a 10x15 tilemap on a tiny 320x480 canvas takes 16ms to render. The fill rate limitation itself is not insurmountable, but the per-sprite cost really starts to bite when drawing tilemaps.

Since you really need to get all your rendering done in under 30ms if you're going to have any hope of hitting a solid 30fps, these are some pretty serious performance constraints.

So my question is - are these results typical for HTML5 (I'm running in Firefox 4). And for those who have the full version: how does HTML5 compare to Flash compilation in this regard? How about iOS and Android?

therevills

(Posted 2011) [#2]

With HTML5 the speed is mainly controlled by the browser.

Ive tested with Chrome and Firefox... and Chrome wins all the time. I havent installed IE9 yet but I've read that the javascript engine is hardware accelerated or something :P

Try these examples on your PC (side-by-side HTML5 and Flash):

http://www.therevillsgames.com/monkey/platformer/

http://www.therevillsgames.com/monkey/invaders/invaders.html

http://www.therevillsgames.com/monkey/invaders/invaders.html

http://www.therevillsgames.com/monkey/monkeyDoc.html

Anthony Flack

(Posted 2011) [#3]

"Ive tested with Chrome and Firefox... and Chrome wins all the time."

Unfortunately if I want to target the typical user I have to consider the typical configuration; I can't make something that only runs properly in Chrome.

It looks like flash has a substantial speed advantage in the platform game though, which is encouraging. Is there a way to get a custom level (from the editor) to run in the game engine? It would be helpful to do a speed comparison where the whole screen is filled with tiles.

therevills

(Posted 2011) [#4]

Since HTML5 is "new" I wouldnt use it for anything other than prototyping and a quick play around.

In the global market place many people still use browsers with no HTML5 support. Hopefully in a few years...

Is there a way to get a custom level (from the editor) to run in the game engine?

No, not currently... I could change it so it saves the level string in variable and read that instead of the stored level though...

Anthony Flack

(Posted 2011) [#5]

"Since HTML5 is "new" I wouldnt use it for anything other than prototyping and a quick play around."

Yep, so I'm mostly interested in how Flash performance compares... and iOS/Android, natch.

GfK	(Posted 2011) [#6]

Yep, HTML5 is a no-no for anything serious just yet. I'm sure the demo would have been much better received if it had the ability to compile for different targets but that said, its a bit of a faff to set your system up for targets other than HTML5 (which works out of the proverbial box) as there are differing dependencies for each.

For web games I'd definitely go the Flash route, especially as it now embeds data (it didn't at first).

Finally, I wouldn't use Monkey for the PC platform at all. Relying on Windows playing nicely with OpenGL is a recipe for disaster. Blitzmax + DX9 for that.

CyBeRGoth

(Posted 2011) [#7]

I too find Firefox 4 to be a bit slow, probably due to the hardware acceleration being a bit dodgy, HTML5 stuff tends to run much quicker and smoother on any other browser, including *shudder* IE9.

Flash is definatly faster for the moment.

@ GFK I would love to see a DX9 Target for monkey, OpenGL is fine and all but im wary about the typical casual user at having their PC set up properly for running OpenGL, where as DX is pretty much a cert.

therevills

(Posted 2011) [#8]

I didnt find it too hard to set Monkey up for the other targets... mainly just download the extra SDKs and point Monkey to them (via the config files).

You never know someone might do a Monkey to BlitzMax Target... maybe...

Anthony Flack

(Posted 2011) [#9]

Excellent news; that means I have a bit more headroom to work with.

For PC/Mac native, yeah if I was going down that route I would stick to BlitzMax for the time being, but given the size of games that I feel inclined to work on right now, web/mobile is the only obvious choice anyway.

Matthew Smith

(Posted 2011) [#10]

I've found using various apps on both Chrome and IE9 and IE wins most of the time.

For therevills's platformer I get around 10fps better on IE9 on the same laptop.

Anthony Flack

(Posted 2011) [#11]

Yikes, I just downloaded IE9 and it's rendering around eight TIMES faster. I can get a thousand 64x64 sprites bouncing around the screen, no trouble at all.

therevills

(Posted 2011) [#12]

When writing games for Android you really need to be aware of using "new", every time you create a new object (yourself or monkey) it will call the GC which will slow your app down.

For example if you are using a list for your collections of bullets, every time you create a new bullet and add it to the list, you will be creating new nodes for the list,.. then if you loop thru the list with the "EachIn" command - this creates a new enumerator every time...

Anthony Flack

(Posted 2011) [#13]

Ok, that sounds important to know. What kind of overhead are we talking about for calling the GC? And what is the recommended workaround?

therevills

(Posted 2011) [#14]

I havent calculated the overhead myself, but checking the Google Session "Writing Real Time Games for Android" 2009:

• Never allocate memory. Or release it.
– Well, never allocate during gameplay.
– The GC will stop your game for 100 ~ 300 ms. That’s death for
most real-time games.
• Revised: Allocate as much as possible up front, don’t release
things until you have natural pause time. Invoke the GC
manually when you know it to be safe.

http://dl.google.com/io/2009/pres/WritingRealTimeGamesforAndroid.pdf

You can use arrays to set up everything first or use a Stack and manually loop thru it:

Strict

Import mojo

Function Main:Int()
	New MyGame()
End

Class MyGame Extends App

	Method OnCreate:Int()
		For Local i% = 0 To 10
			New Sprite(Rnd(10, DeviceWidth()-10),Rnd(10, DeviceHeight()-10), False)
			New Sprite(Rnd(10, DeviceWidth()-10),Rnd(10, DeviceHeight()-10), True)
		Next
		
		SetUpdateRate 60
		Return 0
	End
	
	Method OnUpdate:Int()
		Return 0
	End
	
	Method OnRender:Int()
		Cls
		Sprite.DrawAll()
		Sprite.DrawAll2()
		Return 0
	End
End

Class Sprite
	Global list:List<Sprite> = New List<Sprite>
	Global stack:Stack<Sprite> = New Stack<Sprite>
	Field x#, y#
	Field size%
	
	Method New(x#, y#, useStack?)
		Self.x = x
		Self.y = y
		Self.size = 10
		If useStack
			stack.Push(Self)
		Else
			list.AddLast(Self)
		End
	End
	
	Method Draw:Void()
		DrawRect x, y, size, size
	End
	
	Function DrawAll:Void()
		SetColor 0,255,0
		For Local s:Sprite = EachIn list
			s.Draw()
		Next
		SetColor 255,255,255
	End
	
	Function DrawAll2:Void()
		SetColor 255,0,0
		For Local i% = 0 To stack.Length() - 1
			(Sprite(stack.Get(i))).Draw()
		Next
		SetColor 255,255,255
	End
End

Set limits on your objects, say 100 particles ever on screen, 100 bullets etc and create them beforehand, then reuse them in game.

Last edited 2011

skidracer

(Posted 2011) [#15]

Creating objects before hand does not help entirely, large object populations will impact on all managed languages, including BlitzMax and all Monkey targets.

I now disable the garbage collector at start of level and enable at end of level but until I hacked that approach (which is only possible on C++ targets like iOS where GC is monkey based), I modified my particle systems to steer clear of objects entirely:

Class Rubble
	Field xy#[MAXRUBBLE*8]
	Field count
	
	Method Reset()
		count=0
	End
	
	Method Add(x#,y#,vx#,vy#,n,c)
		If count<MAXRUBBLE
			xy[count*8+0]=x
			xy[count*8+1]=y
			xy[count*8+2]=vx
			xy[count*8+3]=vy
			xy[count*8+4]=n

			xy[count*8+5]=Rnd(360)
			xy[count*8+6]=0.1+Rnd(0.2)
			
			xy[count*8+7]=c
			count+=1
		Endif
	End
	
	Method Update()
		For Local i=0 Until count
			xy[i*8+4]-=1
			If xy[i*8+4]<0
				count-=1			
				If i=count Exit
				xy[i*8+0]=xy[count*8+0]
				xy[i*8+1]=xy[count*8+1]
				xy[i*8+2]=xy[count*8+2]
				xy[i*8+3]=xy[count*8+3]
				xy[i*8+4]=xy[count*8+4]
				xy[i*8+5]=xy[count*8+5]
				xy[i*8+6]=xy[count*8+6]
				xy[i*8+7]=xy[count*8+7]
			Endif
			xy[i*8+3]+=0.1
			xy[i*8+0]+=xy[i*8+2]
			xy[i*8+1]+=xy[i*8+3]			
		Next		
	End

	Method Draw(x,y)	
		Local rock:Image
		For Local i=0 Until count
			Local rot#=xy[i*8+5]
			Local scale#=xy[i*8+6]
			Local c=xy[i*8+7]
			rock=Game.rocks[c]
			DrawImage rock,x+xy[i*8+0],y+xy[i*8+1],rot,scale,scale
		Next
	End
End

Avoiding rotate and scale on an untransformed display would I guess buy some extra performance also. IE9 and the next generation of Flash I would guess won't care so much.

Last edited 2011

Anthony Flack

(Posted 2011) [#16]

100 ~ 300 ms - ouch.

All right, thanks for that - bit of a nuisance, but manageable. After all this time getting comfortable with OOP, and it's back to using old-school arrays again!

Any other platform-specific gotchas out there?

Last edited 2011

skidracer

(Posted 2011) [#17]

Memory is my biggest issue, for iOS i seem to be straining older devices after loading 4 or 5 1024x1024 32 bit sprite sheets.

Unless playing games on a tiny screen covered by large opaque fingers is your thing I would ask yourself why design for such an inadequate platform? If it's just about the money then you might as well not bother with anything original, complex, or in any way busy. Same goes for the browser targets.

I would consider sticking with targeting the desktop where your creativity can enjoy some real freedom.

Last edited 2011

Anthony Flack

(Posted 2011) [#18]

"for iOS i seem to be straining older devices after loading 4 or 5 1024x1024 32 bit sprite sheets."

Ok, that's a good benchmark to keep in mind.

"Unless playing games on a tiny screen covered by large opaque fingers is your thing"

Yeah, the lack of tactile controls is a longstanding grudge I have against iOS devices. Not an insurmountable design challenge, but definitely a major limitation that has to be designed around.

"If it's just about the money then you might as well not bother with anything original, complex, or in any way busy. Same goes for the browser targets."

It's partly the need to (attempt to) generate some quick pocket-money. But also I do kind of feel like doing some quickie games of extremely reduced scope. A 2-minute score-attack game, randomised procedural content, that sort of thing. After being buried in a huge project for so long the idea of making a few itty-bitty games with <6 week turnover has a certain appeal. And it feels like browser/mobile is the most appropriate/accessible format for these kinds of bite-sized games.

I still want to make them look pretty though...!

After I've released a few little projects I'll probably regain some of my appetite for tackling more adventurous titles; Steam/home console etc.

Gabriel

(Posted 2011) [#19]

iOS is capable of loading a lot more textures than that. If you're struggling to load that many 1024x1024 textures, I would suggest that you're not using PVRTC compressed textures, which you nearly always should be. If they're 1024x1024, you absolutely should be, because the only real restriction of compressed textures on iOS is that they be square (and PoT, but that's normal). If Monkey doesn't (yet?) support compressed textures on iOS and Android that's something that needs fixing pretty urgently. It's along the same lines as embedding images on Flash (which was already fixed). You need it.

skidracer

(Posted 2011) [#20]

After testing I decided woric the artist on Zombie Trailer Park would have disembowled me had I gone with PVRTC (think jpeg at 60% quality).

For 2D cell shaded art, bilinear filtering lower res sprites gave superior results and even then iOS displays are so sharp both approaches were not really acceptable for most of the game sprites.

Last edited 2011

therevills

(Posted 2011) [#21]

Unless playing games on a tiny screen

Android isnt on just mobile phones anymore...

http://www.motorola.com/Consumers/US-EN/Consumer-Product-and-Services/Tablets/ci.MOTOROLA-XOOM-US-EN.overview

10.1 inch screen ;)

Gabriel

(Posted 2011) [#22]

Well the 2-bit PVRTC is pretty awful, I'll grant you, but I get excellent results with 4-bit. Unity does it for me though, and they did have to do some work on the conversion/importing process. I don't know enough about it to recommend, but perhaps it matters how you convert/encode the textures?