A note about NVIDIA drivers (on windows) an glCapsViewer

Thanks to Christophe Riccio, it came to my attention that most NVIDIA driver reports on windows are discarded when trying to upload them to my OpenGL hardware database.

The cause for that is pretty simple : Contrary to the other vendors, NVIDIA does not include their (or any, e.g. OpenGL ICD) driver version inside the GL_VERSION string on windows (at least not on Windows Vista and up, on XP this still seems to be the case). So the database doesn’t see reports generated with more recent driver version as new ones, discarding them though even they may be never and contain new extensions and features.

Christophe already reported this to NVIDIA and I hope they change this for the future, and get this in line with their GL_VERSION strings on Mac OSX and Linux. Until then I’m trying to release a glCapsViewer version for windows that’ll get the driver version from WMI (which isn’t that easy for systems with multiple GPUs) and add it to the GL_VERSION string like on the other operating systems, so that reports with newer driver versions won’t get discarded.

So if you’re on windows and own an NVIDIA GPU, don’t worry if your reports get discarded even after installing the most recent drivers. I’m aware of this and I’m trying to fix it until NVIDIA adds the driver versions to the GL_VERSION string again.

OpenGL ES CapsViewer updated to 0.3

High on the heels of the last release (0.2),  I just updated the OpenGL ES CapsViewer to version 0.3.

Changelog :

  • Changed way of setting up the OpenGL ES render context
    Certain devices (mostly those with PowerVR GPUs) were reporting wrong OpenGL ES versions (e.g. 1.1 instead of 2.0). I’ve changed the way of setting up the highest possible OpenGL ES version, so those devices should now display their real supported OpenGL ES version.
  • Additional duplicate check
    The app will now check whether your device (with it’s current OpenGL ES and android version) is already present in the database before actually having you input your name and uploading it. If it’s already present you can directly jump to the device report.
  • Action bar at screen bottom
    On narrow devices (usually phones), the action bar will now be display at the bottom of the screen. That should improve the actions’ visibility.

The update should be automatically installed, and if you’ve submitted a device where 0.2 reported a wrong OpenGL ES version, please feel free to resubmit it.

 

OpenGL ES CapsViewer update to 0.2

ic_launcherI’ve just released an update for the OpenGL ES CapsViewer to google’s playstore. This version should fix crashes upon startup that seemed to be caused by a wrong egl configuration, so for this version I’ve changed the method of selecting the egl configuration for the render context.

So if the application crashed on your device feel free to update (in case you’ve turned automatic updates off) the the most recent version and submit your OpenGL ES reports.

There are already ~30 different devices present in the online database, and over the last few days I added some new features like comparing reports and more listings to the database.

Note that for certain devices (like this Samsung Galaxy Tab 2), the OpenGL ES CapsViewer will read OpenGL ES 1.1 (CM) as the supported OpenGL ES version, though it should actually support OpenGL ES 2.0. Since I don’t have such a device it’s hard to test why it only reports OpenGL ES 1.1.

OpenGL ES Caps Viewer available on Playstore

My first ever mobile app is now available over at Google’s PlayStore! This is a premiere for me, and though I wasn’t on wether to spend the 25$ registration fee for the google’s developer console, I hope many android apps and games will follow.

device-2014-02-02-202348 device-2014-02-02-202410 device-2014-02-02-202423  device-2014-02-02-202459

The OpenGL ES CapsViewer is the mobile counterpart to the OpenGL CapsViewer, reading the OpenGL ES implementation info of your Android device, as well as device information that may be of use to developers. As with the desktop counterpart these reports can then be submitted to the online database, where (game) developers interested in creating OpenGL ES apps for the android platform can take a look at the capabilities of the different devices.

It currently supports the following features :

  • Basic device information (Name, CPU, screensize)
  • Hardware sensors (including their range and resolution)
  • OpenGL ES implementation information
  • OpenGL ES extensions
  • OpenGL ES compressed texture formats, shader and program binary formats
  • OpenGL ES caps for 1.0, 2.0 and 3.0
  • EGL implementation information

As for the hardware requirements, it should work with Android 3.0 (and up) and needs OpenGL ES 1.0 to work. I’m not that deep into android development, so I may be  a bit off with the requirements, and I’m not certain on wether there’s any use in adding support for handsets with old Android version (2.x and below).

Please note that this is the first release, and that I only have limited ways of testing. I did tests on several mobile devices (my Huawei Ascend G510, differnt current Samsung devices and several emulators), so this first release may not be as stable as I want it to be ;)

