Neon Puck 3D - Released

[tberthel]

I release my latest 3D Android game called Neon Puck 3D.

Free Limited Version:

https://market.android.com/details?id=org.allbinary.game.neonpuck



Paid Version:

https://market.android.com/details?id=org.allbinary.paid.game.neonpuck

[princec]

Nice visual style to that. Reminds me of Tokyo at night. Not that I've been, but I've seen photos.

Cas

[teletubo]

The game itself looks good, but damn your UI still hurts my eyes. I think you should spend a weekend effort to make them look good, this will make your game look much much better overall.

Games published by our own members! Check 'em out!

[tberthel]

The game itself looks good, but damn your UI still hurts my eyes. I think you should spend a weekend effort to make them look good, this will make your game look much much better overall.

Yes, I know. 

1.  I need to convince my artist to make me some image buttons.
2.  I need to use a True Type Font.

That would clear up most of the UI issues.

[EgonOlsen]

The UI is unusable, at least on a 800*480 display like on the Nexus S. It's almost impossible to hit any of the checkboxes in the options dialog. The game itself runs pretty bad, because it obviously uses PixelFlinger instead of the GPU for whatever reason (most likely a flaw in your gl init configuration). In addition, it logs a 1284 error which might be releated to that.

[tberthel]

You don't/can't touch the options.  You must use touch gestures instead.  Slide down and up to change selected option, and slide left or right to change the option.

Older android devices don't support GPU acceleration through the Java OpenGL API and has nothing to do with the configuration.  However android 3.0 on up does.

My devour runs it fast and it is slow compared to most android devices.  So you must have a really slow device or you had apps in the background running.

[EgonOlsen]

Older android devices don't support GPU acceleration through the Java OpenGL API and has nothing to do with the configuration.  However android 3.0 on up does.

Even the G1 supports hardware acceleration via the VM. If the device uses PixelFlinger instead, it's usually caused by your configuration asking for a feature that the GPU doesn't provide. Apart from that, the Nexus S is no "older android device"...

[tberthel]

Older android devices don't support GPU acceleration through the Java OpenGL API and has nothing to do with the configuration.  However android 3.0 on up does.

Even the G1 supports hardware acceleration via the VM. If the device uses PixelFlinger instead, it's usually caused by your configuration asking for a feature that the GPU doesn't provide. Apart from that, the Nexus S is no "older android device"...

Many of the early releases did not use or have a GPU through the OpenGL implementation that is provided.  Not all early device are the G1.

If I am wrong then why do Adreno and others have there own api's released to deal with it on phones like my Devour.

The Nexus S is faster than my Devour by far and I get 40 fps.  So, if it is slow it is not the game, but a specific implementation issue with the Nexus S.  If I had a Nexus S I would find out why, but I don't sorry.

[EgonOlsen]

That there are some legacy devices without a proper GPU is out of question, but we are not talking about the Samsung Spica or something like this. My Nexus S (not rooted, moded,...) with 2.3.6 does use the software renderer in this game and there's no obvious reason why it should do this. Maybe you are doing something strange when setting the EGLConfigChooser. It might help if you post that part of the code that initializes the renderer.

BTW: I don't get what you mean with that "Devour sentence". Almost all current devices support OpenGL in hardware if initialized properly. There's no need for custom APIs. Adreno chipsets run fine with using OpenGL via the SDK.

[tberthel]

That there are some legacy devices without a proper GPU is out of question, but we are not talking about the Samsung Spica or something like this. My Nexus S (not rooted, moded,...) with 2.3.6 does use the software renderer in this game and there's no obvious reason why it should do this. Maybe you are doing something strange when setting the EGLConfigChooser. It might help if you post that part of the code that initializes the renderer.

BTW: I don't get what you mean with that "Devour sentence". Almost all current devices support OpenGL in hardware if initialized properly. There's no need for custom APIs. Adreno chipsets run fine with using OpenGL via the SDK.

No.  Millions of them have broken OpenGL APIs.  Some get patched and some don't.  Without specific info on all the 1000+ devices my games run on I can't find all of the broken issues.  Just the 2 devices I have alone have issues between their OpenGL implementations.  One has broken culling and the other needs the Adreno SDK to get acceleration.  The only 3d game I ever ran on it that had GPU support was a game supported by the GPU company and still it won't run on my other device.  Android 3.0 changes that, but before Android 3.0 OpenGL had spotty support at best.

