i'm working a prototype game that has a very similar setup to yours. I
have a 2048x2048 big background texture which i load in 32-bit argb
mode (i have yet to discover what format to use for 16-bit rgb 565,
png doesn't support it, didn't care yet though). I split up this big
thing into 256x256
Hi Federico,
I tried during weeks to get a working code for the opengles. The idea
was to draw an offscreen bitmap into the screen (i do all the graphics
rendering by myself). Then someone told me that using textures for
this was not a good idea, because it takes time to make the texture
get into
Hmm, for less texture data, but keeping some alpha, there are also the
options of: RGBA_5551; PowerVR Texture Compression (PVRTC); and
reducing the resolution of the texture, but still filling the screen
with it. Not all phones support PVRTC, however, so you have to check
for support and have a
Hi Mario,
Thanks for the info! So basically, there's no way to draw a 480x854
image on screen with OpenGL at 60fps because of the texel reading
bottleneck. Bummer :(
I think the PowerVR chip is actually capable of doing it, but Android
is actually fetching the pixels/texels twice. Once when you
Hi Guich,
I didn't do anything special to achieve 60fps with a SurfaceView, just
get a lock to the surface and draw the bitmap onto the canvas. Mind
you, I only get 60fps when drawing a static, full screen bitmap to the
SurfaceView. If I draw more bitmaps on top of that background bitmap,
the FPS
Thanks for the tip, but the dynamic nature of my app won't let me pre-
compress the textures using PVRTC, or ATITC. I'll be loading icons,
images, etc. that come from the user (think the Home/Launcher app for
example) and AFAIK there's no way to do PVRTC compression at runtime,
is there?
Thanks,
Hey all, maybe I am way off base on this.. but I recall years ago messing
around with writing data to an off-screen buffer, then flipping the buffer
to video ram. I am guessing this is no longer done.. or is it? I thought the
reason for that years ago was it was much faster to write multiple
Hi,
If you are using surfaceview I believe it does backbuffer flipping for
you
-niko
On Feb 1, 2:00 pm, Kevin Duffey andjar...@gmail.com wrote:
Hey all, maybe I am way off base on this.. but I recall years ago messing
around with writing data to an off-screen buffer, then flipping the buffer
@Kevin
I can easily see wheter something runs at 30 or 60fps.
http://www.gamasutra.com/blogs/RadekKoncewicz/20100106/4021/Framerates_Do_Matter.php
is an interesting article on the matter
@Federico
The thread over at
@Kevin
Just like Mario, I can easily tell between 30 and 60fps, it makes a
world of difference to me. I'm only going to be drawing simple 2D
quads, no complex geometry, so 60 fps is very important to me.
Anyway, the question is not whether I need 60 fps or not, the question
is: Is the PowerVR
I don't have a Droid to test on, but if you haven't tried it already,
it might be worth dropping the various texture settings down to their
fastest/lowest quality and enabling mipmaps to check if that's where
the problem is. Something like this:
gl.glHint(GL10.GL_PERSPECTIVE_CORRECTION_HINT,
Federico - are you using GLSurfaceView or did you init EGL yourself?
If you initialized it yourself, did you check to make sure the config
gave you 24 bits of depth and not 16? That would be one thing to
cause the slowdown.
I usually get 40FPS on a Droid full-screen (not with a big quad but
with
Hi Lance,
Yes, already tried using mipmaps, and every possible combination of
min and mag filters. Still can't sustain 60fps with one fullscreen
textured quad. I checked GL_DEPTH_BITS and it's properly set to 24.
Thanks,
Federico
On Jan 31, 1:58 pm, Lance Nanek lna...@gmail.com wrote:
I don't
Hi Robert,
I'm using GLSurfaceView. I checked GL_DEPTH_BITS and indeed I have a
24 bit depth buffer.
Since you have a Droid, could you do me a favor? Could you make a
simple app with nothing but a GLSurfaceView, load a 1024x1024 texture
(I'm actually using 512x1024, but 1024x1024 should show the
Droid has dedicated video ram I believe. Not sure about other devices. I
would guess the Nexus One does as well.
On Sun, Jan 31, 2010 at 9:54 AM, Federico Carnales
fedecarna...@gmail.comwrote:
Hi Robert,
I'm using GLSurfaceView. I checked GL_DEPTH_BITS and indeed I have a
24 bit depth
I've created a small sample class to show the problem:
http://fedecarnales.googlepages.com/TextureTest.java
It simply creates a full screen GLSurfaceView, sets up an orthogonal
2D matrix, creates a 1024x1024 texture from the default icon file, and
displays it as a 480x854 quad on screen. The
I'd test it on my Droid but my graphics guy has it right now. I can
try it out in a week or two when I get it back from him.
I think you may be video memory bound in some form. It sounds like
it's sheer bytes slowing you down. Can you load the texture as
RGB_565 mipmapped - nearest and give me
Did the test you requested, RGB_565, mipmapped - nearest. Got 18ms/
frame. Better, but still unacceptable as this would only be the
background image. The final app uses several sprites with alpha on top
of the background, so the performance drops significantly.
What's funny is that I'm getting
Correction: using SurfaceView to draw the background image does indeed
give me 60fps. And when adding the sprites on top of it, the
performance is not 60fps anymore, but still better than GLSurfaceView.
Federico
On Jan 31, 9:09 pm, Federico Carnales fedecarna...@gmail.com wrote:
Did the test
Hi Lance,
I doubt that's going to change much, I'm not doing any complex
geometry or anything. Just to make sure, I removed the glClear,
glActiveTexture, and glBindTexture calls from the draw method, and the
performance is exactly the same.
The performance hit seems to come from using heavy
The texture memory copy / fill bottleneck has been fairly consistent
across all chips so far. It's more pronounced on the MSM7200 chips
but is clearly still there. The good news is that while you might not
be able to get your upper FPS that you were hoping for, you probably
will be able to get a
21 matches
Mail list logo
