There was a post about ads on Android some months ago. As things move quickly on this platform I wanted to do a round 2 and see how your experiences are with the different ad providers? AdMob and Quattro Wireless used to be pretty serious players. However QW was purchased and closed down by Apple recently. Is AdMob the only decent ad provider at the moment or do you have good experiences with other providers as well?

Haha, yeah right now the mexicans and indians are bad guys along with the cowboys. Not yet sure about the whole theme though - might choose a complety different setting than wild west. Graphics is mockup right now.

Have been working on a rough prototype for a sniper game idea lately. The basic gameplay seems pretty fun. Would like some feedback on the direction of the game. Try it out and let us know what you think and anything you dont like/ ideas for the game.

Basic rules are:* control with accelerometer* touch screen to shoot* kill the bad guys* don't kill women or bad guys that have not yet drawn their weapon (Indians and Mexicans)* game ends when either you have been shot too many times or too many innocents have died on your shift.

Playable but still very much beta. Our biggest challenge right now is level design. We want to include a few fun maps in the final release. Thinking maybe it would be a good idea to find a professional level designer to help out. Any ideas, comments and suggestions very welcome!

They have glFlush - it is part of OpenGL 1.0 I believe. Read a bit about it. My impression so far was that it could be done before glSwapBuffers and also that glSwapBuffers can be expected to do a glFlush as the first thing it does. Will flush the pipeline but NOT wait for swap to complete. Was my impression. Curiously on G1 glFlush seems to return immidiatly and not wait for work to be done.

A little follow-up: After testing in depth we actually found that on Droid and Nexus One eglSwapbuffers returns before all the work is done. So it allows for paralellism in the way we hoped. The G1 however appears to block on the eglSwapbuffers call until all work is done. If running multithreaded however it is still possible to gain a performance increase of up to 20% on the G1 by parallelizing work.

I think if you want to give all players the best possible experience it is a good idea to implement both a software renderer and an OpenGL renderer and make an automatic choice on startup which the user can alter in a settings page in case the app chose poorly.

Yes that is a good point oNyx. Forgot to mention the devices running a Software renderer (HTC Tattoo among others). They are almost 5-10% of our players. They emulate hardware acceleration in software and thus have pretty poor OpenGL performance. On Tattoo the framerate was reduced to 10 which is not very playable.

After having spent 1 month rewriting one of our 2D games from Canvas to OpenGL we got the idea we should have had before starting the work: To investigate if this actually would give a higher FPS or not. The short answer is "no". The long answer is that it (big surprise) depends alot on the device. Wanted to post our findings here. Maybe someone can learn from them or has some comments.

Executive summary

It is a world of compromise:- The high-end, 1Ghz devices out there have way better performance on Canvas than OpenGL- The low-end (G1, dream, hero,..) devices have best performance on OpenGL- If you start doing rotations, scaling, applying semi-transparancy OpenGL gains on Canvas

It is an extension of Chris Pruetts Sprite Method Test. You can also find data from the phones we ran it on - G1, Nexus 1, Droid.

If you are in posession of another device we would be VERY interested in having you run the test on that device and let us know the output (found in LogCat). Just install the APK and press "Run Batch". It will go for a while - up to 2 hours. Could be cool to get more data to get a clearer picture of the situation.

I learned from Chris Pruett/ Replica Island that it should be possible to parallelize the eglSwapBuffers call. So if eglSwapBuffers is running in one thread other threads can run while eglSwapBuffers is completing. Reason for this should be that eglSwapBuffers is running on the GPU - not CPU.

I thus coded a game using two threads - a Render thread and a Physics thread. However I experienced none or very little performance gain. Very little if the thread priorities where calibrated. The eglSwapBuffers call takes 10-20 ms so if it was possible for other threads to run parallel with it it should result in 20% more frames.

Anyone has an opinion on 2-threaded GL games like this or even experience on Android or other platforms?

OK - is your code in a format that you can send so I can try and replicate your test run?

Also after instrumenting and further analysis I found that TraceView had exaggerated the cost of the buffer puts in relation to the whole programme execution. Traceview said that the buffer puts were 17% of all time spent whereas actually they are only 3%. So like Riven suggested the profiler was not quite truthful. It is still the case that the puts take 10 times longer than array puts - but the overall impact is lower than I thought.

In the "bin" folder there is the APK which you can install using adb install. Then you can run the test by starting the PerformanceTest app on your phone. The test will output the data in LogCat - these are the interesting lines (seen on a Nexus One 2.1):

Yes, wrote a small test app that times the different methods (one at a time, float[], FloatBuffer.wrap(float[]). One at a time is fastest, then float [], the slowest is to pass it a wrapped FloatBuffer.

Hmmm it is probably hardware specific which implementation of the put method you get. I am running on a Nexus One. And after putting in breakpoints I could see that the implementation of put(float[]) I got was one that just traversed the array and called put(float) on each element.

Was wondering if there could be an alternative way to construct the FloatBuffer for OpenGL. Haven't really been able to think one up though. From the source code it appear what is taking 10 times as long time is different checks and function calls. Nothing much but when applied 1000 times pr frame in a particle system it really ads up.

So we finally got accepted and got up and running on Google AdSense. So far it is disappointing though - we only have a CTR of about .3% whereas admob and QW can get to 2%. Anyone else have similar experiences? Maybe we are doing something wrong - it sounds very low to me...

Does anyone know if it is possible to access all the reviews for a given application on the android market? I noticed sites like cyrket and androlib has some - but they claim it is only a selection of the reviews they have. But all the reviews seem to be available on the phones. Apart from being very interesting data like this could be used in-game to for example make an achievement to write a review of the game to encourage user involvement (any rating ok of course).

I have made a game using Canvas but for performance reasons want to switch to using Canvas. However, some devices such as HTC Tattoo does not have very good hardware acceleration and performs worse with OpenGL! Wondering if anyone has made thoughts about that? Should both OpenGL and Canvas be supported and the user be able to choose via an in-game setting? Or the game can autodetect and choose OpenGL or Canvas? Or is it so few phones that don't support OpenGL HW accelerated that it is ok to just only go with OpenGL? I think I will end up just going with OpenGL for simplicity.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org