Category Archives: Java

Two new NeHe Android Ports

Just a short notice: I added two additional NeHe Android Ports. One is Lesson 09, showing some more blending and working with many star objects. Therefore, continuing the tutorials. The other is Lesson 16. This I added as it only requires minor changes to the tutorials 07 and/or 08. This was a quick port but maybe represents a nice “Cool Looking Fog” ^^.

So, just head over to the page and have a look. Again, more to come…

NeHe Android Ports

NeHe Android PortsAs some may have noticed, I am experimenting with Android, especially with its OpenGL functionality. As I am not inexperienced with OpenGL and Java through my “playing around” with JOGL, I thought I may get a quick access to Android and OpenGL. Cannot be that hard… it is not exactly hard, but it is different. Android supports OpenGL ES as part of its system, framework and SDK. OpenGL ES is not OpenGL, and principles as well as things you do with OpenGL to quickly achieve results cannot be done with OpenGL ES the same way.

NeHe ProductionsThere are actually some minor OpenGL ES tutorials out there and some very basic Android OpenGL tutorials, but none of them show a wide range of functionality. As I am personally a big fan of probably the best OpenGL tutorials in the net, NeHe, I wanted to stick with these and try to adapt these onto Android. This is not exactly the most difficult task but you have to think around the corner at once. The NeHe tutorials are more OpenGL functionality test beds, to show of what could be done and could be combined. The style is straight forwards and very easy to understand but does not work without some rework with Android.

Therefore, I started porting the NeHe tutorials to Android. First, just for myself, to get used to Android and OpenGL, but I think they may be helpful to others, too. That is why I started a project page for this, currently coping the first eight tutorials of NeHe ported to Android with a little explanation what has been changed regarding the platform requirements. I will continue to expand the tutorials and port all others that can be done on Android. I hope anybody looking for help in that area can be helped with the ports.
If any questions should occur, problems, comments, good or bad, just comment to the NeHe Android Ports page and I will get to it. In the meantime I will continue experimenting and porting the rest of the NeHe tutorials. I try to keep this up-to-date on a regularly basis but I cannot promise anything.

Android OpenGL ES – Mipmaps

I am currently a little bit experimenting with Android and its SDK as I am proud owner of a HTC Magic as well as I am pretty impressed by the SDK, Android itself and the ideas and principles it follows.
More precisely I am playing around with the graphical functionalities of Android, especially OpenGL. Android contains an OpenGL ES implementation, therefore I am playing around with some OpenGL codes and test the capabilities and results.

So, I was testing some texturing and of course wanted to test the mipmapping possibilities. Here I tripped over some “problems” you have to avoid by going another way.
In a probably classical way you could use glu to build the mipmaps

gluBuild2DMipmaps(GL_TEXTURE_2D, 3, sizeX, sizeY, GL_RGB, GL_UNSIGNED_BYTE, data);

You hand it the width and height and the texture data and it creates all your needed mipmaps. Problem solved! Unfortunately Android only provides a very small GLU implementation with some helper functions and does not provide you that functionality. Therefore, you would have to go another way.
A possibility on an Android system could be to test for version 1.1 of your GL and use the according hint, as 1.1. adds automatic mipmap generation

gl.glBindTexture(GL10.GL_TEXTURE_2D, textureID);
gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MAG_FILTER, GL10.GL_LINEAR);
gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MIN_FILTER, GL10.GL_LINEAR_MIPMAP_NEAREST);
if(gl instanceof GL11) {
  gl.glTexParameterf(GL11.GL_TEXTURE_2D, GL11.GL_GENERATE_MIPMAP, GL11.GL_TRUE);
  GLUtils.texImage2D(GL10.GL_TEXTURE_2D, 0, bitmap, 0);
} else {
  buildMipmap(gl, bitmap);
}

For the emulator this might work but not every mobile device running Android must have a GL11 instance. Therefore, this solution can work but does not necessarily have to.
Mike Miller had a similar problem/idea and suggested the following functionality

private void buildMipmap(GL10 gl, Bitmap bitmap) {
  //
  int level = 0;
  //
  int height = bitmap.getHeight();
  int width = bitmap.getWidth();

  //
  int[] textures = new int[1];
  gl.glGenTextures(1, textures, 0);
  textureID = textures[0];

  //
  gl.glBindTexture(GL10.GL_TEXTURE_2D, textureId);

  //
  while(height >= 1 || width >= 1) {
    //First of all, generate the texture from our bitmap and set it to the according level
    GLUtils.texImage2D(GL10.GL_TEXTURE_2D, level, bitmap, 0);

    //
    if(height == 1 || width == 1) {
      break;
    }

    //Increase the mipmap level
    level++;

    //
    height /= 2;
    width /= 2;
    Bitmap bitmap2 = Bitmap.createScaledBitmap(bitmap, width, height, true);

    //Clean up
    bitmap.recycle();
    bitmap = bitmap2;
  }

  return textureID;
}

The code is pretty straight forward. It just creates always the mottled bitmap and adds it using GLUtils to the according level, beginning from 0 to whatever level the size 1 for width or height will be.
Unfortunately again, this did not work for me. I tried this in an existing code I had, a special plain project just for mipmap testing, with different AVDs and with different circumstances. Nothing worked! As soon as I added another layer the texture stayed white. I am aware that as soon as you set the texture parameters for mipmapping

gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MAG_FILTER, GL10.GL_LINEAR);
gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MIN_FILTER, GL10.GL_LINEAR_MIPMAP_NEAREST);

