Developer @ Chaotic Box

I've uploaded a small patch for the Display Overlord classes that fixes some issues with the gamma fade-in/out functions. Grab it on the Open Source page.

It's officially the "month of updates"! This new release (available on the Open Source page) features a big overhaul of the FMOD Ex start-up sequence and core functionality. The start-up sequence now conforms to these specifications as recommended by the FMOD dudes, and the classes now give you (nearly) full control over every FMOD Ex init parameter. You can also enumerate drivers, pick outputs, choose speaker modes, and so on. Don't worry though, you don't have screw around with all that if you don't want/need to - one simple call will still choose the best/default settings automagically.

Part of the core overhaul means the classes now support multichannel and surround sound hardware. If you've got a 5.1 or 7.1 speaker setup the 3D engine will automatically take advantage that hardware (sadly, FMOD Ex only supports real surround sound on Windows, best you can do on Mac/Linux is Prologic). You can also configure stuff like ASIO output and "raw" speaker modes to manually map audio through pro-level hardware.

There are some other goodies in there, like being able to read (and in some cases modify) raw PCM data, plus a bunch of bug fixes and shiny new documentation. Also, don't let the perpetual "beta" status scare ya off - these classes have been used in shipping products for years now. "Beta" just means they aren't done yet. I have recording and waveform plotting classes near completion, and some big 3D audio updates planned as well.

I've posted an update to my OxMath classes on the Open Source page. I usually apologize when I make API changes, but not this time! Plenty of stuff has changed but these classes really needed a refresh in the API department. What I should apologize for is not sticking a "beta" tag on the previous releases

I also spent some time to fully document the classes (view the docs online). Other than that there's plenty of bug fixes and useful additions, plus a workaround for a nasty Rb bug involving Ptr on x86 builds. Unfortunately that workaround meant wrapping pointers with memoryblocks and using slow accessor methods, so certain vector-array operations may perform less than stellar on x86 targets. The good news is that bug was quickly fixed (thanks Aaron!) the bad news is it wasn't reported in time to make the soon-to-be released Rb 2008r1. So, I've got the fast path rigged up to automatically kick-in on PPC builds or when building with Rb 2008r2 and up. Intel Mac OS X targets will also avoid the slow path most of the time by hitting the (fastest) SIMD path so this will mostly affect Windows and Linux builds till 2008r2 comes out - them the breaks.

I'll also point out that these classes should make a nice companion to Tinrocket's recently released OpenGLSurface Plugin. OpenGL is very cool but usually requires a bunch of math to back it up.

When you import an image into your REAlbasic project you may or may not realize that upon compiling, Rb converts the image into an uncompressed internal format (BMP or PICT most likely). It may even mangle it in some other fashion, such as ignoring the alpha channel.

Losing your alpha channels is an obvious problem, and another potential issue is a increase in application size. That 50Kb PNG file you've imported may convert to a 500Kb resource - add a few more images and you could hit a resource size limit on some build targets.

One workaround is to keep your images external and load them at runtime. Here again you may run into some alpha channel issues but at least your carefully compressed images remain compressed till they're needed.

Another solution is to trick the IDE into treating the image files as strings, then use a plugin to convert the strings into Picture objects. Several plugins can manage this conversion - my own PNG Utilities, Einhugur's GraphicsFormats, and the MBS Plugins to name a few. Now for the "trick" part: Before importing the images into your project, change the file extension to ".txt" or ".dat" (or anything else Rb won't recognize as an image file format). If you're running the Mac OS X IDE you may also need to change the file type to "TEXT" or remove it entirely. A bit of freeware such as Quick Change will manage that easily enough.

Once your images are in the IDE and the IDE thinks they're plain old strings you can have at them with the plugin of your choice.

... This entry was inspired by a recent thread on the Rb NUG, but similar questions have shown up on the NUG, forums, and in my email box from time to time. Hopefully someone somewhere finds this info useful. ...