BlockLeftTop, PRELOAD BlockLeftBottom, PRELOAD BlockLeftStretch, PRELOAD BlockTop, PRELOAD BlockBottom, PRELOAD BlockStretch, PRELOAD BlockRightTop, PRELOAD BlockRightBottom, PRELOAD BlockRightStretch, PRELOAD

OpenGL ES 2.0: The many faces of one API

by Heiko Schmitt 24. November 2010 10:18
Our Delta Engine supports many platforms, which support many different graphics API's like XNA, DirectX9, DirectX10, DirectX11, OpenGL2, OpenGL3, OpenGL ES 1.1 and OpenGL ES 2.0. Currently I am just working with different flavors of OpenGL ES 2.0 implementations and trying to integrate them all into our Delta Engine. To make it even more interesting, there are at least 4 OpenGL ES 2.0 windows emulators, which we support (we add new ones as soon as we discover them): One from PowerVR, one from Nvidia (Tegra), one from Qualcomm, and one from Mali


For each emulator (which roughly corresponds to a specific platform), there is a header file (gl2ext.h) plus the default one from khronos which describes available extensions.


My task was to merge all those files into a single file (in C#), which we can use on all platforms. First idea was to convert this by hand, but in sight of evolving platforms, this solution was thrown away quickly. Second idea was to write an automated converter, which is what I am working on right now.


Even though these headers should be quite similar in structure and naming (remember, there is khronos which approves all those extensions), there were many differences and inconsistencies. I started with Nvidia Tegra header, which looked real good at first. Next was khronos. They sometimes just omit parameter names from their function prototypes. Really funny... (not!). So I needed to switch parsing the real function declarations instead of prototypes. Would be no problem so far, besides mapping the ugly uppercase function names to their nice camel-cased counterparts. IF they would obey their own naming scheme consistently - which they do not ;)


Just some examples:
  • There were sudden lower-case letters: "PFNGLGETTEXLEVELPARAMETERiVNVPROC"
  • Naming inconsistencies: Prototype: "glDrawPathbufferNV" Declaration: "PFNGLDRAWPATHBUFFERPROC" (Note they missed their own NV :) )
All in all this took way longer than it was planned, but at least it is working now :)

MobileBits und die Delta Engine bei n-tv :)

by Karsten Wysk 22. November 2010 21:40

Dank der Einladung von Microsoft zum Bizspark-Camp in Berlin, wurden wir auch von n-tv interviewt und durften unsere Delta Engine vorstellen.


Danke für die Chance - ist schön geworden! Hier gehts zum Video:

3D Model formats: Collada or FBX?

by Benjamin Nitschke 11. November 2010 14:33

Our Delta Engine supports Collada files for 3D Models since we have worked with Collada for many projects (since 2005). However the support for Collada .DAE files in 3DS Max 2011 or Maya just gets worse every year. No one is actively working on a plugin anymore. ColladaMax is dead, Feeling Software is not working on Collada anymore, OpenCollada (open source collada support) has done nothing for a year now, Sony does not like Collada anymore, Autodesk wants everyone to use FBX and never really supported collada well, etc.


So should we give up on Collada? Well, yes, the artists will no longer use Collada (we still support it for our engine and content importers) and instead export everything in FBX, which works fine out of the box in 3DS Max or Maya (or XSI or Blender, etc.). Now we got a bunch of FBX files (and some older collada files we still want to support) and we are way too lazy to write a new importer right now (we want to work on our 3D SoulCraft TechDemo now). There is the FbxConverter tool you can download from Autodesks website (for free, you just need to register). With this tool you can freely convert from FBX to Collada or one of many other formats (many different FBX formats, 3DS, OBJ, or DXF). The resulting collada .DAE file is MUCH better than one exported directly from 3DS Max or Maya (at least if the artist does not have the latest FBX exporter installed). It seems to be in a more standard format, it exports all animations, bones, skin, camera, spline, etc. information out where the standard Autodesk Collada exporter leaves this all out and makes the format useless. Sadly ColladaMax, OpenCollada, etc. all do not provide a plugin for 3DS Max 2011 or 2010 because no one is working on that, older versions like 3DS Max 2009 work fine, but we had our problems with those plugins as well. Note: Feeling Software still supports FCollada, but it is not longer a free plugin, you need to get a commercial license, but we had too many problems with FCollada in the past to go that route again (some stuff works great, other stuff not so much, at least for us).


I will report back how our implementation goes with all this format mess :)




