[android-developers] Re: [RFC] What are your thoughts on cross-platform development for Android and iOS?
Great input, thanks! As you said, with a cross-platform UI solution, there will always be platform/OEM/device specific issues that need special care. We can solve a lot of these on our end. There will obviously be cases we can't anticipate. The take away for me here is, that it should be possible for developers to easily special case in such a scenario. E.g. use the cross-platform API for 80% of the app, mix it with native APIs where necessary. As for our target. Atm Android developers who want to expand to iOS more easily as well as Android/iOS devs who already do both platforms but want to unify their tooling and share code across platforms are our target. In terms of type of apps, we want to cover all the bases. Game Dev is already covered (via libGDX) with great success. Retailers are also covered, they can use the native APIs on each platform to get 100% native UX, while sharing business logic between platforms. Governmental and enterprise is what we currently are working on and at which my initial questions are aimed. Thanks for the input, really appreciated! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] [RFC] What are your thoughts on cross-platform development for Android and iOS?
Hi, i'm the guy behind libGDX (http://libgdx.badlogicgames.com) and am currently also working on RoboVM (http://www.robovm.com) which allows you to run Java/Scala/Kotlin/... on iOS. Just like with libGDX, my main concern with RoboVM is to make cross-platform app development easier for people coming from a Java/JVM/Android background. We want to get input from the broader Android developer community to help us shape the future of RoboVM. It would mean a lot to us, a team of 4 devs, if you find the time to comment on the below blurb. A lot of people here are working in app shops that probably create apps for customers or themselves that need to work on both iOS and Android. Some may only focus on Android but may wish to expand to iOS. There are a few frameworks/platforms out there that can help with sharing code between both Android and iOS (C#, Java, JS, Ruby, pick your poison). Some of these frameworks/platforms allow you to share business logic and use the native UI APIs on each platform. This means you'll have to write the UI for each platform separately. The UX will most likely be better, but at the expense of more development time. Let's call this the native UI solution. Some frameworks allow you to share both the business logic and the UI code. A cross-platform UI API either wraps the native UI API (lowest common denominator between the two platforms), or it uses something like a webview, emulating the native UI. The UX will most likely be worse, but development time can be reduced. Let's call this the cross-platform UI solution. I'd be super happy if you have any input on the following questions 1. Do you think cross-platform development is viable at all? Why/Why not? 2. Would you rather use the native UI solution or the cross-platform UI solution? Why? Our focus with RoboVM at the moment is on the native UI solution and making the code-sharing of the business logic as easy as possible. Once this is complete, we also want to offer a crossplatform UI solution. We are currently evaluating different approaches: 1. JavaFX. That's already alpha quality, there's a whole community around it and we enable them to work on iOS. But it isn't the most natively looking feeling option. It also carries the Swing heritage with it. 2. Webview. Quite flexible but shares all the same problems that Phonegap et. al. have (performance, look feel). 3. Custom cross-platform UI. Gives us the most freedom. Maps a common API on top of native UI APIs, so the look feel is native. Might be a leaky abstraction though. I do have my preferences regarding the above 3 options, but i'd really love to get input from you folks on that. Thanks for your time, really appreciate it. Ciao, Mario -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Softkeyboard Problems (Fullscreen + GLES)
Hi,
i fooled around with the softkeyboard API a little and tested it on a
couple of phones. My test setup is an activity with a GLSurfaceView
set to fullscreen. When the screen is touched the softkeyboard is
brought up via
InputMethodManager manager =
(InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
manager.showSoftInput(view, 0);
A standard affair. This works flawlessly on all the phones i've
tested, e.g. Moto Droid (2.1.1), HTC Hero (1.5), Samsung Leo (2.1.1),
Asus Transformer (3.1), Nexus One (2.3.4).
It fails on the HTC Desire HD. The problem manifests itself in that
the keyboard is not shown at all. However, when one closes the app one
can briefly see the keyboard flicker on screen. The problem is not
present in non-fullscreen mode.
I assume the HTC Sense keyboard is the issue here. To confirm this i
installed one of the free IMEs from the market, and behold, it worked
without a problem.
Is there a solution to the issue? It seems there's no kind of
developer center apart from the download list at http://developer.htc.com.
Is there any way to report this to HTC directly?
For completeness, here's the source for the test activity. The
manifest file is pretty much vanilla, no additional attributes are set
for the activity.
Thanks a bunch!
Mario
package com.badlogic;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;
import android.app.Activity;
import android.content.Context;
import android.opengl.GLSurfaceView;
import android.opengl.GLSurfaceView.Renderer;
import android.os.Bundle;
import android.view.MotionEvent;
import android.view.View;
import android.view.Window;
import android.view.WindowManager;
import android.view.View.OnTouchListener;
import android.view.inputmethod.InputMethodManager;
public class SoftKeyboardTestActivity extends Activity implements
Renderer, OnTouchListener {
GLSurfaceView view;
@Override public void onCreate (Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
requestWindowFeature(Window.FEATURE_NO_TITLE);
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
WindowManager.LayoutParams.FLAG_FULLSCREEN);
getWindow().clearFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN);
view = new GLSurfaceView(this);
view.setFocusable(true);
view.setFocusableInTouchMode(true);
view.setRenderer(this);
view.setOnTouchListener(this);
setContentView(view);
}
@Override public void onPause() {
super.onPause();
view.onResume();
}
@Override public void onResume() {
super.onResume();
view.onResume();
}
@Override public boolean onTouch (View arg0, MotionEvent arg1) {
InputMethodManager manager =
(InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
manager.showSoftInput(view, 0);
return false;
}
@Override public void onDrawFrame (GL10 gl) {
gl.glClearColor(1, 0, 0, 1);
gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
}
@Override public void onSurfaceChanged (GL10 gl, int width, int
height) {
}
@Override public void onSurfaceCreated (GL10 gl, EGLConfig config) {
}
}
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Multi-touch pointer ids on Sony Xperia Play spurious ACTION_DOWN events
So, i wondered why we had that assumption. Back in 2009/early 2010 when 2.0 came out and the Droid blew away the world this group was full of multi-touch related topics. Dianne Hackborn answered ALL our questions back then, a feat that probably took up all her work time :P. She also explained how pointer ids are handed out by the system. original message: http://groups.google.com/group/android-developers/msg/2786021d43ae196d quote: If finger A goes down, then finger B, then finger A is released, you will see pointer #0 going up and the following movements will have only pointer ID #1 (at index 0 because that is the only active pointer). When the next finger goes down, it is given the first available pointer ID (there is no way to know which finger this is, so we assume the first available), thus you see a new pointer ID 0 going down. So, the first available pointer id is chosen. That was our assumption as well. There are a few more threads on the group that go into pointer ids and how they are generated. It seems the Xperia breaks this assumption. Would be nice to hear an official word on this. On 17 Mai, 04:25, Michael Leahy mleahy@gmail.com wrote: It looks indeed as if Sony was brewing their own special kind of 'fragmentation' I've come to a succinct definition of fragmentation at least from a developer perspective as unfortunately this term is widely misused and abused in the press and sometimes twisted in definition by organizations that produce it. Fragmentation is what happens when OS and device differentiation fails to honor standards and contracts of developer APIs. This covers faults in various OS versions and various ODM faults as well at least from a developer perspective. OS / device differentiation should be celebrated; fragmentation as defined above... not so much. --Mike On Mon, May 16, 2011 at 7:08 PM, Mario Zechner badlogicga...@gmail.comwrote: I don't have direct physical access to an Xperia myself so i can't comment on the button issues Robert discovered. It looks indeed as if Sony was brewing their own special kind of fragmentation. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Multi-touch pointer ids on Sony Xperia Play spurious ACTION_DOWN events
Jeffrey, thanks for your excellent answer, that cleared everything up! The confusion many people have concerning the pointer id versus pointer index issue is probably due to the wrongly named mask constants (ACTION_POINTER_ID_MASK or some such) in the original touch APIs. While those are now deprecated i know of a lot of people that still can't figure out the meaning behind that. That we all assumed that pointer ids would be handed out in the first free pointer id is returned kind of way is probably due to the dicussions we had on here, including Android engineers. I recognize that a lot has changed since then, and your use case scenario of touch splitting clearly illustrates the difference to the old ways. Makes total sense as well. I'd strongly suggest to either write a new dev blog entry on multi- touch that clearly states all your points in your post or updating the MotionEvent documentation which is still very ambiguous. Thanks again for the answers, much appreciated! On 17 Mai, 22:42, Jeffrey Brown jeffbr...@android.com wrote: Pointer ids should be considered to be arbitrary non-negative integers. The framework currently makes some assumptions about the range of these ids, but applications must not, lest they be broken sometime in the future. Imagine a device that supports 60 simultaneous finger touches. It could happen. :) Moreover, the order in which pointer ids are assigned is completely arbitrary. It happens to be the case that on most devices, the first pointer id assigned is 0. However the first pointer id could be anything. This is especially the case when the Honeycomb touch splitting feature is enabled (as it is by default for new applications). Suppose the user puts two fingers down within two different scrollable list views. The first finger might have id 0 and be delivered to a scrollable list view on the left. The second finger might have id 1 and be delivered to a scrollable list view on the right. From the perspective of the right hand list view, the first pointer id it received was 1, not 0. So I'm sad to say that many applications are making incorrect assumptions about pointer id values. One common bug is to conflate the meaning of the pointer id and pointer index values... crash! I strongly recommend that you track pointers using a sparse data structure like a map or android.util.SparseArray. Now let's talk about MotionEvent.ACTION_DOWN. The framework guarantees that motion events will always be delivered to a window in a consistent sequence: down/move/up, down/cancel, down/pointerdown/move/pointerup/up. However, the framework cannot work around buggy views that drop or corrupt part of the motion event stream before passing motion events down to their children. I've seen some custom views that do bad things like eat all multitouch events, or intercept some part of the gesture without canceling the rest. OnTouchListener implementations can also be problematic if they consume part but not all of a gesture. Views downstream may receive weird sequences of events as a result. As a defensive coding practice, views should be implemented to always reset themselves to a known ground state before handling ACTION_DOWN. In this way, they can recover in case some of their ancestor views fail to pass along the ACTION_UP or ACTION_CANCEL as would be expected. Likewise, bad things can happen during a gesture such as a pointer id mysteriously vanishing from the event without a an ACTION_POINTER_UP ever have been seen (because it was consumed somewhere else). Views should always check the result of MotionEvent.findPointerIndex and handle the case where a pointer went missing. Otherwise, the application may crash when it tries to access a pointer with index -1. Clearly if any of these things happen, there's a bug somewhere (probably in the app). It might not be very obvious though. With a little case, the app should be able to recover gracefully. Hope that helps, Jeff. On May 16, 12:58 pm, Mario Zechner badlogicga...@gmail.com wrote: A user reported an ArrayIndexOutOfBoundsException today in ourmulti-touchhandler. We store x/y/touchState on a per pointer id basis in an array. Dirty? Yes, but it worked on all devices so far. Usually pointer ids are handed out like this: first finger goes down - pointer Id 0 second finger goes down - pointer id 1 second finger lifted second finger goes down - pointer id 1 second finger lifted second finger goes down - pointer id 1 This works on all phones and some discussions in this group also point out this exact behaviour. Sadly, MotionEvent is underdocumented so it seems this was an assumption after all, not a rule all manufacturers would follow. On the Sony Xperia Play the following behaviour is observed. first finger goes down - pointer Id 0 second finger goes down - pointer id 1 second finger lifted second finger goes down
[android-developers] Multi-touch pointer ids on Sony Xperia Play spurious ACTION_DOWN events
A user reported an ArrayIndexOutOfBoundsException today in our multi- touch handler. We store x/y/touchState on a per pointer id basis in an array. Dirty? Yes, but it worked on all devices so far. Usually pointer ids are handed out like this: first finger goes down - pointer Id 0 second finger goes down - pointer id 1 second finger lifted second finger goes down - pointer id 1 second finger lifted second finger goes down - pointer id 1 This works on all phones and some discussions in this group also point out this exact behaviour. Sadly, MotionEvent is underdocumented so it seems this was an assumption after all, not a rule all manufacturers would follow. On the Sony Xperia Play the following behaviour is observed. first finger goes down - pointer Id 0 second finger goes down - pointer id 1 second finger lifted second finger goes down - pointer id 2 second finger lifted second finger goes down - pointer id 3 Is this a bug in the Xperia touch driver or is this actually wanted behaviour? Did we all (and there are a couple of people i know of having this issue) created faulty apps based on a wrong assumption? On a related note: The MotionEvent documentation has a new addition which reads like this: The view implementation should be prepared to handle ACTION_CANCEL and should tolerate anomalous situations such as receiving a new ACTION_DOWN without first having received an ACTION_UP for the prior gesture. The handling of ACTION_CANCEL is a no-brainer of course. What is making me a bit nervous is the fact that spurious ACTION_DOWN events can now happen. It is not clear whether this will only happen if a parent View consumed the accompanying ACTION_UP event or if this is behaviour to be expected even in single View applications. Any pointers would be appreciated, no pun intended. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Multi-touch pointer ids on Sony Xperia Play spurious ACTION_DOWN events
I don't have direct physical access to an Xperia myself so i can't comment on the button issues Robert discovered. It looks indeed as if Sony was brewing their own special kind of fragmentation. I have a kind issue reporter that helps us test. That's of course a very remote kind of debugging, but it's better than nothing. whine, whine, whine :) i found a temporary workaround, but it's fuglier and a tad bit slower than what we had previously. I basically allocate my own pointer ids and associate them with the real pointer ids as reported in the MotionEvents. This way i can guarantee our semantics that go like a finger going down on the screen will receive the first free pointer id, where pointer id is in the range 0 to #supportedfingers -1 On 17 Mai, 00:56, MichaelEGR foun...@egrsoftware.com wrote: ugh! Thanks for posting this message as this is a gnarly one and an example of ODM fragmentation if pointed IDs are not indexing correctly to the proper point data at least. I never was impressed by the multitouch API and always thought it wasn't thought out well and simply just tacked onto MotionEvent. Dirty as you say it is correct. I also wasn't pleased with the lack of documentation and unclear contract. Perhaps this lack of documentation led to this potential ODM fault. As for spurious ACTION_DOWN events this could be from varied quality of touchscreen hardware too. So from my reading of your post you are saying that pointer IDs are not recycled and that the data of subsequent pointer IDs is not correct at the specified array index? Not looking forward to coming up with a solution for my platform / middleware / custom event system and certainly am not excited if I need to buy an Experia Play just for this, but w/ talking with Robert G. it sounds like button support on this device is a bit wacky too. If I understand correctly button presses don't generate key events? Hrm; I hope that is not the case as I hate to have to waste $500+ to fix these kinds of issues. Likely I'll pick one up, fix the issues, then sell it. Regards, --Mike On May 16, 12:58 pm, Mario Zechner badlogicga...@gmail.com wrote: A user reported an ArrayIndexOutOfBoundsException today in our multi- touch handler. We store x/y/touchState on a per pointer id basis in an array. Dirty? Yes, but it worked on all devices so far. Usually pointer ids are handed out like this: -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: opengles question (to change content of vertexbuffer used in gldrawarrays)
Do not call glBufferSubData, use glBufferData instead. The former is dog slow on most mobile GPUs for various reasons (pipeline stall if that buffer is currently in use etc.). Also, do not use Buffer.put(int index, float value) if you can instead use the bulk put operations. For direct Buffers that's one JNI call per float which is way to costly. Note however that bulk puts are slow up until Android 2.3 as well. See http://www.badlogicgames.com/wiki/index.php/Direct_Bulk_FloatBuffer.put_is_slow On 2 Mai, 23:50, elix emr...@gmail.com wrote: Thanks adam. I asked this topic in stackoverflow and it is solved. Simply; update the coordinate data within the buffer object by using put(index, value) method and then call glbuffersubdata() method. Here is detailed answers:http://stackoverflow.com/questions/5849566/how-to-change-the-content-... On May 2, 8:21 pm, Adam Hammer adamhamm...@gmail.com wrote: Just use get and put on the buffer with your data.memory layout can vary but typically is xyzxyzxyz which would be the 9 floats that define your 3 vertices. Adam On May 1, 12:27 pm, emre onal emr...@gmail.com wrote: I have some triangle polygons and drawing them in a traditional way: (android-java code) gl.glDrawArrays(GL10.GL_TRIANGLES, i, j); I want to update the vertex coordinates of the triangles. All of the tutorials I've found use an initial vertex data then only apply transformations to them. I need to change each vertex coordinate independently. I change the content of the array which is used to create the related vertexbuffer but it doesn't make any change on the screen. Rebuilding the vertexbuffer on eachframe doesn't seem to be right way I guess. Can you point out any example source code at least, if you know any? -- Emre -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Help needed on porting Flixel Framework to Android. Current issue: switch from canvas draw to opengl es
Neat, a Flixel Android port would indeed be a nice to have. I saw that the project is actually not an Actionscript 3 project but a Java based project. Might i suggest basing the Android Flixel port on libgdx [1]? Benefit: it would also run on the desktop (windows, linux, mac) and the nasty OpenGL ES stuff is pretty much hidden by the utility classes we offer on top of the GLES binding. I played around with Flixel a little bit a while ago and the port to libgdx should be very straight forward and painless. I might even have some time to do this myself. Could you answer me some questions? - How much of the original Flixel API should be covered? - How much has been ported so far? I'd actually just rip out the interfaces/class/method signatures and replace the implementations. The more that is already available the better. Ciao, Mario [1] http://code.google.com/p/libgdx/ (ignore the fugliness of the site, we are working on a dedicated one with super awesome images and ajax and web scale and all that jazz...) On 27 Apr., 16:59, Leonardo Zimbres leonardozimb...@gmail.com wrote: Hello Android Devs, WingEraser (its how I know him) has been porting Flixel to Android for a while. What is flixel? An actionscript 3.0 game framework. Its very well organized and have a lot of good stuff into it. Collisions, particles, nice use of bitmaps to tiles and sprite animations. If someone is curious about flixel, its homepage has some games:http://flixel.org/ Abour the porting to android: Theres a lot of good done, but one issue is giving certain trouble: to convert the framework render pipeline, from canvas draw to opengl es. Theres someone up to work on that? Im lerarning what I can, but Im a little new on Java, Android and OpenGL. Ah, the last threads about flixel-android:http://flixel.org/forums/index.php?topic=2848.45 And the project page:http://code.google.com/p/flixel-android/ Thanks, Zimbres. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Honeycomb / 3.0 / Critical Java NIO Regression for duplicate()
My fsm, Mike! You must either be sick or getting tired. A 2 paragraph, 140 words reply? SCNR, just kidding :) Glad to see you alive and kicking. Thanks for the bug report, that will save me some grieve. On 29 Apr., 02:49, MichaelEGR foun...@egrsoftware.com wrote: Hah.. yes.. A minor oversight in prepping.. Doesn't change the bug though.. Having spent over 45 hours to hunt and fix this issue in my NIO code I don't really care to spend too much time on the write up / proof reading. Back to actual productive work.. ;P On Apr 28, 5:28 pm, Zsolt Vasvari zvasv...@gmail.com wrote: You realize 0x1 is 65536 not 65535 -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] GLSurfaceView + Android 2.3.x = EGL_BAD_ALLOC
Hi,
i got some reports from users of our framework that opening/closing an
OpenGL ES based app would force close with an EGL_BAD_ALLOC after
~20-30 open/close cycles on an Android 2.3 device. To eliminate any
problems related to our framework i wrote the simplest GLSurfaceView
based app i could come up with:
package com.badlogic.egl;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;
import android.app.Activity;
import android.opengl.GLSurfaceView;
import android.opengl.GLSurfaceView.Renderer;
import android.os.Bundle;
import android.view.Window;
import android.view.WindowManager;
public class EglBadAlloc extends Activity {
GLSurfaceView view;
@Override public void onCreate (Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
requestWindowFeature(Window.FEATURE_NO_TITLE);
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
WindowManager.LayoutParams.FLAG_FULLSCREEN);
getWindow().clearFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN);
view = new GLSurfaceView(this);
view.setRenderer(new Renderer() {
@Override public void onDrawFrame (GL10 gl) {
gl.glClearColor(1, 0, 0, 1);
gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
}
@Override public void onSurfaceChanged (GL10 gl, int
width, int
height) {
}
@Override public void onSurfaceCreated (GL10 gl,
EGLConfig config)
{
}
});
setContentView(view);
}
@Override public void onPause () {
super.onPause();
view.onPause();
}
@Override public void onResume() {
super.onResume();
view.onResume();
}
}
Running this on a Nexus One/Samsung Galaxy S with stock 2.3.3 will
eventually result in a force close with the following interesting
stack trace:
04-13 13:33:24.400: VERBOSE/RenderScript_jni(191): surfaceDestroyed
04-13 13:33:24.460: ERROR/Surface(867): invalid token (identity=335)
04-13 13:33:24.470: ERROR/Surface(867): invalid token (identity=335)
04-13 13:33:24.470: ERROR/Surface(867): invalid token (identity=335)
04-13 13:33:24.470: ERROR/Adreno200-EGL(867): egliGetNativeWindowSize:
unable to dequeue native buffer
04-13 13:33:24.470: ERROR/Surface(867): invalid token (identity=335)
04-13 13:33:24.470: ERROR/Surface(867): invalid token (identity=335)
04-13 13:33:24.470: ERROR/Adreno200-EGL(867): egliGetNativeWindowSize:
unable to dequeue native buffer
04-13 13:33:24.470: ERROR/Surface(867): invalid token (identity=335)
04-13 13:33:24.480: WARN/dalvikvm(867): threadid=9: thread exiting
with uncaught exception (group=0x40015560)
04-13 13:33:24.490: ERROR/AndroidRuntime(867): FATAL EXCEPTION:
GLThread 41
04-13 13:33:24.490: ERROR/AndroidRuntime(867):
java.lang.RuntimeException: eglMakeCurrent failed: EGL_BAD_ALLOC
04-13 13:33:24.490: ERROR/AndroidRuntime(867): at
android.opengl.GLSurfaceView
$EglHelper.throwEglException(GLSurfaceView.java:1080)
04-13 13:33:24.490: ERROR/AndroidRuntime(867): at
android.opengl.GLSurfaceView
$EglHelper.throwEglException(GLSurfaceView.java:1072)
04-13 13:33:24.490: ERROR/AndroidRuntime(867): at
android.opengl.GLSurfaceView
$EglHelper.createSurface(GLSurfaceView.java:992)
04-13 13:33:24.490: ERROR/AndroidRuntime(867): at
android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:
1335)
04-13 13:33:24.490: ERROR/AndroidRuntime(867): at
android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1118)
04-13 13:33:24.490: WARN/ActivityManager(103): Force finishing
activity com.badlogic.egl/.EglBadAlloc
To reproduce the issue just open and close (via the backbutton) the
app above around ~20 times in succession. The app is cached on 2.3 it
seems, The cache memory is growing and eventually the EGL error will
appear, force closing the app.
I looked at the sources of GLSurfaceView for 2.2 and 2.3 (latest AOSP
release tag in both cases) and there seem to be some changes in the
way EGL context destruction is handled. It seems that one can
explicitely request a the context destruction now. Sadly my brain
couldn't untangle the logic behind all that yet (and i'm afraid i lack
the time to go further down that rabbit hole).
So, before i log a bug on b.android.com, does anyone see a problem
with my above Activity code? Is there any solution that might not
require waiting for the next Android release and it's deployment?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this
[android-developers] Re: 3d engine advices
The overhead introduced by Interfaceing GL10/GL11 and GL20 is neglible i'd say. Sadly, there's no work around for that, i'd have prefered a static method solution if at all possible, but so is live. In real- world scenarios that overhead does not have an noticeable impact on your performance, tuning other things like texture filters/sizes will have a 100x bigger impact on the performance of your game. We are currently in the process of rewritting the 3D utility classes of libgdx, including better model format support among other things. See the blog at http://www.badlogicgames.com for more info (as well as the forums :)). Btw, Peter, Gamine looks very interesting as well! You should consider using a different license though, LGPL and Android don't mix well due to the dex format (users can't exchange the Gamine impl due to dex, which is a requirement of the LGPL if you don't provide the source of your complete app). On 13 Apr., 10:07, elix emr...@gmail.com wrote: Nice to hear from engine writers. As a note; The game was better than I expected to see :). On Apr 13, 3:12 am, Peter Eastman peter.east...@gmail.com wrote: Another engine to consider is Gamine (http://sourceforge.net/projects/ gamine). I have some experience with it since, well, I wrote it. :) And I wrote Losing Your Marbles with it, if you want to see it in action. Peter -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: GLSurfaceView + Android 2.3.x = EGL_BAD_ALLOC
Forgot to add: the problem does not appear on Android 2.3 (tested on
Hero 1.5, Droid 2.1.1, HTC Desire HD 2.2.2).
On 13 Apr., 14:31, Mario Zechner badlogicga...@gmail.com wrote:
Hi,
i got some reports from users of our framework that opening/closing an
OpenGL ES based app would force close with an EGL_BAD_ALLOC after
~20-30 open/close cycles on an Android 2.3 device. To eliminate any
problems related to our framework i wrote the simplest GLSurfaceView
based app i could come up with:
package com.badlogic.egl;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;
import android.app.Activity;
import android.opengl.GLSurfaceView;
import android.opengl.GLSurfaceView.Renderer;
import android.os.Bundle;
import android.view.Window;
import android.view.WindowManager;
public class EglBadAlloc extends Activity {
GLSurfaceView view;
@Override public void onCreate (Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
requestWindowFeature(Window.FEATURE_NO_TITLE);
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
WindowManager.LayoutParams.FLAG_FULLSCREEN);
getWindow().clearFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN );
view = new GLSurfaceView(this);
view.setRenderer(new Renderer() {
@Override public void onDrawFrame (GL10 gl) {
gl.glClearColor(1, 0, 0, 1);
gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
}
@Override public void onSurfaceChanged (GL10 gl, int
width, int
height) {
}
@Override public void onSurfaceCreated (GL10 gl,
EGLConfig config)
{
}
});
setContentView(view);
}
@Override public void onPause () {
super.onPause();
view.onPause();
}
@Override public void onResume() {
super.onResume();
view.onResume();
}
}
Running this on a Nexus One/Samsung Galaxy S with stock 2.3.3 will
eventually result in a force close with the following interesting
stack trace:
04-13 13:33:24.400: VERBOSE/RenderScript_jni(191): surfaceDestroyed
04-13 13:33:24.460: ERROR/Surface(867): invalid token (identity=335)
04-13 13:33:24.470: ERROR/Surface(867): invalid token (identity=335)
04-13 13:33:24.470: ERROR/Surface(867): invalid token (identity=335)
04-13 13:33:24.470: ERROR/Adreno200-EGL(867): egliGetNativeWindowSize:
unable to dequeue native buffer
04-13 13:33:24.470: ERROR/Surface(867): invalid token (identity=335)
04-13 13:33:24.470: ERROR/Surface(867): invalid token (identity=335)
04-13 13:33:24.470: ERROR/Adreno200-EGL(867): egliGetNativeWindowSize:
unable to dequeue native buffer
04-13 13:33:24.470: ERROR/Surface(867): invalid token (identity=335)
04-13 13:33:24.480: WARN/dalvikvm(867): threadid=9: thread exiting
with uncaught exception (group=0x40015560)
04-13 13:33:24.490: ERROR/AndroidRuntime(867): FATAL EXCEPTION:
GLThread 41
04-13 13:33:24.490: ERROR/AndroidRuntime(867):
java.lang.RuntimeException: eglMakeCurrent failed: EGL_BAD_ALLOC
04-13 13:33:24.490: ERROR/AndroidRuntime(867): at
android.opengl.GLSurfaceView
$EglHelper.throwEglException(GLSurfaceView.java:1080)
04-13 13:33:24.490: ERROR/AndroidRuntime(867): at
android.opengl.GLSurfaceView
$EglHelper.throwEglException(GLSurfaceView.java:1072)
04-13 13:33:24.490: ERROR/AndroidRuntime(867): at
android.opengl.GLSurfaceView
$EglHelper.createSurface(GLSurfaceView.java:992)
04-13 13:33:24.490: ERROR/AndroidRuntime(867): at
android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:
1335)
04-13 13:33:24.490: ERROR/AndroidRuntime(867): at
android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1118)
04-13 13:33:24.490: WARN/ActivityManager(103): Force finishing
activity com.badlogic.egl/.EglBadAlloc
To reproduce the issue just open and close (via the backbutton) the
app above around ~20 times in succession. The app is cached on 2.3 it
seems, The cache memory is growing and eventually the EGL error will
appear, force closing the app.
I looked at the sources of GLSurfaceView for 2.2 and 2.3 (latest AOSP
release tag in both cases) and there seem to be some changes in the
way EGL context destruction is handled. It seems that one can
explicitely request a the context destruction now. Sadly my brain
couldn't untangle the logic behind all that yet (and i'm afraid i lack
the time to go further down that rabbit hole).
So, before i log a bug on b.android.com, does anyone see a problem
with my above Activity code? Is there any solution that might not
require waiting for the next Android release and it's deployment?
--
You received
[android-developers] Re: Libgdx vs. andengine
Full disclosure: i'm the developer of libgdx. I think both have it's merits. Andengine will get you up and running faster than libgdx but is less flexible and slower in terms of rendering speed. It has a couple of nice features though that libgdx doesn't have (and vice versa). Libgdx is not a game engine like Andengine but more like a framework. We also have a fully functional 2D scene graph which is a tad bit more powerful than Andengine's layer concept. The downside is that you'll have to code custom nodes yourself. As a scene graph is most often overkill we also let you go a little bit more low level. Look into SpriteBatch and SpriteCache. And if you want to go fullblown OpenGL ES that's possible as well, nothing will interfer with your code :) Apart from that i'd say that you shouldn't overlook the cross-platform feature. If you don't want to deploy your game on the desktop that is totally fine. However, you can benefit from the extremely fast development times as you can code/run/debug on the desktop for 99% of the time instead of having to wait for the slow installation of every new apk you produce. Think of it as a lighting fast replacement for the slow emulator. We also have full javadocs, full 2D and 3D example games and are currently also creating wiki articles to help users out. Again, Andengine is really cool so i won't tell you to ignore it. It has a lot of stuff going for it. It uses our box2d wrapper and vector classes as well (among other things), so the physics are nearly identical. I just added a new feature today that was missing so far: box2d raycasting. I don't know when Nicolas will synch with upstream. That shouldn't keep you from using Andengine though. Evaluate both, they both have a pretty minimal setup cost and should be straight forward to get into. Ciao, Mario (http://www.badlogicgames.com) On 22 Dez., 05:34, Pedro Duque pmdu...@gmail.com wrote: I'm starting a new Android project and I need an opinion. The project needs a 2d physics engine and OpenGL. I looked into libgdx and andengine and both seem to fit although I don't think I'll need the cross platform features from libgdx. Which one is more suitable? Advantages/disadvantages? Opinions? Thank you, Pedro Duque -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL Problem with Sphere Texture Mapping
On 22 Dez., 20:42, Robert Green rbgrn@gmail.com wrote: 3DVec normal = (sphereCenter - point).normalize(); 3DVec normal = (point - sphereCenter).normalize(); Or your world will be upside down. Unless my brain is totally borked :) (could well be, 4am here...) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Libgdx vs. andengine
Cool. Let me know how it went. Good luck, have fun! On 23 Dez., 03:44, Pedro Duque pmdu...@gmail.com wrote: Mario, thank you for your informed and quite complete post. My main concern is that I don't want to divert too much from Android concepts and I'm afraid that using Lidgdx will lead me into new and strange concepts from Android while AndEngine is more integrated with Android way. Anyway I'll follow your suggestion: I will try to evaluate both to get an hands on decision (maybe I'll blog about the experience). Thank you, Pedro Duque On 22 December 2010 23:49, Mario Zechner badlogicga...@gmail.com wrote: Full disclosure: i'm the developer of libgdx. I think both have it's merits. Andengine will get you up and running faster than libgdx but is less flexible and slower in terms of rendering speed. It has a couple of nice features though that libgdx doesn't have (and vice versa). Libgdx is not a game engine like Andengine but more like a framework. We also have a fully functional 2D scene graph which is a tad bit more powerful than Andengine's layer concept. The downside is that you'll have to code custom nodes yourself. As a scene graph is most often overkill we also let you go a little bit more low level. Look into SpriteBatch and SpriteCache. And if you want to go fullblown OpenGL ES that's possible as well, nothing will interfer with your code :) Apart from that i'd say that you shouldn't overlook the cross-platform feature. If you don't want to deploy your game on the desktop that is totally fine. However, you can benefit from the extremely fast development times as you can code/run/debug on the desktop for 99% of the time instead of having to wait for the slow installation of every new apk you produce. Think of it as a lighting fast replacement for the slow emulator. We also have full javadocs, full 2D and 3D example games and are currently also creating wiki articles to help users out. Again, Andengine is really cool so i won't tell you to ignore it. It has a lot of stuff going for it. It uses our box2d wrapper and vector classes as well (among other things), so the physics are nearly identical. I just added a new feature today that was missing so far: box2d raycasting. I don't know when Nicolas will synch with upstream. That shouldn't keep you from using Andengine though. Evaluate both, they both have a pretty minimal setup cost and should be straight forward to get into. Ciao, Mario (http://www.badlogicgames.com) On 22 Dez., 05:34, Pedro Duque pmdu...@gmail.com wrote: I'm starting a new Android project and I need an opinion. The project needs a 2d physics engine and OpenGL. I looked into libgdx and andengine and both seem to fit although I don't think I'll need the cross platform features from libgdx. Which one is more suitable? Advantages/disadvantages? Opinions? Thank you, Pedro Duque -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] eglSwapInterval not exposed
Hi, i was curious to see whether the vsynch that is default on all devices is actually a hardware limitation of a software limitation. For this i first tried to get EGL_MIN_SWAP_INTERVAL. Neither EGL10 nor EGL11 expose that constant. Fair enough, the official EGL headers show me the constant value. I was surprised to find that my Hero has a EGL_MIN_SWAP_INTERVAL of 0. So you could in fact disable vsynch. For that you need eglSwapInterval. Only problem is that it's not exposed in the Java interface. It is however in the latest r5 release of the NDK, the first one to expose EGL functionality on the native side of things. Is there any way to backport this to to native code for say a 1.5 device? Or a 2.1 device? I know that turning of vsynch is probably a bad idea on a battery powered device. But i'd still like to have complete control if at all possible. The LG Star (Optimus 2X) featuring that shiny Tegra chip seems to have vsynch disabled by default, running at higher framerates than the display is capable of handling (a lot more than 60Hz). Ciao, Mario -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: eglSwapInterval not exposed
That makes a lot of sense. Thanks for the info, i completely forgot about compositing. I gather that some manufacturers might opt to disable the compositing vsynch as it seems to be the case with the LG Star. On 17 Dez., 03:07, Dianne Hackborn hack...@android.com wrote: Currently you can never draw directly to the screen, so this isn't meaningful. You are always drawing into a surface flinger surface, which is composited to the screen when you are done, and screen compositing is vsynced. On Thu, Dec 16, 2010 at 5:21 PM, Mario Zechner badlogicga...@gmail.comwrote: Hi, i was curious to see whether the vsynch that is default on all devices is actually a hardware limitation of a software limitation. For this i first tried to get EGL_MIN_SWAP_INTERVAL. Neither EGL10 nor EGL11 expose that constant. Fair enough, the official EGL headers show me the constant value. I was surprised to find that my Hero has a EGL_MIN_SWAP_INTERVAL of 0. So you could in fact disable vsynch. For that you need eglSwapInterval. Only problem is that it's not exposed in the Java interface. It is however in the latest r5 release of the NDK, the first one to expose EGL functionality on the native side of things. Is there any way to backport this to to native code for say a 1.5 device? Or a 2.1 device? I know that turning of vsynch is probably a bad idea on a battery powered device. But i'd still like to have complete control if at all possible. The LG Star (Optimus 2X) featuring that shiny Tegra chip seems to have vsynch disabled by default, running at higher framerates than the display is capable of handling (a lot more than 60Hz). Ciao, Mario -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Gamine 0.3 (3D game engine)
We switched from LGPL to Apache 2 for exactly that reason in libgdx. I'd recommend using it for your engine. Looks neat btw, keep up the good work! On 12 Dez., 19:24, Emmanuel emmanuel.ast...@gmail.com wrote: Do you have a suggestion for a different license? I don't want to create any obstacles to using it in commercial games, but I do want to make sure that if someone improves the library itself, those improvements will be released as open source. I'm not sure. Someone on the AndEngine blog ( that suffer the same LGPL plague ! ) advised to go with the Apache 2 license, but I'm not sure it force the modifications to be open source. Open source licensing is such a complex thing !! :) Ps: by the way I tried you game : it's nice but I think the difficulty slope is too big : I'm stucked in the third level ! Then try the fourth level. :) I failed too :) And you should give the option to remove the vibration... Good suggestion. I'll add that. Peter -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: compatible-screens and uses-gl-texture ?
I think the only thing needed is a manifest tag that let's you specify the OpenGL ES profile you want to work have available. That feature is already there but it seems some devices don't report it correctly. Everything else can and should be checked at runtime. That's what the extension string is for. Actually, you can even check for GLES2 support via EGL. Adding all possible OpenGL extensions to the manifest file will result in a lot of pain for everyone. And given that manufacturers aren't capable of letting their devices return the GLES profile i wouldn't rely on any manifest attributes the market tries to check anyways in case of OpenGL. Most drivers have horrible problems and manufacturers don't give a damn. On 12 Dez., 18:04, Dianne Hackborn hack...@android.com wrote: On Sun, Dec 12, 2010 at 8:54 AM, Phil Endecott spam_from_goo...@chezphil.org wrote: Don't overcomplicate it. 99% of reqirements are satisfied by and greater than, i.e. I need = 4 user clip planes and = 3 texture units. Don't let the theoretical possibility that someone might want to say I need exactly 2 user clip planes and anisotropic filtering OR less than 6 user clip planes and non-power-of-two mipmaps stop you from implementing the basic functionality. That's my point. I believe the number one pain point that has been raised is texture formats, so this is a solution for that which can be provided very quickly because it can re-use all of the existing infrastructure for features and shared libraries. Doing something more will delay any solution for textures. Anyway, I can't discuss this much more. I work on the platform, and this is totally unrelated to the platform -- filtering like this is not at the platform level (the platform doesn't even know what these things are), it is part of Market, and that is outside my area of expertise. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android 2.3: eclipse reporting Unable to execute dex: null
I have the exact same issue. I went the exact same route as the original poster. The verbose output of all the Android tools in Eclipse is not all that verbose it turns out. However, digging up the .log file in $workspace/.metadata/.log brought this up: !ENTRY com.android.ide.eclipse.adt 4 0 2010-12-07 01:40:29.576 !MESSAGE Unable to execute dex: null !STACK 0 java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.android.ide.eclipse.adt.internal.build.DexWrapper.run(Unknown Source) at com.android.ide.eclipse.adt.internal.build.BuildHelper.executeDx(Unknown Source) at com.android.ide.eclipse.adt.internal.build.builders.PostCompilerBuilder.build(Unknown Source) at org.eclipse.core.internal.events.BuildManager $2.run(BuildManager.java:629) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java: 172) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java: 203) at org.eclipse.core.internal.events.BuildManager $1.run(BuildManager.java:255) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java: 258) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java: 311) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java: 343) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java: 144) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java: 242) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: java.lang.NullPointerException at java.io.File.init(Unknown Source) at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java: 106) at com.android.dx.command.dexer.Main.processOne(Main.java:284) at com.android.dx.command.dexer.Main.processAllFiles(Main.java:220) at com.android.dx.command.dexer.Main.run(Main.java:176) ... 19 more Root exception: java.lang.NullPointerException at java.io.File.init(Unknown Source) at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java: 106) at com.android.dx.command.dexer.Main.processOne(Main.java:284) at com.android.dx.command.dexer.Main.processAllFiles(Main.java:220) at com.android.dx.command.dexer.Main.run(Main.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.android.ide.eclipse.adt.internal.build.DexWrapper.run(Unknown Source) at com.android.ide.eclipse.adt.internal.build.BuildHelper.executeDx(Unknown Source) at com.android.ide.eclipse.adt.internal.build.builders.PostCompilerBuilder.build(Unknown Source) at org.eclipse.core.internal.events.BuildManager $2.run(BuildManager.java:629) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java: 172) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java: 203) at org.eclipse.core.internal.events.BuildManager $1.run(BuildManager.java:255) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java: 258) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java: 311) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java: 343) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java: 144) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java: 242) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) This is the output i get when cleaning a previously working Android project that has dependencies to a normal Java project. Not all that helpful either, at least for me :/ Ciao, Mario On 7 Dez., 00:16, Xavier Ducrohet x...@android.com wrote: gotta love the error message. *sigh* From what you're saying you have all that's needed. Have you tried using the Sun VM instead of OpenJDK? We load dx.jar through reflection and it looks like calling out to a method through reflection failed. Xav On Mon, Dec 6, 2010 at 2:33 PM, Tom Gibara tomgib...@gmail.com wrote: I upgraded to the 2.3 SDK and have hit a problem I can't
[android-developers] Re: Android 2.3: eclipse reporting Unable to execute dex: null
Forgot to mention my system specs: Windows 7 Home Premium 32-bit, JDK 1.6.0_22, Eclipse Helios SR1. On 7 Dez., 00:16, Xavier Ducrohet x...@android.com wrote: gotta love the error message. *sigh* From what you're saying you have all that's needed. Have you tried using the Sun VM instead of OpenJDK? We load dx.jar through reflection and it looks like calling out to a method through reflection failed. Xav On Mon, Dec 6, 2010 at 2:33 PM, Tom Gibara tomgib...@gmail.com wrote: I upgraded to the 2.3 SDK and have hit a problem I can't resolve. First I updated the android plugins for eclipse (3.5.2) to the new version (8.0.0.v201011171904-77661). Then I used the SDK manager within eclipse to install the Android SDK 2.3 API 9 package, its documentation, and the Android SDK platform tools revision 1. On restarting eclipse I found that every non-library android project was reporting the same error: [2010-12-06 21:58:32 - Dex Loader] Unable to execute dex: null [2010-12-06 21:58:32 - ] Conversion to Dalvik format failed: Unable to execute dex: null I have tried cleaning the projects, reinstalling the plugins and changing the declared SDK location. I have confirmed that eclipse has the latest plugin, that the platform-tools directory exists, as does the platforms/android-9 directory, and that they contain the correct files. I switched the plugin into verbose for building, but can't see anything remotely suspicious. I can even run dx manually on the project bin directory and produce a classes.dex file. I'm stumped, does anyone have any ideas? This is on a 32-bit Ubuntu (Lucid Lynx) machine with OpenJDK (IcedTea6 1.8.2) (6b18-1.8.2-4ubuntu2) (build 16.0-b13, mixed mode) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Xavier Ducrohet Android SDK Tech Lead Google Inc. Please do not send me questions directly. Thanks! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android 2.3: eclipse reporting Unable to execute dex: null
Awesome thanks a bunch :) On 7 Dez., 01:54, Xavier Ducrohet x...@android.com wrote: hey all, we found the issue. It's related to referencing java project. We're looking at pushing a fix to ADT asap. In the meantime you can temporarily change to including your java project as a jar file. On Mon, Dec 6, 2010 at 4:42 PM, Mario Zechner badlogicga...@gmail.com wrote: I have the exact same issue. I went the exact same route as the original poster. The verbose output of all the Android tools in Eclipse is not all that verbose it turns out. However, digging up the .log file in $workspace/.metadata/.log brought this up: !ENTRY com.android.ide.eclipse.adt 4 0 2010-12-07 01:40:29.576 !MESSAGE Unable to execute dex: null !STACK 0 java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.android.ide.eclipse.adt.internal.build.DexWrapper.run(Unknown Source) at com.android.ide.eclipse.adt.internal.build.BuildHelper.executeDx(Unknown Source) at com.android.ide.eclipse.adt.internal.build.builders.PostCompilerBuilder.bui ld(Unknown Source) at org.eclipse.core.internal.events.BuildManager $2.run(BuildManager.java:629) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java: 172) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java: 203) at org.eclipse.core.internal.events.BuildManager $1.run(BuildManager.java:255) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java: 258) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.j ava: 311) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java: 343) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java: 144) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java: 242) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: java.lang.NullPointerException at java.io.File.init(Unknown Source) at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java: 106) at com.android.dx.command.dexer.Main.processOne(Main.java:284) at com.android.dx.command.dexer.Main.processAllFiles(Main.java:220) at com.android.dx.command.dexer.Main.run(Main.java:176) ... 19 more Root exception: java.lang.NullPointerException at java.io.File.init(Unknown Source) at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java: 106) at com.android.dx.command.dexer.Main.processOne(Main.java:284) at com.android.dx.command.dexer.Main.processAllFiles(Main.java:220) at com.android.dx.command.dexer.Main.run(Main.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.android.ide.eclipse.adt.internal.build.DexWrapper.run(Unknown Source) at com.android.ide.eclipse.adt.internal.build.BuildHelper.executeDx(Unknown Source) at com.android.ide.eclipse.adt.internal.build.builders.PostCompilerBuilder.bui ld(Unknown Source) at org.eclipse.core.internal.events.BuildManager $2.run(BuildManager.java:629) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java: 172) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java: 203) at org.eclipse.core.internal.events.BuildManager $1.run(BuildManager.java:255) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java: 258) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.j ava: 311) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java: 343) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java: 144) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java: 242) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) This is the output i get when cleaning a previously working Android project
[android-developers] Vertex buffer object corruption on MSM720xa
Hi there, i was refactoring some of my code today and wanted to minimze buffer object binds. My use case is it to bind a vertex buffer/index buffer pair once and batch up rendering as much as possible. Each batch is uploaded to the currently bound vbo. This works as expected on all tested devices (Nexus One, Droid, Samsung Galaxy) but fails on the HTC Hero with stock Android 1.5. I haven't updated the Hero to test exactly that kind of problems. I have compiled a small in depth description with a reproduceable test example. Both can be found at: http://www.badlogicgames.com/wiki/index.php/Severe_Bug_Updating_Already_Bound_Buffer_Object#Sample_Code I consulted with a couple of people whom i consider OpenGL experts and they all agreed that the way i handle the vbo/ibo is indeed correct and standard compliant. It would help if some people with an update Hero could try it out and see whether the problem persists. Should i file a bug on the Android bug tracker? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: GLES/IntBuffer/?? Mis-placed verts?
A screenshot of the error would help a lot. I suspect z-fighting of some sort given the information you gave us so far. On 13 Jun., 23:30, Samsyn d...@synthetic-reality.com wrote: and no, it's not 'the last triangle in the mesh' Seems fairly evenly distributed in that way, so I no longer blame my ShortBuffer (at least not in that way). It does maybe have a sweet spot though. the last few failures I have seen have all occured when looking just shy of due east (88 degrees from north, where north in my coord system is (0, 0, -1); so the failure is when looking about (.9, 0, 0 ). But now I have a cool texture diagnostic mode to more easily identify exactly which triangle I am looking at, so that's nice :-) I know, I will just prevent the camera from looking in that direction! turn turn SNAP turn turn SNAP. I can have a little on- shoulder-conscience-pet that hits you in the head when you get close to looking in the bad direction. The actual visual defect looks more like a triangle that is intersecting the near plane, more so than simply gone. But there is no way this triangle would be intersecting the near plane. It's like one of the verts is suddenly mis-placed behind the camera (again, static vertex buffer, the vert has not really moved, only the camera has moved). Well, only the transform has changed. Definitely a bug, just only 99% sure it's not mine :-) ON another note, I think this game just started to be fun today. Which is to say, it's now possible to get killed if you're not careful. Plus the code is still young enough that's it's all pretty and organized and easy to understand. On Jun 13, 1:34 pm, Samsyn d...@synthetic-reality.com wrote: Well, with that special hubris that comes just before you realize you did something super stupid: no, the code is PERFECT! :-) For some reason, I found some other threads talking about this (sort of) AFTER making my post (I looked first, honest!), but I guess those were sort of off-topic comments, so maybe a new post just for this is not a huge sin. I should mention I do not have the issue in the emulator (when I can stomach running at 4 fps), just on my Droid. (and maybe not on the Eris, the only other test phone I have), so this might be a Droid- specific issue. So far, I have only noticed it on my terrain, though the same code is used to render other meshes in the game (the poseable-skeleton characters, for example). It's possible it happens there as well and I just haven't noticed yet (I mean, if it's a Droid bug, I would think it would have some probability of happening on any of my meshes). But the terrain mesh has fairly large triangles, which is why I am willing to suspect a math overflow issue. Still, lots of nearby triangles, sharing the same verts, will be non-problematic. I guess the most LIKELY explanation would be the short index buffer. something like the first or last entry in the list, maybe. I lied a little implying there was just one terrain mesh, when really the full terrain is tiled with multiple meshes, and I haven't tried using goofy texturing to help identify if this is always a particular corner of such a mesh (i.e. first/last triangle). I guess I will try that now. But to answer your question, I pass the gl check stuff when I turn it on. And again, all the buffers are completely static, so their content should not be flakily changing. If I had bad numbers in the buffers, I would expect the problem to be pretty constant. - Dan On Jun 13, 1:21 pm, Frank Weiss fewe...@gmail.com wrote: I'm no GL expert by far, but is there possibly a debug or logging mode which might expose a calculation or data error?- Hide quoted text - - Show quoted text - -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Avoiding float operations in game design
What you are searching for is called fixed point math. The reason to do this on Android is that many current devices don't have a floating point processing unit. This will change in future devices i'm sure (all second generation devices seem to have an FPU). If you work in Java it does not pay of using fixed point math compared to using floating point math. For some reasons integer divisions are extremely costly and at the end of the day you will need to get the non-fractional part of the fixed point number which involves a division (or right shift). If you use fixed point math in native code via the NDK you might see a bit of a speed up on older devices. If you stay in Java land i strongly suggest to staying with floating point math. I'm also pretty sure that the decision to use of fixed point math in the Google Maps API is not due to performance considerations but due to precision considerations. Floats lose stuff when not handled with care (and even with care taken). It's the same for financial applications. In both cases its recommended to use fixed point integer math. On 8 Jun., 16:08, Neilz neilhorn...@gmail.com wrote: Right, ok. So in my example, I have Bitmaps being drawn to the Canvas (using an adaptation of SpriteMethodTest which I referred to a few days ago). 1) The Canvas.drawBitmap() method takes two floats as coordinates, so how can I avoid using them? Or if i was to pass 'integer' values, would that mean they were treated as such, regardless of the method signature? 2) Typical x and y points for my bitmaps are X: 281.01068 Y: 455.04297. When bitmaps get drawn to the screen, is this all wasted precision? Is drawing at 281.01068 any different from drawing at 281.31343? On Jun 8, 2:32 pm, Mark Murphy mmur...@commonsware.com wrote: Neilz wrote: Hi all. I've read this in a few articles, that one should avoid floating point operations within the physics update of a game. But how do you really achieve this? Surely all half decent games are going to involve this kind of maths? Use integer math. Does it mean, convert all your variables to int, or use double instead, or simply just cut it out as much as possible? For example, look at the Google Maps API, compared to the Location API. A Location object has a double for getLatitude() and getLongitude(). For light uses, that's fine. However, for Google Maps, trying to do everything in floating point would get too slow. Hence, the GeoPoint class has latitude and longitude as integer microdegrees -- 1E6 times the double value in degrees. This allows Google Maps to maintain a fair bit of precision while sticking with integer math. What you need to do for your game is come up with appropriate units of measurement such that you won't need fractional units, for whatever degree of precision you want. For example, instead of kilometers, do your calculations in meters, or centimeters, or millimeters. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, One Low Price! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Avoiding float operations in game design
First: what you are in need off is called fixed point math which is implemented by using integers, deciding how many low bits to use for the fractional part of a number and then do some shift magic to do basic math operations. It's an old trick used mainly on devices that do not have an FPU like many of the first generation android devices. From what i can tell from your posts you are using Java to develop your game(s). I strongly advise against using fixed point math in Java on Android, there's hardly any speedups gained due to this. All it does is obfuscate your code without any real benefit. If you go the native route you will see some speed up when using fixed point math though on older devices without an FPU. Seeing that most new devices all have an FPU (N1, Droid etc.) i'd suggest not thinking about it and going with floating point math. If you ever reach a point where your performance is not acceptable go native with the performance critical parts. If that does not help than you can consider using fixed point math. I'm also pretty sure that the Google Maps API uses fixed point math for the same reason financial applications use fixed point math: precision. It's nothing to do with speed. On 8 Jun., 16:08, Neilz neilhorn...@gmail.com wrote: Right, ok. So in my example, I have Bitmaps being drawn to the Canvas (using an adaptation of SpriteMethodTest which I referred to a few days ago). 1) The Canvas.drawBitmap() method takes two floats as coordinates, so how can I avoid using them? Or if i was to pass 'integer' values, would that mean they were treated as such, regardless of the method signature? 2) Typical x and y points for my bitmaps are X: 281.01068 Y: 455.04297. When bitmaps get drawn to the screen, is this all wasted precision? Is drawing at 281.01068 any different from drawing at 281.31343? On Jun 8, 2:32 pm, Mark Murphy mmur...@commonsware.com wrote: Neilz wrote: Hi all. I've read this in a few articles, that one should avoid floating point operations within the physics update of a game. But how do you really achieve this? Surely all half decent games are going to involve this kind of maths? Use integer math. Does it mean, convert all your variables to int, or use double instead, or simply just cut it out as much as possible? For example, look at the Google Maps API, compared to the Location API. A Location object has a double for getLatitude() and getLongitude(). For light uses, that's fine. However, for Google Maps, trying to do everything in floating point would get too slow. Hence, the GeoPoint class has latitude and longitude as integer microdegrees -- 1E6 times the double value in degrees. This allows Google Maps to maintain a fair bit of precision while sticking with integer math. What you need to do for your game is come up with appropriate units of measurement such that you won't need fractional units, for whatever degree of precision you want. For example, instead of kilometers, do your calculations in meters, or centimeters, or millimeters. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, One Low Price! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Java OpenGL ES 2.0 bindings
Hi, i just found out (thanks James) that the new Java GLES 2 bindings are missing a vital method: glVertexAttribPointer(int indx, int size, int type, boolean normalized, int stride, Buffer ptr) That's the only thing in there and takes a buffer. Given only that we can not use VBOs in OpenGL 2.0 with the Java bindings. Any chance of getting that in say 2.2.1? Should i file a bug in this case? I did custom JNI bindings a couple of months ago which work with 2.0 upwards if anyone want's to try that instead in the meantime (http:// code.google.com/p/gl2-android/). Ciao, Mario -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Java OpenGL ES 2.0 bindings
Awesome, thanks for the quick reply! On 8 Jun., 20:40, Romain Guy romain...@android.com wrote: Our OpenGL guy is looking into it :) On Tue, Jun 8, 2010 at 10:15 AM, Mario Zechner badlogicga...@gmail.com wrote: Hi, i just found out (thanks James) that the new Java GLES 2 bindings are missing a vital method: glVertexAttribPointer(int indx, int size, int type, boolean normalized, int stride, Buffer ptr) That's the only thing in there and takes a buffer. Given only that we can not use VBOs in OpenGL 2.0 with the Java bindings. Any chance of getting that in say 2.2.1? Should i file a bug in this case? I did custom JNI bindings a couple of months ago which work with 2.0 upwards if anyone want's to try that instead in the meantime (http:// code.google.com/p/gl2-android/). Ciao, Mario -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Box2D on Android via JNI
Hi there, i thought i'd post a link here for future reference. I wrote a complete JNI bridge to the latest Box2D release for Android. All relevant classes are wrapped via lightweight Java counter parts, all listeners except the destroy listener are exposed, all joints are support and so on and so forth. The only things missing are some of the body-GetNextBody() methods which would just not work out very well in Java (well, it's possible but not very wise performance wise). The focus of this port was on getting a zero dynamic allocation version of Box2D directly accessible in Java and i think i succeeded in that. You can find more info about it at http://apistudios.com/hosted/marzec/badlogic/wordpress/?p=586. I altered the source only marginally, some of the include definitions needed reworking (at least i couldn't get it to work any other way) and the dependence on the stl algorithm package for sorting has been replaced by a simple qsort. Other than that it's a vanilla Box2D version that's used. Also note that this does work on the desktop as well (libgdx is crossplatform ). I consider making a seperate project out of this so it is not dependant on libgdx. For the time being i keep it there though as it eases my pains of managing multiple projects a little. It should be trivial to cut out the box2d parts from the libgdx source and create a seperate project out of it. So just go ahead if that's what you want to do :) Hope that helps out a couple of you guys a little, Mario -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to create Android library in Eclipse?
Actually, i do something a bit nasty to get a seperate Android library project. In your SDK folder you have several android jars for the different Android versions. I simply create a Java project and add the lowest Android version jar i want to support as a dependency et voila you have a nice Android library project. On 4 Mai, 08:11, Menion menion.as...@gmail.com wrote: You say that sharing resources between projects is coming? Hopefully, thx for very, very good info :) On May 3, 11:34 pm, Xavier Ducrohet x...@android.com wrote: If you're code is straight java with no android resources then just create a Java project and reference it by your Android projects. Android libraries allowing you to share (android specific) code and resources between projects is not supported at the moment, but it's coming. Shared libraries are not supported at this time by the platform and I don't think there's any plan for it. Xav 2010/5/3 Rafał Grzybowski aguyngue...@gmail.com: I'm working on two android applications and would like to share some code between them. My guess is I need to create Java library and put all the required code there. But I don't know: - what kind of project create for the library in Eclipse, - does the shared library can contain Android resources, - what about AndroidManifest.xml for the library, is it possible to have one, - is it possible to deploy shared library once on the device or is it shareable during development and then deployed per Android application? Thank you. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Xavier Ducrohet Android SDK Tech Lead Google Inc. Please do not send me questions directly. Thanks! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Device Seeding Program for Top Android Market Developers
Got my N1 on friday but missed the fed ex guy. Just received it 2 hours ago, Graz, Austria from Netherlands. Thanks a bunch Google! On 3 Mai, 17:43, heedrox heed...@gmail.com wrote: TreKing: for those of us (including me) that have not received the N1, I think we still would like to hear ocasionally the sentence N1 received in... so as we can see that N1s are still being sent, and ours will arrive (soon?). I don't know if I'll have to wait one week or three or six more, but I will get very nervous if I don't see movement in this list, and I would feel very alone in this whole universe... Hope you understand. Thanks. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Change the playback rate of a track in real time
i have written jni wrappers around mpg123 and libvorbis for android. you can find them included in libgdx which is available at http://code.google.com/p/libgdx/. More info can be found at http://www.badlogicgames.com or you can email if you have any questions. writting to a wav file is not included should be extremely simple though. On 2 Mai, 19:48, Peter Jeffe pje...@gmail.com wrote: On May 2, 6:36 am, yakura y yakura@gmail.com wrote: Is there any library out there that it allows to decode mp3/ogg to wav in android in realtime? (not necessarily in realtime but it could be great). I think I need to use the NDK but I would not like to have to manage with that. ffmpeg and mpg123 are the ones that I know of for MP3, don't know of any for OGG. I don't think you're going to find a Java decoder, and certainly not in real time. -- Peter -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Maximum Texture Units
gentextures only creates handles for you. Actual memory for the bitmap data is allocated when calling glteximage2D. That will be your biggest limitation as video ram is of course limited. How much vram is available is dependent on the chipset/device you are running your application on. On 1 Mai, 00:59, Jeremiah Sellars sylus.mcf...@gmail.com wrote: Oh, geez... okay that explains it. Thanks to both of you, that really explains it well. Is there then a limit on the number of textures GenTextures can return? On Apr 30, 3:39 pm, Robert Green rbgrn@gmail.com wrote: Yeah multiple texture units are only needed for multitexturing, of which the most common use is for lightmapping. On Apr 30, 4:57 pm, Mario Zechner badlogicga...@gmail.com wrote: The number of texture units and the maximum texture size are not really related in any way. The number of texture units tells you how many textures you can use simultaniously when drawing geometry (how many textures can be bound at once). You can have more textures in video ram than there are texture units, however, you can only bind #texture units textures at any time. A maximum of 2 texture units is sufficient for most scenarios where you have a diffuse texture and a lightmap for example. The maximum texture size is really just an estimate with most drivers and depends on things such as internal storage (which might be fixed by the driver anyways) and so on. In any case, both numbers will differ from device to device or rather chipset to chipset. On 30 Apr., 23:19, Jeremiah Sellars sylus.mcf...@gmail.com wrote: I'm wondering if this is just an issue with how the emulator is setup, but I'm not sure. I'm (natively) calling this: int maxt = 0; glGetIntegerv(GL_MAX_TEXTURE_UNITS, maxt); __android_log_print(ANDROID_LOG_VERBOSE, Native, Max textures %d, maxt); This only outputs 2... could it be possible that I'm going to be allowed only 2 textures? That seems impossible... GL_MAX_TEXTURE_SIZE reports 4096 which is more than enough. I suppose you could lay everything out on a couple of 4096x 4096 images (seems a bit crazy) but anyway... Am I just running into one of things that will be different per phone processor? Thanks everyone, Jeremiah -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Maximum Texture Units
The number of texture units and the maximum texture size are not really related in any way. The number of texture units tells you how many textures you can use simultaniously when drawing geometry (how many textures can be bound at once). You can have more textures in video ram than there are texture units, however, you can only bind #texture units textures at any time. A maximum of 2 texture units is sufficient for most scenarios where you have a diffuse texture and a lightmap for example. The maximum texture size is really just an estimate with most drivers and depends on things such as internal storage (which might be fixed by the driver anyways) and so on. In any case, both numbers will differ from device to device or rather chipset to chipset. On 30 Apr., 23:19, Jeremiah Sellars sylus.mcf...@gmail.com wrote: I'm wondering if this is just an issue with how the emulator is setup, but I'm not sure. I'm (natively) calling this: int maxt = 0; glGetIntegerv(GL_MAX_TEXTURE_UNITS, maxt); __android_log_print(ANDROID_LOG_VERBOSE, Native, Max textures %d, maxt); This only outputs 2... could it be possible that I'm going to be allowed only 2 textures? That seems impossible... GL_MAX_TEXTURE_SIZE reports 4096 which is more than enough. I suppose you could lay everything out on a couple of 4096x 4096 images (seems a bit crazy) but anyway... Am I just running into one of things that will be different per phone processor? Thanks everyone, Jeremiah -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Finally, I published my Android/GAE based MMO War Game
Got spamed too. Not holding my breath that anything will be done about it though... On 28 Apr., 22:22, Mike michaeldouglaskra...@gmail.com wrote: Also, section 3.8 of the Android Market Terms of Service covers unfair competition law. Encouraging 5 star comments on your app in exchange for benefits to your users is clearly a method of spreading false information for competitive advantage. 3.8 You agree that Google and/or third parties own all right, title and interest in and to the Market and the Products available through the Market, including without limitation all applicable Intellectual Property Rights in the Products. Intellectual Property Rights means any and all rights existing under patent law, copyright law, trade secret law, trademark law, unfair competition law, and any and all other proprietary rights worldwide. You agree that you will not, and will not allow any third party to, (i) copy, sell, license, distribute, transfer, modify, adapt, translate, prepare derivative works from, decompile, reverse engineer, disassemble or otherwise attempt to derive source code from the Products, unless otherwise permitted, (ii) take any action to circumvent or defeat the security or content usage rules provided, deployed or enforced by any functionality (including without limitation digital rights management or forward-lock functionality) in the Products, (iii) use the Products to access, copy, transfer, transcode or retransmit content in violation of any law or third party rights, or (iv) remove, obscure, or alter Google's or any third party's copyright notices, trademarks, or other proprietary rights notices affixed to or contained within the Products. - Mike On Apr 28, 2:13 pm, Mike michaeldouglaskra...@gmail.com wrote: Google Android Market TOS Section 3.4 states: 3.4 You agree that you will not engage in any activity that interferes with or disrupts the Market (or the servers and networks which are connected to the Market). You agree that you will not use any of the Products found on the Market in a way that interferes or disrupts any servers, networks, or websites operated by Google or any third-party. I would count artificially enhancing the ratings/ranking of your app, as well as posting spam comments on other apps as feedback to be engaging in activity that interferes with or disrupts the Market. - Mike On Apr 28, 12:34 pm, Ralf Schneider li...@gestaltgeber.com wrote: I just checked World War. This game uses a referral system, too. The generated codes look similar as the referral codes from PE. Wrold War has over 25 downloads as PE. Unfortunately I think there is no easy solution to the problem for google. Is a referral system really violating the TOS of the market? What can be done to reduce spamming comments on other apps? Is it really illegal to ask users to advertise your apps in comments for other apps? Is an automatic solution possible to clean the comments? The problem will get much more serious if other developers will follow. It can ruin the whole comment system. On the other hand: If it work so well and nothing is done against it, it would be silly to not to use a similar system. 2010/4/28 Robert Green rbgrn@gmail.com Just got another spam comment on one of my games, this time for a game called World War Also getting several pocket empires spam comments on my games. Not cool. On Apr 28, 12:46 pm, Robert Green rbgrn@gmail.com wrote: Oh wow. I had no idea they were actively telling people to spam their game on our games. Here are some alleged quotes from the developer's chat with some android users: Pocket Play is the publisher of this game: [4/18/2010 9:05:40 PM] Pocket Play: Could use some help advertising our game on the market. I'll reward anyone who helps with 200 gems. [4/18/2010 9:07:20 PM] Pocket Play: Basically, I need some people to go to apps and post one time per app about our game. [4/18/2010 9:07:24 PM] Pocket Play: So we can spread the news. [4/18/2010 9:07:51 PM] Pocket Play: Not every app needs to be done but just some. [4/18/2010 9:08:43 PM] Pocket Play: Just post something like.. [4/18/2010 9:09:14 PM] Pocket Play: Want an awesome online medieval war game? Search up Pocket Empires in the market. 40,000 and counting. [4/18/2010 9:12:52 PM] Pocket Play: You have to rate it first [4/18/2010 9:12:56 PM] Pocket Play: Rate everything you comment on 5 stars [4/18/2010 9:26:02 PM] Pocket Play: all good. [4/18/2010 9:26:10 PM] Pocket Play: Theres your 220, keep up the good work The quotes are from here - http://www.google.com/support/forum/p/Android+Market/thread?tid=173b4... On Apr 28, 11:19 am, Ralf Schneider li...@gestaltgeber.com wrote: The referall system together with users spamming other apps seems to
[android-developers] Re: glTexImage2D very slow on phones like Nexus one
In that case you have a problem indeed. Frame buffer objects will not be of any help in your situation. Speaking in absolutes is always a problem but i think for your problem at hand you will have to abonden OpenGL for the time being. I'm not aware of an alternative but remember another thread on here that talked about the same issue. On 19 Apr., 08:40, Eong eong.c...@gmail.com wrote: Sorry, I mean write the frame to a pixel buffer. I think fbo is a ES2 feature, right? What about the other ES1 phones? As a developer, you can't just give up the 75% users. On 4月19日, 下午2时20分, Eong eong.c...@gmail.com wrote: Hi, I'm writing this part for video output. This is for video output at most of the time. Our decoder write the screen to a pixel buffer. And then I need to draw it to the screen. So, you mean, I can use FBO to do this? I'm not very familiar with fbo stuffs. Could you give more hint? Thank you! On 4月18日, 下午5时18分, Robert Green rbgrn@gmail.com wrote: Eong, All Mario and I are trying to say is that the thing you are trying to do (upload textures every frame) is generally not considered a good practice and workarounds usually exist that are more efficient, especially if you can target higher levels of opengl or use extensions like framebufferobjects. If you would be willing to tell us something a little bit more specific about what you're doing that requires a texture update every frame, we could potentially offer some more efficient ways of doing it. On Apr 18, 2:44 am, Eong eong.c...@gmail.com wrote: Thanks, Mario. I think it's somewrong with the driver or the chip. It's not just a bandwidth problem. If it's really a bandwidth problem, it only has 1/7 bandwidth of milestone? (150ms compare to 20ms with a full screen tex).That's very funny. I'm working on some libs, which will be used for our tools and games. When a full screen update only takes 20+ms, it's usable in some conditions as it already gets at least 40fps. On 4月17日, 下午6时22分, Mario Zechner badlogicga...@gmail.com wrote: It seems that the msm chips are notorious for having a low bandwidth. There's really no solution to that problem other than 1) lowering your texture size 2) lowering the bit depth of the texture, e.g. instead of using RGBA use RGBA444 or RGB565 2) uploading your texture in patches, e.g. split it up into 4 smaller parts and upload one part each frame. This will probably lead to artifacts if your frame rate is low but could work otherwise. Just out of curiousity: why do you have to upload such a big texture each frame? If you'd state your scenario in detail we might be able to suggest other solutions to the problem. On 17 Apr., 12:10, Eong eong.c...@gmail.com wrote: Robert, Sorry, it's not text, it's tex. I just use this to draw the background. I just want to know why nexus one is so slow with this. It takes 20ms on my milestone but it takes at least 80ms on the nexus one, for one frame. On 4月17日, 上午2时08分, Robert Green rbgrn@gmail.com wrote: Eong, You said you are uploading every frame just to draw text? There are much more efficient ways to do that. On Apr 16, 11:14 am, Eong eong.c...@gmail.com wrote: I'm afraid it's not a same problem. My problem only happenes on Snapdragon phones. It's fine on Milestone or Droid. I found a few threads about this but no solution. On 4月16日, 下午9时15分, Felipe Silveira webfel...@gmail.com wrote: Just a guess: It can be the same error reported here:http://code.google.com/p/android/issues/detail?id=7520 Take a look... Felipe Silveirahttp://www.felipesilveira.com.br On Fri, Apr 16, 2010 at 8:40 AM, Eong eong.c...@gmail.com wrote: Hi, We are developing 2D games. And we found our game works fine except the snapdragon chips, like Nexus one and Liquid A1. It even runs fine on G1. We use GLSurfaceView, and we useglTexImage2Dand glTexIsubmage2D to put on the text and then draw. TheglTexImage2Dclass take more than 100ms on Nexus one (1024x512 pix tex). It's very strange, G1 is even faster than this. If anyone know something about this? -Code snip--- gl.glClear(GL10.GL_COLOR_BUFFER_BIT | GL10.GL_DEPTH_BUFFER_BIT); gl.glTexSubImage2D(GL10.GL_TEXTURE_2D, 0, 0, 0, m_width, m_height, GL10.GL_RGB, GL_UNSIGNED_SHORT_5_6_5, m_byteCanvas); ((GL11Ext)gl
[android-developers] Re: What format and tools do you use for music in your games?
I'm also sticking to ogg at the moment which of course limits the amount of music i can pack into my games. For production is use some tools from drpetters, namely sfxr for 8-bit sound effects as well as audacity and cubase for heavy lifting. Another way i plan on lifting the application size problem is via downloading the tracks to sd-card after the game was installed. I'd also be very interested in an Android port of libmod :) On 19 Apr., 22:25, Robert Green rbgrn@gmail.com wrote: I really like Cubase 5. I've been a Cubase user for years and you can get a light version pretty cheap. It, like many production apps, take a little bit of effort to learn but I can now crank songs out in it like nothing else. I don't recommend MIDI on Android, btw. I started using it for a new game but switched back to 22khz low-quality ogg after I had problems with MIDI playback performance, trigger misses and the lack of ability to loop seamlessly. Perhaps JET can do better. I was thinking trackers would be ideal, though. I grew up around mods and used fast tracker 2 for years. Let me know if you get that lib working well! I'm currently sticking to small, low quality loops to keep file size down. On Apr 19, 11:17 am, Patrick specter...@gmail.com wrote: I've been looking around for tools for working with MIDI to create soundfonts, but the one mentioned in the Android JET docs (Awave) is a bit pricey for me. Tried Vienna Soundfont Studio but it quickly told me that I have no soundfont compatible device on my laptop... Since I'm coming from a GBA/DS homebrew background, my current solution is using the tracker formats (MOD,XM,IT, etc.) and building libmodplug with the NDK. It allows me to bring the size of the 12 music files in my game down from about 15MB (ogg) to 750KB (mod,xm + libmodplug.so size). Yes, I like music in games! Anyway, just wondering how other game developers are handling music and what tools you're using. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Is the bad MotionEvent/Touch slowdown stuff actually fixed on first-gen 2.1 updates?
I can confirm that the issue is still there in Android 2.0.1 on my Milestone as well (and more pronounced) on my HTC Hero which still runs 1.5. I put together a quick test that you can download from http://file-pasta.com/file/0/touchflood.apk (Note: it's 300kb because i used a game dev framework to put that together which features a bit more than is needed). Observations on 2.0.1: - Touching alone decreases the performance a bit, around 2-4 frames are lost - Touching and moving the finger around makes things works, the frame rate drops by up to 8fps - The slow down is not constant but fluctuates a lot. - Sleeping in onTouch does not solve the problem at all (sleep times from 16 to 40ms) but only increases the lag in user input At least there's no garbage collection in 2.0.1 anymore due to touch events. On 18 Apr., 11:46, Robert Green rbgrn@gmail.com wrote: Actually I take it back about the emulators. I just tested again in the 2.1 emulator and realized that in my first test, I was holding the finger down on the screen but unlike a device, it doesn't send constant motion events if you hold the cursor still. Moving the cursor (touch) around caused the same problem as on 1.6! Now I'm a little worried. Is this problem really still not fixed? On Apr 18, 4:30 am, Robert Green rbgrn@gmail.com wrote: Just wondering if anyone can speak on this yet. I'd really like to know what the state of that fix is as 2.1 is rolled out onto first generation (MSM7200-based) devices. As it stands, I don't see much of a problem with touch eating up CPU on the Droid and N1 but those are much faster phones so I don't think it would be quite as pronounced on them. My current 1.6 devices (G1 and Tattoo) cut my framerates in half during any touch (with the sleep hack, even). I optimized my new games so that they would run well-enough (25-40fps) on that hardware but they have very touch-centric interfaces so won't work well with that bug. I talked to a few people who run 2.0/2.1 mods on their G1s and they said the problem isn't any better. They still see the big slowdown. I tested on my 1.6 emulator vs a 2.1 emulator and there is a huge improvement. The 1.6 emulator slows down just like my G1 does and the 2.1 emulator shows only a tiny bit of slowdown, which is what I was hoping for. That's encouraging, but I have yet to see a real 2.1 MSM7200 update in the field so I don't know what to think yet. Anyone got anything concrete on this? Thanks! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Is the bad MotionEvent/Touch slowdown stuff actually fixed on first-gen 2.1 updates?
see replica island switch to constant-touch controls (virtual joystick or virtual dpad) and retain framerates over 20 with that input scheme on any MSM7200-based device. I'm a little frustrated. I've spent the last 6 months writing two really nice games (Best work I've ever done in my 11 year programming career, in fact) and this is their main issue now. They run fantastic on the Droid and N1, of course, and even get solid framerates on the MSM7200 up until you touch the screen... Then it's lag-city all the way home. I'm ready to put up a decent cash bounty for someone that can provide a reliable solution to this that doesn't involve me taking away the constant-touch controls. Contact me if you have experience fixing this problem and are sure you can do it. On Apr 18, 5:41 am, Mario Zechner badlogicga...@gmail.com wrote: I can confirm that the issue is still there in Android 2.0.1 on my Milestone as well (and more pronounced) on my HTC Hero which still runs 1.5. I put together a quick test that you can download fromhttp:// file-pasta.com/file/0/touchflood.apk(Notehttp://file-pasta.com/file/0/touchflood.apk%28Note: it's 300kb because i used a game dev framework to put that together which features a bit more than is needed). Observations on 2.0.1: - Touching alone decreases the performance a bit, around 2-4 frames are lost - Touching and moving the finger around makes things works, the frame rate drops by up to 8fps - The slow down is not constant but fluctuates a lot. - Sleeping in onTouch does not solve the problem at all (sleep times from 16 to 40ms) but only increases the lag in user input At least there's no garbage collection in 2.0.1 anymore due to touch events. On 18 Apr., 11:46, Robert Green rbgrn@gmail.com wrote: Actually I take it back about the emulators. I just tested again in the 2.1 emulator and realized that in my first test, I was holding the finger down on the screen but unlike a device, it doesn't send constant motion events if you hold the cursor still. Moving the cursor (touch) around caused the same problem as on 1.6! Now I'm a little worried. Is this problem really still not fixed? On Apr 18, 4:30 am, Robert Green rbgrn@gmail.com wrote: Just wondering if anyone can speak on this yet. I'd really like to know what the state of that fix is as 2.1 is rolled out onto first generation (MSM7200-based) devices. As it stands, I don't see much of a problem with touch eating up CPU on the Droid and N1 but those are much faster phones so I don't think it would be quite as pronounced on them. My current 1.6 devices (G1 and Tattoo) cut my framerates in half during any touch (with the sleep hack, even). I optimized my new games so that they would run well-enough (25-40fps) on that hardware but they have very touch-centric interfaces so won't work well with that bug. I talked to a few people who run 2.0/2.1 mods on their G1s and they said the problem isn't any better. They still see the big slowdown. I tested on my 1.6 emulator vs a 2.1 emulator and there is a huge improvement. The 1.6 emulator slows down just like my G1 does and the 2.1 emulator shows only a tiny bit of slowdown, which is what I was hoping for. That's encouraging, but I have yet to see a real 2.1 MSM7200 update in the field so I don't know what to think yet. Anyone got anything concrete on this? Thanks! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group athttp:// groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group athttp:// groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group athttp
[android-developers] Re: NDK / glsl / Es 2.0 advice please?
Hi, OpenGL ES 2.0 (GLES2) is completely based on writting your own vertex and fragment shaders. Both types serve a specific purpose. Vertex shaders in their most basic form are responsible for transforming the incoming vertex position. This includes moving them from object to world space, from world space to camera or view space and finally projecting the camera/view space positions. Transformations and projections are achieved via matrices which you usually pass to your shader as so called uniforms. A vertex shader outputs the final vertex position and potentially other information for the fragment shader, like interpolated texture coordinates and normals. A vertex shader thus has to perform the equivalent of the fixed function pipeline transformation and lighting stage (with the later often being implemented in the fragment shader instead to get per pixel lighting). A fragment shader is responsible for outputting a fragments color based on various conditions. You might want to fetch a texel from a texture as the color, apply phong shading based on interpolated normals you receive from the vertex shader and so on. As you can see there's various types of parameters and arguments involved when programming shaders. In GLES2 there's 3 main types (there are other less frequently used types as well): attributes, uniforms and varyings. Attributes and uniforms are specified by you via calls to glVertexAttrib, glVertexAttribPointer or glUniform. Attributes represent vertex attributes like position, texture coordintates, per vertex colors or normals. Uniforms are normally used to pass in things like transformation and projection matrices that you calculate outside the shaders in your program. Varyings are generated within the vertex shader and passed to the fragment shader. Popular examples would be interpolated texture coordinates or normals for phong shading. So what does all this mean for your scenario? First, you will need to calculate the proper transformation and projection matrices yourself, keep track of them yourself and pass them in as uniforms to your vertex shader which then uses them to transform and project your vertices. There is no Android specific GLES2 reference as GLES2 is a standard developed by Khronos which keep the API the same for all platforms. The only difference between platforms is how to setup the GLES2 context and buffers. Usually this is done via EGL, another standard by Khronos. On Android you can use the GLSurfaceView from the hello-gl2 example for that purpose and not worry about it. To get information on the compilation process you can use the functions glGetShaderInfoLog (http://www.opengl.org/sdk/docs/man/xhtml/ glGetShaderInfoLog.xml) and glGetProgramInfoLog (http://www.opengl.org/ sdk/docs/man/xhtml/glGetProgramInfoLog.xml). You usually use the first one after you compiled a vertex or fragment shader and the second one after you linked together a vertex/fragment shader pair to a program. This will give you any errors or warnings the compiler produces. Note that the output is not standardized and will differ for different GPUs and their drivers. My advice would be to get the OpenGL ES 2.0 Programming Guide, a nice little book by the writers of the GLES2 standard which will guide you through all the features and standard procedures of GLES2. The basic concepts of GLES1 are still there in GLES2, however, you have a greater flexibility by providing your own implementation for various stages of the fixed function pipeline, including for example the transform and lighting stage. hth, Mario On 16 Apr., 06:20, HaMMeReD adamhamm...@gmail.com wrote: Working with NDK here. How are perspective correct projection supposed to occur in es 2.0. I can currently draw my geometry to the screen, but it is not getting transformed to 2d. Is there some sort of way of getting meaningful compiler errors out of the shader compiler? Is there a android specific reference to glsl support on it? Am I even supposed to be doing projections in my glsl? I was using hello-gl2 as a baseline, and then modified it to load additional geometry, which is rendering correctly although flat, without any translation or projection. Any advice on translation/ projection is appreciated too, since it seems that all of that has disappeared from es2.0. I've got a opengl 1.1 live screensaver that I've developed that I want to work on porting critical sections to NDK and es2.0, so any advice on porting gl11 to gl20 is appreciated. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers
[android-developers] Re: glTexImage2D very slow on phones like Nexus one
It seems that the msm chips are notorious for having a low bandwidth. There's really no solution to that problem other than 1) lowering your texture size 2) lowering the bit depth of the texture, e.g. instead of using RGBA use RGBA444 or RGB565 2) uploading your texture in patches, e.g. split it up into 4 smaller parts and upload one part each frame. This will probably lead to artifacts if your frame rate is low but could work otherwise. Just out of curiousity: why do you have to upload such a big texture each frame? If you'd state your scenario in detail we might be able to suggest other solutions to the problem. On 17 Apr., 12:10, Eong eong.c...@gmail.com wrote: Robert, Sorry, it's not text, it's tex. I just use this to draw the background. I just want to know why nexus one is so slow with this. It takes 20ms on my milestone but it takes at least 80ms on the nexus one, for one frame. On 4月17日, 上午2时08分, Robert Green rbgrn@gmail.com wrote: Eong, You said you are uploading every frame just to draw text? There are much more efficient ways to do that. On Apr 16, 11:14 am, Eong eong.c...@gmail.com wrote: I'm afraid it's not a same problem. My problem only happenes on Snapdragon phones. It's fine on Milestone or Droid. I found a few threads about this but no solution. On 4月16日, 下午9时15分, Felipe Silveira webfel...@gmail.com wrote: Just a guess: It can be the same error reported here:http://code.google.com/p/android/issues/detail?id=7520 Take a look... Felipe Silveirahttp://www.felipesilveira.com.br On Fri, Apr 16, 2010 at 8:40 AM, Eong eong.c...@gmail.com wrote: Hi, We are developing 2D games. And we found our game works fine except the snapdragon chips, like Nexus one and Liquid A1. It even runs fine on G1. We use GLSurfaceView, and we useglTexImage2Dand glTexIsubmage2D to put on the text and then draw. TheglTexImage2Dclass take more than 100ms on Nexus one (1024x512 pix tex). It's very strange, G1 is even faster than this. If anyone know something about this? -Code snip--- gl.glClear(GL10.GL_COLOR_BUFFER_BIT | GL10.GL_DEPTH_BUFFER_BIT); gl.glTexSubImage2D(GL10.GL_TEXTURE_2D, 0, 0, 0, m_width, m_height, GL10.GL_RGB, GL_UNSIGNED_SHORT_5_6_5, m_byteCanvas); ((GL11Ext)gl).glDrawTexiOES(0, 0, 0, m_width, m_height); -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Felipe Silveira Engenharia da Computação Universidade Federal de Itajubáhttp://www.felipesilveira.com.br MSN: felipeuni...@hotmail.com - -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group,
[android-developers] Re: OpenGL and the use of ByteBuffers
From my experience this also happens with the PowerVR chips in the Droid/Milestone On 16 Apr., 13:07, Eong eong.c...@gmail.com wrote: If glTexImage2D is more than 100ms, glTexSubImage2D doesn't make any sense. I found that this will only happen on phones with snapDragon chips, like Nexus one, Liquid and so on. I tried a lot, can't solve it yet. On 2月24日, 下午5时19分, Ralf Schneider li...@gestaltgeber.com wrote: 2010/2/24 Jonathan jon.aposto...@gmail.com It's a 2D application, and the contents of the screen (as represented by this internal array I'm passing around) can change at any given time. I'm think I may have to use some combination of sub texture updates in order to get what want and have it be smooth. Uploading a 512x256 texture each frame may be too much. Any other ideas how I can speed this up? You can try: glTexSubImage2D http://www.khronos.org/opengles/documentation/opengles1_0/html/glTexS...instead of glTexImage2D. Usually this function is the right choice to update textures frequently. glTexSubImage2D may have the advantage to not require the OpenGL Es memory management system, because an existing texture (memory area) gets updated. Furthermore some OpenGL ES implementation implicit convert textures to one of its internal formats. For example the implementation may convert all textures to 565 or regardless of the format you provide. Thus, if you provide textures in an native format the implementation could do a plain copy of the data, instead of a more expensive conversion. ... But i have no real data available. These are just general advices floating in the intertubes. Regards, Ralf -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to apply different textures on different faces of a cylinder
kirti, when doing OpenGL programming it's best to actually know what you do. Just copy and pasting code will lead to more problems that you can't solve due to a missing understanding of how OpenGL works. Consider following Robert's suggestion and get your hands on the Red Book and the OpenGL Superbible. Note that you can not directly use everything found in there as those books are for desktop OpenGL which offers functionality not available in OpenGL ES. I therefore also suggest reading the tutorial series on OpenGL ES for the IPhone. The examples are written in Objective-C/C++ but should be very easy to port over to Java. http://iphonedevelopment.blogspot.com/2009/05/opengl-es-from-ground-up-table-of.html. hth On 15 Apr., 05:56, kirti kaul kirti.k...@wipro.com wrote: Thanks,can you give me an example/Snippet on how to use Atlas Texture in openGL ES? On Apr 13, 4:08 pm, Lance Nanek lna...@gmail.com wrote: Put all the images needed for texturing all the faces into a single texture. Then refer to coordinates inside the texture to use different parts of it in different places. This is called an atlas texture. I suppose it is also possible to draw the different parts in separate draw calls with a different texture object bound, or to use a second texture unit at the same time. On Apr 12, 1:15 am,kirtikaul kirti.k...@wipro.com wrote: Hello, Can anybody tell me how to apply apply different textures on different faces of acylinder?I am able to apply one texture which covers the wholecylinder.But I want one texture for each face. Thanks in advance!!!- Hide quoted text - - Show quoted text - -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject.
[android-developers] Re: Common Libraries
Assuming your lib is written in Java you simply create a normal Java application in Eclipse and let it have a dependency to the lowest Android platform jar you want to support. In your Android project you can then either directly reference the common library project or generate a jar from the library project which you make the Android project dependent on. The Android platform jar can be found in the SDK folder. If your lib is written in C/C++ (which i actually assume as you said you move over from the IPhone) then you can again create a seperate project in Eclipse, put a jni/ folder in it that houses all your C/C++ code along with an Android.mk for the build rules. There's ways to directly compile in Eclipse, i suggest googling for cdt android ndk. The problem will be that you will need to copy the shared library over to your Android project each time it is rebuild. This can be automated to some extend but will probably result in hardcoding a path to write the shared library file to in some script, not the nicest solution. Getting the ADT plugin to copy over the libs/armeabi folder from a referenced project to an Android project does not work yet which is a bit of a bummer. hth On 14 Apr., 20:38, scott sherwoo...@googlemail.com wrote: I am currently moving from Xcode and iPhone development to Android with Eclipse. I want to have a shared code project so that I can store all the code to be shared across apps in one common library. However it would appear that the only android project available is for applications and not for code libs how can i achieve this? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject.
[android-developers] Re: Out of Memory for Large Images
Try not to load the image into a byte array before passing it to the BitmapFactory but rather pass the InputStream directly to the BitmapFactory. There is a limit for the size of an image, however, 4mb should work. On 14 Apr., 09:25, Kamal Hasan kamal.hasa...@gmail.com wrote: I want to display an image which is around 4 MB,It is giving Out of Memory while loading the image.It is working fine for small images. Is there any alternative method using which I can display large size images. FileInputStream fin = new FileInputStream(new File(sdcard/DSC00712.jpg)); BufferedInputStream bis = new BufferedInputStream(fin); byte[] data = new byte[bis.available()]; bis.read(data, 0, data.length); Bitmap bitmap = BitmapFactory.decodeByteArray(data,0,data.length); if(bitmap!=null) img.setImageBitmap(bitmap); else Log.e(Bitmap , Not Created); Please suggest me a method to display large images or its not possible to display large images !! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject.
[android-developers] Re: Weird OpenGL performance in Nexus one
That's still better than what i'd have excepted. Do you draw 4-5 full
screen quads with alpha blending? Are they textured? Gotta try that
myself sometime. 40fps wouldn't be that bad.
On 14 Apr., 11:36, Vladimir vladimir.funti...@gmail.com wrote:
You are right, being an OpenGL noob I only timed GL commands, the
actual fps is around 40
On Apr 14, 1:24 am, Mario Zechner badlogicga...@gmail.com wrote:
Hm, seems my post got swalled by the flying spagetthi monster. Here we
go again.
I wonder how you measure the time. Do you measure you frames like
this?
...
long startTime = System.nanoTime();
int frames = 0;
public void onDrawFrame( )
{
... draw stuff ...
if( System.nanoTime() - startTime 10 )
{
Log.d( My App, fps: + frames )
frames = 0;
startTime = System.nanoTime();
}
}
This gives you the frames rendered each second and takes into account
eglSwapBuffers execution time which tells the GPU to actually draw
stuff (if the GPU buffers haven't been filled up to that point). I
highly doubt the 100-120fps on the Droid. The maximum amount of fps
achievable on any Android device so far is 60fps due to vertical
synch. Additionally you have the actual drawing executed in
eglSwapBuffers for the most part unless your scene is extremely big
and fills up the command buffer, which is not the case with a puny 4-5
fullscreen quads. I'd expect something like 30-33fps for your scenario
as that poor little thing is heavily fill-rate bound and blending only
makes it worse. I'd love to know how you timed your code.
On 13 Apr., 23:41, Vladimir vladimir.funti...@gmail.com wrote:
Rokon got 60fps and my app just 55fps in average.
I tried drawTexfOES for backgrounds in Rokon and got 200+ fps with 4
or 5 alpha-blended layers on Droid, around 100-120 on G1. I also used
it in a 3D game I wrote from scratch and there was a noticeable
performance boost compared to quads.
Canvas faster than OpenGL way. Why? Did anybody test it on the other
device?
I can assure you that Canvas performance is terrible on both G1 and
Droid (since 2.1) I own, and most devices out there.
On Apr 6, 8:12 am, lixin China smallli...@gmail.com wrote:
I'm preparing code a game.
So I need benchmark the OpenGL find a good way render my 2d stuffs.
And I found a project have done
that.http://code.google.com/p/apps-for-android/
SpriteMethodTest
I only have nexus one. The following it's the test result from my
phone.
test 1: 10 Sprites without animate
Canvas: 142.85 fps
OpenGL 1: 34.48 fps
OpenGL 2: 33.33 fps
OpenGL 3: 33.33 fps
test 2： 10 Sprites with animate
Canvas: 90 fps
OpenGL 1: 32 fps
OpenGL 2: 33 fps
OpenGL 3: 32 fps
test 3： 100 Sprites without animate
Canvas: 111 fps
OpenGL 1: 43.47 fps
OpenGL 2: 43.47 fps
OpenGL 3: 41.66 fps
test 4： 100 Sprites with animate
Canvas: 62.5 fps
OpenGL 1: 45 fps
OpenGL 2: 43 fps
OpenGL 3: 45 fps
===
test 5： 500 Sprites without animate
Canvas: 27 fps
OpenGL 1:20 fps
OpenGL 2:23.8 fps
OpenGL 3:23.8 fps
test 6： 500 Sprites with animate
Canvas: 25 fps
OpenGL 1: 20 fps
OpenGL 2: 23 fps
OpenGL 3: 22 fps
===
test 7： 1000 Sprites without animate
Canvas: 15.38 fps
OpenGL 1: 10.5 fps
OpenGL 2: 12.82 fps
OpenGL 3: 14.7 fps
test 8： 1000 Sprites with animate
Canvas: 15.15 fps
OpenGL 1: 10.3 fps
OpenGL 2: 12.65 fps
OpenGL 3: 14.28 fps
==
The result observably show that the rendering performance on nexus
one, Canvas faster than OpenGL way.
Why? Did anybody test it on the other device?
And another question.
I write a test application just render a background and a moving
sprite with draw_texture extension.
And use Rokon (which is a 2D game engine) do the same thing.
And test device of course its my nexus one.
Rokon got 60fps and my app just 55fps in average.
It was weird because I saw a video on Google I/O Session about how to
write a real-time game（http://www.youtube.com/watch?v=U4Bk5rmIpic.
Video shows that draw_texture have better performance that the usual
way.
Somebody knew the reason?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
To unsubscribe, reply using remove me as the subject.
[android-developers] Re: Weird OpenGL performance in Nexus one
I kind of doubt the performance figures you give. 4 to 5 full screen alpha blended layers on the droid will give you around 30 to 35 fps. I assume you only measure the time it takes to execute your OpenGL commands. The real deal is measuring the delta time between the last and the current frame. Actual drawing is mostly performed on eglSwapBuffers which is executed after the Renderer.drawFrame() method is executed. On 13 Apr., 23:41, Vladimir vladimir.funti...@gmail.com wrote: Rokon got 60fps and my app just 55fps in average. I tried drawTexfOES for backgrounds in Rokon and got 200+ fps with 4 or 5 alpha-blended layers on Droid, around 100-120 on G1. I also used it in a 3D game I wrote from scratch and there was a noticeable performance boost compared to quads. Canvas faster than OpenGL way. Why? Did anybody test it on the other device? I can assure you that Canvas performance is terrible on both G1 and Droid (since 2.1) I own, and most devices out there. On Apr 6, 8:12 am, lixin China smallli...@gmail.com wrote: I'm preparing code a game. So I need benchmark the OpenGL find a good way render my 2d stuffs. And I found a project have done that.http://code.google.com/p/apps-for-android/ SpriteMethodTest I only have nexus one. The following it's the test result from my phone. test 1: 10 Sprites without animate Canvas: 142.85 fps OpenGL 1: 34.48 fps OpenGL 2: 33.33 fps OpenGL 3: 33.33 fps test 2： 10 Sprites with animate Canvas: 90 fps OpenGL 1: 32 fps OpenGL 2: 33 fps OpenGL 3: 32 fps test 3： 100 Sprites without animate Canvas: 111 fps OpenGL 1: 43.47 fps OpenGL 2: 43.47 fps OpenGL 3: 41.66 fps test 4： 100 Sprites with animate Canvas: 62.5 fps OpenGL 1: 45 fps OpenGL 2: 43 fps OpenGL 3: 45 fps === test 5： 500 Sprites without animate Canvas: 27 fps OpenGL 1:20 fps OpenGL 2:23.8 fps OpenGL 3:23.8 fps test 6： 500 Sprites with animate Canvas: 25 fps OpenGL 1: 20 fps OpenGL 2: 23 fps OpenGL 3: 22 fps === test 7： 1000 Sprites without animate Canvas: 15.38 fps OpenGL 1: 10.5 fps OpenGL 2: 12.82 fps OpenGL 3: 14.7 fps test 8： 1000 Sprites with animate Canvas: 15.15 fps OpenGL 1: 10.3 fps OpenGL 2: 12.65 fps OpenGL 3: 14.28 fps == The result observably show that the rendering performance on nexus one, Canvas faster than OpenGL way. Why? Did anybody test it on the other device? And another question. I write a test application just render a background and a moving sprite with draw_texture extension. And use Rokon (which is a 2D game engine) do the same thing. And test device of course its my nexus one. Rokon got 60fps and my app just 55fps in average. It was weird because I saw a video on Google I/O Session about how to write a real-time game（http://www.youtube.com/watch?v=U4Bk5rmIpic. Video shows that draw_texture have better performance that the usual way. Somebody knew the reason? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject.
[android-developers] Re: Weird OpenGL performance in Nexus one
Hm, seems my post got swalled by the flying spagetthi monster. Here we
go again.
I wonder how you measure the time. Do you measure you frames like
this?
...
long startTime = System.nanoTime();
int frames = 0;
public void onDrawFrame( )
{
... draw stuff ...
if( System.nanoTime() - startTime 10 )
{
Log.d( My App, fps: + frames )
frames = 0;
startTime = System.nanoTime();
}
}
This gives you the frames rendered each second and takes into account
eglSwapBuffers execution time which tells the GPU to actually draw
stuff (if the GPU buffers haven't been filled up to that point). I
highly doubt the 100-120fps on the Droid. The maximum amount of fps
achievable on any Android device so far is 60fps due to vertical
synch. Additionally you have the actual drawing executed in
eglSwapBuffers for the most part unless your scene is extremely big
and fills up the command buffer, which is not the case with a puny 4-5
fullscreen quads. I'd expect something like 30-33fps for your scenario
as that poor little thing is heavily fill-rate bound and blending only
makes it worse. I'd love to know how you timed your code.
On 13 Apr., 23:41, Vladimir vladimir.funti...@gmail.com wrote:
Rokon got 60fps and my app just 55fps in average.
I tried drawTexfOES for backgrounds in Rokon and got 200+ fps with 4
or 5 alpha-blended layers on Droid, around 100-120 on G1. I also used
it in a 3D game I wrote from scratch and there was a noticeable
performance boost compared to quads.
Canvas faster than OpenGL way. Why? Did anybody test it on the other device?
I can assure you that Canvas performance is terrible on both G1 and
Droid (since 2.1) I own, and most devices out there.
On Apr 6, 8:12 am, lixin China smallli...@gmail.com wrote:
I'm preparing code a game.
So I need benchmark the OpenGL find a good way render my 2d stuffs.
And I found a project have done
that.http://code.google.com/p/apps-for-android/
SpriteMethodTest
I only have nexus one. The following it's the test result from my
phone.
test 1: 10 Sprites without animate
Canvas: 142.85 fps
OpenGL 1: 34.48 fps
OpenGL 2: 33.33 fps
OpenGL 3: 33.33 fps
test 2： 10 Sprites with animate
Canvas: 90 fps
OpenGL 1: 32 fps
OpenGL 2: 33 fps
OpenGL 3: 32 fps
test 3： 100 Sprites without animate
Canvas: 111 fps
OpenGL 1: 43.47 fps
OpenGL 2: 43.47 fps
OpenGL 3: 41.66 fps
test 4： 100 Sprites with animate
Canvas: 62.5 fps
OpenGL 1: 45 fps
OpenGL 2: 43 fps
OpenGL 3: 45 fps
===
test 5： 500 Sprites without animate
Canvas: 27 fps
OpenGL 1:20 fps
OpenGL 2:23.8 fps
OpenGL 3:23.8 fps
test 6： 500 Sprites with animate
Canvas: 25 fps
OpenGL 1: 20 fps
OpenGL 2: 23 fps
OpenGL 3: 22 fps
===
test 7： 1000 Sprites without animate
Canvas: 15.38 fps
OpenGL 1: 10.5 fps
OpenGL 2: 12.82 fps
OpenGL 3: 14.7 fps
test 8： 1000 Sprites with animate
Canvas: 15.15 fps
OpenGL 1: 10.3 fps
OpenGL 2: 12.65 fps
OpenGL 3: 14.28 fps
==
The result observably show that the rendering performance on nexus
one, Canvas faster than OpenGL way.
Why? Did anybody test it on the other device?
And another question.
I write a test application just render a background and a moving
sprite with draw_texture extension.
And use Rokon (which is a 2D game engine) do the same thing.
And test device of course its my nexus one.
Rokon got 60fps and my app just 55fps in average.
It was weird because I saw a video on Google I/O Session about how to
write a real-time game（http://www.youtube.com/watch?v=U4Bk5rmIpic.
Video shows that draw_texture have better performance that the usual
way.
Somebody knew the reason?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
To unsubscribe, reply using remove me as the subject.
[android-developers] Re: Dear Mark Deloura
I want to say Me Too here. I'm not a full time android game developer but invest a lot of my spare time in producing games as well as engines/frameworks for Android. I can only agree to all the points Robert already mentioned. For me the biggest issue is the broken multi-touch which also affects motorola devices as oposed to only HTC devices. It is of course idiotic to blame anyone here, it would just be nice to know where to turn to get this things looked at and potentially fixed. Given that i'm a hobbyist i strive to rapid development times which i can only achieve by staying as much in Java as possible. Going native for really performance hungry stuff in small pieces is not a big deal but writting a full game in native code without being able to rely on a full fledged cross-platform library as many big players have is out of scope for me given the lack of proper debugging support for native code. It would therefore be nice if improvements of Dalvik would be a top priority so we can stay as much as possible in Java. This includes a better garbage collector strategy, JIT or dynamic adaptive compilation and so on. I know that some of the things are already worked on, so i guess there's a bright future for us Java noobs :) In that regard it was a bit of a bummer that the bindings for OpenGL ES 2.0 were only made available via the NDK (which i worked around by writting my own JNI bindings, http://code.google.com/p/gl2-android/). Another thing which not only affects game developers but application developers too: the market needs to be improved a lot. You can find several threads on this topic here. The same is true for the developer console which lacks a lot of information. It's a bit sad seeing how nice Google Analytics works for example. Improvements in both areas would really help a lot of us, especially the single person and small development teams, as it would give us back some time we'd otherwise need to manually manage our project statistics and user support. Other than that (and i know it sounds like a christmas wishlist), i think we all can agree on the fact that we love Android and want it to become one of the most important mobile game development platforms. Welcome to the community! p.s.: what about a Game Programming Gems seeding program for poor Android game developers? :) On 12 Apr., 21:00, Robert Green rbgrn@gmail.com wrote: Dear Mark Deloura, I see that you started your first day at Google today. Congratulations on the new gig! I thought as part of your first day as the new Android games guru, I would make a concise list of things that make game development tough for us full-time Android game developers. 1) Touch events consuming ridiculous amounts of CPU, causing 20-50% reduction in framerates. This is very apparent in 1.6 and back and I believe it is still somewhat there in 2.0/2.1 but it's hard to tell if it's better just because the CPUs are much better on those devices or if the underlying code is actually improved. Either way, I can't put out any 3D games with a hold-your-thumb-down interface because they drop from 30fps to 15fps when controlling and there is no workaround (sleeping like suggested by myself and many hardly does the trick.) 2) Sound APIs are unstable and difficult to work with from a native cross-platform engine. SoundPool is a well-designed class for doing low latency one-shoot and looping sounds played at various rates (I use for engines, and everything else) but it crashes now and then. I don't see it crashing much on 2.0/2.1 but just last night I had a segfault on my G1 (1.6) while testing a new game. AudioTrack in 2.0.1 is also reported to be unstable and has no DirectBuffer interface for getting pcm bytes in from a native mixer. 3) Background processes destroy intense game framerates, even on 2.1. I've been asking for a game mode for a year now. Players probably won't mind shutting off everything but incoming calls if a game asks for it. If it made my gaming lag-free, I'd definitely play that way. Sorry I can't check my email, I'm sort of playing a game right now. 4) With a range of GPUs starting with none and going up to PVR SGX530 and Snapdragon it's difficult for us to deal with comments like This game is unplayable when people install and run a game requiring GPU acceleration on a phone with no GPU. We tell them not to, but they don't listen and then give us 1-star ratings and nasty comments. Yes, we can specify GLES versions in the manifest (which is great!) but both a pixelflinger phone and a G1 are ES1.0 so it's impossible to stop the installs and bad ratings. A simple classification system would do, where a class-1 phone is no GPU, class-2 is MSM7200-era, class-3 is MSM7600, class-4 is SGX530 and Snapdragon speeds, class-5 is whatever the next gen is and so forth and so on. That would allow us to target a game at class-3 and higher GPUs and optionally only ones that support ES2.0
[android-developers] Re: Audio Mixing
I did some audio work on Android and have to agree with Kevin's analysis. Writting to the audio device via AudioTrack works and you can also alter the buffer sizes to get to the lowest possible latency but from what i remember the buffer was still pretty big. Also, AudioTrack does not allow passing in direct buffers so you have to do everything with an array backed buffer if you go native which might incurr overhead as the array has to be locked when working with it in native code. And i know it's considered spam and off topic, but Kevin maybe the lib i'm working at the moment is of interest for you. It does have some features of XNA (cross-plattform, meaning Windows/Linux/Mac and Android) and even has more or less ports of some XNA classes like SpriteBatch) and is pretty big already, covering a lot of ground. You can check it out at http://www.badlogicgames.com and http://code.google.com/p/libgdx/. The public API is heavily document and there's a lot of examples in the SVN that should get you started. Alternatively there's a series of articles that serve as a tutorial. This series is not yet finished but gets updated on a constant basis. Sorry for the thread hijack :) On 12 Apr., 22:10, Kevin Duffey andjar...@gmail.com wrote: Mixing audio in itself is not too hard.. you basically add each byte of each sound (that plays at the same exact point in time). You do face the issue of dynamic range.. if you are mixing 16-bit sounds, you don't want to use a 16-bit value to store the mixed sounds.. you'll overflow it. or clip the sound. Usually you'll use a 32-bit integer to add all the sounds, then you'll lower it to 24-bit or 16-bit with some fancy algorithm that won't clip all the mixed sounds.. sort of like lowering their combined volumes so they don't clip. However, you can't keep lowering volumes with more sounds.. it changes the overall mixed volume.. there is some FFT or something like that which properly does this. It's been a long time since I did this stuff, back when SoundBlaster 8-bit sound card was out and mikmod and module players were quite popular. Long before the sound cards mixed audio themselves. ;) I am sure you can find stuff on it. I too wanted to work on a low-latency music app, but until google puts more resources into making the NDK and android platform on par with iPhone, I don't think it's worth the effort. There is just WAY too many problems with the issue of low latency audio right now. Really what you need is to use the NDK, pass the sound buffers of different sounds (or better yet, NDK can directly access the buffers of loaded sounds or SD stored sounds), do the mixing there, and then be able to play to a the sound output in some low latency manner. Unless things have changed, I've been led to believe we're a long ways off before we'll have anything like that. Sadly, it seems google/android team is completely quiet on any details at all with regards to this stuff. I've not been able to find one bit of info whether or not they are hearing us game/audio developers and are working on a better platform for us or not. Given their stagnant market work and lack of any info at all on anything being worked on.. I wouldn't count on anything anytime soon. Let's hope I am very wrong on this, but I fear that the articles that indicate android will surpass iphone by 2012 are grossly misleading if android as a platform can't compete on games and audio with iPhone. :( They still need to fix the multi-touch issue which plagues gamers on several devices but apparently it's in the hardware, not the platform. If I am wrong.. if there is some place google posts what is coming and when.. please correct me. I really love the idea of Android, and still follow along, but I've basically stopped any development primarily because there isn't much money in it, and with no idea if far better game/audio support is coming, I don't want to waste time hoping. There are other avenues of interest in non game/music related things for Android tho, but my heart lies in making a kick ass music app... and possibly a side scroller game at some point. Would be wonderful if Google had something like XNA for us. :) On Mon, Apr 12, 2010 at 12:42 PM, k_day kevin.r@gmail.com wrote: Despite everything I have read about the difficulty of making low latency audio apps in Android, I am giving it a shot. To start, I loaded each note in an octave into a SoundPool, and then looped through each note that was to be played on that beat and called play(). This didn't even come close to being accurate enough for me, and got especially bad if a lot of notes were being played at once. From what I read, the only way to do something like this is to mix the audio yourself, though I am not entirely sure how to go about this. My initial thought is that for each beat, I could precompute the sound the sound that is to be played (i.e., combine the wav's), and then pass that
[android-developers] Re: Android OpenGL Game - App Architecture and Threading Logic
This topic is pretty interesting. I also am off the school of one
thread is enough. I have to admit that I don't fully understand the
benefits of a seperate logic thread. Am I right in thinking that the
only reason to have a seperate logic thread is being able to use the
cpu while it blocks on the GPU on a call to say eglswapbuffers? And
isn't that increased CPU usage downplayed by the needed lock for
synchronization? Did anyone do some benchmarking in that regard? I'd
really be interested in whether it's worth it (not all that complex if
you go the route of robert)
On 9 Apr., 20:01, shaun shashepp...@gmail.com wrote:
I wonder how much true parallelism is happening when the game logic
runs on a separate thread than the rendering (in addition to the
Activity thread for a total of 3). I do not claim to be an expert in
this arena, but what follows is what I think about the subject of
threads in Android games.
Since we are dealing with a single CPU device, there is only a
possibility to gain speed when the game logic thread and the GPU are
processing simultaneously. It could be easy to have the rendering
thread spend a lot of time on the CPU instead of the GPU if there are
many calls to GL being made. And in order to get the most bang for
the true parallelism buck, you would need to make sure the rendering
pipeline has as few calls to GL as possible (preferably 1 for
glDrawArrays and 1 bind texture atlas for an entire scene and then 1
to swap the buffers, of course there are a few others surrounding
that, but hopefully you see my point). The basic point is, the more
calls to GL, the more time CPU cycles are taken up in the rendering
thread and since there is one CPU, the game logic thread is not
simultaneously running.
My overall take for most 2D games on Android is that you are better
off with a single thread for both game logic and rendering UNLESS you
have optimized your OpenGL rendering pipeline down to have a bare
bones minimum of GL calls in a sort of render the entire scene at
once from vertexes and 1 texture. With 3D games, the rendering
pipeline seems more conducive to the render all at once
implementation.
I tried going down the path of 3 total threads and found not nearly
enough performance benefit for the threading overhead (programming and
context switching). In my case, I would have had to re-write quite a
bit of my rendering pipeline to minimize the GL calls made to render
each frame, so I opted with 2 total threads - Activity and All Else
(game logic and rendering).
On Apr 9, 12:03 pm, Robert Green rbgrn@gmail.com wrote:
It's pretty easy to do this:
I use a World to write to and read from for the two sides. Makes
networking nice too. My World has a simple lock. Only one thing can
write to it or read from it at a time.
in GameLogicThread:
run() {
while (!done) {
// wait for renderer
world.getLock(); // blocks
update()
world.releaseLock();
}
}
in Renderer:
onDrawFrame() {
world.getLock(); // blocks
draw()
world.releaseLock();
}
On Apr 9, 3:27 am, Clankrieger tob...@googlemail.com wrote: Hi,
I had a lot of difficulties getting the threading and app lifecycle
issues done, too. For my part, this was much more confusing than
getting the actual game done. ;)
The good thing is: you do not have to do too much for the render- and
logic-thread separation because most of the rendering time is getting
spent outside of your renderer's onDraw method. This is how I got
this done: The Game itself is owned by the glSurfaceView renderer
instance. the when the game starts (at onResume), I start an
updatethread that is very simple an does something like
while(bKeeprunning) {
synchronized(Game.sInstance) {
Game.sInstance.update();
}
Thread.sleep(50);
}
I have to add that my game logic is doing only this: logic. The world
gets simulated. This is done less than 10 times per second - this is
why I can have it sleep for 50 ms. sleeping is important here to give
the render thread time to do this (I don't remember the full method
signature, but I think you know what I mean):
onDrawGlFrame() {
synchronized(Game.sInstance) {
Game.sInstance.render();
}
Thread.sleep(5);
}
I defined the updatethread as class inside of the Renderer because it
is so small. This gave me a huge performance boost. Handling the app
lifecycle is less easy (at least for me).
On Apr 9, 3:09 am, Eddie Ringle ed...@eringle.net wrote:
Surprisingly, I don't seem to have issues with the OpenGL side of
things (which is very unusual), but my problems stem from getting a
clear idea for app architecture and a few other problems.
Right now, most tutorials on the net just describe the render portion.
I know that when I create a GLSurfaceView and hook a Renderer into it,
it uses it's own thread for
[android-developers] Re: Android OpenGL Game - App Architecture and Threading Logic
That's what i was wondering. It makes of course a lot of sense to use
the CPU idle time while the GPU is doing the heavy lifting. However,
but having to put a synch around the access to the logic data in the
rendering thread and the logic thread you explicitely starve one of
the threads, depending on which one is faster. So while the logic
thread can do it's work in parallel to the rendering thread blocking
on eglSwapBuffers you effectively take away CPU from the logic thread
while the rendering thread is setting everything up so that
eglSwapBuffer can do it's magic, thus essentially serializing the
logic and rendering thread again. As some poster noted earlier the
design will only increase performance if your scene drawing minus the
swap is extremely fast, e.g. very little GL calls or routines that
generate geometry on the fly. This essentially means that your
rendering pipeline must be rather simple.
But as stated earlier, implementing it one or the other way isn't
really a huge biggie as you have explicit synchronization in the
critical regions anyways.
On 9 Apr., 21:24, Robert Green rbgrn@gmail.com wrote:
Eddie,
Yes, that'll do the trick.
As far as the multiple threads goes, sure you can drive your logic off
of the call to onDrawFrame but there is a situation in which having a
separate thread makes sense:
After onDrawFrame, the rendering thread is finishing/swapping. That
can actually take a decent amount of time to do in certain cases and
most of it is happening on the GPU, especially on a device like the
Droid which has a discrete CPU/GPU. During that time, the CPU is
available and can be used on the logic thread. Properly implemented,
in a heavy scene you can get some or all of the logic processed before
the rendering thread is ready again, which is why I favor it.
My question is: onDrawFrame is only called once the GPU is ready for
another draw. Why waste those precious GPU idle moments just doing
CPU stuff like physics and collisions? You can maximize with another
thread.
Also - 2 (game and UI) or 3 threads (game logic, rendering and UI)
does make sense because you never want to block the UI thread in
Android. Get out of its way as fast as possible! :)
On Apr 9, 1:58 pm, Eddie Ringle ed...@eringle.net wrote:
Is it as simple as:
In GameView.java (my custom GLSurfaceView class):
World _world = new World();
GameRenderer _renderer = new GameRenderer(_world);
In GameRenderer.java:
public World _world;
public GameRenderer(World world)
{
_world = world;
}
In GameRenderer.java, _world would now have the address of world,
which is the address of GameView.java's _world, right?
On Apr 9, 2:49 pm, Eddie Ringle ed...@eringle.net wrote:
One more thing question and I think I will be set. Coming from a C/C++
background, I enjoyed the use of references. I know that there is a
way to pass the reference by value in Java, but am not quite clear on
how. Could I, for example, create my World object, then pass that
object to the renderer and logic objects when I create them? I did a
small bit of reading on this topic, but still am not quite sure.
On Apr 9, 1:55 pm, Robert Green rbgrn@gmail.com wrote:
Yeah, you're going to want to model your game like you would model the
real world:
class World {
public Player player;
public Enemy[] enemies;
public int timeLeft;
public int level;
//etc..
}
Then you update the world (usually by calls to player.update,
enemy.update, etc) from your logic thread.
Then what I like to do is separate the rendering stuff from the
simulation so that I have renderers for specific things:
class PlayerRenderer extends BaseRenderer {
// knows about player geometry, knows how to draw the player and
anything player-related..
}
Then in my main Renderer, I just call out to the individual component
renderers:
class WorldRenderer implements Renderer {
onDrawFrame(GL gl) {
// clear, set up projection, etc
playerRenderer.draw(gl, world.player);
enemyRenderer.draw(gl, world.enemies);
// etc..
}
}
And that's how I do it. I have just a little bit of initialization
communication from the Renderer side to the game logic so that we can
set up positioning of touchable UI components but otherwise it's
always GameThread updates World, WorldRenderer draws World, repeat.
On Apr 9, 11:25 am, Eddie Ringle ed...@eringle.net wrote:
Where do you store all your attributes, like player position?
Currently I just have a GLQuad class that I use to create new quads,
texture them, and manage position and velocity. Do you store them in
World, and then each side can access them from the world object?
Also, threading is new to me, so I really have no clue what a lock is.
On Apr 9, 12:03 pm, Robert Green rbgrn@gmail.com
[android-developers] Re: Android OpenGL Game - App Architecture and Threading Logic
That depends on what kind of input you need. If your game is happy
with just checking the current state of the accelerometer/touch screen/
keyboard/trackball simply polling will do the trick. This means that
in the UI thread, where you have your event listeners installed, you
simply save the last state reported to you. In your logic thread you
can savely access this state even without synchronization as it will
only be composed of plain old data types like booleans or ints (of
course there are cases where you catch the x coordinate of the
previous event and the y coordinate of the current event but i dare
say that the differences are so tiny, it doesn't make a difference).
Other things might need event based input handling, like a GUI you
implement yourself with say OpenGL. In that case you will need a queue
that gets filled in the Android GUI thread by the listeners you have
installed for the input devices. The logic thread acts as a consumer
and takes the events from the queue. As you are working with a complex
data structure you need to synchronize the adding and removing of
events to and from the queue in both the Android GUI thread and your
logic thread. This is a classical consumer/producer pattern which can
be found frequently in multithreaded applications. Check out Robert's
site at http://www.rbgrn.net, i think he wrote an article on that sort
of thing once.
it basicaly boils down to this (pseudo code, written from the top of
my head, will not compile)
public class GameActivity extends Activity implements
MotionEventListener
{
QueueEvent events = new QueueEvent();
public void onTouch( MotionEvent event )
{
synchronized( events )
{
events.add( new Event( event.getX(), event.getY() );
}
}
}
public class GameLogic
{
GameActivity activity;
public GameLogic( GameActivity activity )
{
this.activity = activity;
}
public void handleInput( )
{
synchronized( gameActivity.events )
{
// proces events here
}
}
}
Now, a couple of comments: You don't want to instantiate a new Event
everytime a listener method in the GameActivity is called. You will
need to implement a simple object pool and reuse events. That way the
garbage collector will stay calm. Also note that the design above is a
bit nasty, i would directly pass the GameActivity to the GameLogic
among other things. But that's up to you.
Polling input handling would work like above but without a queue and
without the need for the synchronized blocks. All you do is set some
members of GameActivity, say touchX and touchY in the onTouch method
and read those values in the GameLogic class' handleInput method.
hth,
Mario
On 9 Apr., 22:39, Eddie Ringle ed...@eringle.net wrote:
Robert,
Silly question, but how do you get input to the logic thread? I have
to get sensor and touch data from the main Activity class and somehow
get it to the logic thread.
Current program flow is as follows:
onCreate() - GameView() - World() Renderer() GameLogic()
On Apr 9, 3:24 pm, Robert Green rbgrn@gmail.com wrote:
Eddie,
Yes, that'll do the trick.
As far as the multiple threads goes, sure you can drive your logic off
of the call to onDrawFrame but there is a situation in which having a
separate thread makes sense:
After onDrawFrame, the rendering thread is finishing/swapping. That
can actually take a decent amount of time to do in certain cases and
most of it is happening on the GPU, especially on a device like the
Droid which has a discrete CPU/GPU. During that time, the CPU is
available and can be used on the logic thread. Properly implemented,
in a heavy scene you can get some or all of the logic processed before
the rendering thread is ready again, which is why I favor it.
My question is: onDrawFrame is only called once the GPU is ready for
another draw. Why waste those precious GPU idle moments just doing
CPU stuff like physics and collisions? You can maximize with another
thread.
Also - 2 (game and UI) or 3 threads (game logic, rendering and UI)
does make sense because you never want to block the UI thread in
Android. Get out of its way as fast as possible! :)
On Apr 9, 1:58 pm, Eddie Ringle ed...@eringle.net wrote:
Is it as simple as:
In GameView.java (my custom GLSurfaceView class):
World _world = new World();
GameRenderer _renderer = new GameRenderer(_world);
In GameRenderer.java:
public World _world;
public GameRenderer(World world)
{
_world = world;
}
In GameRenderer.java, _world would now have the address of world,
which is the address of GameView.java's _world, right?
On Apr 9, 2:49 pm, Eddie Ringle ed...@eringle.net wrote:
One more thing question and I think I will be set. Coming from a C/C++
background, I enjoyed the use of references. I know that there is a
way to pass the reference by value in Java, but am not
[android-developers] Libvorbis and Libmpg123 for Android
Hi there, i thought i post here as some might find it useful. I ported libvorbis (the fixed point version) and libmpg123 (using ARM assembler for speed) to Android. This allows you to get a hold of the PCM samples of MP3 and Ogg files which is not possible with the Android framework at the moment (unless you use non-official native classes). They are included in my game dev lib libgdx which you can find at http://code.google.com/p/libgdx/. If you don't want to depend on that simply checkout the source from SVN and place the jni folder in your own project. Make sure to copy over all flags from the Android.mk file. You will of course want to remove anything that is libgdx specific which are the .cpp files in the jni folder. I hope that helps some of you out there. Ciao, Mario -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject.
[android-developers] Re: glDrawElements vs glDrawArrays with glColorPointer in opengl es GL10
You can't specify that with indices. Instead you will have to duplicate those vertices which share the same position but have different normals, colors and texture coordinates. Think of it this way: You have an array of vertices, each defined by a position, color, normal and texture coordinates. When you specify the different glXXXPointers you simply tell OpenGL where to look for the position, normal, color and texture coordinates of a single vertex. The pointers you give OpenGL point to the first vertex' attributes. When you then specify your indices later on when invoking glDrawElements the indices map to that vertices array. An index of 0 will take the first position from the pointer you passed to glVertexPointer, the first color from the pointer you passed to glColorPointer and so on. You can not say: use the position at index 0 in the vertex position array and the color from position 3 in the color array for this vertex. Thus the 1:1:1:1 mapping. On 24 Mrz., 10:11, Perty pertyj...@gmail.com wrote: Hi Robert, thanks for your help. Yes, thats makes sense and it's exactly how I do it I think. But does the relationship (1 to 1 to 1 to 1, vertexarray,colorarray,normalarrat, textmaparray) still apply when you use glDrawElements ? For example a when creating a 3D cube, the same vertex could have three different colors and three different normals depending on the triangle it belongs to, so the arrays can't have (?) the same one to one relationship. So, the question is how do I map the colors to the indexed vertex? /Perty On 24 mar, 06:00, Robert Green rbgrn@gmail.com wrote: Vertices, Texture coordinates, Normals and Colors have a 1 to 1 to 1 to 1 relationship. That means that for any given vertex, you can define: The vertex's location The texture coordinate The normal The color If you define 4 vertices (with or without any of the other attributes, doesn't matter), you can draw 2 triangles using drawElements. Let's say that your verts define the following for a 2d square: top left, top right, bottom right, bottom left Easy enough, clockwise rotation. Your indices would look like: 0,1,2, 0,2,3 let's say you put that into a directly-allocated ShortBuffer called indexBuffer. You'd then just call glDrawElements(GL10.GL_TRIANGLES, 6, indexBuffer); which says, draw triangles using 6 points indexed by this index buffer Make sense? On Mar 23, 6:09 pm, Perty pertyj...@gmail.com wrote: Hi, If I use a glColorPointer together with a glVertexPointer and a glNormalPointer the vertex is all in the same position in the array (taking into accont the stride). Thats working fine. But if I want to use the glDrawElement to save some memory (performance?) I do not understand how I should map the normals and the colors. How does the vertexIndex lookup table relates to the colors and normals? The glDrawElements is rendering the triangles fine but the normals and colors is all messed up. So I manually traverse the the index and creates a vertexArray now. It feels like I have just made a simple error. /Regards Perty -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[android-developers] Re: OpenGL Thread suddenly dead? (onDrawFrame no more called)
Do you see the thread disappear while debugging? I wouldn't know of a mechanism which could silently kill it unless you do something nasty in the onDrawFrame method. What physics library do you use? I remember Box2D having a nice infinite loop bug in one of the previous releases. On 22 Mrz., 12:44, plusminus stoeps...@gmx.de wrote: Hello, I have a problem with a suddenly dead(?) OpenGL Thread. After an indeterminate time (30 seconds to a couple of minutes) the onDrawFrame of the Renderer simply doesn't get called anymore. I get no exception, no ForceClose, no ActivityNotResponding, no nothing! I can still open the Menu, have another Handler/Runnable-cycle logging out Alive, etc ... Recently I introduced some native stuff (physics-library). But I can verify that there is no native problem, as there is obviously no native crash and after the GLThread died, I can still do like: Log.d(Before native call) nativeCall(); Log.d(After native call) Maybe anyone of you experienced something similar to this? Thanks in advance for all helpful advice =) Best Regards, Nicolas -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[android-developers] Re: Being legally harassed, by a large iPhone developer
I have no legal advice as i'm the last person to ask about such questions. I just want to share my concern that this will happen to a lot of game developers on Android. If you happen to get more info on the matter from say a proper legal advisor please share it here with us. On 22 Mrz., 19:34, MrChaz mrchazmob...@googlemail.com wrote: I guess it depends on just how similar the layout of the levels are, they might have a case for IP infringement. I don't think they can have any claim over the gameplay etc but if the art style and layout is a clone they I dunno IP law seems really complicated :( I would seriously contact a lawyer to see where you stand On Mar 22, 12:24 am, Richard rtaylor...@googlemail.com wrote: Hi everyone, I'm the developer of a game, Flying Aces, that was released last September. It's a simple line drawing game, of which there are now several variations on a similar theme. There is a very popular iPhone game, Flight Control, that is one of the most popular (over 2 million sales) developed by Firemint. Firemint, according to their website, are porting their Flight Control game to Android very soon. I was contacted last week, with this email:http://stickycoding.com/fa1.pdf I promptly replied, asking whether it was some kind of joke, and asked whether they are accusing me of using any of their graphics/audio/ resources (which I do not). I got this response today:http://stickycoding.com/fa2.pdf They appear to be demanding (they haven't explicitly mentioned, but I'm sure they will mention legal proceedings in their next reply) that I stop selling my game, because it is vaguely similar to theirs. Now, yes, you land planes by dragging a path, but that's the line-drawing genre. And mentioning similar things such as helicopter landing site with a big H. Does anyone have any opinions on this matter? I'm assuming they have contacted developers of similar apps (Flight Director is very similar to my game, and is more popular, I would assume they were contacted first) so I've emailed them to see. I don't take to kindly to larger businesses trying to nudge indie devs like myself out of the way to create a monopoly for there game before it is even published. I know this isn't a programming question but, I figured it applies to many developers like myself, and there isn't much in the way of advice other than on here. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[android-developers] Touch Event flood
I just coded up a simple performance for a project of mine and found
that the touch event flood problem is back in town albeit with a new
face. Here's a simple test case which:
pre lang=Java
package com.badlogic.gdx;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;
import android.app.Activity;
import android.opengl.GLSurfaceView;
import android.opengl.GLSurfaceView.Renderer;
import android.os.Bundle;
import android.util.Log;
import android.view.Window;
import android.view.WindowManager;
public class LagTest extends Activity implements Renderer
{
public void onCreate( Bundle bundle )
{
super.onCreate( bundle );
requestWindowFeature(Window.FEATURE_NO_TITLE);
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
WindowManager.LayoutParams.FLAG_FULLSCREEN );
GLSurfaceView view = new GLSurfaceView( this );
view.setRenderer( this );
setContentView( view );
}
long startTime = 0;
int frames;
@Override
public void onDrawFrame(GL10 gl)
{
frames++;
if( System.nanoTime() - startTime 10 )
{
Log.d( Lag Test, fps: + frames );
startTime = System.nanoTime();
frames = 0;
}
}
@Override
public void onSurfaceChanged(GL10 gl, int width, int height) {
// TODO Auto-generated method stub
}
@Override
public void onSurfaceCreated(GL10 gl, EGLConfig config)
{
startTime = System.nanoTime();
frames = 0;
}
}
/pre
What this does is simply setting up a GLSurfaceView and output the
frames per second each second. If you watch your LogCat output while
touching the screen and dragging your finger you'll see the fps
counter go crazy. On my Droid with Android 2.0.1 it changes between 55
frames and 59 frames. As soon as i lift the finger it's back to 60
frames per second. Setting an OnTouchListener and sleeping in the
onTouch method does not solve the problem. Can anyone confirm this?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.
[android-developers] libgdx - a game development library with a twist
Hi there, I'm a bit hesitant to present this here already but today i put out the first architecturally frozen release of my game development library called libgdx. I go ahead and post the content of the description page of libgdx here so you get an idea what it is all about. A series of articles is currently in preparation at my blog at http://apistudios.com/hosted/marzec/badlogic/wordpress/?cat=17. I will continue extending the library in the near future and hope that some of consider joining the effort. Without further ado, here's a simple FAQ for libgdx. === What is libgdx? === Libgdx is my attempt at a cross-platform game development library written in Java with some JNI code for performance hungry code. It abstracts away the differences between writting an OpenGL application for the desktop via Jogl and doing the same for the Android platform. This allows you to prototype and develop your application entirely on the desktop and only needing 6 lines of code to execute it on Android. Neat, so what does it offer? Libgdx offers modules for graphics via OpenGL ES, audio, input and file i/o. All modules abstract away system specifics so you can execute the same code on the desktop and Android. The graphics module offers full bindings to OpenGL ES 1.0, 1.1 and 2.0. On the desktop almost all of the OpenGL ES functionality is emulated. The audio module features a native MP3Decoder and simple classes to playback sound effects as well as stream music. The input module provides you with information about the current state of all input devices available. This includes the touch screen, the accelerometer and the keyboard. On the desktop the touch screen is emulated via mouse input, the accelerometer is of course not available and keyboard input is mapped accordingly. The file i/o module offers you a unified way to read application internal data which map to assets on Android and files in the root directory of the application on the desktop. Additionally the module allows you to read and write external data. On Android this maps to the external storage device like the SD-card, on the desktop all paths are relative to the user’s home directory. In the future all of these modules will get extensions. For example, classes for doing common 2D graphics like tile maps or animated sprites will get included. Other additions will be bindings to 2D and 3D rigid body physics libraries like Box2D and Bullet. Ok, but can i write commercial games with this? Libgdx is licensed under the LGPL so there’s no problem when you want to use it in your paid game. Where can i find it? You can either check out the code via SVN from http://code.google.com/p/libgdx/source/browse/#svn/trunk/gdx/src/com/badlogic/gdx or get the latest build from the download page at http://code.google.com/p/libgdx/downloads/list. The build files contain all the needed jars for the desktop version as well as the shared libraries for the desktop and Android. To get something setup fast you can simply download the gdx- helloworld.zip from the download page above. It contains two eclipse project, one for the desktop version and one for Android. All the jar dependencies and shared libraries are in place and the inter project dependencies are also setup properly. The Android project depends on the desktop project which hosts all the code. The Android project only houses a single class that is the Activity of the Android version of the application. Of course you have to create a Run Configuration for each project which starts the main class and activity respectively. On the desktop you have to pass the VM argument “- Djava.library.path=libs/” to the VM in order for libgdx to find the shared library. On Android no special actions are needed. === That’s all nice and good, but is there any documentation? === Glad you ask! Everything in libgdx has extensive Java docs attached to it. In the binary distribution you will find a file called gdx-version- sources.jar. You can attach that to your Java projects to get the Java doc info for all classes and methods that are offered to you by libgdx. You can also browse the SVN repository to get to that information. You can start at http://code.google.com/p/libgdx/source/browse/#svn/trunk/gdx/src/com/badlogic/gdx and check out the main interfaces first, then move on to the packages in that directory to see what else is available to you. Additionally i’m writting a series of small blog posts that illustrate the various functionalities libgdx offers you. You can find all of those at http://apistudios.com/hosted/marzec/badlogic/wordpress/?cat=17. === I want to help! === Perfect! What’s needed is an understanding of Java, Eclipse and subversion. Everything else you can learn on the way. What’s needed at the moment is the following: * Small examples that illustrate the the various classes * Helper classes for 2D sprite and tilemap rendering * Whatever comes to your mind! === Dude, you’re code is bugged ===
[android-developers] Re: Are primitive types garbage collected in Android?
As a rule of thumb: everything you have to use the new operator for to get a hold of it is going to get garbage collected at some point. Note that this is also true for primitive arrays like int[], float[] etc. Local primitive type variables within methods don't need to get garbage collected. On 19 Mrz., 02:58, snctln catlin.s...@gmail.com wrote: I know this may be a dumb question, but my background is more in c++ and managing my own memory. I am currently cutting down every single allocation that I can from one of my games to try and reduce the frequency of garbage collection and perceived lag, so for every variable that I create that is an Object (String for example) I am making sure that I create it before hand in my constructor and not create temporary variables in simple 10 line functions... (I hope that makes sense) Anyways I was working though it some more tonight and I realized that I a may be completely wrong about my assumption on garbage collection and primitive types (int, boolean, float) are these primitive type variables that I create in a 10 line function that gets called 20 times a second adding to my problem of garbage collection? Thank you for any responses. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[android-developers] Re: Java OpenGL ES 2.0 bindings project
Hi, i just updated the library. I forgot to add support for VBOs für vertices and indices by introducting proper glVertexAttribPointer and glDrawElements variantes that take an int instead of direct Buffers. All is fixed now. You can download the latest library from http://gl2-android.googlecode.com/files/androidgl2-0.2.zip, the source is located at http://code.google.com/p/gl2-android/source/checkout. Check out the example code that shows you how to decide wheter OpenGL ES 2.0 is supported, how to setup a GLSurfaceView20 and how to create shaders and VBOs for vertex and index data at http://code.google.com/p/gl2-android/source/browse/trunk/src/com/badlogic/gdx/GL2Test.java. Have fun. On 13 Mrz., 17:48, MichaelEGR foun...@egrsoftware.com wrote: On Mar 13, 7:50 am, Mario Zechner badlogicga...@gmail.com wrote: Cool. Thanks for the flowers. The thing is apache 2 licensed so you are free to do with it whatever you want. It's not rocket science after all :). I'm not such a big fan of lwjgl but the more libraries there are out there forandroidthe better. Perhaps add the license to the source code as I missed it. What you came up with may not be rocket science per se, but it was just one more thing tacked onto a long list I'm trying to work through, so it's excellent to see this get cleared away to enough satisfaction that work can continue into 2.x land with no delay. And do send on that Paypal email if you'd like; your effort saved me more than $50 of my time! :) The uncertainty factor for 2.x support with all the other anxiety/ stress in getting the project I'm working on out adds up. I'm pretty impartial regardingbindingsas I support JOGL, LWJGL, andAndroidOpenGLES with Typhon (the middleware I'm releasing for desktop Android), but I do like the history and community in general surrounding LWJGL and that perhaps has something to do with being a part of JGO (www.javagaming.org) for quite some time. Having a separate community driven binding is always a good thing and keeps the big corps on their toes at least a little. On 13 Mrz., 16:19, MichaelEGR foun...@egrsoftware.com wrote: Figured I'd repost in this thread and include the variable time kill frag test... Awesome! Got it up and running here. You are myAndroiddev hero for the month if not longer! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[android-developers] Re: How to load a Typeface from an Inputstream
Sorry to revive this thread. But i was just fooling around with a 1.5 project where i wanted to load a Typeface from a file given as a filename. Am i correct that this is not possible in 1.5? That is kinda unfortunate :/ On 16 Mrz., 00:53, Dianne Hackborn hack...@android.com wrote: Sorry I don't believe so -- the FreeType library is native code that needs a real fd to deal with. On Mon, Mar 15, 2010 at 4:42 PM, Mario Zechner badlogicga...@gmail.comwrote: The class Typeface has a couple of static factory methods which take different inputs. However, Inputstreams are not among themn (there is a way to load a file though). Is there a way around this apart from copying the font to a temporary file? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[android-developers] Re: screen flickering in GLSurfaceView
The problem is that there's actually to targets you render to, the back and the frontbuffer of the OpenGL surface. In each call to Renderer.onDrawFrame() you actually render to the back buffer while the front buffer is presented on screen. Once you leave the onDrawFrame method the back buffer becomes the new front buffer and is presented on screen, while the former front buffer becomes the new back buffer. This is called double buffering and is actually used to reduce another form of flickering which is related to screen refresh rates. What happens in your case is the following (as far as i can tell). In the first onDrawFrame() call you render some elements to the initially black back buffer. The front buffer is also black. Now you leave onDrawFrame() and the back buffer gets presented while the front buffer becomes your new back buffer. But the new back buffer does not contain the elements you just rendered! So you render your new elements to a completely black back buffer this time so the final image is not a composition of the first onDrawFrame and the second one. As the buffers are constantly swaped they never have the same content as half of the elements is in one buffer and the others are in the other buffer. There might be a way to disable double buffering in the GLSurfaceView if you use that. Otherwise you will need to use EGL directly to setup your OpenGL surface without double buffering. On the other hand i wonder why you don't compose your complete scene in a single onDrawFrame call. On 18 Mrz., 13:44, ac andres.colu...@gmail.com wrote: Hello, I'm using GLSurfaceView to create a simple OpenGL drawing application. Since the elements drawn in each frame must remain on screen in order to be composed into the whole drawing, I don't use gl.glClear(GL10.GL_COLOR_BUFFER_BIT) at the beginning of each frame. But not clearing the color buffer leads to substantial flickering. Is there any way to eliminate flickering while still not clearing the screen at the beginning of each frame? Thanks a lot, ac -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: screen flickering in GLSurfaceView
oh, i tried that once with OpenGL ES. I didn't use the backbuffer but drew directly to a texture using an intermediate Bitmap as the drawing surface and reuploading only those parts of the texture that changed. You can find a video and an apk of that at http://apistudios.com/hosted/marzec/badlogic/wordpress/?cat=10. The problem is that if you update to much of the texture at once you get 100ms interruptions which might be visible to the user. On 18 Mrz., 14:46, Andres Colubri andres.colu...@gmail.com wrote: What happens in your case is the following (as far as i can tell). In the first onDrawFrame() call you render some elements to the initially black back buffer. The front buffer is also black. Now you leave onDrawFrame() and the back buffer gets presented while the front buffer becomes your new back buffer. But the new back buffer does not contain the elements you just rendered! So you render your new elements to a completely black back buffer this time so the final image is not a composition of the first onDrawFrame and the second one. As the buffers are constantly swaped they never have the same content as half of the elements is in one buffer and the others are in the other buffer. Thanks for the explanation, this makes the source of the problem perfectly clear. There might be a way to disable double buffering in the GLSurfaceView if you use that. That would be nice, I wonder if it is possible to do at all... After a quick look at the source code of GLSurfaceView, it seems to me that the double buffering is hard coded into the EglHelper class. Otherwise you will need to use EGL directly to setup your OpenGL surface without double buffering. I'd like to avoid this, since it basically means implementing my own GLSurfaceView... On the other hand i wonder why you don't compose your complete scene in a single onDrawFrame call. Because the goal is to have an interactive drawing application controlled by the user input (brushes strokes, etc). -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL Circle drawing
I wouldn't place all my bets on OpenGL ES 2.0 so fast as most devices out there won't support it (hardware wise, it's not so much a question of the Android version used). For a foreseeable time you will have to have to rendering paths one for OpenGL 1.x and another for 2.0. Start with 1.x, it's easier to crasp conceptually especially if you've never done any graphics programming before. On 18 Mrz., 18:54, Loki117 thomas.sheppar...@gmail.com wrote: Indeed as Robert said and as I mentioned in the question I did not want to use Canvas operations as it is just too slow especially if any other animation is running at the same time or could run as the result of some user input such as a slide up menu or animated swirl. Thanks for your suggestion Robert I am now looking at picking up the books you mentioned also I see Google just officially released the ES 2.0 supports yesterday so like you said best not to pick up a dated book. Tom On Mar 18, 1:49 pm, Robert Green rbgrn@gmail.com wrote: That's not OpenGL. That's a Canvas method. You could use that to draw to a texture, upload that and draw a quad with that texture on it, appearing to be a circle. On Mar 18, 4:34 am, tarin tatarenkov...@gmail.com wrote: Loki, you can try this: Paint paint = new Paint(Paint.ANTI_ALIAS_FLAG); paint.setColor(Color.BLUE); paint.setStyle(Style.STROKE); paint.setStrokeWidth(2); c.drawCircle(100, 100, 60, paint); On Mar 16, 11:38 pm, Loki117 thomas.sheppar...@gmail.com wrote: Afternoon all, I hope someone can help. I am trying to get my head around OpenGL on Android and hopefully start making some nice GUI's that are both quick and nice to look at. At the moment I am attempting to draw a radar type screen. To describe the screen think of a mapview with a point on the map. From the point a circle will radiate like a sonar pulse spreading out. Now I have tried doing this via MapOverlays and it is just not fast enough so I would like to try doing it via openGL ontop of the mapview. Does anyone know how I can draw this ring? I can't even work out where to start here. I did have a look at the OpenGL sample for the spinning cubes but that just confused me further. Any help would be much appreciated. Thanks in advance, Tom -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Multiple OpenGL Activities
I think Dianne Hackborne stated in one of the live wallpaper related threads that many devices have problems with managing more than one OpenGL contexts. The context is where all your OpenGL states get stored and managed. I assume there's no solution to this as it's probably tightly connected to hardware limitations and to keep the drivers simple(r). I'm not a 100% sure though. On 18 Mrz., 08:36, Tim Liu timl...@gmail.com wrote: Hi, I'm having a problem when I create a Sub-Activity to my main activity. Both activities have their own GLSurfaceViews. Nothing on Logcat. Basically It just opens up the new view and it's black and it never renders with the new opengl stuff. I've tried a bunch of stuff, just want to know if there's some special way I need to pause the first opengl activity to get the second to run, or if there's some toggle which I am missing, or if it just can't be done. When I open the second activity with a GLSurface View, the first activity stops drawing frames, but the second one, never initializes or starts to draw. Main Activity Creation: GLSurfaceView view = new GLSurfaceView(this); OpenGLRenderer renderer = new OpenGLRenderer(this); view.setRenderer(renderer); view.setOnTouchListener(renderer.tListener); setContentView(view); Sub Activity Invokation inside of OpenGLRenderer: intent = new Intent(); intent.setClass(context, PickAPlayerActivity.class); context.startActivity(intent); Sub Activity Creation: setContentView(R.layout.pickaplayerview); GLSurfaceView view = (GLSurfaceView) findViewById(R.id.jerseys); CoverFlowRenderer cover = new CoverFlowRenderer(this); view.setRenderer(cover); view.setOnTouchListener(cover.tListener); -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Game Developers: Some general questions about high scores, achievements, multi player support and in game ads.
I agree a 100% with Robert (and i didn't know i was actually of any help ever :p). I found that actually relying on 3rd party libraries is often times not beneficial. It's perfect to quasi out source tasks like loading models, basic collision and intersection testing and so on to a 3rd party library. But most of those libraries also impose some sort of scene graph API on you, which frankly is most often an extreme overhead. The resulting scene graphs are also mostly flat in games so there's no real benefit using them. Apart from the books Robert mention there is also quiet a lot of information on the web. Here's a couple of links: - http://www.flipcode.com this is the archive of the former flipcode side. May it rest in piece, it was one of the most helpful resources back when i started game programming - http://www.gamedev.net/reference/ also an immensely helpful resource. Not all of the articles there are of high quality but you're able to find quiet a large number of gems in there - http://www.gamasutra.com/category/programming/, as of late there haven't been many interesting programming related articles there, but if you dig deep enough in the archives you will find treasures. This of course only scratches the surface but should suffice for almost all your initial needs. And don't be afraid to look at really old stuff from the 90ies. It's there where you will find the most valuable information actually. On 18 Mrz., 17:52, Robert Green rbgrn@gmail.com wrote: Thank you for the compliment. I was intimidated by the math at first but it keeps getting easier and easier the more I do. I've also met people like Mario Zechner who is very knowledgeable and helpful. Just yesterday I was writing something and it wasn't working right. We talked, he mentioned a different way to do it, I changed my code and it worked perfectly. My point is, just having people to talk to that are doing the same thing as you is a really great thing and helps a lot in keeping moving along. Also there are books that clearly outline just about everything you could ever need to know: Real Time Collision Detection (Christer Ericson) is the most comprehensive suite of code examples I've seen. A must-have for any game dev. Programming Game AI by Example (Mat Buckland) is a really good overview of how to design effective AI Game Physics Engine Development (Ian Millington) has everything you could ever want for writing a 2d or 3d physics game 3D Math Primer for Graphics and Game Development (Feltcher Dunn et al) is great at teaching 3D math concepts (better than math for 3d game programming and computer graphics IMO) OpenGL Superbible (blue book) contains a huge coverage of how to program for GL. There are also different colored books that are basically the authority on any other GL-related topic. The thing is, people think that using an engine means they don't have to learn certain things, like low-level rendering and math. The fact of the matter is that games are math and it is just inherent in them. It's like saying you don't need to know basic geometry as an architect because you can just use Autocad to do your dirty work. Clearly that won't work, you'll need to be able to make calculated designs. No engine does absolutely everything you want out of the box. To add a unique feature to a game, you'll need to know how to write that exact code, and chances are that if it does anything cool at all, there will be some math involved. Fortunately, if you have the right resources (people, books, pen, paper and a calculator) you'll be able to figure it out and get it working correctly :) I say just dive in head first. Learn as you need to. I think that's what lots of us have done. As far as art goes - I've only found one way to deal with that. Find a good artist! I'm working with a guy who was willing to partner up for a percentage of the game's revenue. He's turned out to be a great 3D artist and so it really worked out well. Everyone involved in making a game needs to have passion to do it. It's hard and takes a lot of time and patience. I think it's awesome that you are thinking about doing it. Feel free to email me with questions along the way. Also, check and see if there is an IGDA chapter in your area. That's where I met several very talented people. We have a meeting tonight, in fact! On Mar 18, 9:40 am, Kevin Duffey andjar...@gmail.com wrote: I agree full heartedly Robert. I can't imagine EA spending a few hundred grand on a game for mobile, knowing that they likely won't recoup the costs.. unless it's just a brand recognition thing and an exepected loss. I am well aware of the costs for large scale games, have a few friends in the business working for EA, Blizzard, etc. I've wanted to break into the gaming business for a looong time. I am just not so good with all that extensive math involved in the bigger games. That is why kits like
[android-developers] Re: 3D Physics Engine For Android Demo
There's a couple of choices, none of them will work fast enough if you use the Java implementations. Popular choices are Chipmunk (http:// code.google.com/p/chipmunk-physics/) and Box2D (http:// www.box2d.org/). There's also a Java port of Box2D which is called JBox2D (http://www.jbox2d.org/) i really wouldn't recommend using it though. It horribly leaks memory due to small object instantiation when contact points are resolved. You best bet will be to write a JNI bridge for Box2D or Chipmunk. Both compile easily with the NDK provided you have a proper Android.mk file. On 17 Mrz., 15:37, Jiri jiriheitla...@googlemail.com wrote: Sorry to be off topic, but can somebody also point me to a 'decent' _2d_ physics engine. I seen a few, but i was wondering what the general consensus is about the 'most' reliable one in terms of steady/continues development. Cheers, Jiri On 15/03/2010 15:25, Kevin S. wrote: I've completed my first Android application. It as 3D demo with a physics engine. It uses the phone's accelerometer so that you can shake the world by moving the phone around. There are options to adjust things like gravity, friction, and elasticity. The physics engine is a 100% Java port of the open source JigLib physics engine. However, I only have a Motorola Droid, and I don't know if it will work on any other phone. The project is set to use Android 1.6. Before I put it in the market, I was hoping to get some feedback from the developer community here. If anybody is interested in 3D stuff or physics simulation, you can give the app a try. The link is on the follow page. There is a screen shot there so you can get an idea of what the app is. http://www.pieintheskysoftware.com/menuitem-resources-pie-3d-physics-... -Kevin -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?
Not at this point. I plan to write a JNI bridge to Box2D and Bullet in the future though. Happy to have some volunteers that help me put that together :) On 17 Mrz., 15:57, Jiri jiriheitla...@googlemail.com wrote: Does this framework support simple 2d physics and collision detection and/or elastic collision? Jiri On 10/03/2010 01:11, Mario Zechner wrote: While it's not nearly as full featured as XNA i started working on something similar to XNA. It allows you to develop your games mostly on the desktop and deploying it to your Android device with just a couple of lines that instantiate a special Activity subclass. It's based on OpenGL and allows developing 2D and 3D games. I just finished writting all the java doc for it and am constantly adding new features to it. It's called libgdx and can be found athttp://code.google.com/p/libgdx/. I also started blogging about it lately and will continue so adding sample codes for specific problems. You can find that blog at http://www.badlogicgames.com. An introduction to it can be found at http://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A series of small tutorials wil follow this week and next week. The whole thing is LGPL so that there's no problem including it in commercial apps. It's far from being perfect of course but i think the base functionality and ease of use can kill some of the burden a fresh android game developer has to overcome. I'm open for suggestions and features you want to see in there! On 9 Mrz., 22:35, Piotrpiotr.zag...@gmail.com wrote: Hello, At my daily job I work as WinMo C++ developer, so I had enough time to become hater of that platform ;) But now, M$ is coming with new Windows Phone. As I suspected, they will abandon awful Win32/MFC native coding and all applications, will be now managed - run in CLR sandboxes on top of 15 years old Win32 kernel. Main coding language will be C# with .NET framework - Java rival. WinMo always was terrible phone OS, but now, more interesting is, that Windows Phone will support XNA framework: http://www.youtube.com/watch?v=LQv_3fwopo8 This is full gaming framework with C# interfaces and support for 2D/3D graphics, animation, sprites, net play, game sound, controllers, etc.. XNA greatly improves creating games, because it gives a developer an ready to use game abstraction layer. To the point; Android needs game framework, like XNA. Maybe it should be written as NDK library, ready to link with your own application. This library could load, manage and draw sprites, backgrounds, make simple physics, etc.. Why ? To create games faster, easier. At this time, you must be very skilled to create simple platformer with 2 bkgs and 5 sprites. Our devices have even 1GHz CPU's and animation can be STILL too slow ! I'm tired of the same logical bricks/ball/falling diamonds games over and over. What do you think ? Is there any chance, that Google will work on something like that ? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?
I agree to this point based on my own experience and micro benchmarks. That's why i think only performance critical code should be written in native code such as physics calculations. I'd really love to get more people on board of libgdx, it's now in a pretty useable state and the API is nearly good enough to be frozen. Contact me if you are interested. I contacted the guy who wrote the Scorpios API but he didn't seem to be interested in collaborating. On 17 Mrz., 16:31, niko20 nikolatesl...@yahoo.com wrote: Personally through my experience this JNI layer overhead is so small that its effect is negligible. In my apps using NDK with JNI has alway increased my speed immensly regardless of any JNI method call overhead. It's just simply not true that the JNI will slow you down. -niko On Mar 17, 9:06 am, Sean Hodges seanhodge...@googlemail.com wrote: On Wed, Mar 17, 2010 at 2:25 PM, Streets Of Boston flyingdutc...@gmail.com wrote: True and not true. If google thinks that making an XNA like framework could enhance Android's adoption and device sales enough to bring more ad-revenues/ SaaS-revenues (because more phones would be around if such a framework existed), then google could be interested in creating such framework. However, if the potiential return on such a framework is not large enough, then they won't do it. You are of course correct, though I firmly believe spending lots of time speculating on such things will 100% fail to actually get the work done. There is also the question of whether Google are the ideal company to produce such a framework. Microsoft have invested a lot in DirectX and their XBox projects, they have the experience and the partners to make it work. What experience do Google have in the games industry? Personally I think they are stretching themselves enough with their shoulder barging into the mobile market, without trying to dive into the centre of the extremely competitive games market. Having said that, the Android platform does need to compete in this field. This seems like the perfect opportunity for a start-up, or an established games development company, to build a native framework and contribute it upstream. Mario's library might be a good starting point for this - as well as a technical evaluation of the other libraries/engines out there (such as Rokon by StickyCoding). The way to move forward would be to actively pursue a solution though, rather than mull around the topic passing notes to Google like we were in the Peoples' Front of Judea. :) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Game Developers: Some general questions about high scores, achievements, multi player support and in game ads.
I use a simple MySQL database on my server combined with some simple php scripts that use salted md5 hashes to verify the authenticity of a submitted score. In the game i only display the top 10 scores for each level. Communication with the server is done via Http Posts. I do that via OpenGL, i'm not using any Android GUI components. I don't have achievements as of now and i'm currently to busy to implement them. Then again, the game is probably more about finishing a level than getting a high score or achievements :) On 17 Mrz., 18:07, Wayne Wenthin wa...@fuligin.com wrote: In my Game I actually display the Hiscore as a webpage. This allows it to be shown on my website also. I generate it once an hour since it was taking way to long to display otherwise. I have since revised my code and I could update ever 15 minutes. Ads: If you have a game that users spend enough time in ads can indeed create some cashflow. Now are you going to live off of it? That's an unknown. I make a bit on my ads. Its not going to pay my bills but it is better than nothing. Free with ads vs. Paid. I went with ads because my game is in progress. I have had many people say they would pay for it. I personally feel that since this is a labor of love I don't want the stress of having to deal with paid application support. I give good support because I want them to stay in the game and support me that way. While my game is Mulitplayer its not very real time. Everything is done via restful services. On Tue, Mar 16, 2010 at 5:08 PM, Kevin Duffey andjar...@gmail.com wrote: Hey all, I am curious how the various groups of game developers, primarily mobile (android in this case) and cross-platform (android/iPhone/facebook) handle storing high scores, achievements, and such as well as how multi player is done. How does your game(s) access high scores, update the list, remove them if need be? The same would apply for achievements, and to a lesser degree, leader boards. Are you using a service out there that you pay for... if so how much does it cost.. and do they provide some sort of java/objective-c SDK that you can just plug in to your code? How do you dispaly high scores, leader boards, achievements, etc in your game? Do you provide your own web site with the same info, perhaps jazzed up a bit more or with more detail than your mobile game (due to limited screen realestate for mobile devices)? Do you provide a link to a web site in your game if they want to see things like high scores, achievements and leader boards? I would also like to know what sort of things are most important for your games. High scores are so yesterday, so to speak. The latest craze in most games seems to be achievements and the ability to obtain extra items for your games, either by buying them, or earning them through achievements, etc. So what are some things you game developers would want to make use of in your game to add more appeal to your game, to draw in players for longer, especially long enough to pass the 48 hour refund time so that you can actually earn some money from your hard work. I look at games on Facebook like Farmville that are doing so well they are hiring more developers at good pay to work on it. I also look at games like World of Warcraft, which I play and got sucked into for a while, due to getting to that next level or getting that next awesome epic gear piece... those sorts of things seem to be what draws in players to otherwise simple games. A number of mobile games that seem to do very well often seem to be fairly simple games but offer that right mix of I just got to get to that next I am curious what some of you developers have found work for games either those that you played, or are working on (or have written) that draw in players. This leads to the next paragraph.. making a living on game development ultimately requires that your game does well and that people pay for it in some manner and not refund it. Hence why I am trying to understand what it is that those otherwise simple games seem to do that draw in the masses. Which brings about another topic.. how do games like Farmville make so much money being free games, that they can have a company behind it? I can't believe ads on the stie alone make up for all their revenue. I've been considering looking at ads in the game as opposed to charging for it, and that seems like players might keep a game longer than if they pay for it and then refund it within 48 hours if they don't absolutely love the game... although I am not entirely sure how much it annoys players to have a small portion of the screen saved for ads as opposed to just buying it. Lastly, multi-player. I am curious how games work multi-player. The only way I can think of is the client (game) has to update a server of some data, a move, location of a sprite, etc, and at the
[android-developers] Re: glBufferData crash
Hi,
you have to use direct buffers with native byte ordering for this to
work. Instead of
testBuffer = IntBuffer.wrap( testArray );
you have to do a bit more work like this:
ByteBuffer buffer = ByteBuffer.allocateDirect( testArray.length * 4 );
buffer.order( ByteOrder.nativeOrder() );
testBuffer = buffer.asIntBuffer();
testBuffer.put( testArray );
testBuffer.flip();
I didn't test this but wrote it from the top of my head. It should
work though.
hth,
Mario
On 17 Mrz., 01:23, ac andres.colu...@gmail.com wrote:
Hello,
I have experienced some trouble using VBOs, since the method
glBufferData crashes when I try to copy data to the vertex buffer.
Below is the smallest snippet of code that I found to generate the
crash:
int numVert = 32;
GL11 gl11 = (GL11)gl;
testArray = new int[numVert * 3];
testBuffer = IntBuffer.wrap(testArray);
gl11.glGenBuffers(1, testID, 0);
gl11.glBindBuffer(GL11.GL_ARRAY_BUFFER, testID[0]);
final int siz = testBuffer.capacity() * Integer.SIZE;
gl11.glBufferData(GL11.GL_ARRAY_BUFFER, siz, testBuffer,
GL11.GL_STATIC_DRAW);
gl11.glBindBuffer(GL11.GL_ARRAY_BUFFER, 0);
testArray, testBuffer and testID are members of the class containing
this code, declared as follows:
int[] testArray;
IntBuffer testBuffer;
int[] testID = {0};
I tried this code in several OpenGL applications which don't show any
problem otherwise.
The crash occurs specifically at the glBufferData() method call. If
numVert is set to zero, then the crash doesn't occur.
Any comments will be greatly appreciated.
Thanks,
ac
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: glBufferData crash
Oh and one more thing
final int siz = testBuffer.capacity() * Integer.SIZE;
should really be
final int siz = testBuffer.capacity() * Integer.SIZE / 8;
as Integer.SIZE gives you the number of bits an integer occupies.
On 17 Mrz., 01:23, ac andres.colu...@gmail.com wrote:
Hello,
I have experienced some trouble using VBOs, since the method
glBufferData crashes when I try to copy data to the vertex buffer.
Below is the smallest snippet of code that I found to generate the
crash:
int numVert = 32;
GL11 gl11 = (GL11)gl;
testArray = new int[numVert * 3];
testBuffer = IntBuffer.wrap(testArray);
gl11.glGenBuffers(1, testID, 0);
gl11.glBindBuffer(GL11.GL_ARRAY_BUFFER, testID[0]);
final int siz = testBuffer.capacity() * Integer.SIZE;
gl11.glBufferData(GL11.GL_ARRAY_BUFFER, siz, testBuffer,
GL11.GL_STATIC_DRAW);
gl11.glBindBuffer(GL11.GL_ARRAY_BUFFER, 0);
testArray, testBuffer and testID are members of the class containing
this code, declared as follows:
int[] testArray;
IntBuffer testBuffer;
int[] testID = {0};
I tried this code in several OpenGL applications which don't show any
problem otherwise.
The crash occurs specifically at the glBufferData() method call. If
numVert is set to zero, then the crash doesn't occur.
Any comments will be greatly appreciated.
Thanks,
ac
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Game Developers: Some general questions about high scores, achievements, multi player support and in game ads.
How about security? As a developer, do you have to get some sort of API key? Is it done over SSL/TLS, or both an API key and SSL/TLS? I am wondering how invovled the process is to get set up to actually use one of these services... or for those of you that wrote your own, what do you do to ensure it's your game calling the server side, and not some hacker or another game trying to use it for free? As stated in my post all data is submitted with an accompanying salted md5 hash which the server can reconstruct. What you basically do on the client is construct a string out of your data, salt it by concatenating it with another string only you know about and then calculate an md5 hash from that. On the server you also construct a concatenated string out of the send data and salt it with the same string you use on the client. If the md5 hashes match the data is coming from an original client, if not someone is trying to hack your server. Reengineering the salt string by sniffing the transfered md5 hashes is possible to my knowledge, however you'd need a shitload of computing power to do so (and i really mean a shitload). Nobody has the resources to do this and nobody is probably going through the hassle to crack your game server anyways :) I don't say that this is the perfect method, but it worked well for me and a couple of my friends in various projects. And an off topic question.. I see more and more people talking about getting a free phone from google? Is there some place you sign up to get this? I'd love to get a Nexus One to test on... sounds like some people are getting just that.. a free phone to test on? Thanks again all. More to come I hope. On Wed, Mar 17, 2010 at 10:37 AM, Justin Giles jtgi...@gmail.com wrote: Just to throw it out there... There's also Google Apps Engine:https://appengine.google.com It's java or python based (your choice). The free quotas are rather generous. I keep my high scores stored there for my apps and for one of the apps I have over 75000 active installs and I have yet to go over the free quota. You do get charged if you go over your quota, but the rates, in my opinion, are reasonable. Same basic idea as the MySQL and Rails suggestions. No, I'm not a Google fanboy, but with a free device coming sometime soon, if Google asked me, I'd sheepishly say yes sir, yes I am a fanboy :). Justin On Wed, Mar 17, 2010 at 11:25 AM, Robert Green rbgrn@gmail.comwrote: Since no one else has responded I'll talk about what I did, though I haven't gone cross-platform yet (which is why I didn't respond right away). I chose cross-platform technologies just in case I ever wanted to and I know that they will work for it. What works well for me for my leaderboards and turn-based multiplayer code is to use Ruby on Rails with JSON as the encoding. It's supported natively by rails and Android comes with JSON parsing and encoding. It's such a simple protocol that one could easily write an encoder/decoder for any platform, though I don't think you'd have to because I'm sure one exists for almost every one. There are many routes to go that will work fine, including having an XML-based service. I'd stay away from things like Java Object Serialization. That is not easily portable. I'd also stay away from technologies like SOAP and WS. They are heavy and you want to keep it light and simple usually on a phone and small server / high traffic setup. My first recommendation is to use Ruby on Rails / REST / JSON for your basic server. How it works: Rails runs either as a plugin to apache via Phusion Passenger or standalone via mongrel/other server apps. Clients make requests using REST, which means HTTP Get Post Put and Delete which query, insert, update and delete respectively. The requests and responses are encoded in JSON, which is a simple encoding, human readable and extremely fast to parse. Advantages: Any platform can implement a client for it. It's very light and fast. All of the necessary tech is inherent in rails and so this provides a very low-resistance coding path. Passenger (the apache plugin that runs RoR servers) runs great and is easy to deploy and uses your standard web server. You can actually easily run a game core written in Java wrapped with the RJB (Ruby Java Bridge) - I do this for Wixel Disadvantages: Another language to learn (though I don't mind working in it at all, it's really kinda nice) Doesn't handle native code well (if you have a game core in C/C++ that you need to access, it's a little tricky with Apache/Passenger/Rails) Is only good for scores/leaderboards and turn-based games. You can only update as much as you can push HTTP requests and process responses. It's not good for real-time games requiring faster than a second or two turnaround, though it can handle scores and accounts for them fine. If you want a
[android-developers] Re: Game Developers: Some general questions about high scores, achievements, multi player support and in game ads.
Yeah, i only have a single string for the game. I chose md5 because i knew how to calculate it. SHA-1 will do just fine too. I'm by no means a security expert and if it comes to transfering currency you really shouldn't use handcoded stuff like i do but really rely on industrial strength solutions. Robert pointed out a solution via Ruby on Rails and some other tools that will help you with implementing such a system. I never looked into that stuff so maybe Robert can enlighten us. On 17 Mrz., 22:27, Kevin Duffey andjar...@gmail.com wrote: Hey Mario, Thanks for the replies. So your salted md5 hash, do you generate one for each player, or just one for your game, that is sent in with every request by each game player (via your game code)? So this secret that you concatenate, you hard code it in both the game code and your server code? So some string like abcd123, append it, md5 the whole string, then send it? I have been using SHA-1 for playing around, using the Java SDK api that can also be used for MD5. Any benefit in using MD5 over SHA-1? I thought SHA-1 was more secure/harder to crack? I agree with you.. the chances of anyone sniffing the packets, figuring out its game data, trying to decipher it, and for what purpose anyway.. is unlikely. However, for some reason, companies tend to shy away from anything that isn't super industrial strength secure. I am also curious because I may want to allow the game player the option to use real currency in game to buy game items. That may require a game player to set up some sort of credit card or paypal account... not sure yet how this all works, but because of this there may be a need to be more secure, such as using TLS. What do you think? On Wed, Mar 17, 2010 at 11:15 AM, Mario Zechner badlogicga...@gmail.comwrote: How about security? As a developer, do you have to get some sort of API key? Is it done over SSL/TLS, or both an API key and SSL/TLS? I am wondering how invovled the process is to get set up to actually use one of these services... or for those of you that wrote your own, what do you do to ensure it's your game calling the server side, and not some hacker or another game trying to use it for free? As stated in my post all data is submitted with an accompanying salted md5 hash which the server can reconstruct. What you basically do on the client is construct a string out of your data, salt it by concatenating it with another string only you know about and then calculate an md5 hash from that. On the server you also construct a concatenated string out of the send data and salt it with the same string you use on the client. If the md5 hashes match the data is coming from an original client, if not someone is trying to hack your server. Reengineering the salt string by sniffing the transfered md5 hashes is possible to my knowledge, however you'd need a shitload of computing power to do so (and i really mean a shitload). Nobody has the resources to do this and nobody is probably going through the hassle to crack your game server anyways :) I don't say that this is the perfect method, but it worked well for me and a couple of my friends in various projects. And an off topic question.. I see more and more people talking about getting a free phone from google? Is there some place you sign up to get this? I'd love to get a Nexus One to test on... sounds like some people are getting just that.. a free phone to test on? Thanks again all. More to come I hope. On Wed, Mar 17, 2010 at 10:37 AM, Justin Giles jtgi...@gmail.com wrote: Just to throw it out there... There's also Google Apps Engine:https://appengine.google.com It's java or python based (your choice). The free quotas are rather generous. I keep my high scores stored there for my apps and for one of the apps I have over 75000 active installs and I have yet to go over the free quota. You do get charged if you go over your quota, but the rates, in my opinion, are reasonable. Same basic idea as the MySQL and Rails suggestions. No, I'm not a Google fanboy, but with a free device coming sometime soon, if Google asked me, I'd sheepishly say yes sir, yes I am a fanboy :). Justin On Wed, Mar 17, 2010 at 11:25 AM, Robert Green rbgrn@gmail.com wrote: Since no one else has responded I'll talk about what I did, though I haven't gone cross-platform yet (which is why I didn't respond right away). I chose cross-platform technologies just in case I ever wanted to and I know that they will work for it. What works well for me for my leaderboards and turn-based multiplayer code is to use Ruby on Rails with JSON as the encoding. It's supported natively by rails and Android comes with JSON parsing and encoding. It's such a simple protocol that one could easily write an encoder/decoder for any platform
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
Hi there, not sure whether i can help but you stated that you couldn't find anywhere that AudioTrack.play() (which should probably read AudioTrack.write()) does not block. Well, it does. And if you do the following in your thread: AudioRecord.read(sampels) AudioTrack.write(samples) i can imagine that the write will block long enough for the AudioRecord to overflow as you don't read in the next buffer of samples early enough. You could try decreasing the number of samples you read and write so the write will not block as long. No idea whether that will solve the problem. hth, Mario On 18 Mrz., 00:33, HeHe cnm...@gmail.com wrote: no, i havent, because my app runs ok on g1 with 1.6 firmware. it just runs weird on 1.6 emulator. so i am 90% happy already. btw, my app does not record and play audio at the same time, but it encodes audio with speex, which should take overhead no less than playback, i guess. anyway, i wish you lucks and hope goodle folks will help you solve the issue. On Mar 17, 8:55 am, Gabriel Simões gsim...@gmail.com wrote: Installing ubuntu 9.1 on my machine. I will try using linux to develop as I think it will be less confusing to develop using NDK. Hehe: I was thinking about trying to get an answer from someone from Google tomorrow at irc. Have you ever tried it? Won´t anyone who is actually using AudioRecord with success show up and tell us what we are doing wrong? :( On 17 mar, 12:53, HeHe cnm...@gmail.com wrote: i heard that too. but some google folk seemed discouraging use of the stuff. On Mar 17, 6:27 am, Gabriel Simões gsim...@gmail.com wrote: Nope, I´ve paid attention to see if GC was being called, but nothing shows up on LogCat. Well, I´ve found some posts on the internet about using AudioRecord´s native implementation. Isn´t it supported anymore? I still can´t believe we are spending so much time on something that should be plug and play. It´s almost becoming plug and pray! On 17 mar, 02:41, HeHe cnm...@gmail.com wrote: if you find any native audio interfaces in NDK, please share it with me first :) for your issue, did you check GC? that is, around the time when you see buffer overflow msgs, does GC happen too? On Mar 16, 7:33 pm, Gabriel Simões gsim...@gmail.com wrote: *** Idea ... Using the NDK native audio interfaces should solve this problem? On 16 mar, 22:26, Gabriel Simões gsim...@gmail.com wrote: News, but no good news... I´ve tried the source code above on another machine running the sdk 2.1, an AVD with default parameters plus audio record and audio playback capabilities, another operational system (linux), etc. The results? the same we had before audio delay (long delay), chopping, distortion and a metalic voice. I can not believe nobody here in this forum hasn´t been able to develop any app that can record from the microfone using AudioRecord. Also, anyone here hasn´t even made a loop back from microfone to line out to check the audio being recorded? Please, c´mon guys ... this is not a commercial secret, this won´t increase competition, and I really can´t see any other reasons not to see some posts from developers who work with audio or other signal processing using Android. Please, show us a way to go because I´ve tried almost all the possibilities here (the only one left is to try using a real device) and revising the code I can´t find what else it could be. *Obs: once again, a program with a thread only to read from AudioRecord and play with AudioTrack is giving warnings about buffer overflows (Audio Record). There´s no processing going on and since I haven´t found anything related to AudioTrack.play() blocks until the audio stream is played, based on it´s actuall behavior in my app I can ´t see how this class could be useful for online audio processing applications. Thank you, Gabriel On 15 mar, 20:53, Gabriel Simões gsim...@gmail.com wrote: Well, just to try I´ve downloaded the SDK 1.6 (v. 4), created a new AVD based on that and then tried the source code from the first post in two different situations: - App compiled using SDK 1.6 on an AVD running 1.6 - App compiled using SDK 1.6 on an AVD running 2.1 Had exactly the same results as compiling and running on 2.1: audio chopping, distortion and artfacts even if I solo the microfone input level (using a 1 second buffer, sometimes the audio decays in a lot longer) and AudioRecord buffer overflow messages even if all I do in the thread is to read from AudioRecord and to play using
[android-developers] Re: Game Developers: Some general questions about high scores, achievements, multi player support and in game ads.
yeah, i should have pointed out that my approach is the poor man's security approach :) On 18 Mrz., 01:05, Bob Kerns r...@acm.org wrote: Yes, SHA-1 is what you should go with. It's really a matter of just requesting a different engine; the API doesn't care which one you use. One thing to consider is that a salt doesn't prevent replay attacks. If you want to prevent people driving up their score by replaying the packets already sent, you may want to include a nonce in your protocol. I'd suggest using a secure random, and the current time, and remember recent nonces, and reject anything that's either not recent, or has a nonce that's been recently seen. It's easy too do -- and even if it's not necessary to have that level of security, it's a good technique to be aware of. On Mar 17, 2:27 pm, Kevin Duffey andjar...@gmail.com wrote: Hey Mario, Thanks for the replies. So your salted md5 hash, do you generate one for each player, or just one for your game, that is sent in with every request by each game player (via your game code)? So this secret that you concatenate, you hard code it in both the game code and your server code? So some string like abcd123, append it, md5 the whole string, then send it? I have been using SHA-1 for playing around, using the Java SDK api that can also be used for MD5. Any benefit in using MD5 over SHA-1? I thought SHA-1 was more secure/harder to crack? I agree with you.. the chances of anyone sniffing the packets, figuring out its game data, trying to decipher it, and for what purpose anyway.. is unlikely. However, for some reason, companies tend to shy away from anything that isn't super industrial strength secure. I am also curious because I may want to allow the game player the option to use real currency in game to buy game items. That may require a game player to set up some sort of credit card or paypal account... not sure yet how this all works, but because of this there may be a need to be more secure, such as using TLS. What do you think? On Wed, Mar 17, 2010 at 11:15 AM, Mario Zechner badlogicga...@gmail.comwrote: How about security? As a developer, do you have to get some sort of API key? Is it done over SSL/TLS, or both an API key and SSL/TLS? I am wondering how invovled the process is to get set up to actually use one of these services... or for those of you that wrote your own, what do you do to ensure it's your game calling the server side, and not some hacker or another game trying to use it for free? As stated in my post all data is submitted with an accompanying salted md5 hash which the server can reconstruct. What you basically do on the client is construct a string out of your data, salt it by concatenating it with another string only you know about and then calculate an md5 hash from that. On the server you also construct a concatenated string out of the send data and salt it with the same string you use on the client. If the md5 hashes match the data is coming from an original client, if not someone is trying to hack your server. Reengineering the salt string by sniffing the transfered md5 hashes is possible to my knowledge, however you'd need a shitload of computing power to do so (and i really mean a shitload). Nobody has the resources to do this and nobody is probably going through the hassle to crack your game server anyways :) I don't say that this is the perfect method, but it worked well for me and a couple of my friends in various projects. And an off topic question.. I see more and more people talking about getting a free phone from google? Is there some place you sign up to get this? I'd love to get a Nexus One to test on... sounds like some people are getting just that.. a free phone to test on? Thanks again all. More to come I hope. On Wed, Mar 17, 2010 at 10:37 AM, Justin Giles jtgi...@gmail.com wrote: Just to throw it out there... There's also Google Apps Engine:https://appengine.google.com It's java or python based (your choice). The free quotas are rather generous. I keep my high scores stored there for my apps and for one of the apps I have over 75000 active installs and I have yet to go over the free quota. You do get charged if you go over your quota, but the rates, in my opinion, are reasonable. Same basic idea as the MySQL and Rails suggestions. No, I'm not a Google fanboy, but with a free device coming sometime soon, if Google asked me, I'd sheepishly say yes sir, yes I am a fanboy :). Justin On Wed, Mar 17, 2010 at 11:25 AM, Robert Green rbgrn@gmail.com wrote: Since no one else has responded I'll talk about what I did, though I haven't gone cross-platform yet (which is why I didn't respond right away). I chose cross-platform technologies
[android-developers] Re: 3D Physics Engine For Android Demo
Tried it on my Milestone. Pretty neat. The fps degrade to around 12-15 after some time (essentially when the big plate starts to touch the ground completely) probably due to there being a lot more contact points then. Also, the garbage collector is getting a fair amount of work to do every 5 seconds or so. I don't know much about JigLib but maybe you could make it so that it uses JStackAlloc. JBullet uses that library and has no garbage collection at all. I put together a simple JBullet demo a while back, you can find information on that at http://apistudios.com/hosted/marzec/badlogic/wordpress/?p=81. I do not recommend using a pure Java based physics library at this point for a full featured game unless the scene is really really simple. Consider using bullet via the NDK. You get extra points for implementing the activity life cycle correctly :) On 15 Mrz., 15:43, Marc Lester Tan mail...@gmail.com wrote: Works well on my Nexus One. Cool! On Mon, Mar 15, 2010 at 10:25 PM, Kevin S. dada...@gmail.com wrote: I've completed my first Android application. It as 3D demo with a physics engine. It uses the phone's accelerometer so that you can shake the world by moving the phone around. There are options to adjust things like gravity, friction, and elasticity. The physics engine is a 100% Java port of the open source JigLib physics engine. However, I only have a Motorola Droid, and I don't know if it will work on any other phone. The project is set to use Android 1.6. Before I put it in the market, I was hoping to get some feedback from the developer community here. If anybody is interested in 3D stuff or physics simulation, you can give the app a try. The link is on the follow page. There is a screen shot there so you can get an idea of what the app is. http://www.pieintheskysoftware.com/menuitem-resources-pie-3d-physics-... -Kevin -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: GL11Ext.glCurrentPaletteMatrixOES problem
Hi,
i suggest checking the extension string you can get via a brave call
to gl.glGetString( GL10.GL_EXTENSIONS ). I suspect that the software
renderer that's used for OpenGL on the emulator does not support this
extension. The casting might seem a bit barbaric at first but you get
used to it :). Not sure why directional lights wouldn't work.
On 13 Mrz., 16:50, JimVonMoon jimvonm...@gmail.com wrote:
Hello! :-)
I'll try to make this brief:
public void draw(GL10 gl)
{
gl.glMatrixMode(GL11Ext.GL_MATRIX_PALETTE_OES);
((GL11Ext)gl).glCurrentPaletteMatrixOES(0); // I get
java.lang.UnsupportedOperationException here.
}
I am using Android emulator under Windows XP and Eclipse. So my
question is:
Is that just an emulator issue or is it really unsupported?
I wanted to check if Android SDK is any good before I buy a real
device so I can't verify that issue by myself. As for now I can't say
that I like this SDK - necessity to cast GL10 objects to GL11, GL11Ext
etc. is ummm... barbaric? I also had problems with directional
lighting and now this - go figure...
Anyway, thanks for help. :-)
--
Cheers, :-)
JimVonMoon
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Want to start building 3d games, pointers?
Hi, let me start by answering your questions: 1) What you refer to is usually called picking and involves a bit of math. Your initial goal is to get a ray (defined by a starting point and a unit length direction) from your touch coordinates. This can be done via GLU.gluUnProject (http://developer.android.com/reference/ android/opengl/GLU.html#gluUnProject(float,%20float,%20float, %20float[],%20int,%20float[],%20int,%20int[],%20int,%20float[], %20int)). With this ray you can now check wheter an object in your world has been hit. Usually your objects will have something called a bounding volume like a sphere or an axis aligned bounding box (nice keywords for google). All you then have to implement is a ray/bounding volume intersection test which tests the ray against all your objects' bounding volumes. Among the objects that intersect with your ray the one nearest to the ray's starting position will be you touched object. Simple eh? :) 2) There's no support for any 3d formats in Android out of the box and i guess that will stay this way for good reasons. 3) That's a matter of taste i guess. I myself use OpenGL for everything. Others add standard GUI widgets on top of the GLSurfaceView. The later is a bit easier while the former is more flexible. Chose your poison. 4) That would be cool, maybe we can collaborate :) Additionally i want to link to Robert's great introductionary text on Android game programming you can find at http://www.rbgrn.net/content/54-getting-started-android-game-development. Make sure to also check out the other articles on his blog. Furthermore i'm currently writting a small and hopefully easy to use game programming library for cross plattform development myself. It's called libgdx allows you to code up your games on the desktop with standard Java emulating OpenGL ES via Jogl and seamlessly deploy them to an Android device without changing a line of code. I'm currently giving it the finishing touches, the only thing missing is the OpenGL based GUI system i rewrote from scratch as well as the Audio classes. If you want to collaborate just drop me a line, the more hands the faster the lib grows. You can find info on the lib at http://www.badlogicgames.com and http://code.google.com/p/libgdx/. Hth, Mario On 15 Mrz., 17:28, Ronnyek wwe...@gmail.com wrote: Hi, I'd like to just start off by saying I've done a bit of research into 3d development, and am confident in simple lets build some simple 3d objects, and render them... would be easy. I also have a very long history writing software, understand how games work internally etc. I understand 3d concepts, 3d space, shapes, camera, lighting etc... but I do have a couple questions. (and no I dont expect anyone to hold my hand through it, more than happy to put the work in) 1) Initially I wont need it, but how do you handle for touch interactions with a given 3d object on screen? I've heard of doing things like mapping screen vertices to objects and when you touch in x region, you are touching x object. Is there an easier way? 2) I intend to take a 3d format and import into my app, and there is plenty of documentation on the formats I intend to use, so I can write an importer... but does android 2.1 support anything out of box? 3) For basic menus and screen overlays, are those typically drawn with opengl stuff too? Or a diff sort of view layed over the top of glsurface? 4) I don't know if I'd say I want to build a 3d engine for android, but I definitely think writing some useful utilities and wrappers and converters to simplify some of the most common bits, and perhaps document my efforts in blog, might be helpful to others. These bits I'd like to make opensource.. any recommendations on features you'd all like to see? (or maybe this is reinventing the wheel) I appreciate everyone's time, I assure you I've done some research... and want to help prevent future newbies from running up against the same problems I am. (trying to build wrappers and helpers and converters etc) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] How to load a Typeface from an Inputstream
The class Typeface has a couple of static factory methods which take different inputs. However, Inputstreams are not among themn (there is a way to load a file though). Is there a way around this apart from copying the font to a temporary file? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Vertex Array/Vertex Buffer Objects driver bug on Droid
Hi,
just wanted to drop by to tell you about a nice little bug i just
encountered on my droid. Here's some sample code:
@Override
public void render(Application app)
{
GL11 gl = app.getGraphics().getGL11();
gl.glViewport( 0, 0, app.getGraphics().getWidth(),
app.getGraphics().getHeight() );
gl.glClearColor( 0.7f, 0.7f, 0.7f, 1 );
gl.glClear( GL11.GL_COLOR_BUFFER_BIT );
gl.glBindBuffer( GL11.GL_ARRAY_BUFFER, vboHandle );
gl.glEnableClientState( GL11.GL_VERTEX_ARRAY );
gl.glEnableClientState( GL11.GL_COLOR_ARRAY );
gl.glVertexPointer( 3, GL11.GL_FLOAT, 6 * 4, 0 );
gl.glColorPointer( 3, GL11.GL_FLOAT, 6 * 4, 3 * 4 );
gl.glDrawArrays( GL11.GL_TRIANGLES, 0, 3 );
}
@Override
public void setup(Application app)
{
ByteBuffer buffer = ByteBuffer.allocateDirect( 3 * 6 * 4 );
buffer.order(ByteOrder.nativeOrder());
FloatBuffer vertices = buffer.asFloatBuffer();
vertices.put( new float[] {
-0.5f, -0.5f, 0, 1, 0, 0,
0.5f, -0.5f, 0, 0, 1, 0,
0.0f, 0.5f, 0, 0, 0, 1,
});
vertices.flip();
GL11 gl = app.getGraphics().getGL11();
int[] handle = new int[1];
gl.glGenBuffers( 1, handle, 0 );
vboHandle = handle[0];
gl.glBindBuffer( GL11.GL_ARRAY_BUFFER, vboHandle );
gl.glBufferData( GL11.GL_ARRAY_BUFFER, 3 * 6 * 4, vertices,
GL11.GL_STATIC_DRAW );
gl.glBindBuffer( GL11.GL_ARRAY_BUFFER, 0 );
}
In the setup method i create a FloatBuffer holding three vertices,
each having 3 coordinates (x,y,z) and 3 color components (r,g,b). Next
i generate a vertex buffer object to store the vertex data in. As you
can see the vertex data is interleaved, so everything goes into a
single VBO.
In the render method i set the viewport and clear the screen first.
Next i bind the VBO and set the vertex and color pointer to start at
the correct positions in the interleaved vertex data in the VBO. This
code works perfectly fine on the desktop.
On my Droid it crashes horribly in glDrawArrays with a segfault. I
triple-checked everything i did with the OpenGL ES specs and i came to
the conclusion that i'm not doing anything wrong (also, as i said it
works on the desktop). By accident i changed the number of color
components from 3 to 4 (r,g,b,a) and finally it worked.
This seems like a bug in the Motorola Droid PowerVR drivers. Can
anyone confirm this?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Vertex Array/Vertex Buffer Objects driver bug on Droid
Yes, indeed. I mixed that up with the desktop GL specs at
http://www.opengl.org/sdk/docs/man/xhtml/glColorPointer.xml. Now
that's embarassing :)
On 14 Mrz., 19:07, Lance Nanek lna...@gmail.com wrote:
Doesn't the spec say it has to be 4?
Fromhttp://www.khronos.org/opengles/sdk/1.1/docs/man/glColorPointer.xml
:
size
Specifies the number of components per color. Must
be 4. The initial value is 4.
Fromhttp://java.sun.com/javame/reference/apis/jsr239/javax/microedition/k...
:
size specifies the number of components per color, and must be 4.
On Mar 14, 12:47 pm, Mario Zechner badlogicga...@gmail.com wrote:
Hi,
just wanted to drop by to tell you about a nice little bug i just
encountered on my droid. Here's some sample code:
@Override
public void render(Application app)
{
GL11 gl = app.getGraphics().getGL11();
gl.glViewport( 0, 0, app.getGraphics().getWidth(),
app.getGraphics().getHeight() );
gl.glClearColor( 0.7f, 0.7f, 0.7f, 1 );
gl.glClear( GL11.GL_COLOR_BUFFER_BIT );
gl.glBindBuffer( GL11.GL_ARRAY_BUFFER, vboHandle );
gl.glEnableClientState( GL11.GL_VERTEX_ARRAY );
gl.glEnableClientState( GL11.GL_COLOR_ARRAY );
gl.glVertexPointer( 3, GL11.GL_FLOAT, 6 * 4, 0 );
gl.glColorPointer( 3, GL11.GL_FLOAT, 6 * 4, 3 * 4 );
gl.glDrawArrays( GL11.GL_TRIANGLES, 0, 3 );
}
@Override
public void setup(Application app)
{
ByteBuffer buffer = ByteBuffer.allocateDirect( 3 * 6 * 4 );
buffer.order(ByteOrder.nativeOrder());
FloatBuffer vertices = buffer.asFloatBuffer();
vertices.put( new float[] {
-0.5f, -0.5f, 0, 1, 0, 0,
0.5f, -0.5f, 0, 0, 1, 0,
0.0f, 0.5f, 0, 0, 0, 1,
});
vertices.flip();
GL11 gl = app.getGraphics().getGL11();
int[] handle = new int[1];
gl.glGenBuffers( 1, handle, 0 );
vboHandle = handle[0];
gl.glBindBuffer( GL11.GL_ARRAY_BUFFER, vboHandle );
gl.glBufferData( GL11.GL_ARRAY_BUFFER, 3 * 6 * 4, vertices,
GL11.GL_STATIC_DRAW );
gl.glBindBuffer( GL11.GL_ARRAY_BUFFER, 0 );
}
In the setup method i create a FloatBuffer holding three vertices,
each having 3 coordinates (x,y,z) and 3 color components (r,g,b). Next
i generate a vertex buffer object to store the vertex data in. As you
can see the vertex data is interleaved, so everything goes into a
single VBO.
In the render method i set the viewport and clear the screen first.
Next i bind the VBO and set the vertex and color pointer to start at
the correct positions in the interleaved vertex data in the VBO. This
code works perfectly fine on the desktop.
On my Droid it crashes horribly in glDrawArrays with a segfault. I
triple-checked everything i did with the OpenGL ES specs and i came to
the conclusion that i'm not doing anything wrong (also, as i said it
works on the desktop). By accident i changed the number of color
components from 3 to 4 (r,g,b,a) and finally it worked.
This seems like a bug in the Motorola Droid PowerVR drivers. Can
anyone confirm this?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL ES 2.0 on Eclair
Hey Michael, http://groups.google.com/group/android-developers/browse_thread/thread/064ebeaa6401# hope that helps :) Ciao, Mario On 13 Mrz., 05:17, MichaelEGR foun...@egrsoftware.com wrote: Also I just want to point out that the community driven LWJGL desktop Java binding has already added OpenGL 4.0 support immediately after announcement / specification release. This seriously is the level of support that Google and the Android team should extend to OpenGL ES 2.x at the very least for all developers. It's not like the hardware isn't available and released. It is available; give us what we need to succeed and make Google Android look good.. :) If the LWJGL community can add the latest OpenGL 4.0 support in a matter of hours to their binding. There is no reason Google can't support a developer binding/wrapper separate of the OS. There simply isn't a good excuse.. I'm afraid we're just trying to get it right is just a diversion of sorts. And no condemnation here.. I really like Android and have been working with GL since Android 1.0. Lets keep things rolling and show what Android and 2nd gen devices really can do... http://lwjgl.org/forum/index.php/topic,3245.0.html Support the developers otherwise Android is going to lag behind on next gen titles. Yes the NDK exists, but that primarily benefits iPhone devs who are porting OpenGL 2.x titles from the iPhone and / or commercial game companies and not the larger base of Java oriented Android devs. --Mike On Mar 12, 7:54 pm, MichaelEGR foun...@egrsoftware.com wrote: I'm glad others are concerned like I am on Java bindings to OpenGL ES 2.x. As things go it would be nice to hear from Google that they will -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL ES 2.0 on Eclair
Sorry for the double post, just had to add one more thing. I understand that many of your are a bit angry for there being no java bindings at this time. But from an architectural point of view i totally understand Romain's comment that they want to get it right. OpenGL ES 2.0 is not compatible to 1.x and the current bindings depend on the compatibility between 1.0 and 1.1. As an example: You have the GL10 interface which is the base GL instance that get's passed around to for example the Renderer interface. If you want to use 1.1 features you simply check wheter the GL10 instance is a GL11 instance and cast the hell out of it. That wouldn't work so well with 2.0. Say you create a GL20 interface having all the functions of OGL ES 2.0. You can't simply derive that from GL11 as the methods in there are no longer availble in 2.0 (for the most part). That would simply confuse the user and be a nice source for a lot of bugs. Similar problems occur with the GLSurfaceView a lot of us rely on to initialize OpenGL. An OpenGL ES 2.0 context is setup a bit different and you have to support a query mechanism before instantiating the GLSurfaceVIew to check wheter 2.0 is available. Lots and lots of interface design issues that have to be taken care of in a clean manner. The native bindings are not the problem, they really can be done in a couple of hours (see link above which took me about 4 hours yesterday). A clean interface design on the Java side is and i understand that this takes time. On 13 Mrz., 11:29, Mario Zechner badlogicga...@gmail.com wrote: Hey Michael, http://groups.google.com/group/android-developers/browse_thread/threa... hope that helps :) Ciao, Mario On 13 Mrz., 05:17, MichaelEGR foun...@egrsoftware.com wrote: Also I just want to point out that the community driven LWJGL desktop Java binding has already added OpenGL 4.0 support immediately after announcement / specification release. This seriously is the level of support that Google and the Android team should extend to OpenGL ES 2.x at the very least for all developers. It's not like the hardware isn't available and released. It is available; give us what we need to succeed and make Google Android look good.. :) If the LWJGL community can add the latest OpenGL 4.0 support in a matter of hours to their binding. There is no reason Google can't support a developer binding/wrapper separate of the OS. There simply isn't a good excuse.. I'm afraid we're just trying to get it right is just a diversion of sorts. And no condemnation here.. I really like Android and have been working with GL since Android 1.0. Lets keep things rolling and show what Android and 2nd gen devices really can do... http://lwjgl.org/forum/index.php/topic,3245.0.html Support the developers otherwise Android is going to lag behind on next gen titles. Yes the NDK exists, but that primarily benefits iPhone devs who are porting OpenGL 2.x titles from the iPhone and / or commercial game companies and not the larger base of Java oriented Android devs. --Mike On Mar 12, 7:54 pm, MichaelEGR foun...@egrsoftware.com wrote: I'm glad others are concerned like I am on Java bindings to OpenGL ES 2.x. As things go it would be nice to hear from Google that they will -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Java OpenGL ES 2.0 bindings project
Cool. Thanks for the flowers. The thing is apache 2 licensed so you
are free to do with it whatever you want. It's not rocket science
after all :). I'm not such a big fan of lwjgl but the more libraries
there are out there for android the better.
On 13 Mrz., 16:19, MichaelEGR foun...@egrsoftware.com wrote:
Figured I'd repost in this thread and include the variable time kill
frag test...
Awesome! Got it up and running here. You are my Android dev hero for
the month if not longer! Where I can I paypal you $50; I'd send more
if I could right now.. You also got a life long purchaser of all your
games on the market. Folks... Support Mario and buy his games! I like
your Newton game by the way! :)
I knew this was a trivial, but perhaps tedious exercise, so thanks for
stepping up _and_ sharing your work / effort.
I'm also rabble rousing now on the LWJGL community forums to get an ES
version of LWJGL ported to Android. That would be absolutely fantastic
as Slick2D plus many other LWJGL games could make it to Android sooner
rather than later with few changes from their desktop counterparts.
I'm not sure what license you may want to attribute to your work, but
perhaps MIT or a completely open license that doesn't conflict with
anything.
If you need any further assistance I have a bunch of Android devices I
can test on, but things work fine on the Droid / N1!
Again you rock!!! This is fantastic..
The following is a slightly modified test that has a variable time
kill fragment shader:
-
package com.badlogic.gdx;
import java.nio.ByteBuffer;
import java.nio.ByteOrder;
import java.nio.FloatBuffer;
import java.nio.IntBuffer;
import javax.microedition.khronos.egl.EGL10;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.egl.EGLContext;
import javax.microedition.khronos.egl.EGLDisplay;
import javax.microedition.khronos.opengles.GL10;
import android.view.Menu;
import android.view.MenuItem;
import com.badlogic.gdx.backends.android.AndroidGL20;
import com.badlogic.gdx.backends.android.surfaceview.GLSurfaceView;
import com.badlogic.gdx.backends.android.surfaceview.GLSurfaceView20;
import
com.badlogic.gdx.backends.android.surfaceview.GLSurfaceView.Renderer;
import com.badlogic.gdx.graphics.GL20;
import android.app.Activity;
import android.content.Context;
import android.os.Bundle;
import android.util.Log;
public class GL2Test extends Activity
{
GLSurfaceView view;
int appCutoff1, appCutoff2;
long startTime;
int equationIndex = 0;
/**
* Called when the activity is first created.
*/
�...@override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
if (checkGL20Support(this))
view = new GLSurfaceView20(this);
else
view = new GLSurfaceView(this);
view.setRenderer(new TestRenderer());
setContentView(view);
}
public boolean onCreateOptionsMenu(Menu menu)
{
Menu menuEquations = menu.addSubMenu(10, 10, 0, Kill Frag
Equations (t == time));
menuEquations.add(10, 0, 0, x: .5 y: cos(t));
menuEquations.add(10, 1, 1, x: sin(t) y: .2);
menuEquations.add(10, 2, 2, x: sin(t) y: cos(t));
menuEquations.add(10, 3, 3, x: sin(t)/2 y: cos(t)/2);
menuEquations.add(10, 4, 4, x: .5*sin(3*t+4) y: .5*sin(t));
menuEquations.add(10, 5, 5, all killed; xy: -1);
menuEquations.add(10, 6, 6, none killed; xy: 1);
return true;
}
public boolean onOptionsItemSelected(MenuItem item)
{
if (item.getItemId() = 6)
equationIndex = item.getItemId();
return true;
}
protected void onPause()
{
super.onPause();
view.onPause();
}
protected void onResume()
{
super.onResume();
view.onResume();
}
private boolean checkGL20Support(Context context)
{
EGL10 egl = (EGL10) EGLContext.getEGL();
EGLDisplay display =
egl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
int[] version = new int[2];
egl.eglInitialize(display, version);
int EGL_OPENGL_ES2_BIT = 4;
int[] configAttribs =
{
EGL10.EGL_RED_SIZE, 4,
EGL10.EGL_GREEN_SIZE, 4,
EGL10.EGL_BLUE_SIZE, 4,
EGL10.EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,
EGL10.EGL_NONE
};
EGLConfig[] configs = new EGLConfig[10];
int[] num_config = new int[1];
egl.eglChooseConfig(display, configAttribs, configs, 10,
num_config);
egl.eglTerminate(display);
return num_config[0] 0;
}
class TestRenderer implements Renderer
{
AndroidGL20 gl2 = new AndroidGL20();
FloatBuffer vertices;
int program;
int viewportWidth, viewportHeight;
private float calculate(int
[android-developers] Java OpenGL ES 2.0 bindings project
Hi there,
i started a small project over at google code that provides you with
bindings for OpenGL ES 2.0 in Java. I started just a couple of hours
ago so it's not finished yet. The project includes the original
GLSurfaceView plus all the helper classes from the latest Eclair build
as well as a modified version of GLJNIView from the NDK samples which
is now a fully functional GLSurfaceView subclass called
GLSurfaceView20.
OpenGL ES 1.x and 2.0 are exclusive so you have to first check wheter
GL ES 2.0 is supported. You can check this via the following method:
private boolean checkGL20Support( Context context )
{
EGL10 egl = (EGL10) EGLContext.getEGL();
EGLDisplay display =
egl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
int[] version = new int[2];
egl.eglInitialize(display, version);
int EGL_OPENGL_ES2_BIT = 4;
int[] configAttribs =
{
EGL10.EGL_RED_SIZE, 4,
EGL10.EGL_GREEN_SIZE, 4,
EGL10.EGL_BLUE_SIZE, 4,
EGL10.EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,
EGL10.EGL_NONE
};
EGLConfig[] configs = new EGLConfig[10];
int[] num_config = new int[1];
egl.eglChooseConfig(display, configAttribs, configs, 10,
num_config);
egl.eglTerminate(display);
return num_config[0] 0;
}
Based on the result you then instantiate either a GLSurfaceView or a
GLSurfaceView20. In the later case you should refrain from using GL10/
GL11 instances, most of the methods won't work with OpenGL ES 2.0.
Instead you simply instantiate a class called AndroidGL20 which offers
you the complete OpenGL ES 2.0 API.
The project is in its infancy meaning that a couple of the native
binding methods are stubs at the moment. I'm trying to fill all of
them up over the weekend so we have a working wrapper on monday.
This is a lot of work, i was able to generate the stubs automatically
but filling them in has to be done manually. If anyone can spend some
time on this with me contact me via badlogicgames at gmail.com.
You can find the complete source at http://code.google.com/p/gl2-android/.
The current source tree is not all that clean, i simply imported the
complete project to SVN. In order to build it you have to create an
Application.mk in a folder in the app/ directory of your NDK
installation. The Application.mk has to look like this
APP_PROJECT_PATH := /cygdrive/c/Users/mzechner/private-workspace/gl2-
android
APP_MODULES := libandroidgl20
Simply substitute the APP_PROJECT_PATH with what you have and you are
ready to build. Note that i haven't optimized the Android.mk in the
jni/ directory of the project yet, later on everything will compile to
arm instead of thumb and some optimization flags will also be set.
I hope somebody is willing to help out a little. I'll report back any
progress on this here as well as on my blog at http://www.badlogicgames.com.
Ciao,
Mario
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Java OpenGL ES 2.0 bindings project
);
gl2.glAttachShader( program, fragmentShader );
gl2.glBindAttribLocation( program, 0, vPosition );
gl2.glLinkProgram( program );
ByteBuffer tmp = ByteBuffer.allocateDirect(4);
tmp.order(ByteOrder.nativeOrder());
IntBuffer intbuf = tmp.asIntBuffer();
gl2.glGetProgramiv( program, GL20.GL_LINK_STATUS,
intbuf );
int linked = intbuf.get(0);
if( linked == 0 )
{
gl2.glGetProgramiv( program,
GL20.GL_INFO_LOG_LENGTH, intbuf );
int infoLogLength = intbuf.get(0);
if( infoLogLength 1 )
{
Log.d( GL2, couldn't link program:
+
gl2.glGetProgramInfoLog( program ) );
}
throw new RuntimeException( Creating program
didn't work );
}
float vVertices[] = { 0.0f, 0.5f, 0.0f,
-0.5f, -0.5f, 0.0f,
0.5f, -0.5f, 0.0f };
tmp = ByteBuffer.allocateDirect( 3 * 3 * 4 );
tmp.order(ByteOrder.nativeOrder());
vertices = tmp.asFloatBuffer();
vertices.put( vVertices );
vertices.position(0);
}
private int loadShader( int type, String source )
{
ByteBuffer tmp = ByteBuffer.allocateDirect(4);
tmp.order(ByteOrder.nativeOrder());
IntBuffer intbuf = tmp.asIntBuffer();
int shader = gl2.glCreateShader( type );
if( shader == 0 )
throw new RuntimeException( creating the
shader didn't work );
gl2.glShaderSource( shader, source );
gl2.glCompileShader( shader );
gl2.glGetShaderiv( shader, GL20.GL_COMPILE_STATUS,
intbuf );
int compiled = intbuf.get(0);
if( compiled == 0 )
{
gl2.glGetShaderiv( shader,
GL20.GL_INFO_LOG_LENGTH, intbuf );
int infoLogLength = intbuf.get(0);
if( infoLogLength 1 )
{
String infoLog =
gl2.glGetShaderInfoLog( shader );
Log.d( GL2, shader info: + infoLog
);
}
throw new RuntimeException( creating the
shader didn't work );
}
return shader;
}
}
}
This is more or less the hello triangle example from the purple book.
Here's a couple of things that i changed:
- glGetActiveAttrib and glGetActiveUniform return a string which is
the name of the attribute/uniform.
- glGetProgramLogInfo and glGetShaderLogInfo also directly return a
string. the log is limited to 10k characters internally
- glShaderSource only takes the shader handle and a single java
string.
- glGetShaderSource is not implemented, i will add that some time soon
- glGetVertexAttribPointerv is not implemented and i don't plan on
implementing it
Everything else is implemented 100% to the specification. I actually
took the gl2.h file from the khronos site to generate the interfaces
and stubs.
You can find the full source code at http://code.google.com/p/gl2-android/,
check it out via subversion from http://gl2-android.googlecode.com/svn/trunk/.
You'll get an Android eclipse project which a pre-build shared
library. If you want to rebuild the native code you have to add an
Application.mk to your NDK apps/ folder somewhere. The eclipse project
is set to target 2.0, however the library works fine with 1.5 devices
too as long as you don't try to access OpenGL ES 2.0 functionality.
Simply use the check for OpenGL ES 2.0 from above to decide which
render path to go.
And for your convenience i also packaged the shared library as well as
the jar file with the Java classes. You can find that at
http://gl2-android.googlecode.com/files/androidgl2-0.1.zip
Now write some awesome shaders!
On 12 Mrz., 15:56, Mario Zechner badlogicga...@gmail.com wrote:
Hi there,
i started a small project over at google code that provides you with
bindings for OpenGL ES 2.0 in Java. I started just a couple of hours
ago so it's not finished yet. The project includes the original
GLSurfaceView plus all the helper classes from the latest Eclair build
as well as a modified version of GLJNIView from the NDK
[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?
Extremely well written post Bob, thanks a lot for that. I can totally agree to your statements and can confirm that the bottleneck in games is not the Dalvik VM and therefor Java for almost all parts of a game. What kills performance at the moment is way down in the chain at the hardware level. Fill-rate limits are the biggest issue we game developers have to face at the moment. Everything else does not contribute much, implementing your whole game in C does not solve that problem. And i speak from personal experience in this case :) On a side note: ExDeus was not developed with the NDK. The game is actually a port of an IPhone version so it was developed with the IPhone tools for the most part. Those feature a native debugger. The Android version is probably only different in setting up the gl surface and processing input. On 11 Mrz., 17:01, Bob Kerns r...@acm.org wrote: This comment is perhaps a bit off your main topic, and I don't mean it to derail your efforts or to criticize. But I have a bit of a problem with your statement Java is just too slow..., taken as a general statement. Perhaps you have benchmark data showing specific performance problems, and found it so; I'm not disputing that. However, the performance landscape is a lot more complex than this would suggest, if taken beyond your context. In particular, there are at least 4 performance areas to consider here: 1) Java performance -- which is actually generally quite good in the desktop/server world; I've not done any Android benchmarking. 2) JNI performance -- there's added cost per switch to native code; sometimes it's better to do more work in Java to avoid this overhead, or to batch up work and do more per JNI call. 3) OpenGL library/driver performance. This is both the stuff that's done in software in preparing for the GPU pipeline, and how effectively it makes use of the hardware, and failures to use capabilities that exist in the hardware. 4) The GPU hardware itself Judging from the reports I see here (and not personal experience on this platform as yet), a lot of the performance problems we see are further down this chain. Better graphics hardware and better drivers push the bottlenecks up the chain; faster main processors and Java VM improvements push them down. But where you encounter the bottleneck will always depend on just what the application is doing. Textures are a big part of that, as is managing levels of detail so you don't waste time rendering detail that isn't really noticeable. There are a lot of ways to use OpenGL poorly. And there are a lot of ways to use it well, but push the limits in the search for image quality. Pushing things down in to C++ is just going to harm developers, if it's not actually where the bottleneck is. As Mario says, you have to choose carefully. Do you move your physics engine into C++ -- or just the matrix multiplications? Or perhaps just significant components, like collision detection and the timestep integrations? If you push stuff down to C++, how do you allow for customization, without incurring the JNI callback overhead? Part of what I'm getting at is that because apps are different, the optimal tradeoff will differ. I'm not sure that Google providing a framework would be the way to go. Obviously, each developer implementing their own isn't a good thing either. I think shared community efforts, or commercial libraries make a lot more sense (though there could be an official library as one of these options). This is especially true of physics engines. But there is such wide variation in what demands an application makes of 3D rendering that blanket statements like Java is too slow conceal the issues. So I would council against blindly pushing stuff down to native code based on such broad statements, but rather doing so conservatively, based on realistic benchmarks. On Mar 10, 2:35 am, Piotr piotr.zag...@gmail.com wrote: Both these frameworks are interesting, but as I mentioned before; it could be better, to create low-level, native NDK game framework library. Java is just too slow to handle thousands opengl calls per second for any game more complex than falling bricks or sth. Such framework could load game elements (maps, tiles, sprites, bkgs, sounds), giving developer control interface set to call high level methods like setSpriteSpeed, setBackgroundScroll, manageSpritePhysics, etc.. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL ES 2.0 on Eclair
I'd also be interested in the java bindings. A not so precise time estimate would suffice so that i can decide wheter i write my own bindings or not. On 10 Mrz., 16:17, scott19_68 sw.cop...@gmail.com wrote: So, with GL ES2.0now present in the NDK r3, how much longer until the Java bindings are present? Any idea what form the bindings will take? JSR-297 (M3D2.0)? Custom extensions to JSR-239? If I could offer my $0.02... please DO NOT adopt the full M3D2.0spec - the history ofOpenGLhas plenty of scene graphs littered on the side of the road (Performer, Cosmos, OpenGL++, Farenheit, ...) and I think this will eventually be another one. -Scott On Feb 9, 9:30 pm, David Turner di...@android.com wrote: OpenGLES2.0headers and libraries are not available in the NDK yet. They are coming. Access from Java is also planned. The Android software renderer doesn't support GL ES2.0, neither does the emulator. I can't give any ETA for this, sorry. On Tue, Feb 9, 2010 at 12:12 AM, David Anders david.anders0...@gmail.comwrote: Hi, I also would like to bump this topic. - I guess thatOpenGLES2.0API will be defined in Java layer as android.opengl.GLES20 class. - We have been able to useOpenGLES2.0API through hardware bindings using JNI. However in my understanding, it is impossible to useOpenGLES2.0API with software rendering on emulator. When does Android plan to support software rendering forOpenGLES2.0API? Regards, /David On 1月6日, 午前10:08, r2d2Proton r2d2pro...@live.com wrote: I would like to bump this. . . I was thinking the same thing - use the NDK to gain access to the2.0 functions. I imagine that theOpenGLES2.0functions are exposed in Imagination Technologies shared object file. Games should be considered an NDK level application. Wasn't anybody watching Microsoft when they tried this? Remember Direct-Draw? On Dec 28 2009, 11:10 am, rollbak roll...@gmail.com wrote: So, that means that with NDK i can? Can you explain this further please? Thanks, Lucas On Dec 28, 3:09 pm, Romain Guy romain...@android.com wrote: Java apps cannot directly accessOpenGLES2.0 APIs at the moment. On Thu, Dec 24, 2009 at 7:32 PM, Lawrencelee leelawrenc...@gmail.com wrote: Eclair has supportedOpenGLES2.0. But I can not find related JNI wrapper forOpenGLESAPI. How a Java application useOpenGLES2.0 functions? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?
Very cool! didn't know about that. I try to get in contact with the author. On 10 Mrz., 02:31, Lance Nanek lna...@gmail.com wrote: It allows you to develop your games mostly on the desktop and deploying it to your Android device Neat project. Have you seen this one for the same purpose?http://code.google.com/p/skorpios/ Might be neat to cooperate or share techniques or something. On Mar 9, 7:11 pm, Mario Zechner badlogicga...@gmail.com wrote: While it's not nearly as full featured as XNA i started working on something similar to XNA. It allows you to develop your games mostly on the desktop and deploying it to your Android device with just a couple of lines that instantiate a special Activity subclass. It's based on OpenGL and allows developing 2D and 3D games. I just finished writting all the java doc for it and am constantly adding new features to it. It's called libgdx and can be found athttp://code.google.com/p/libgdx/. I also started blogging about it lately and will continue so adding sample codes for specific problems. You can find that blog athttp://www.badlogicgames.com. An introduction to it can be found athttp://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A series of small tutorials wil follow this week and next week. The whole thing is LGPL so that there's no problem including it in commercial apps. It's far from being perfect of course but i think the base functionality and ease of use can kill some of the burden a fresh android game developer has to overcome. I'm open for suggestions and features you want to see in there! On 9 Mrz., 22:35, Piotr piotr.zag...@gmail.com wrote: Hello, At my daily job I work as WinMo C++ developer, so I had enough time to become hater of that platform ;) But now, M$ is coming with new Windows Phone. As I suspected, they will abandon awful Win32/MFC native coding and all applications, will be now managed - run in CLR sandboxes on top of 15 years old Win32 kernel. Main coding language will be C# with .NET framework - Java rival. WinMo always was terrible phone OS, but now, more interesting is, that Windows Phone will support XNA framework: http://www.youtube.com/watch?v=LQv_3fwopo8 This is full gaming framework with C# interfaces and support for 2D/3D graphics, animation, sprites, net play, game sound, controllers, etc.. XNA greatly improves creating games, because it gives a developer an ready to use game abstraction layer. To the point; Android needs game framework, like XNA. Maybe it should be written as NDK library, ready to link with your own application. This library could load, manage and draw sprites, backgrounds, make simple physics, etc.. Why ? To create games faster, easier. At this time, you must be very skilled to create simple platformer with 2 bkgs and 5 sprites. Our devices have even 1GHz CPU's and animation can be STILL too slow ! I'm tired of the same logical bricks/ball/falling diamonds games over and over. What do you think ? Is there any chance, that Google will work on something like that ? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?
I concur with this statement. I did a lot of benchmarking and the JNI bridge crossing of OpenGL methods is not a problem, I can happily render hundreds of objects. Also, for performance hungry things like MP3 decoding (to get PCM data which is not possible at the moment with the mediaframework), physics and so on there's a native library in the background of libgdx which does just that. The physics library is something i'm currently implementing on top of bullet. These native components have a JNI bridge as you suggested. I however carefully chose what's going to be included in the native library part of libgdx to reduce the pain of coding C++. What also speaks against a pure NDK solution is the missing debugging features which slows down development immenseley. On 10 Mrz., 11:35, Piotr piotr.zag...@gmail.com wrote: Both these frameworks are interesting, but as I mentioned before; it could be better, to create low-level, native NDK game framework library. Java is just too slow to handle thousands opengl calls per second for any game more complex than falling bricks or sth. Such framework could load game elements (maps, tiles, sprites, bkgs, sounds), giving developer control interface set to call high level methods like setSpriteSpeed, setBackgroundScroll, manageSpritePhysics, etc.. On 10 Mar, 11:00, Mario Zechner badlogicga...@gmail.com wrote: Very cool! didn't know about that. I try to get in contact with the author. On 10 Mrz., 02:31, Lance Nanek lna...@gmail.com wrote: It allows you to develop your games mostly on the desktop and deploying it to your Android device Neat project. Have you seen this one for the same purpose?http://code.google.com/p/skorpios/ Might be neat to cooperate or share techniques or something. On Mar 9, 7:11 pm, Mario Zechner badlogicga...@gmail.com wrote: While it's not nearly as full featured as XNA i started working on something similar to XNA. It allows you to develop your games mostly on the desktop and deploying it to your Android device with just a couple of lines that instantiate a special Activity subclass. It's based on OpenGL and allows developing 2D and 3D games. I just finished writting all the java doc for it and am constantly adding new features to it. It's called libgdx and can be found athttp://code.google.com/p/libgdx/. I also started blogging about it lately and will continue so adding sample codes for specific problems. You can find that blog athttp://www.badlogicgames.com. An introduction to it can be found athttp://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A series of small tutorials wil follow this week and next week. The whole thing is LGPL so that there's no problem including it in commercial apps. It's far from being perfect of course but i think the base functionality and ease of use can kill some of the burden a fresh android game developer has to overcome. I'm open for suggestions and features you want to see in there! On 9 Mrz., 22:35, Piotr piotr.zag...@gmail.com wrote: Hello, At my daily job I work as WinMo C++ developer, so I had enough time to become hater of that platform ;) But now, M$ is coming with new Windows Phone. As I suspected, they will abandon awful Win32/MFC native coding and all applications, will be now managed - run in CLR sandboxes on top of 15 years old Win32 kernel. Main coding language will be C# with .NET framework - Java rival. WinMo always was terrible phone OS, but now, more interesting is, that Windows Phone will support XNA framework: http://www.youtube.com/watch?v=LQv_3fwopo8 This is full gaming framework with C# interfaces and support for 2D/3D graphics, animation, sprites, net play, game sound, controllers, etc.. XNA greatly improves creating games, because it gives a developer an ready to use game abstraction layer. To the point; Android needs game framework, like XNA. Maybe it should be written as NDK library, ready to link with your own application. This library could load, manage and draw sprites, backgrounds, make simple physics, etc.. Why ? To create games faster, easier. At this time, you must be very skilled to create simple platformer with 2 bkgs and 5 sprites. Our devices have even 1GHz CPU's and animation can be STILL too slow ! I'm tired of the same logical bricks/ball/falling diamonds games over and over. What do you think ? Is there any chance, that Google will work on something like that ? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group
[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?
While it's not nearly as full featured as XNA i started working on something similar to XNA. It allows you to develop your games mostly on the desktop and deploying it to your Android device with just a couple of lines that instantiate a special Activity subclass. It's based on OpenGL and allows developing 2D and 3D games. I just finished writting all the java doc for it and am constantly adding new features to it. It's called libgdx and can be found at http://code.google.com/p/libgdx/. I also started blogging about it lately and will continue so adding sample codes for specific problems. You can find that blog at http://www.badlogicgames.com. An introduction to it can be found at http://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A series of small tutorials wil follow this week and next week. The whole thing is LGPL so that there's no problem including it in commercial apps. It's far from being perfect of course but i think the base functionality and ease of use can kill some of the burden a fresh android game developer has to overcome. I'm open for suggestions and features you want to see in there! On 9 Mrz., 22:35, Piotr piotr.zag...@gmail.com wrote: Hello, At my daily job I work as WinMo C++ developer, so I had enough time to become hater of that platform ;) But now, M$ is coming with new Windows Phone. As I suspected, they will abandon awful Win32/MFC native coding and all applications, will be now managed - run in CLR sandboxes on top of 15 years old Win32 kernel. Main coding language will be C# with .NET framework - Java rival. WinMo always was terrible phone OS, but now, more interesting is, that Windows Phone will support XNA framework: http://www.youtube.com/watch?v=LQv_3fwopo8 This is full gaming framework with C# interfaces and support for 2D/3D graphics, animation, sprites, net play, game sound, controllers, etc.. XNA greatly improves creating games, because it gives a developer an ready to use game abstraction layer. To the point; Android needs game framework, like XNA. Maybe it should be written as NDK library, ready to link with your own application. This library could load, manage and draw sprites, backgrounds, make simple physics, etc.. Why ? To create games faster, easier. At this time, you must be very skilled to create simple platformer with 2 bkgs and 5 sprites. Our devices have even 1GHz CPU's and animation can be STILL too slow ! I'm tired of the same logical bricks/ball/falling diamonds games over and over. What do you think ? Is there any chance, that Google will work on something like that ? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: ADC3?
I'd be interested in such knowledge too :) On 9 Mrz., 19:15, Robert Green rbgrn@gmail.com wrote: I just gotta ask... Does anyone have any knowledge of an upcoming ADC3? :) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to parse audio input from the mic
For this you want to use the AudioRecord class (http:// developer.android.com/reference/android/media/AudioRecord.html). The read methods will return you pure PCM samples in either 8-bit or 16- bit mono or stereo depending on what you set in the constructor of the AudioRecord. The 16-bi PCM samples are signed, no idea about the 8-bit samples but they probably are unsigned. This means that the amplitude in 8-bit can range from 0 to 255 and in 16-bit from -32k to +32k. I'd go with 16-bit in most cases. hth, Mario On 8 Mrz., 22:53, theMailman ksmithanimat...@gmail.com wrote: Does anyone know how to get usefull information from audio that comes from the mic? I would like to parse the audio bit stream to gauge how large or dmall the audio wave is any help would be great. Thanks -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: New Android SDK Tools, Eclipse plug-in and NDK
Awesome! OpenGL ES 2.0 support in the NDK! Any eta for the Java bindings? On 9 Mrz., 00:27, Xavier Ducrohet x...@android.com wrote: Hello everyone, As you may have seen on our blog this morning, we have released a new version of the NDK (revision 3). Release notes are available athttp://developer.android.com/sdk/ndk/index.html We have also released revision 5 of the Android SDK Tools. This is available through the SDK updater. Release notes:http://developer.android.com/sdk/tools-notes.html To go with these new tools, we have released a new version of the Eclipse plug-in (0.9.6). Release notes:http://developer.android.com/sdk/eclipse-adt.html The new tools and new plug-in are required to access the SDK repository. If you are using rev 4 you can update the tools through the SDK updater normally before seeing the rest of the repository. If you have a prior revision of the tools (rev 3 or earlier), please download the main package fromhttp://developer.android.com/sdk/index.html Xav -- Xavier Ducrohet Android SDK Tech Lead Google Inc. Please do not send me questions directly. Thanks! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Device Seeding Program for Top Android Market Developers
I just received the confirmation e-mail. Seems like my new shiny Nexus One is on its way! Thank you google! Here's the full e-mail (minus my personal data) Dear Mario, We’ve received your information for the Android Market Device Seeding Program and have successfully validated the Google Order Number from your developer account. Your information will now be sent to our shipping partner for order processing. Just to confirm, the information we received from you was: Badlogic Games XXX my personal data XXX If you need to make any changes to your information above, please contact us at android-market-seed...@google.com as soon as possible. Otherwise, you should receive your phone in 2-4 weeks! On behalf of the Android team, Thanks, and happy coding! On 6 Mrz., 02:44, Seni Sangrujee sangru...@gmail.com wrote: On Mar 5, 2:52 pm, bryan browne.al...@gmail.com wrote: Did anyone else fill out the form with their personal email address Yeah, I did the same thing. I figured that my personal email address was associated with my market order id that I used to purchase the dev fee. But then later I noticed that the Seeding email was sent to my generic publisher address. We'll have to check in and commiserate with each other in a month if everyone is receiving their phones but us. :) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Multitouch seems badly broken on Nexus One 2.1-update1
It's not so much an issue of gestures that may be impossible to recognize on certain screens but more that the API exposes functionality that is broken on all screens at the moment. Especially the coordinate flipping/confusion is something that can't be solved according to Dianne. And it is exactly this functionality (just tracking two fingers that are not close to each other on the screen) that is needed by us game developers to create more elaborate input schemes. It's kind of sad really :/ On 15 Feb., 10:22, Sean Hodges seanhodge...@googlemail.com wrote: The Nexus One uses the Synaptics ClearPad 2000 series:http://www.synaptics.com/about/press/press-releases/synaptics-clearpa... According to this reference:http://www.synaptics.com/solutions/products/clearpad#benefits-2000 this model has support for a maximum of 2 simultaneous touches, the 3000 series supports up to 10. The Synaptics site also describes some of the gestures that are possible with its products:http://www.synaptics.com/solutions/technology/gestures/touchpad. The touchscreen technology is very diverse across handsets, some of the more complex gestures are going to be limited or impossible on certain devices (e.g. ones that have obtrusive dead-zones or singletouchonly). For this reason, I don't believe the interface can be normalised to be compatible with all devices, primarily because you will cripple the devices with the superior functionality (we'd losemulti-touchfor a start, to support handsets like the HTC Magic / Dream). I think you just have to be conservative about the complexity of the gestures you require in your app, and provide alternative methods of control for the devices that can't support those gestures. The Dolphin Browser is a good example of this in action. On Sun, Feb 14, 2010 at 7:14 PM, Dianne Hackborn hack...@android.com wrote: G1, myTouch, and Passion use a Synaptics screen. Droid uses one from another company (I can't recall). Even for a particular company, there are a wide variety of screens you will encounter. For example here is what I found for Synaptics: http://www.synaptics.com/solutions/products/clearpad On Sat, Feb 13, 2010 at 9:11 PM, Kevin Duffey andjar...@gmail.com wrote: So are they all using the same company for the screen? On Sat, Feb 13, 2010 at 5:10 PM, Lance Nanek lna...@gmail.com wrote: A more capable multitouch screen probably costs more. If that is the case, it isn't really surprising that multiple manufacturers would go with a cheaper, less capable one. On Feb 13, 6:51 pm, Kevin Duffey andjar...@gmail.com wrote: So Robert.. is this a platform issue in your mind.. being that it happens on all android devices currently regardless of manufacturer? Or is it a driver issue for each hand set and just oddly happens to be coincidental that various manufacturers have the exact same issue withmulti-touch? I am sure what Diane says is accurate... but yet it seems odd that different manufacturers have the same problem. On a slightly different note.. what is the stance of the Android platform team as a whole towards game developers? By this I mean, if this is indeed an issue on different manufacturer's handsets.. is it important enough that game developers, which for sure will be a large segment of popularity for android as it is on iPhone.. can get this escalated enough to get some platform/driver developers looking into it and if possible, tap the community (such as Robert) to help, so we can figure out exactly what is going on? It just seems too crucial of an issue to overlook being that it directly makes it impossible as of now for game developers to really utilize multitouch. Robert (et all)... an app I want to eventually get around doing is a drum machine app.. with multiple drum pads. On the iPhone, an app called BeatMaker allows for 5 pads at once to be touched. Would this issue possibly make an app like this not work? I don't even know if Android can handle more than two touches at once.. but there are plenty of apps out there that will use more than two simultaneous touches at once. On Fri, Feb 12, 2010 at 4:20 PM, Robert Green rbgrn@gmail.com wrote: Ok if you guys want to see what I'm talking about, check out the app I just published called Multitouch Visible Test. Play around with that and you'll see the problems. If you're interested in developing a multitouch app, check that out first so that you know the limitations of the data you'll be working with. On Feb 12, 4:55 pm, Robert Green rbgrn@gmail.com wrote: Luke's code cleans up some basic stuff like gestures involving pinching but it can not fix the two independent point problem. Currently, even with his code which filters out some noise, it is impossible to have a reliable control system involving two
[android-developers] Re: Motorola Droid (possible android) multi-touch bug and how to reproduce
I haven't issues a bug report yet as i was not sure that my implementation is correct. I have some sample code lying around that could help reproduce the bug, however it needs some tries before it works and is probably hard to debug. On 6 Feb., 04:57, Peter Kirn peterk...@gmail.com wrote: Did anyone ever fill out a bug report for this? I can confirm it as well. I think it can safely be described as a defect. The most significant issue is that of the conflicting flag on those touch up events. I can confirm that the video is exactly accurate. So, the next questions -- How should a developer even verify whether the hardware supportsmultitouchaccurately, if it returns the second point when it's not accurate? (I've seen at least one app do a calibration test to verify it's not working.) Is there any workaround to try to filter this out? Has anyone heard status on this issue from, say, Motorola or Google engineers? The threads I saw seem to suggest people are unaware of the issue (even though it's a fundamental hardware-firmware issue), meaning we'd better get on that bug report. On the other hand, it really becomes a device bug, not a platform bug. Peter On Jan 29, 6:03 pm, Mario Zechner badlogicga...@gmail.com wrote: Thanks, i stubled upon your blog today and already found a lot of usefullcodethere. I guess that's how you arrived at this post :) It's kind of a sad situation really. I'd love to use android to it's full potential but it seems that some things aren't just where they should be yet. Never the less, android is the way to go! On 29 Jan., 20:46, luke luke.hu...@gmail.com wrote: All these bugs (and several more you may not have discovered yet, e.g. event noise on touch up/down) are covered in excruciating detail on my blog,http://lukehutch.wordpress.com/android-stuff. The main posts you will want to read are: http://lukehutch.wordpress.com/2009/01/10/full-working-multitouch-on-.. These are hardware / firmware limitations and it is actually impossible to overcome them on current hardware/firmware. Some could possibly be fixed with a firmware update from synaptics though this probably won't happen (e.g. partially raising a touch point up loses one of X or Y but not the other) and some of the bugs will not be fixed without new hardware (the fact it's a 2x1D device and not a 2D device). -- Luke Hutchison On Jan 28, 7:06 pm, Mario Zechner badlogicga...@gmail.com wrote: It seems Toon Warz, another game usingmultitouchalso has some issues on N1 and Droid. Can others confirm the problem with thecodeposted above? Did anyone arrive at a solution? This is a pretty bad situation for game developers as nothing freaks users more out than bad controls. I think thecodeabove is even a democodefrom the android framework so i find it kinda strange that the problem didn't pop up during their testing phase. I also couldn't find any information on the logcat output telling me about the drop of a bad pointer. On 23 Jan., 19:39, mzechner mario.zech...@gmail.com wrote: I can confirm this problem using the samplecodeabove, my owncode and playing multipong. I created two videos, one showing the problem for the samplecodeabove and one showing it in multipong. http://www.youtube.com/watch?v=865cd2Ui0Co(samplecode)http://www.yout...) Each time thepointergo crazy LogCat displays messages tagged InputDevice saying droppingbadpointer#0, in all 3 cases (sample code, mycode, multipong). ThepointerIds get mixed up, and as can be seen in the video for the samplecodeabove the x coordinate for the secondpointeris wrong. I have a suspicion that this might be a driver related bug. In any way it makes writting games withmultitouch impossible. The bug can be reproduced by quickly tapping around and then settle with 2 digits on the screen. It does not work always but often enough to be annoying in a game with a dual analog stick setup on screen (like in mycode). I hope this gets fixed asap. If more people can confirm this i file a bug athttp://b.google.com/ On 15 Jan., 21:32, Mirmathrax mirmath...@gmail.com wrote: here is in the original text from the post, this explains how to make the bug occur: 1) Touch screen with finger 1 and start doodling 2) Without removing finger 1, touch screen with finger 2 and start doodling 3) Remove finger 1 from the screen (without removing finger 2) 4) Replace finger 1 on the screen and start doodling again (never remove finger 2) 5) Voila, you will see the bug. The drawn lines for finger 1 will suddeny connect to finger 2. This is because there is a bug when the first finger is placed back down again, the event only has points for the wrong finger! Even though finger 1
