Posted on

FutureTrade for free

On Christmas Eve of 2020 my father passed away and beside the grief I walked down the memory lane. This led to an intention, which I already wanted to realize multiple holidays ago.

My first commercially available computer game, which had been released in 2000, is not being sold for a long time anymore because the original publisher had been shut down. Some years ago I tried to start the DOS game in Windows 7 or 8 but there was an issue with the mouse handling when using DOSBox as emulator. The cursor stuck at the upper edge of the screen. I wanted to fix the problem and installed the original development environment in a virtual machine. But all in all it claimed too much time so the everyday life took my attention away.

After last Christmas I made another attempt by looking into the possibility to install the original mouse driver. Research brought me to DOSBox-X, which is a derivation of the original emulator and has got more options. Utilizing that application it was possible to get correct mouse control.

After playing the game for a while I decided to re-release the game but this time for free. I figured out a way to publish a package, which should make it easy to start the game without the need to download multiple archives and adapt a configuration to match the file paths on the target PC. You can get it here. But be warned: There is only a German version, because the product was never released outside of Germany, Austria and Switzerland.

I did not stop there and also made the source code publicly available. It is mainly written in Turbo Pascal, has got few commentaries and is a mix of English and German descriptors but there are also some interesting things like working with interrupts, 16 bit address space or 2,5D terrain rendering in Assembler using less than 256 colors. Maybe it could be a place of discovery for digital archaeologists. Have fun!

And I want to dedicate that repository to my father, who like my mother supported my passion, which turned into profession and so enabled this game to exist.

Posted on

Voxels for Unity: Version 1.1

An update for my Unity plug-in has just been released at the Asset Store. It took me much more time to get a collection of new features and useful enhancements, which are worth to be published, than I had originally planned. Here are the key ones:

Voxels for Unity 1.1

  • Adaption to Unity 5.6 and 2017
  • Better results using PBR (physical based rendering) and HDR (high dynamic range)
  • Two fully working file exporter examples added: PLY (common point cloud format) and VOX (MagicaVoxel editor format)
  • Rasterizer enhanced by supersampling and multithreading options
  • API enhancement: Callback parameter to inform the executing script about the creation of new game objects
  • API extension: New class to decrease number of resulting materials in a processor to given amount
  • Multi-textured terrain included into the example scene
  • Bug fixes for minor issues

If you are interested in acquiring the extension to convert common Unity assets into Voxel objects or files, you can use the following link:

But if you have already purchased it or want to have a look into the manual before, here is the updated version:


 

Posted on

Voxels for Unity: The release version



“Voxels” is being published as an extension to the Unity runtime and editor via the Asset Store. Its purpose is to scan existing graphics for its colors or materials and store those into a three-dimensional data structure. Those scanned cells can be called “volume pixels”, or voxels for short, and are being transferred to processor classes. Two types of processors are included in the release package.
The first one constructs a hierarchy of game objects from the incoming data and attaches a specified mesh, a renderer and a material to every of its objects. The material is instantiated using a standard shader or a given template and modulated by the sampled color data of the individual cell. An optimization can be enabled to merge multiple voxels that share the same material into single meshes.
And the second processor is able to store the voxel data into a particle system, which is also instantiated by a given one.
Because there is a very simple programming interface it is easy to write own scripts, which are building other game objects, passing the voxels to volume textures, converting the data for (existing) scripts respectively plug-ins or even exporting them to be used outside of Unity. You can use the two included processor classes as blueprints for your own efforts.

But you can also stay away from programming and only utilize the user interface of the components to create appealing voxel graphics. The conversion can be done in the edit mode and while the game or application is running.

Converter inspector in edit mode Converter inspector in runtime while processing

It is also possible to mix inspector adjustments and scripting. For example you set up converter and processor properties in the editor but the operation will only be started when an event in the game like loading a level occurs.

The scanning process works by rendering the desired items in slices to off-screen buffers, which are being copied to main memory afterwards. Whenever a pixel is set, its color is added to a cell in an octree. Later the colors are being combined per cell using mathematical operations or a more complex algorithm for the most frequent color method. That way source materials, lights and shaders remain intact and you get a result comparable to the original, if the settings are right. And this solution is the unique feature of the tool because other, existing extensions are using the ray casting methods provided by Unity. Those methods do not perceive vertex transformations by the shader or material computations per pixel.

Voxels logo

