SlimTune Plans

I had to sit down and figure out exactly what to do about SlimTune. People really, really like that little thing, which is amazing for something I put together in six weeks. It doesn’t deserve to die, so I’m going to make sure it doesn’t. That said, it looks like it will be a while before I get back to it. January, to be exact. Unfortunately, I need to buckle down and finish my degree right now, and I can’t really afford to commit to a side project.

That’s the bad news. The good news is that I haven’t stopped thinking about the project, and I’ve figured out how to do some really sweet stuff. Let’s recap. The current release of SlimTune is a purely sampling based profiler. The goal is to enable instrumentation and hybrid modes for public use. They actually already work, except the data is thrown away by the frontend. I’ve been unsure of how to collect it in a useful way, but I’ve got some ideas now that will give you some serious detail. Min/average/max will be there, but who cares? I can give you a graph with timings, showing you the actual characteristics of the function. So if it often takes 5ms or 50ms, but nowhere in between, you’ll see two spikes at 5 and 50. The average might be 30ms, but that’s basically a bogus number in these situations.

I’ve also got some UI improvements scheduled. Probably chief among them is to fully enable custom visualizer plugins, so you can throw together your own views of the data. I’d really like to enable some kind of graphing support, but we’ll have to see how that goes. It’s tricky to find a chart control that also has favorable distribution terms. I was using MS’ chart control for the teaser photos, but it really sucks — or at the very least, I don’t understand how to use it the way I want to. Things get sized very strangely, for example. I’ll figure something out.

Oh, and people are practically begging for a way to save and load launch configurations. I promise you, that’s top of the list. It annoys me too. I did it in six weeks, remember? It will be fixed.

Now, here is the important bit. For those of you who are interested in SlimTune, I have a request! File issues against the profiler for anything you want. And I don’t just mean bugs. UI and other feature requests are welcome! You can even request things I’ve promised I will do. That’s totally fine. Hit me with everything you’ve got people! That way I know what’s most important to YOU, not me.

New Amp Day!

ToneLab LE, Cube 30, FSR Stratocaster

The Cube 30 is the new bit, replacing a Line 6 Spider III 15.

How is SlimDX August Coming?

Badly. Really badly. It’s a crashy goddamn mess and I am in the middle of starting a company and getting a degree. Maybe I’ll be able to get it up and running over the weekend.

Oh hell yes.

Remember our iPhone game, Aves?

We're new and noteworthy on iTunes!

Revolution, Part 2: BioReplicant Animation

I promised this a long time ago, and here it is. I prefer to let the video speak for itself. This is a demo from January, so it’s actually a much older iteration of what we’ve got now.

P.S. Of course I delete negative comments. It’s my damn blog!

Our iPhone/iPod Touch game is out!

Link

I’ll concede it doesn’t look like much, but honestly, the game is really addictive and fun. And it’s a dollar.

One of the technologies in this is the binaural audio system that I discussed earlier. On the above page, there’s a linked video — put on headphones and watch it. You’ll get the point very quickly. It’s even better in-game than in the video, was my experience.

There’s also the animation system, which is not really shown off that well here, but it’s procedurally constructed, like NaturalMotion (but better, we believe). At no point were any animations build in a modeler. It’s all done dynamically using relatively simple rules. The future games will leverage this tech more heavily, but at least as developers I think you can appreciate how awesome that is. The flying, the hits — it’s all physics based.

Did I mention it’s a dollar? Try it out. And if you do try it out, please take the time to write an honest (and hopefully positive!) review. It’ll go a long way for us if you do.

SlimTune Profiler Update

You may have noticed that the profiler’s development is completely frozen. No this isn’t an accident, and no it’s not discontinued or finished. I’ve got so much in store for it. The problem is that when I get into my projects, I get really immersed. Keeping up the pace on SlimTune basically meant SlimDX’s August release would never get done; I’m obsessive like that. So I made a conscious decision to freeze SlimTune until the next SlimDX release was out. (Also classes were starting.) That freeze was only supposed to last two weeks or so.

