Odds and Ends

Entry posted by Josh · November 16, 2011

3,095 views

I implemented direct WAV file loading, and will add OGG as well. The MP3 file format has licensing issues, and we are not going to support it. However, if you use a third-party MP3 converter, the editor will detect whatever converters you add and use them (see more below). We're using OpenAL for sound, but have a more in-depth implementation than in the past. Sound source management is important because you only get so many sound channels on most cards, and this is handled automatically, based on sound range. It's actually quite elegant because sounds are stored in the world octree, and only sounds that intersect the listener are evaluated. This makes it very very fast, and sounds can have any arbitrary range value. You can also get the length of a sample and skip to a certain time.

I decided it was important to be able to load TTF files directly. The FreeType library is quite large and isn't set up to compile for ARM processors. Aria has been working on that, which is good because dealing with compiling issues and other people's code is not my strength. I just got word that it was working on the last platform, so I will check it out tomorrow.

The direct loading of WAV, OGG, and TTF files got me thinking about textures...could we justifiably load images files directly, instead of automatically converting them in the background? I wrote a BMP texture loader, and although I got the loading and mipmap generation down to 28 milliseconds for a 1024x1024 BGR image, I don't think it's the right way to do things. Textures and models are complex files, and it's best to have the editor automatically convert them to our own TEX texture format when a change on the hard drive is detected. The only disadvantage is that if you are coding and working in Photoshop, you have to either leave the editor running or open and close it, if you want your TEX files updated. Or you could drag the image file onto the appropriate converter, but we know from experience that is unacceptable. I think automatic conversion of these files is best because:

Not all conversion code can be included in the engine library. The Autodesk FBX SDK, for example, isn't even available for ARM systems.
Some libraries like FreeImage, which is needed to load PSD files, are enormous. FreeImage compiled as a static library is 17 mb! That is way too much bloat for a mobile app.
Automatic conversion means you can add support for new file formats just by dropping a converter in the "Tools" folder.

I want to show you how the directories are laid out in the Leadwerks3D installation folder. Instead of switching your asset path around in the options whenever you want to load assets from a directory, we're going to use a concept of "projects". When you select a project, Leadwerks3D starts loading all assets from that directory, and sets the project's "Maps" folder as the default open/save directory for maps. When you are ready to make a distributable game, Leadwerks3D will read all the maps and scan source code files for asset files, and copy only the asset files you use into your final distributable game.

Root directory:

Templates for all supported languages:

A sample C++ project:

C++ and C# project files for Visual Studio, Xcode, and Eclipse are stored in a "Build" directory, each with a subfolder for the platform. This is how we manage the Leadwerks3D source code, because all those compilers can create a ton of extra files you wouldn't want residing in your main project folder:

Finally, I started the OpenGL2 renderer tonight, which is aimed to be identical to the OpenGLES2 renderer. This is my primary focus for now, as it is important to have one uniform renderer that looks the same on all platforms. Of course advanced graphics is our specialty, and I have already done all the research for new effects when I finish the OpenGL 3.2 and 4 renderers. Deferred rendering will work on OSX Lion, multisampled deferred rendering is already working on Windows, and other stuff like per-pixel motion blur is done.

We're nearly to the point of having a usable game programming library for four platforms, and only have one more library to compile for mobile. It's coming along nicely! B)