Further on you can also create results that only resample the shape of the basis but contain total different surfaces and appear as holograms, dust clouds, artistic effects and so on. Another option is the ability to animate voxels, e.g. for detonating 3D models or transforming between different ones.

Converter inspector in runtime while processing

Unfortunately not everything works the way it has been planned. Shadow maps seem to become effectless and particle systems are culled in the scanning process because of the near depth clipping planes. Up to now no options could be found to prompt Unity to use other clipping values for shadow map creation or not to hide specific objects while rendering. But I am still looking for answers. Moreover I want to include new features into upcoming versions. Some will help to make the conversion more powerful, others may handle the results in various directions.

Posted on

Voxels: A personal introduction

In my free time of the past year I developed a tool for Unity, which arose out of Project: Evolution. For the planned main effect I need pixels in three-dimensional shape to advance graphically from level to level. Those cells are commonly called voxels, which is a combination of “volume” and “pixels”, and they have to be generated from 3D models with generic meshes like I did it for the 2D presentation in the prototype. So I started to program a solution to do the conversion and shortly afterwards a decision grew inside me. Because there was no plug-in comparable to mine I wanted to release it as a product, which other people can use.

The actual functionality for meshes had been finished relatively rapidly but at that state it was a quick-and-dirty implementation, which could be used in-house but was not ready to be published. I began to adapt the user interface and polish the functionality. And it lasted a long time and there are still sections to improve and features to be added. But I am satisfied by now and intent to release “Voxels overview” in the next days.

Posted on

COLLADA – A powerful file format for digital content creation

COLLADA is an XML file schema, which allows users to exchange 3D assets between various DCC applications like “Autodesk® 3ds Max®“, “Autodesk® Maya®” or “SOFTIMAGE®|XSI™” and other interactive 3D applications. It was originally initiated by Sony Computer Entertainment® America (SCEA) to create a development format for “PlayStation® 3” and “PlayStation® Portable” projects and became a standard of The Khronos Group, which also holds the OpenGL standard.

There are a lot of problems to transfer data from one 3D application to another, because every software uses proprietary file formats, which are optimally suited to the features the application supports. Most programs also support other file formats like “Wavefront Object“, which however can only store a small set from the features list. That way it is often only possible to convert model data like polygon meshes with a single texture coordinate set and more complex data like multiple texture sets or animations get lost. Even commercial converters are not able to translate every asset completely.
So for realtime 3D or game development programmers were forced to abstain from features, which were not supported by the file formats their team was using but which became more and more important with increasing game quality. Or you had to write an exporter or importer for every 3D application, which the artists were using. Just a single im- or exporter can be a lot of work.

A solution would be a standard file format that every application can read from and write to. The first attempt was “FBX®“, which is now owned by Autodesk®. It became free to use but a long time it does not solve important issues like exchanging multi-textures between programs because the existing plug-ins were not able to do that, even though the format itself could handle it. And there is no source code to extend the plug-ins by yourself. You still had to write your own for every application.
Today “FBX®” is the most common format for asset exchange between DCC applications but not important for game programming.

In October 2006 the COLLADA format had been published. It was and is open source, easily readable XML and extendable. But there were no plug-ins and no programming kits. Because “FBX®” has got a C++ SDK it was easier to write im- and exporters for that format than for COLLADA at this time. Fortunately some month later a SDK was released and the first plug-ins for programs appeared. Today many 3D applications support the format but not all major ones like “LightWave 3D®“, which we are using. However native support is announced unofficially for the current main version.

We have already implement a COLLADA file loader into a character animation plug-in for “Viz|Artist 3.0™” called “Action Model“. And currently I am using COLLADA as standard development format for “TigerHeart” II projects.
Files are being read using the SDK and converted to “TigerHeart” objects. These can now be modified using C++ and will also be changeable in a editor later. After that object data can be stored back without destroying original COLLADA data that was not converted or modified. In doing so multiple applications can access a COLLADA file, modifying its data without loosing something that was useless for a program. A sound editor may use some 3D data for setting effects but it cannot utilize textures. Although it does not destroy those texture objects by overwriting the original file at export time, because only new and modified data is updated to the COLLADA file database. That is no standard behavior for the COLLADA runtime but can be easily integrated using the SDK.

