Maximus-Dev

It’s been quite some time since I posted anything, so I figured I should whether anyone will actually be reading it or not. Things are going quite well with Through the Rift. I have a lot of engine work done, but of course have tons more to go. I’d gotten an animation for walking working well with matrix palettes (again… still working with OpenGL ES 1.1) but I’m in the midst of needing to implement a more global game solution. I have a few ideas I’m toying with, so I have a pretty good feeling things will be back on track in no time. Here’s to the future of TTR…

Behold…

If you are like me and developing an OpenGL ES 1.1 game for Android (yes… I know that 2.0 is more modern… I’m just not interested in changing mid-project now that 2.0 has been available) then you need to know who your target audience is, i.e. what phones you’re expecting your game to be compatible with. Personally, since I’m quite sure I’ve got at least another year to go, I’m targeting all phones with a Snapdragon or better (so Snapdragon (several phones), Hummingbird (Galaxy S series) and the TI OMAP 3630 (Droid X and Droid 2(?))). In the next year or so, I have a feeling that these kinds of phones are going to be very wide-spread and that developing for them is really the best target if you’re planning on making an even remotely detailed OpenGL game.

There’s one catch though. These phones all have 1 Ghz CPU’s but are, unfortunately, not all created equal. The big disappointment (at least for me…) is with the highly touted Snapdragon. It has an AMD GPU that just can’t compare with the PowerVR GPUs that are paired with the TI and Samsung processors. Sorry Qualcomm, I think you made a mistake here…

Head over to http://www.glbenchmark.com/result.jsp and check it out. Grab any Galaxy S phone (notice they’re at the top of the list) and compare to any Snapdragon device. The differences are pretty great. And here’s the thing that really bugs me. The Extended Palette Matrix extension is supported on all of the devices, and the GL_MAX_PALETTE_MATRICES_OES should be 32… but the snapdragon has a hardware limit of 20 for this parameter. That… stinks. I have at least one model that will need about 24 bones for animation which means I have to split up the draw calls and my game structure for the elements. It’s not the end of the world, but it feels lame to have to make the change for one set of phones.

Anyway, take what you will from this. My goal is to have my game run pretty darn well on Snapdragon devices, but really shine on the rest. We’ll see how it goes…

So I got a Samsung Captivate. Wow… nice damn phone. Between the Super AMOLED screen and the Hummingbird CPU (and substantially better PowerVR GPU than the AMD GPU that’s in the Snapdragon) I’m loving life. I unfortunately realize that I still need to develop with the Snapdragon in mind, but things feel so much easier now developing. No my slow emulation… and what is most important, no more limited GL Extensions.

What sucks… is that I spent quite a bit of time working on animations… doing my own modifications to vertices and normals because I couldn’t so much as call a glGet() on the current ModelView Matrix. Now… I’m working on implementing a skeletal animation system with the Matrix Palette extension and having a substantially easier time with it (once I figured out how it worked…). I’m also considering doing lighting fully with textures… but we’ll have to see exactly how much trouble that will be.

So believe it or not… this video shows something that was none too easy. The way OpenGL ES works, as long as I’m not completely mistaken, you can not to transformations mid-way through drawing faces. Because of this, I was a bit torn on how to do a smooth looking joint animation, like an elbow for instance. Then I had an idea…

Basically what I’ve done is take two OBJ output files from Blender and compare them to see what vertices are shared, then output the binary files that I’ve already been doing as well as an additional file containing the vertex “pairs.” In my native code, I’m rotating the vertices for the second object manually, that is, running through them all and multiplying them by my own rotation matrix. Then, I’m going through the paired up vertices and using them to set the matching vertices in the first object equal to those in the rotated first object, thus giving the effect seen here.

Joint Demo from Jeremiah Sellars on Vimeo.

Here’s a video of a quick demo of an cube with a texture loaded on it. Pressing in different screen areas affects the diffuse and ambient light. Those values are displayed in text in the upper right corner. Buttons to rotate in the Y and X directions provided by DayDream.

Simple 3D Demo from Jeremiah Sellars on Vimeo.

So moving my Open GL code from Jave to the native environment is officially going well. I’ve just completed the last step in the initial test phase, which was getting all of the data for vertices, normals, texture coordinates, indices, and finally the texture image data loaded off of the sd card and used for rendering. I’m quite pleased to say that (after finding out that I have to use RGB565 color and that Red is in the higher bits) that it’s all working smoothly. It may be time to really head back into the design phase…

For starters, I’m typing this on our family’s new MacBook. Well, it’s not new, my brother upgraded and was generous enough to pass it down to me, but my wife’s PC is about 5 years old, and this MacBook could easily replace it.

Besides that, I’m feeling like I’ve done all that I really need to with Blender for now, and I’m trying to make my push back into Android dev. Hell, now that I have a Mac, I might even take a shot at both Android and iPhone… who knows? Anyway, I’m working on some of the meat, so you could say, and things are going well. Here’s where I’m at so far:

1. Modeling in Blender is going very well. I’ve learned far beyond what I need for Android and plan to revisit Blender now and again for sure, especially to play with LuxRender.

2. Blender exports to OBJ, but there was one primary issue. OpenGL ES 1.0 only allows triangles. When converting Quads to Triangles, the Normals (the vectors that control the way light is reflected) are somewhat messed up, causing diagonal streaks across what should have been flat quad surfaces. What I ended up doing, was writing a quick C command line app that would take 2 OBJ files, one as modeled and one triangulated, and use all of the correct normals from the first file in the triangulated one.

3. The other issue with OpenGL ES that was new to me, was that it did not use glBegin and glEnd as a way to list vertices. Instead, entire arrays of vertices, normals, colors and or texture coordinates are given to ArrayElement functions. You can also shorten the amount of memory used by creating indices for sets of vertices that share a normal and texture coordinate, which thankfully with smooth surfaces is quite a few of them. This lead me to write a second command line app to take the final OBJ file and output binary files containing each of these arrays.

4. With those binary files, I’ve been able to add them as assets to the Android package, open and read them in and create the necessary game arrays and then finally draw them on screen, complete with texture.

TODO:

1. Review and complete a method to load files from the package from within JNI code.

2. Plan out how to take model pieces (like wall segments) and load them out based on some kind of level map.

3. Fix the normals where the things like wall segments meet.

Haven’t posted anything in some time… but here’s what I’ve been working on in Blender for the last several weeks. The die shapes weren’t particularly hard, but the numbers were somewhat difficult to get melded into the sides. This was rendered with blender 2.49b’s internal render engine… I may have a gander at what I can do with luxrender once I’ve done some tutorials. Have a look!

Click for larger image...

So I had to post this little achievement. I’ve gotten some great praise over at Blender Underground’s forums, so hell… I guess I did a good job! Here’s a regular ‘ole pencil I modeled. Click for a larger image.

Click please...