The closer we get, the more we want to shove into it.

I’ve taken a break from unitcollection, even though i know it’s bound to need more work, to star working on some actual game experience changing issues. Most notably, texture processing. VS takes every texture it reads, and decompresses it from whatever format it happens to be in, then recompresses it in GL and generates mipmaps. This is extremely time consuming for loading of textures both at the beginning of a game, at the beginning of loading a system, and everytime a unit has to be loaded from disk. Not only is it cpu intensive, but it wastes a lot of ram. I thought DDS files would be an excellent way to avoid most of that and it seems to have worked. More work definitely needs to be done, but dds files load many times faster from disk read to GL rendering than the rest of the VS textures already. As more and more textures get converted to dds files, users should expect to see drastically lower load times.

The downside of such a great thing is that it needs testing before it can be considered stable. And we’re very close to what would have been a new release.

The other thing i’m going to be working on is cubemaps. cubemaps are hopefully going to replace the environment/sphere maps that we use now for space backgrounds. With any luck they should also be able to use compressed textures and natively have much less overhead than the current implementation for backgrounds. This work is slotted for ASAP, but finding the time is proving difficult with work right now, being the end of the month rush.

Another thing we’re trying to discuss and determine is how we want to organize the next release’s dataset and svn tree. It’s already been agreed that the new dataset will be data5.x and the current data5.x will be moved. What is still being determined is how we want to organize the texture maps. We want a repository for master textures (originals) so that we can update them, and read from them, and have them be separate from the compressed/lossy versions in the distribution. At least, that’s how i want to do it.

And finally.  My raided ext3 filesystem has finally succumbed to some corruption…which isn’t surprising since i’m running 24/7 without ac in the summer.

Hopefully i can get this worked out before the end of the weekend.  The corrupted parts are inside the data4.x dir …probably due to the constant activity in that area of the filesystem in addition to the fact that it’s a 500+ GB raided fs.

Anyways, good things are definitely coming.

After SIGGRAPH in San Diego this year, I probably spent 2 of my most productive Vega Strike hacking days in a long time with jacks.

We started simple, fixing bugs like the idling star streaks and the presence of spec interdictors on the bases, but then we got ambitious. Radar has gotten a long overdue overhaul so now a unit appears in at most one radar rather than both front and back, which makes it much easier to tell where the different starships are.  The problem where mission craft appear right in front of your nose is now gone, because we forced a minimum spawning distance. We made sure units would not cluster around the sun in generated systems and we improved the planet layouts in those systems so that the spec wells are not too harsh.

Our most noticable change has been the massive python mission reorganization causing all missions to look to a central area for naming conventions. Now missions should be much easier to complete since they will give both a flightgroup and a number in addition to the ship class for the ship needed to meet. Additionally they will enable you to cycle through friendly mission craft with a new key to make it easier to find far-off targets.

As icing on the cake we completely revisited the ASAP autopilot system. Instead of turning you onto a collision course to the object, the new system plots a nearly optimal path through the spec gravity wells to minimize your travel time to a far off target. Until your spec value is at least 100, you will be launch perpendicular to your origin planet, then you will slowly orbit around that planet until the object is straight ahead….at which point you will zip directly to your destination. When you reach the destination, autopilot will release control and put you at your cruising velocity–meaning you can set your velocity to 0, grab a quick snack…and when you’re back, you will be there— if of course– the pirates haven’t gotten to you first. Hopefully this improves the enjoyability of cruising around space. We’re still considering potentially allowing you to change targets while in ASAP but have it continue to its original course, instead of allowing you to redirect midstream. User input is certainly welcome!

Anyhow I have a feeling the 0.5.0 release is closer than ever before–and if we get time, we may have a few more surprises up our sleeve for that gem….