COLLADA has got also disadvantages. Because the format is very flexible, diverse programs can store their data differently. The programmer has to adapt his software for every utilized application. And even then an update of an application or its plug-in can force him to change his code. But this is being done lots of times faster than to write an im-/exporter for every proprietary file format.
Many common file formats have got the second downside. They are very slow to load and save because much data has to be interpreted multiple times. It does not really matter at editing time but loading time is essential for interactive programs and games. Programmers are able to accelerate reading texture file content using an own format and they also are able to do it with all other data. Generally speaking it is important to convert as few as possible and often to minimize bandwidth.
COLLADA files and other development assets could be converted before they are regularly used by the project or when they are finalized. That depends on the time you are saving during the development. In any case they should be converted before the product is delivered to the customer.

I believe that COLLADA will become the standard game development format one day, if no other competitive format occurs. Currently it is already utilized by some big names like Sony®, Google™, “3ds Max®”, “Maya®”, “Unreal® Engine” or “XSI™”.

Posted on

XML for engineering

The Extensible Markup Language (XML) can be used to store any given data. I am using it to design functions, interfaces, classes and other types for the second TigerHeart engine.

Besides pure XML files, which store names, parameters, result types, derivations and so on, there are also a schema (XSD) and transformation files (XSLT).
The first one defines basic types and valid elements, attributes, groups and sequences for the XML files. So their syntax is checked for mistakes. Both kind of files are free from programming language specifications like class or virtual for C++.
For that XSLT is available to assemble files that are usable for coding. The greatest benefit of the whole system is the convertibility of the XML files into various languages and even multiple files of the same language (e.g. .h[pp] and .c[pp] for C). It is also possible to automatically generate bindings of functions and variables for scripting languages and to build a documentation in HTML or whatever you want. For TigerHeart II C++ headers, source code files and Lua bindings are formed. Maybe there will be a time when XSLTs for C# are added but they are not currently planned.

XML: schema XML: sample XML: transformation XML: result

After the transformations I can add content to the created source code. If I have to change a type name or a definition later, then I only need to do it once in an XML file and not at every appearance in the code.

Posted on

TigerHeart

After my first game “FutureTrade” had been published I started to learn 3D programming, which was a wise decision because I needed it for my first commercial graphics engine some month later. It was developed for “BomberFun” and also used for a winter sports game called “Winterspiele 2002” and its successor “WinterSports Extreme“. But in the development time I began to realize that the design was not very good. Even it was object-orientated it was made up of one giant class for the game and one giant derivation for the editor. The engine was fast but inflexible especially using shaders and it was no real fun to program with it.

Early in 2002 I started the planning of a new engine. It should be really object-orientated, perform more common tasks than only graphics and be nice to use. The design was adopted from “Microsoft DirectX” because I love how the objects live up to their names. I started the implementation after “BomberFun” was finished and a new project was started in late summer and named the project “TigerHeart” because it is a good name for an engine.
The base of the system is the main engine, which is responsible for object management like COM but platform-independent, loading extension libraries like a plug-in and data storage and access. Meanwhile some extensions have gathered but the first and most important is the 3D engine using “Direct3D“. Different from the previous one there are a lot of classes for the various functions and attributes: renderers (frames, bodies, meshes), states (textures, materials, shaders), animation data (animations, sets, blenders) and some more. They are used to build a hierarchy, which can be processed or rendered with one command.
Next I created an extension for scripting and one derivation for “Lua” support. It is completely independent from the 3D engine but can be combined with it smoothly because of the “TigerHeart” design. There is the possibility to add support for another language, which is applicable immediately without the need for a change of the target program. But up to now there was no demand for it.

TigerHeart sample TigerHeart sample TigerHeart sample

For our bowling, card and air hockey games I implemented a compilation of class, which were based on the “TigerHeart” engine. But they were not flexible enough and not clearly separated from the games themselves. So I started to implement a game engine base as an extension library for the main engine at the beginning of 2005. It handles initialization, standard scene management, script access, multi-threaded loading, some user interface functions, console support for development, input processing and sound output.
The first use was for “Uli Stein – Summer Games” and later for “Balko”. We also developed our broadcast applications for the “Four Hills Tournament” 2005/06 and “tvVAT3D” as an add-on for it.

TigerHeart sample

Every now and then there a some design issues and some missing features, for which time was lacking. But we still currently use the “TigerHeart” engine and extensions for the development of a casual game selection. Anyway the planning phase of the second version has just begun and I will use this weblog to keep you informed. Maybe that would help you to design an engine or maybe there are times when you are able to help me in difficult situations.