And if you keep track of what’s happening in the DirectX world, you can guess that I’ve been screwed over pretty solidly on that one. I’m not sure when I’ll actually be able to get moving on SlimDX, so I may as well bring SlimTune back to active development. Initially, I had intended to discontinue the 0.1 release series and step to 0.2, which was going to provide more profiler modes. However I got some good feedback on the 0.1.5 release that I’d like to incorporate a release, so I’ll start by putting out a 0.1.6 that will basically clean up a few bugs and inconveniences in the current release.

As for the 0.2 release series, let’s see what happens. Instrumentation is actually pretty close to ready, so maybe I’ll get that out the door and throw in some other support functionality too. There’s some prototyping happening with regards to support for native code as well, so who knows. Maybe there will be an initial implementation of that available, too. I’ve got a lot more invested in this project than I think anyone realizes. Don’t think I’ve given up.

P.S. Last I heard, the DirectX SDK was going to be released last Friday. So I have no earthly idea what’s going on.
LATE BREAKING NEWS! August 09 DX SDK is out!

My Fender Stratocaster

Okay, so it’s been a long while since I had an entry, and this time we’ll actually step away from technical matters to a different passion of mine — guitars. I’ve owned several, but the subject of today’s talk is my beloved Fender.

I bought this thing in 2007, after deciding that I really wanted to get back into playing guitar. I got it brand new from Guitar Center online; it’s a Fender Standard Stratocaster, which is a Mexican made model. This particular one is a “Fender Special Run”, FSR for short. It had the HSS pickup layout with hot pickups, a turned aluminum pickguard (that pattern is etched), black painted headstock, and a single piece maple neck + fretboard. In short, it started out in life as a rather unique guitar to begin with.

As with most of my things, I couldn’t bear to leave it stock for very long. The electronics are completely redone, and it has new GraphTech String Saver saddles instead of the original junk that Fender provides. It has strap locks as well — they’re the ever-popular Dunlops. It’s due for a new tremolo unit and nut, maybe even tuners. That stuff will have to wait until I have money again though. In the meantime, let’s look at what’s under the hood…

I went through a lot of possibilities for the pickups, but finally settled on BG Pups. They are handwound, and the guy who makes them is active on the Harmony Central forums, and he’s always eager to make adjustments to the pickups to suit each individual. Not only are the prices good, but he actually gives forum members a discount. So I talked to him and settled on a pair of hot wound Vintage 60 pickups, without the stagger, for my neck and middle pickups. For the bridge, we picked a Hellabucker. All of the pickups are AlNiCo 5, and both coils of the humbucker are magnets. I was actually trying to emulate the sound of the stock neck pickup that Fender had, but without the suck. These did a beautiful job of that. The bridge was basically meant to be as hellishly aggressive as possible without sacrificing tone; that, too, is handled amazingly well. Listen to the clips on the site if you’re not convinced.

The electrical setup is a bit more complex as well. I chose to use 250K tone pots and a 500K volume pot. That gives me a rather bright sound with everything turned up, and a LOT of range to back things off. (The volume pot is dramatically different between even 10 and 8.) I also wired the bottom tone control to the bridge instead of the middle pickup. The volume pot is a push pull that engages a coil split in the Hellabucker. The Hellabucker’s been wound so that each individual coil is about as strong as a Vintage 60; I get a pretty good Stratocaster sound out of it, though not quite the same of course. It’s a little beefy, thanks to the setup of the Hellabucker, and that suits me just fine.

I absolutely love the sounds this thing gives me, and it’s also got an amazing ability to produce a good fascimile of almost any sound. (Except it doesn’t do a great job of pretending to have a neck humbucker, sadly.) The unconventional electronics setup is a big part of that; I’ve deliberately dialed in a ton of treble, and I use the tone knobs and my amp to keep that in check. Still, it’s not a mellow guitar by any stretch. And that’s how I like my guitars, to be honest.