Update 2010-11-18: While Collada (including converted fbx files and yes, I tried many different converters and exporters) still works great for simple static meshes and animated meshes, it just causes too many problems with many of our more advanced content. While we might continue to support Collada in the future (I am not so sure right now), we will switch completely to importing FBX files directly now. This gives us much more flexibility, but it of course also adds lots more work to support FBX completly (e.g. there is no easy managed library to load FBX files, you gotta use the native FBX SDK). But everyone else uses FBX too (Unreal, Unity, most modeling tools, etc.), so I guess we have to jump on that bandwagon too. Another good thing is our artists already use FBX and they don't care how stuff is converted, it just should work. Another important aspect is that we want the ability to convert game content and levels back into FBX files (we used collada for that before), this way a nice interaction can happen between modeling tools like 3DS Max or Maya and the engine editors (but we are not there yet obviously) :)

For me the following put the nail into the coffin for getting away from the FBX to collada converted way. We had additional problems like missing material info and no tangent data that could be reconstructed from the original FBX file, but it turned out to be too much work and there are plenty of other subtle problems with the conversion (it looks fine at first, only after working with it a while you see more and more stuff not working the way you want):

From the FBXConverter Documentation by Autodesk:

What’s not supported by COLLADA
The following is a list of elements that DAE (COLLADA) do not support on
export or import.
■ Triangles, polylist, and polygons. The FBX Converter exports polygons
without holes, and imports them without holes and triangles.
■ Bake & single matrices
■ Variable sampling rates.
■ Absolute Paths (when invalid)
■ Instances
■ Skew
■ Non-standard Materials and maps for different parameters
■ Orthographic cameras
■ Normals (for skin and shape)
■ Light parameters
■ Vertex animation
■ Material parameters animations
■ Effects specialized profiles
■ COLLADA physics
NOTE Export or import to DAE (COLLADA) can destroy or produce unpredictable results for some elements.


We also tried putting some FBX files into the XNA Content pipeline to see what comes out at the other side, but there were way too many restrictions for us to work with the XNA Content pipeline. I am happy to see that XNA's FBX support is getting so much better (I used it last in 2006 and it totally sucked), but the following things were just too annoying:


■  All pathes must fit, including textures, shaders, and whatever else is in the fbx file. File formats also have to match, artists love to use .psd files, but that is nothing I want to support (there is a .png file with the same name right there, but the content processor does not see it). All of our FBX models we tested used absolute paths that were just not available on the content server (or my machine for testing). While FBX ASCII files can easily be edited, this is still a show stopper for us. While a small XNA team might be ok with this restriction (you can just use relative paths in 3DSMax when exporting and make sure all images, shaders, etc. are in place), I don't think this is the right way for us.

■  Many files caused other compiling issues, for example most of our animated meshes use not just a standard skeleton and bones, but some other system (e.g. CAT). Again, this can be sometimes fixed before exporting, but it just does not work automatically, it is always a custom process with lots of fiddling around. The following error was just too annoying to me to try this out any more (especially because you find not much useful information in the internet about problems like this): Skeleton not found. Meshes that contain a Weights vertex channel cannot be processed without access to the skeleton data.


■  Finally the process always takes way too long, we spend already most of the content server time inside the XNA content pipeline (to convert stuff to WP7), hopefully loading FBX directly instead of converting them to collada or going through the XNA content pipeline is way faster ;)


■  Even with all these problems the XNA Model Processor has some cool tricks up its sleeve. For example when you get far enough with the importing process an .xml file will be generated in the Content/obj/x86/Debug directory, which contains a lot of extra information the xnb generated file might not have. It can be useful to look at those .xml files and maybe even extract useful information out of those. For us it worked not so well with some easy to get information like tangents (they are just missing), but it contained all the CAT bone information on the other hand. Still good to know ^^


So we are back by converting FBX into our own format ourselves (not sure if I will write a native tool with the FBX SDK or just PInvoke from C# yet ^^). For anyone interested, there are some cool projects out there using the FBX SDK, for example this FBXViewer is a nice one, it worked out of the box with everything I had thrown at it (as opposed to converting collada mess or trying the XNA content pipeline).

Some impressions from the TechEd Europe 2010 in Berlin

by Benjamin Nitschke 10. November 2010 05:58
I was only 2 days at the TechEd Europe 2010 and spend most time in the Press Center, but I still got some nice impressions from the conference. I hope you enjoy.

Picture 1-4 are from the first day, not much to see from the fair, there was only the keynote anyway.

Picture 5-7 are from the Technikmuseum in Berlin where we went on monday evening with Microsoft and press people. On Picture 5 you can see the Z1, the first computer ever, re-build by Konrad Zuse here (because the original was destroyed in the war).

Picture 8-10 are from my hotel in Berlin (Hampton).

And the rest of the pictures is from day 2 with various sessions I twittered a little bit about .. cool stuff.

It was a nice Tech-Ed, but not really for game programmers. There were still some interesting .NET and development topics. Now back to work.

ZombieHockey on iPad, Android Tablet, WP 7, iPhone, iPod, Android & PC

by Benjamin Nitschke 9. November 2010 12:22

Since I am presenting our Delta Engine here at the Tech-Ed Europe all day with our current free example game ZombieHockey, I thought why not blog about what I am showing here (excluding the iPhone which I needed to take the picture below ^^). We just were released on the WP7 Marketplace, you can download the Windows PC version and the iPod/iPhone/iPod version is coming this or next week.

Please note that the game itself (ZombieHockey) was written only once and has zero knowledge of the platforms it is supposed to run on. It is fully written in C# in Windows (only using VS2010) and utilizes our Delta Engine, which handles all the abstraction, content conversion, building and all features required for 2D and 3D games. It also runs at the maximum framerate on all platforms (using their native maximum resolution) and often only needs a fraction of the CPU and GPU power (iPad: 60fps, 80-90% utilization, iPhone: 60fps, 40% utilization, WP7: 30fps (limited by XNA), 25% utilization, Windows 7: 4000-5000 fps (with my home PC, on my netbook I have maybe 500fps still), Android: 60fps, depends on the device GPU however).

The Android version works, but since we are based on MonoDroid there, we cannot go live yet (MonoDroid is still in preview, but works great for us so far), but it will be available as soon as MonoDroid goes into beta and go-live is allowed :)