So if you encounter any problems or crashes, please drop me a line and I’ll look into it. Also note that that online database is a work-in-progress too, and stuff like comparing reports will be added at a later point.

I hope this Android OpenGL ES hardware database will become as valuable to the developer community as the desktop OpenGL hardware database, which is currently approaching 500 hardware reports. So let me use this posting as a way of thanking all of you that contributed (and still contribute) to that database!

3D loader for android, first roaming zombies

A 3d game needs 3d models, so I wrote a simple .obj (wavefront) model loader, and it was surprisingly easy with java. It took me roughly 30 minutes and is no more than 50 lines of code (including declarations and comments). So the “game” (still no gameplay in) can now display 3d models, and since it’s a zombie game, I’ve put in a (drum roll please) zombie! But it’s not just visual, but also backed by an NPC class that makes it move (more or less randomly) around the dungeon in a turn based manner.

device-2014-01-28-135250 device-2014-01-28-135411 device-2014-01-28-135538

Next on my list are 3d models for the doors, which are currently plain textured (and two-sided) quads that you can simply pass through. And replacing them with 3d models will allow me to add opening animations (think of the first resident evil games), and I also plan to use doors as a gameplay element that’ll hold back zombies that chase you. I’ve also implemented a simple gesture based model viewer that I’ll use to display items to the player (weapons and such).

After adding the doors I’m going to implement color picking for touch inputs, so that the player can interact with the objects in the 3d world, for e.g. opening the doors by touching them (or gestures for locked doors), hitting enemies or picking up items. Since it’s OpenGL ES 2.0, all the rendering is done using shaders anyway, and just adding shaders for color picking and reading pixel colors should be an easy task, especially as I’ve been using that technique in several other games too.

As far as the model format is concerned, I plan to use .obj just in the beginning. It’s ASCII based, so it’s taking up lots of space, is slow to parse (compared to a binary format), and the most important drawback is the lack of animation. It supports neither keyframe animation, nor bones or anything else do store animations. I guess I’ll go the same route for android as with my Delphi projects and create my own binary 3d file format that’ll implement animations.

I’ve also already gathered dozens of gameplay ideas, including randomly generated zombies from a pool of different body parts (heads, upper and lower parts, arms, weapons) and I even think about taking photos of your friends or relatives, that can then be used as zombie faces. Should make up for a pretty nice moment if a zombified friend of yours is trying to rip you apart ;)

Zombie infected random dungeon crawling

2014 started off pretty busy and I haven’t had that much time to work on my current (and first) android project. But at least I wrote down the first pages of the basic game design draft, and I plan on doing a randomly generated, zombie themed dungeon crawler with not your usual zombie story.

device-2014-01-11-110401  device-2014-01-11-110513  device-2014-01-11-110614

So in terms of gameplay it’ll be a traditional dungeon crawler (think of “Eye of the Beholder“, or more recently “Legend of Grimrock“), with semi-realtime movement but with a modern horror theme based on a zombie infection (yeah, I know, zombies are all around nowadays, see the success of DayZ, but I always wanted to do something with zombies anyway). It’ll have RPG elements like health, stamina, skills, experience and an inventory sytem and I plan on having the items generated procedurally like the dungens itself. I even though about randomly generated enemies with random body parts that can be comnnected at random, though I’m not certain if that’ll work out as I want it to be.

I already got the basic engine up and running, and did the first performance optimiziations (visibility checks), so it’ll run smooth and nice on even lower end devices (like my Huawei Ascend G510, it “only” has a dual core with 1,2 GHz and a mere 512 MBytes of memory). I added smooth animations for turning and moving, and wrote a nice looking shader for per-pixel based spotlight shading with distanc attenuation, which is basically a low-powered flashlight that makes up for a an eerie and claustrophobic atmosphere. What you can’t see on the screenshots : It’s animated and sways around and flickers, and I plan on adding some kind of touch or sensor based way of having to regenerate the batteries from time to time to add some suspension to the gameplay.

As soon as things have settled, I’ll post more information on this project, including some of the technical aspects of the “engine”.

2013 – Final posting – Dwelling in randomly generated mobile Dungeons

Another year has (almost) passed, and as with the previous years I’ll keep up the tradition of publishing a final posting before heading into 2014. From a personal point-of-view, 2013 wasn’t thad bad (though still far from perfect) like some of the years before. I still earn my money as a sofware developer using delphi and love my job, and recently I even bought the house I’ve been spending most of my 32 years in (though there is still a bit of renovation to be done, but the house itself is in a good shape).

