Tuesday, June 20, 2006

SpaceRocks! update (finally)

Tonight, I finally had the energy to work on my computer some at home. And, since the beta build of Flight Simulator X kept dying on me before I could take off, I decided to do some code work.

A while back, I finally got around to converting the SpaceRocks! code to use a high performance timer (the one included with the DirectX SDK, slightly modified), instead of just using a simple frame counter.

This is a Good Thing™. And a difficult thing. In game programming (at least my game programming), I have found the need for several constants. I originally tweaked these constants to get decent playability (like in version 0.0.8). After switching to the high perf timer, I had to re-tweak nearly every constant. So, that’s what I’ve been doing for the last few coding sessions.

In addition to tweaking the game settings, to achieve some measure of playability, I also tweaked the particle code. Finally, I am fairly happy with the particles, and how they behave. That was much more of a frustration than I thought it would. Over time, I will continue to play with the particles. Specifically, I plan to change them so they attenuate over time, and I am going to randomize the colors somewhat. I’m planning on specifying a base color, and creating particles whose colors are close to that base, but not exact, with probably a few white ones thrown in for fun.

Lots of good stuff, for a couple of hours worth of work.

Oh yeah, cruisecontrol.net is working just fine. I was having more source control issues, but they seem to have cleared up (magically). Actually, now that I think about it, the computer was rebooted due to a power outage. I bet that cleared some cache somewhere. I had been making changes to the config file, and relying on the service being restarted to apply the changes. I wonder if the hard reboot forced some changes to be applied that were being cached before.

It’s actually building right now, as I type this. Beautiful, isn’t it?

Question for Eric Sink: Do I need to purchase a seperate Vault license for the cc.net service?


Zman said...

There's no need to use the hi res timer from dx any more. .Net 2.0 added System.Diagnostics.Stopwatch that wraps all that interop stuff very nicely.

Cullen Waters said...

You know, I read an article about the stopwatch, and it didn't even register. Guess that will be my next refactor.

Eric Sink said...

Short answer: No, you probably do not need a separate Vault license for cc.net.

Long answer: Each Vault license allows one active named user account. If your build process needs to have its own named user account, then you need a license. But I doubt that to be the case.

Cullen Waters said...

I guess my question was poorly stated. From the SourceGear point of view, is it allowable for my build process to use the same named account as I do?

The build process is only performing a glv, and doesn't check anything in. Generally, it runs while I am not working with Vault.

Thanks for the quick answers.

Eric Sink said...

SourceGear has no opinion on what consenting adults or build machines might do when sharing the same Vault account.