it wants all layers. The function posted by Mike provides these but still it did not work for me. I had no idea why it did not work, because that it is a common solution, trivial and eventually should work. (Nevertheless, I solved it. Read at the end of this post why it did not work for me.)
I do not remember why I tried the following, but after many hours and lost hair I replaced the line of GLUtils.texImage2D(GL10.GL_TEXTURE_2D, level, bmp, 0); with the following, actually resembling what GLUUtils should provide, but based on an older SDK version

ByteBuffer bytebuf = ByteBuffer.allocateDirect(bmp.getHeight() * bmp.getWidth() * 4);
bytebuf.order(ByteOrder.nativeOrder());
IntBuffer pixelbuf = bytebuf.asIntBuffer();

for(int y = 0; y < bmp.getHeight(); y++)
  for(int x = 0; x < bmp.getWidth(); x++) {
    pixelbuf.put(bmp.getPixel(x, y));
  }
pixelbuf.position(0);
bytebuf.position(0);

gl.glTexImage2D(GL10.GL_TEXTURE_2D, level, GL10.GL_RGBA, bmp.getWidth(), bmp.getHeight(), 0, GL10.GL_RGBA, GL10.GL_UNSIGNED_BYTE, pixelbuf);

This basic self-implementation of what should be done by GLUtils works for me. But please note that it is just a working example and does is neither optimized nor necessarily the finite solution to this task.

I also figured out why the GLUtils did not work for me: It was only in the Emulator and it was only on one of my machines. And especially that machine it did not work on has a very basic, cheap, old graphics card. But for a whole overview and if you step into the same trap, I posted everything so you know what could be a reason and how to solve it.

So, now after all these tests I have done I have three implementations that work for me. On the one hand side, the use of GL11 and the self-implementation of a mipmap building method in two ways. In conclusion after all these tests and also minor performance tests I did, use one of the suggested methods from above or let me know of other possibilities. I would start with the GL11 test and then go over to the implementations. GLUtils should always work. Hope this helps…

Ubuntu Edgy, Eclipse and Subversion

I know, I know… I haven’t posted for a long time. But be honest, would you have read it? See!? That’s the reason why ^^’

OK, so why do I break the silence? I am currently setting up a linux system as base for my diploma thesis. As I like Debian but wanted to have some more comfort I installed Ubuntu in its newest version 6.10, called Edgy. Dapper Drake (6.06) still is the LTS release and Edgy is known to have some problems but overall everything worked fine for me.
I downloaded the DVD, started the Live Ubuntu version and installed Ubuntu to my harddrive just by simple clicking. Some 30 minutes later everything was ready to run. And it runs fine!

Debian’s APT/DPKG system is just superb. Combined with the nice given user interface its just plain great. You can select from a large amount of good software to install without the need to compile or configure anything. Ubuntu is currently probably the best approach for a Desktop Linux overall. And in my opinion with all its comfort and the typical Linux software features it can stand up to Windows, MacOS X etc and outperform them.
I do not know how to describe it, but I am some kind of addicted to Ubuntu now. It just gives me everything I need and more. Features I haven’t even thought about that are just there without slowing down the machine while eating up my performance. I am happy…

…until now! For development I am using Eclipse. A great and free IDE especially for Java development and more. Fast and supportive with a large amount of plug-ins to use (a post about those is coming, too ^^). Again, Eclipse 3.2.1 made absolutely no problems during its installation with Ubuntu’s own program installer/deinstaller.
As I am developing in Java I needed a JDK. JDK 1.4.2 was already configured and ready to use but is out-dated. As JDK6 is the newest installment I wanted this package. Apparently, even if final for some time now, Debian still counts it as unstable. So your only chance is to get the binary from Sun’s official homepage with an own installer given (so no problem here) or to add the unstable packages sources to your source.list and install the “unstable” package (runs fine!!!).

Everything worked, you might say. What is he complaining about, you might ask. Those were no real problems, you might state. And you are right. BUT development is nothing without code. And code is often stored in a repository, in this case a Subversion repository.
Tigris, the Subversion developer, brings an own Eclipse Plug-In called Subclipse. It offers easy access for checkout, commit, update, delete etc. By using the Eclipse Update Manager it is an ease to install it. Strictly speaking Eclipse is doing the work while you are getting another java (damn… I couldn’t withstand this joke!).
Subclipse uses the JavaHL adapter by standard, which is part of the Subversion project and used as native API (per JNI) to access Subversion. Again, it’s just package that can be installed with the synaptic package manager. I did so, installed it, installed the libapr0 as needed too and thought everything will run fine now. WRONG! Eclipse did not start anymore.

What has happened? System is clean. 5 seconds ago it was still running. Now it crashes while loading the Subclipse perspective. Why, oh why?
First of all I cleaned Eclipse from the Subclipse installation. Eclipse started again but after installing Subclipse again I had the same problems again. So I reinstalled the complete Eclipse SDK after cleaning every configuration. After updating to Subclipse Eclipse was still running and could be started. But after changing to the Subclipse perspective it crashes. Damn, I thought. What is the problem?
Google BartI asked my magical crystal ball (also known as Google) what the problem could be. And it gave me an answer straight away. It was neither Eclipse nor Subclipse but libsvn-javahl in addition to libapr0 that caused the error. Ubuntu Dapper Drake (6.06) had no problems with its JavaHL compiled package. Eclipse, Subclipse and JavaHL work fine. But since Edgy the package seems to have problems with apr. Those problems are well known but still the package was officially opened to Edgy (at least so it seems).
So long story short: After trying to figure out what the problem was, I could locate JavaHL as the root of all evil. I deinstalled it and am using the Subclipse Java SVN API. That may not be the best solution but it works. There are some “howto’s” that explain ways to compile your own JavaHL with another apr that will work with Subclipse but I am just too lazy.

So, what do we learn from this? Never trust a running system: If it’s running, it can still crash! And of course, always ask Google before complaining on a Mailing List.