Caanoo / WIZ Wiz Game Engine


Aaah, the Wakebreaker source - I remember that :) Like I said, I'm not an expert, but if you have any questions, feel free to ask :) I'm sure the others will chime in too.
 
Hi kurtkz!

Really nice project with a lot of impressive features already. I'm no expert but sounds a lot of work for a one man show.
Just tried the demo and like crow_riot says it works very well but needs a little gamma correction. I have nothing against some more demos... :)
I also hope that you release your engine in the future as I think it really fills a gab. Afaik other game development solutions like BunnuGD and GLBasic don't support OpenGL 3D environments on the Wiz.
 
OK, just managed to update the physics response with angular velocity too - not sure how accurate it is, but it looks alright I guess (plus you can lock an objects axes if you want to ignore angular velocity). Trying to get a new demo together now...
 
I've changed the physics controller (AGAIN) - now you register the physics object type and register combinations of physics resolution handlers. It was becoming unmanageable and slow to implement a full physics engine. Hacking it together is the way forward. This way you could have a car that reacts differently to the terrain (handler #1) and to obstacles (handler #2).
 
Another small update...I've refactored the physics code a little and also made a converter for Blender exported OBJ files (it generates a slightly different format from the other 3D exporters). Peter sent me a test level and I'll be testing it today :)
 
Mmm, after some aggressive optimization in the batching algorithm, the engine runs MUCH faster. It's amazing just how much this little machine can handle :)
 
kurtkz said:
Mmm, after some aggressive optimization in the batching algorithm, the engine runs MUCH faster. It's amazing just how much this little machine can handle :)

Now that's sound like music to my ears... :)
 
Last edited by a moderator:
Thanks guys, I hope to have a new demo up on Friday. I'm testing a big-ish scene at the moment (6000 triangles), but it's dog slow (around 10fps with all optimizations). It runs fine up to about 3000 triangles after which the FPS drops drastically. What's the largest, single draw call you made on the Wiz? Is there an optimal number of vertices/triangles to batch?
 
kurtkz said:
I'm testing a big-ish scene at the moment (6000 triangles), but it's dog slow (around 10fps with all optimizations). It runs fine up to about 3000 triangles after which the FPS drops drastically.
I have noticed exactly the same behaviour (but with less triangles). You might have a look at this thread:
http://www.gp32x.de/board/index.php?/topic/50649-how-to-improve-opengl-es-performance/
 
Last edited by a moderator:
I tried different array sizes myself, and the sweet spot seemed to be around 2560 (0xA00) triangles per glDrawArrays call.

When drawing all of my tris (>3000) with one call I got ~33 FPS
At 256 tris per call I got ~43 FPS
At 2560 tris per call I got > 50 FPS

This is with single (ie not strip or fan), unlit, textured, blended tris for 2d sprites...
 
Interesting, so are you expecting 3000 tris to be the approx. maximum?

That demo scene I'm working on is really not very optimized yet either. But I started doing some test renders at 320x240 (wiz/caanoo native res, right?) and realized that the details in a high poly object are completely lost at such a low resolution. I can shave that scene like a sheep and not really miss much.
 
@hmn: That's very odd behaviour - but I can confirm that that does indeed happen. It's annoying as all hell! Is the vertex cache perhaps too small on the Wiz? Forcing us to batch the draw calls in fixed-size portions?

@traylorpark: I've managed to successfully load the level and you can navigate around it - but the Wiz is struggling to keep up :/ I'm going to keep trying to get it running at a reasonable lick but if you can optimize it at a later stage that would be great. The scene as it stands clocks in at around 6800 triangles and I'm getting around 10fps. If I can get it to run at around 30fps no optimization would be needed. I'll keep you posted on my progress :)
 
@traylorpark: Please ignore my previous posts - the level works just fine (the 6000 triangle one too). I've reworked the batching algorithm and the frame rate stays maxed out at 60fps. The level looks awesome btw :)
 
kurtkz said:
@traylorpark: Please ignore my previous posts - the level works just fine (the 6000 triangle one too). I've reworked the batching algorithm and the frame rate stays maxed out at 60fps. The level looks awesome btw :)
What did you change and what caused the slowdown?
 
Last edited by a moderator:
@Jan-Nik: There are now 2 types of batch sorting in the engine - one for when there are lots of similar objects (usually dynamic objects) and one for disparate objects (usually static objects in a scene exported from a level editor). This distinction is necessary since the exported scenes usually don't have common objects, so sorting on these objects is unnecessary and very slow (I was sorting and creating lists for 200+ objects). The batching algorithm batches objects based on material and object ID (a mixture of variables including mesh, animation and frame). Then it batches objects on lighting (the engine supports more than 4 lights, it just selects an optimal subset for each object) and transformation. If there is no transformation, it tries to compile the objects into one set of buffers, so that they can be rendered with one draw call, otherwise it uses semi-instancing to render the meshes. It also caches previous draw results so that, if the data is unchanged, it just renders using the buffers that were generated previously. It's a really simple approach, but to mind, the fastest one.
 
Back
Top