Vulkan Hardware Capability Viewer 1.4 released

A new version of the Vulkan Hardware Capability Viewer is now available for all platforms (Windows, Linux, Android). This is the biggest update since I released this tool, including lots of new features that also brought along a few changes to the online database. I also decided to drop the “beta” tag now that more than 1,300 reports have been uploaded, making this the first non-beta release of the Vulkan Hardware Capability viewer.

New features

  • Added support for new features and properties provided via VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2
    • Currently supported:
      • VK_KHR_push_descriptor
      • VK_EXT_discard_rectangles
      • VK_KHX_multiview
      • VK_NVX_multiview_per_view_attributes
  • Reports can now be saved to disk via command line using the -s argument (without invoking the UI)
    • Example : vulkanCapsViewer -s my_device.json
  • Added pipeline cache UUID
  • Exported JSON is now compatible with vkjson_info from LunarG SDK
  • Added Android platform info
    • Device model and manufacturer
    • Build information
  • UI improvements 
    • Updated layout and UI scaling 
    • Support for high DPI scaling
    • Touch scrolling for mobile devices (Android)

Bugfixes

  • Fixed unauthorized access to SSL libraries message on Android 6.0 and newer

Continue reading “Vulkan Hardware Capability Viewer 1.4 released”

Vulkan Hardware Capability Viewer 1.4 released

Vulkan Hardware Capability Viewer 1.2 released

I have released an update to the Vulkan Hardware Capability Viewer. The new version (1.2) adds support for os-specific surface capabilities that are added to the reports and online database.

This adds a new category to the tool and reports at the online database (for example this one) containing:

  • Surface properties (extents, usage flags, transforms, etc.)
  • Surface Formats (incl. color spaces)
  • Present modes

You can download the new version from http://vulkan.gpuinfo.org/download.php, downloads are available for Windows, Linux and Android (arm and x86).

The Android version (for now arm only) is now also available at the google playstore.

Vulkan Hardware Capability Viewer 1.2 released

Soruces for simple OpenGL 2.0 HUD/GUI for android

device-2014-07-18-210940As I’m currently prototyping a new game for Android, I was in need of a quick (and simple) way of adding some selectable text elements on top of my 3D OpenGL ES scene. So I created a simple demonstration with full source (you can get them from my OpenGL ES git repository) that renders a 3D scene and a basic hud with clickable text elements on top of it in orthogonal mode.

The text elements are rendered to an OpenGL ES texture, using android’s canvas, making this a very flexible way of drawing text on top of an OpenGL ES scene. Note that this isn’t very fast, so the texture should only be updated when necessary. The demo has a menu along with a fps counter, so the texture will be updated every second, and the elements can be clicked and the hud’s observers will be notified with the clicked element’s id so you can easily react on user input.

Though this isn’t something you’d use in a production app where performance is crucial, it should be good start for rapid prototyping needs where you need to have some basic gui or hud to issue commands. And you’re always free to improve the sources (feel free to fork) to make it perform better, by e.g. only updating the areas of the texture where text changed, instead of updating every time if one of the elements is changed.

Soruces for simple OpenGL 2.0 HUD/GUI for android

Android OpenGL ES repository

device-2014-06-29-171344Following the C++ (OpenGL) repository, I recently added an Android OpenGL ES repositry (using Java) over here. It currently only contains two public demos, one for a simple stl viewer and another one for using the camera input of an android device as an OpenGL ES texture, but over time I plan on adding more and more demos.

And though I used to mock Java in the past I really like coding with Java nowadays. It’s partially because of the language itself (with all it’s modern features) but also because Eclipse is an awesome IDE. So expect more android demos and sources from me in the future.

Android OpenGL ES repository

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 updated to 0.3

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 CapsViewer update to 0.2

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

[appbox googleplay de.saschawillems.glescapsviewer]

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!

OpenGL ES Caps Viewer available on Playstore

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 😉

3D loader for android, first roaming zombies

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”.

Zombie infected random dungeon crawling