>most sprites are rendered via the draw_texture extension
For very large numbers of sprites I've found that the standard draw
arrays/elements methods are much faster than the draw_texture
extension in cases where you can arrange to draw multiple sprites per
draw call. That's impossible with the dr
Pre-scale the background image to match the device resolution.
Split the background image in texture tiles like 256x256, 128x128,
Blitt the tiles separately.
2010/4/8 lixin China
> Hi Schneider:
> As you said avoid scale the texture. Could you tell me the solution
> how to render backgroun
Hi Schneider:
As you said avoid scale the texture. Could you tell me the solution
how to render background texture(480x320 to full screen) without
scale.
On Apr 7, 5:28 am, Ralf Schneider wrote:
> If your performance problem is only related to putting sprites on the
> screen, don't expect an impr
You are benchmarking some math functions.
If you compile the C Code with the default setting from the NDK all floating
point operations are emulated.
The Java version executed on the Dalvik VM will hopefully use real floating
point instructions - if the CPU supports it.
So, as all benchmarks this
I'm doing some little research school project, together with learning
basics of C++ (thanks to JNI) and here is some simple example ...
Java function:
---
public double doClickAction04J() {
double x = 45.0 / (180.0 / Math.PI);
double result = 0.5;
for
There exists (GL_UNSIGNED_SHORT_4_4_4_4) Textures.
May be this helps a litle bit.
I'm not sure but switching to VBOs might not bring an improvement.
My observation on a Nexus One is: VBOs are great if there are many tris
(>250) to render per call. For billboards it really doesn't matter that
100 is a low estimate but it's around that point that the frame-rate
seems to get into the sub 30's.
I'm already doing pretty much everything you've mentioned except using
VBOs - most sprites are rendered via the draw_texture extension.
Unfortunately pretty much all the sprites have some transparen
If your performance problem is only related to putting sprites on the
screen, don't expect an improvement by witching to the NDK.
I don't know how you are currently doint it, but these are some general
remarks:
Use OpenGL ES to draw the sprites.
Limit your textures to 256x256. 512x512 seems to be
I was hoping that someone had tried a little test app with a simple
scene. I think I've pretty much reached the limits in terms of get
sprites on the screen at an acceptable frame rate (at least on G1 type
hardware).
It seems, at least for what I'm doing, the limit is about 100 sprites
but for my
9 matches
Mail list logo