Hello, I've been thinking of developing for OUYA however, I'm just worried that OUYA won't be powerful enough for 3D. Could anyone tell me, how much polys they've been able to get for 60 FPS and 30 FPS?
Poly count seems a rather meaningless thing, because it depends on so many factors, like texture size, shader complexity, whether there are transparent things drawn in front, etc. For example, I have a couple 16,000 textured-polygon models in my game at all times, but a good number of those polys get culled, and the framerate *really* drops if a few transparent things appear in front, since every transparent thing forces a redraw of all those polygons.
Poly count is almost completely meaningless (of course there is a poly limit, I think... not that you're ever likely to hit the poly count unless your game has an absolutely insane number of them) What you should be worried about more is pixel shader complexity and transparent surfaces (transparent surfaces, especially those that overlap, can potentially drop your performance like nobody's business).
You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
If you've played any 3D games on one of the newer Android devices (within the past year) then you know what to expect. (Is that right?)
Probably. Some games use way fewer polys then they could use, though. You can also get an idea of what the OUYA could handle by looking at Wii games. The OUYA is actually slightly more powerful than the Wii.
You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
Magic word is DRAWCALLS. Get some good Unity forum reads about these. They are killing your performance. Just an example:
For our game it doesn't matter at all if we have 15000 or 20000 polys. But if we go from 30-50 drawcalls we use 1/3 of the framerate.
Drawcalls depend on material number, dynamic lights and shader. So a tip: use texture atlassing like hell to reduce material count in visible frame (each material is one drawcall at least), don't use dynamic lights (use lightmapping BEAST instead), batch static all you can and use Mobile Unlit shaders if possible, forget dynamic shadows. You can still get a nice style:
Yes, yes..... polygon counts, in this day and age, are essentially meaningless. You can probably get away with even early Xbox 360 level polycounts (don't be fooled into thinking it can't handle more than PS2 level of polygons...)
What you are looking at are draw calls and fillrate/overdraw. Every time the CPU submits something for the GPU to draw, it's a draw call. Basically everything in the draw call must be drawn with the exact same appearance (the drawcall essentially tells the GPU to set a certain appearance for what it's about to draw next, this includes a shader, and parameters to this shader, and then gives it polygons to draw). Too many draw calls, and your game will end up very slow.
Fillrate generally affects transparent surfaces. Having tons of transparent effects filling the screen, overlapping, etc. is very hard on fillrate and can quickly crash your performance. If you want an explosion for example, it sounds very oldschool but you'll probably just want a single animated billboard like they did in Quake 3 or Half-Life 1. Use particle effects sparingly, as they can be very hard on fillrate.
Another thing to watch out for is blob shadows. While it might seem they are designed for low-power devices like OUYA, it seems they really aren't. Blob shadows will not only redraw entire objects within their frustum, they will also do it with one drawcall for every object they hit. Is your hallway one mesh? It will be drawn twice. Are there 20 little props lying around, separate meshes? 20 extra drawcalls. So not only is blob shadow bad on draw calls, they are also terrible on fillrate. The worst of both worlds. A somewhat cheaper/faster solution is what many PS2 games did: stick a quad at the character's feet. I ended up creating a decal manager that lets me use an immediate-mode style API to draw quads with materials, and at the end of the frame they would be automatically batched by material and drawn, so that if I have 20 soldiers using a drop shadow, the 20 shadows are all batched together into one draw call.
You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
You might get a speed boost if you manually cull the faces you can't see from those boxes. Overdraw is killer.
Just a question for my understanding – does your tip apply to a full 3D game? In our case the camera rotates, so I gues we can't delete the box faces (just the bottom ones). Is there any other option to rduce the overdraw by culling?
You would figure but maybe pre-generating the culling could save some GPU cycles. Especially if you can eliminate overdraw. I can kill the rendering performance with 1200 well placed planes. Check out the ShowMeshPerformance example.
You would figure but maybe pre-generating the culling could save some GPU cycles. Especially if you can eliminate overdraw. I can kill the rendering performance with 1200 well placed planes. Check out the ShowMeshPerformance example.
How many draw calls, can you find out?
You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
GlesgaeGames
Posts: 1Member
Comments
What you should be worried about more is pixel shader complexity and transparent surfaces (transparent surfaces, especially those that overlap, can potentially drop your performance like nobody's business).
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].
For our game it doesn't matter at all if we have 15000 or 20000 polys. But if we go from 30-50 drawcalls we use 1/3 of the framerate.
Drawcalls depend on material number, dynamic lights and shader. So a tip: use texture atlassing like hell to reduce material count in visible frame (each material is one drawcall at least), don't use dynamic lights (use lightmapping BEAST instead), batch static all you can and use Mobile Unlit shaders if possible, forget dynamic shadows. You can still get a nice style:
ms.ouya.tv/discussion/comment/12241#Comment_12241
CLARK
by GoldenTricycle
Developer for CLARK / GoldenTricycle
Developer of OuyaInput Framework >> GIT
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].
What you are looking at are draw calls and fillrate/overdraw. Every time the CPU submits something for the GPU to draw, it's a draw call. Basically everything in the draw call must be drawn with the exact same appearance (the drawcall essentially tells the GPU to set a certain appearance for what it's about to draw next, this includes a shader, and parameters to this shader, and then gives it polygons to draw).
Too many draw calls, and your game will end up very slow.
Fillrate generally affects transparent surfaces. Having tons of transparent effects filling the screen, overlapping, etc. is very hard on fillrate and can quickly crash your performance. If you want an explosion for example, it sounds very oldschool but you'll probably just want a single animated billboard like they did in Quake 3 or Half-Life 1. Use particle effects sparingly, as they can be very hard on fillrate.
Another thing to watch out for is blob shadows. While it might seem they are designed for low-power devices like OUYA, it seems they really aren't. Blob shadows will not only redraw entire objects within their frustum, they will also do it with one drawcall for every object they hit. Is your hallway one mesh? It will be drawn twice. Are there 20 little props lying around, separate meshes? 20 extra drawcalls. So not only is blob shadow bad on draw calls, they are also terrible on fillrate. The worst of both worlds.
A somewhat cheaper/faster solution is what many PS2 games did: stick a quad at the character's feet. I ended up creating a decal manager that lets me use an immediate-mode style API to draw quads with materials, and at the end of the frame they would be automatically batched by material and drawn, so that if I have 20 soldiers using a drop shadow, the 20 shadows are all batched together into one draw call.
CLARK
by GoldenTricycle
Developer for CLARK / GoldenTricycle
Developer of OuyaInput Framework >> GIT
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].