Regardless, the software rendering should be fast enough since it runs fast on the Devour which is half the speed or less than most of the phones now.

Games published by our own members! Check 'em out!

[EgonOlsen]

The software renderer is slow and even more buggy than every flawed OGL implementation i've seen on a phone. It can't do proper vertex lighting, it has issues with zbuffering and filtering and that shows in your game. Menues are flickering, the player's objects is flickering and it runs slow.
What i'm not sure about after reading your posts: Are you actually using it intentionally to avoid compatibility problems with the actual hardware? 

[tberthel]

The software renderer is slow and even more buggy than every flawed OGL implementation i've seen on a phone. It can't do proper vertex lighting, it has issues with zbuffering and filtering and that shows in your game. Menues are flickering, the player's objects is flickering and it runs slow.
What i'm not sure about after reading your posts: Are you actually using it intentionally to avoid compatibility problems with the actual hardware?  

Actually the issue is pretty simple and not intentional.  I simply don't have enough info about the individual OpenGL implementations. You obviously have more experience with OpenGL, but you underestimate the cost of testing with dozens of devices.  So, while I know about all of the issues I don't really have a specific plan to solve all of them because I only have 2 test devices.

The flickering issue is actually device specific.  That is to say it only occurs on some devices.

I probably should swap out the 3d rendering engine I use for jPCT, jME, or other to see if they work better on more devices.

[ra4king]

What about libGDX? It solves many of the API problems and makes it easier for you

[tberthel]

What about libGDX? It solves many of the API problems and makes it easier for you

I am sure libGDX would be fine but that is for 2D games.  My 2D games don't require OpenGL.

[EgonOlsen]

Actually the issue is pretty simple and not intentional.  I simply don't have enough info about the individual OpenGL implementations. You obviously have more experience with OpenGL, but you underestimate the cost of testing with dozens of devices.  So, while I know about all of the issues I don't really have a specific plan to solve all of them because I only have 2 test devices.

Initializing the context properly isn't that much an issue of the OpenGL implementation. I'm using this in onCreate() when enabling a 1.x context:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18

super.onCreate(savedInstanceState); mGLView = new GLSurfaceView(getApplication()); mGLView.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {    public EGLConfig chooseConfig(EGL10 egl, EGLDisplay display) {       // Ensure that we get a 16bit framebuffer. Otherwise, we'll fall      // back to Pixelflinger on some device (read: Samsung I7500)      int[] attributes = new int[] { EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_NONE };       EGLConfig[] configs = new EGLConfig[1];       int[] result = new int[1];       egl.eglChooseConfig(display, attributes, configs, 1, result);       return configs[0];    } }); renderer = new MyRenderer(); mGLView.setRenderer(renderer); setContentView(mGLView);

It's the only way (as far as i know) to initialize things in a way that works on all recent devices plus the old Samsung Galaxy. If you want to try it, i can test it for you on the Nexus S.

[EgonOlsen]

...double..deleted

[tberthel]

Turns out that the config that I was using for my 2d rendering class were never added to the 3d rendering class.  It was defaulting to the SimpleEGLConfigChooser instead of the one I specified.  So, I was not using a custom Config for 3d.

While I thank you for your effort I would not use code from a forum without a license.

[Mads]

Doesnt work in landscape. No idea what I was doing at all, and I didnt really have any control.

[tberthel]

It works on both of my devices in landscape and portrait.

Probably a device specific bug.  I know that my devour bugs out randomly on any OpenGL app that is reloads from time to time and needs a reboot.

[Mads]

It works on both of my devices in landscape and portrait.

Probably a device specific bug.  I know that my devour bugs out randomly on any OpenGL app that is reloads from time to time and needs a reboot.

The app runs, and renders. However, I only have control over a paddle, can only can move two direction. None of which, help be hit the ball.

[badlogicgames]

Libgdx is not just for 2D games. You have full accsess to the GLES 1.x and 2.0 APIs, and there's some basic 3D support in there as well.

Our context setup is pretty robust, for GLES 1.x and 2.0, and also allows you to enable AA and other things that are a pain to do yourself.