As far as my personal programming stuff goes, those of you that follow my blog may have (hopefully) noticed that I moved away from Delphi and went over to Java, mainly because of mobile development for Android devices. I’ve been wanting to develop for smartphones and tablets for some time and the move was easier than I expected. It didn’t take long to get a gripe of the Java syntax, and together with Eclipse I’m pouring out lines of code like never before. The more I work with Java (and Eclipse), the more I realize how far behind Delphi has fallen. It’s sad to see that Embarcadero seems to focus on the wrong areas of Delphi, and instead of fixing their base and giving the community a free Delphi version they hold onto stuff like FireMonkey and decided to release a new Delphi version every 6 months. Though quick release cycles can be good, I don’t think they’re suited for such an expensive development tool. But well, if you take a look around the hobbyist community you’ll quickly notice that nobody cares about Delphi anymore. Especially for OpenGL development, people either moved to Lazarus and/or Free Pascal or (like me) moved over to another programming language. The sad thing about this is that communites I’ve used to be active an have gotten pretty quit over the past few years.

And no posting without any programming stuff! Since I’m totally not into that christmas and holiday stuff I had plenty of time for coding during the recent days, and so I decided to do something gaming / OpenGL related for Android. And therefore I ported the random dungeon generator I described in this article over to Java, and though it’s still in it’s very early stages, you can already walk around randomly generated dungeons on a mobile device.

dungeoncrawler_2013-12-29-204317 dungeoncrawler_2013-12-29-204526 dungeoncrawler_2013-12-29-204538

This is my first Java project that uses several different techniques. It’s based on OpenGL ES 2.0, uses different shaders for e.g. per-pixel lighting (which makes for easy flickering torches), a texture loader, a (yet simple) touchbased OpenGL GUI and much more. I don’t know if I’ll make it into a complete game, but I want to at least release a techdemo. I’ve got plenty of ideas and want to make heavy use of gestures for e.g. solving puzzles, making attacks, etc. I’m also not sure about the setting yet and still swaying between a more common theme (medieval, like the Eye of the Beholder-Series), something in the future (maybe a trapped cyborg in a futuristic factory) or something dark, psychologic and eerie in the vein of Trugbild. Maybe I’ll even open-source it ;)

And thus ends 2013, may 2014 bring forth more Android-related stuff (as long as Cthulhu won’t wake up from it’s eternal slumber cthulhu)

In addition to wishing all of my readers and friends a happy and healthy 2014 I’d like to dedicate this posting to a very special person that’s going through a hard time, seing that makes me pretty sad and it’s even harder not knowing how to really help :(

OpenGL ES Hardware Database Preview

It took (a bit) longer than expected, but I finally got the first preview of the online OpenGL ES Hardware Database online. I want this to be the match to the widely used OpenGL Hardware Database (filled by the glCapsViewer). Where the former is aimed at developing desktop applications with OpenGL, the later one is planned to be a helper for all developers planning on deploying OpenGL ES based applications, games or tools on the Android platform (other platforms that support OpenGL ES may follow in the future, the database design is flexible enough) that want to know what features are offered by the different devices on the market.

In addition to the pure OpenGL ES related information, like extensions, caps, texture formats etc. the database will also store device information (OS version, screen size, CPU), device features and available sensors along with their range and resolution. Especially the sensor information should proove valuable in case you want to wether your targeted devices support e.g. a gyroscopic sensor or not. The database is targeted around OpenGL ES 2.0 and above, as that’s the majority of devices currently out there.

The database is still a work in progress and several new features will be added over the coming days and weeks (like comparing reports), but any feedback on how to improve it or what features to add is welcome.

The android app will be release in the near future. It’s currently in alpha testing stage, but seems to run fine on a wide range of devices (at least the ones you see in the database ;) ). No date yet on when it’ll make it’s way into the public, but since it’s running stable and everything is in place it shouldn’t be too far in the future.