SlimDX August Release Plan

I probably don’t need to tell you that it has been an incredibly long time since the last SlimDX release. That’s because it has been an incredibly long time since the last DirectX release. The reason seems to be somewhat quirky schedule planning on Microsoft’s part; basically they’ve decided to hold out on the next SDK until they have a completely stable Windows 7 compatible release. (IMO they should’ve done a release in June but okay fine.)

I do know two things. One, the SDK is branded as August, so unless they screw this up really badly it should arrive soon. Today is Wednesday; my guess is it’ll show up Friday mid-day. I have confirmed that there’s a bunch of new functionality coming, which of course we’ll have to wrap. That will take some time. Not sure exactly how much, but it will be at least a few days to write and check that code. IOW, our August release will actually come out in early September sometime, hopefully before Labor Day. It will have fully merged support for 10.1, 11, and Direct2D. DirectWrite remains as a maybe.

SlimDX Performance Tips and Tricks

Previously, I discussed some of the inherent performance costs that SlimDX suffers. Although that’s somewhat educational if you’re evaluating SlimDX, it’s pretty useless if you’re already using it and would like to get the most out of your code. This time, I’ll go over what you can actually do to make sure you’re running optimally.

There are two big problems with managed vector/matrix math, and this applies just as well to XNA. First, all of the types are value types, and passed by value to operators. That means when you multiply two matrices via operator*, two matrices (32 floats, 128 bytes) are copied onto the stack, and then another one is copied back into your result. This can get quite expensive, and the solution is to pass by reference, not by value. Unfortunately that means operators are a problem for performance sensitive code; you’ll have to use functions like Add and Multiply instead.

There’s also the problem that generally speaking, vector operations are not candidates for inlining. They’re too big for the JIT’s metrics to pick them up as inlining candidates (the 3.5 SP1 revision may have changed this). For small vector operations, this can again become a substantial cost. Unfortunately this is a messy one to deal with, as you can’t ask the compiler or JIT to inline things for you. The most effective approach I’ve seen is to replace vector operations in stable code with hand-inlined code. Farseer Physics uses this method, and wraps the inlined blocks in #region to clarify what’s going on. Yes it’s incredibly tedious, but if that’s what you have to do, then there it is.

Don’t use strings as effect handles if you can help it. We have to convert from Unicode to ANSI internally, and create a temporary handle. This gets slow and can cause other bugs as well. In future releases, this problem will actually be alleviated somewhat, but it’s best to avoid it completely.

Also make sure that SlimDX itself is configured correctly. These settings in the Configuration class. For example, object tracking is an incredibly useful debugging feature that tells you what objects you’re leaking and where they came from. But because it records call stacks, it’s also quite expensive. The default setting is for it to be active; turn it off for production builds. Also consider disabling exceptions for return codes you don’t care about (device lost and device not reset are common ones), instead of catching and ignoring.

Be careful with get properties and functions. An object’s Description property will always call GetDesc() on the underlying object, and then return a whole struct. This can get expensive quickly, especially if you casually access the property multiple times. We’ve chosen not to cache much of anything in SlimDX for the time being due to some nasty bugs early on. Querying data is expensive as a result.

Anything involving callbacks and callback interfaces is bad news, and it’d be best to avoid them for performance critical code. Every time you cross the boundary from managed to unmanaged or back again involves overhead, and for callbacks we end up bouncing multiple times — all while doing various kinds of fix up and data marshaling. Texture.Fill in particular is incredibly slow.

If you’re working with large amounts of raw data that will be sent to SlimDX, consider using DataStream, especially as a replacement for (Unmanaged)MemoryStream. When you give SlimDX a generic Stream to work with, it has to allocate a buffer large enough to hold the data, read all the data into the buffer, and then copy that into the target native DirectX buffer. This is quite inefficient for certain types of data that are already in memory. If you hand us a DataStream, we can skip the allocation and read, doing a fast memory copy only.

Hopefully that’s helpful. I’ll update this post as I remember more tips.