ZombieHockey now available on Windows Phone 7 for free

by Benjamin Nitschke 9. November 2010 10:51

After a long and painful approval process (lets just say the process gets better every day, and the process is still 10 times faster than Apples ^^) we are finally in the WP7 Marketplace. You can find ZombieHockey if you go in the new category, or just search for it :)

Please remember that this is just a demonstration game for the current state of our ZombieParty (the full version of ZombieHockey) is an iPad Party/Family game, we just brought it to all the other platforms (Windows, iPhone, iPod, iPad, Window Phone 7, Android, etc.) to show off our engine capabilities. You can of course also just download and play ZombieHockey for free on your Windows PC (iPhone, iPad and Android are also coming soon, they just have to be approved).

We have more exciting things in the works, by January we will have a nice 3D tech-demo working showing our SoulCraft game. Stay tuned!

New Delta Engine Wiki online

by Enrico Cieslik 8. November 2010 13:50

Delta Engine

With all the games and tools that we are developing with our Delta Engine, documentation is also very important and should not be neglected. Without it you can end up having quite ugly code that is hard to use and no one understands it after a while anymore.


Since we want to go open source with the Delta Engine next year (which isn't so far in the future), it is a very good idea to have a wiki for it. The question for us was which one of the hundreds we should take. In order to facilitate the decision a little bit, there are comparison sites such as WikiMatrix, where you can compare nearly all features of the wiki's without you have to install and test them all yourself.


After we had discussed what expectations that we have for our new online wiki, only 14 wikis were left.  We looked into them more closely and our decision fell towards the ScrewTurn Wiki, because from the installation, the features, and the handling were what we were looking for. Also the wiki is open source and written in ASP.NET with lots of plugins. Even if there is a feature written we can write it ourselves.


Since the last week, we have started to transfer our existing documentation to the new Delta Engine Wiki and still improve it here and there. Currently it is still in internal state, but we will move most pages from the internal wiki to the public part once we public features and the engine itself. In the wiki you can find our whole API reference, additional informations of all the supported platforms, How-To's, samples and everything else helpful for the development with the Delta Engine. Currently if you have questions or feedback, use the Forums, registering on the wiki starts only in 2011 (optional btw, we want to allow everyone to view and edit pages as long as we can maintain it).

Echtzeit Klub Berlin

by Karsten Wysk 6. November 2010 15:58

Am Freitag durfte ich beim Echtzeit Klub Berlin über die Vor- und Nachteile verschiedener Technologien zur Entwicklung von Apps reden. Überraschenderweise halte ich für Spiele den Einsatz von Multiplattform-Technologien wie die Delta Engine für die beste Wahl :)

Hier ein paar Eindrücke vom Event:


ZombieHockey released for PC

by Kirsten Grobe 5. November 2010 11:52

ZombieHockey is a free version of our Zombie Party iPad-Game.
This is the first game using our Delta Engine.


You can download it now on:
Note: You need a OpenGL 2.0 shader capable graphic card. .NET 4.0 is also required, but will be installed by the Setup if missing. We also finished the versions for iPad, iPhone, iPod, Windows Phone 7 and more, which will be coming out shortly (when they are approved in the respective AppStores).


Some screenshots from the Windows Phone 7 - Version: 





Disclaimer: The opinions expressed in this blog are own personal opinions and do not represent the companies view.
© 2000-2011 exDream GmbH & MobileBits GmbH. All rights reserved. Legal/Impressum


Which platform should Soulcraft be released on next?

Show Results Poll Archive

Recent Games



Jobs @ exDream


<<  April 2014  >>