As for the technical backgrounds :
The android app is written in JAVA (yes, I actually like working with a modern language and IDE, something Delphi has been lacking in the recent years) using Eclipse. I had it up and running with the new Android Developer Studio, but since that one is still a preview version I’ll stick with Eclipse for now. Though google’s developer studio seems to come along very nice.
I also made the switch from SVN to GIT with this project, and I’m pretty amazed by all the features that GIT has to offer and how much better suited it is for agile developement. Sure, the tools (especially on windows) are not as convenient as the ones for SVN, but the easy branching, rebasing and stashing stuff easily makes up for that.
The database uses MySQL, and I’ve used the free MySQL workbench to set it up (which is so much better then working with phpMyAdmin). Since I’ve gathered a lot of experience with (SQL) databases due to my current job, the database design for the OpenGL ES database is much better than the one backing up the old OpenGL database. So instead of letting a PHP script import the report’s xml into the database, it’s now done via a stored procedure using XPATH. Not only easier for me to maintain and extend, but also much faster.
And on the other hand the database design is also much more flexible, and adding new stuff and OpenGL ES versions (along with new caps) should be much easier. And you may also notice that the content is provided under a creative commons license.

But once the OpenGL ES database and it’s android app are out in the wild, I’ll get back to the OpenGL database to see what I can do in terms of performance and what features I can add to make it even more valuable to the OpenGL developer community.

From Delphi, Windows, OpenGL and Newton to…

box2dtest_01 …Java , Android, OpenGL ES and Box2D. That’s what I’ve been doing the last few days during my (currently rather rare) coding sessions. I wrote a simple physics playground using JBox2D for my phone that allows me to drop different objects by the touch of a finger and also uses the orientation sensor to change the gravity vectors. Putting lots of dynamic objects inside a confined box, and seeing them fall over by just tilting the phone is a fun affair ;)

I also wrote a (very simple) OpenGL ES renderer to display the physics bodies. Luckily OpenGL ES is pretty close to recent OpenGL versions (if you skip all the legacy immediate functions), and getting the renderer up-and-running only took a few hours.

And I actually don’t miss Delphi that much for my hobby development (Though I’m still earning my money with it), Java has come a long way, is a modern language that actually evolves (whereas Delphi, in terms of the language hasn’t changed a lot in the recent years) and writing quality code kinda seems easier, even though I’ve actually just started writing code with Java. I’m not yet feeling as comfortable with it as with Delphi, but writing Java code gets easier and easier by every line of code.

So for the next few weeks (or months) I plan on playing around with realtime physics on Android, and especially with all the different input methods and sensors that simply aren’t present on PCs. I’m still not sure about what type of game I’m gonna do for Android, but I have some initial ideas that I’d like to implement. Maybe I’ll even port Trugbild to android, just to get some more experience developing for mobile platforms using OpenGL ES.

 

New target : Android

I’ve been using a symbian “smartphone” (a Samsung SGH-i560) for ages now, but finally decided to swap it for a new and shiny Android device, mainly to code on.
So I recently bought myself a Huawei Ascend G510. It’s a middle class Android handset with a dual-core CPU (1,2GHz) and a 4.5″ screen that supports OpenGL ES 2.0 that doesn’t cost a fortune (~140€) and condidering the pricetag it’s a pretty good phone.
So once the battery was loaded I attached it to my PC and started to develop on it right away. I started off with the native FPC armv7-cross compiler using native Android Controls, went over to integrating Free Pascal (JVM) into Eclipse and did some basic OpenGL ES demos with both of them.

And though it may be appealing to code in pascal for the Android platform, I decided to go with Eclipse and Java. Java has a lot in common with Delphi, and getting used to it’s syntax only took me a few days and I’m already creating productive sources. Actually I kinda like coding with Java (and Eclipse). You get lots of modern language features that Delphi has been lacking for years, and the code features (auto completion, correcting problems, etc.) are just great. And best of all is that you get it for free, which is no comparsion to the expensive entry into the Android world with Delphi XE5 (which btw. forces you to use FireMonkey).

So after getting used to Java and Eclipse (in the form of ADT) I started work on an Android version of the glCapsViewer, called “glESCapsViewer”. It’s already up and running, getting the implementation details. It reads out information on the device, the renderer, all available extensions and all supported texture compression formats. Next on the line is generating XML files for the repots and then uploading them to my online database.

I’m not sure yet on wether to just add the mobile OpenGL ES reports to the current caps database, or to add a sparate database. But I guess I’ll go for the latter way, as it’ll allow for more flexibility. This would allow me to e.g. also add information on the device iteself and wouldn’t inflate the desktop report database with OpenGL ES versions and extensions.

It’s not quite ready yet, but expect an Android version of the glCapsViwer in the near future. And also expect to read lots of postings on Android and Java. Once the glESCapsViewer ist done, I plan on creating my first mobile game, and it may be a port of Trugbild, as the gameplay itself is perfect for touch based devices. I’m even thinking about using the motion sensors to move along the scenery ;)