Since the last release in April, artists have been working on modeling, texturing and integrating new space crafts and installations into the Vega Strike game.

Bringing an asset such as a vessel up to the point where it is usable is a long and arduous task. It starts with the selection of an appropriate candidate from our recently reorganized 3D Models list. The artist must consider the model type, role, and specifically the faction to come up with an adequate concept proposal contemplating the architecture and texture of the model.

Early model concept

Once the concept is accepted, the modeling can commence. While small models can consist of a single mesh, larger or more complex models can be subdivided into several sub-meshes. In addition to the larger scale architecture, a good model will convey its dimensions by adding smaller features like doors, openings, pipes, ladders, cranes and other small scale features. This process is called greebling. After finishing the model, it needs to be unwrapped to provide the outline of the shapes for subsequent texturing, which is mostly done using a paint program like GIMP. Depending on the intended material in various model areas, the textures for color, specular, and glow are painted. Once the main model is finished, marker objects for docking ports, engine thruster exhausts, turrets, subunits, and blink lights must be positioned around the model. Additional meshes for shields, smaller levels of detail (LOD), and simplified collision meshes might be provided too, though it is not a must. After export of the meshes and markers, the unit is ready for integration into the game data.

Placement of thruster markers on the Archimedes model

The integration of a unit has for long been a very tedious and error prone process mastered only by few. With the advent of modding tools, in particular the Unit Converter, which will be discussed in a separate devblog, the integration promises to become merely a task of pointing the correct textures to corresponding meshes. After conversion of the meshes from Wavefront obj format to Vega Strike internal bfxm format, we need to provide a HUD image and tweak the multitude of unit stats, ranging from the unit scale factor to the item categories that a base offers for purchase.

My intention so far was to give you a short glance on the many tasks involved in getting a new unit into the game. Nevertheless, what you were probably hoping for, namely information on models added after the last release, is what I won’t let you wait longer for.

In the space craft fleets of the major factions we have excellent contributions (the majority of which are from the shipyards of our talented modeler and texturer Fendorin where not mentioned otherwise, but also other artists noted besides the models):
* Archimedes
* Bell
* Ct1000, Ct2000, Ct3000 (by rivalin)
* Derivative (by Deus Siddis)
* Determinant (by Etheral walker and Nózmajner)
* Emu
* Jackal (by Oblivion)
* Kahan
* Knight
* Tridacna
* Xuanzong

We had also updates on already existing models in terms of improving the mesh and/or textures:
* Entourage
* H496
* Mk32
* Regret
* Vigilance

Curiously, when starting to work on installations, I have come across one station, the Diplomatic Center (by Strangelet), that has been sitting in the data set probably for years already but never has been spawned. There are also three older contributions by Oblivion (who is now involved in Angels Fall First game development) that have been added:
* Uln Asteroid Refinery
* Uln Refinery
* Uln Commerce Center

Fendorin was active constructing bases in Rlaan space, but not only. The new stations of this craftsmanship that a space faring traveler may encounter:
* Civilian Asteroid Shipyard
* Rlaan Commerce Center
* Rlaan Fighter Barracks
* Rlaan Medical
* Rlaan Mining Base
* Rlaan Star Fortress
* Shaper Bio-Adaptation Station

Including new units into the game is not the only work that was done. We have upgraded most of the vessels HUD images to higher resolution and better quality and were careful to outfit the new additions with engine thruster exhausts, turrets, and blink lights.

Mechanist Built Mk32 Battle Cruiser with H496 shuttle flyby.

We will continue contributing (as we’ve still got some uncommitted models up the sleeves) and hope that you enjoy the work we have been putting into making the Vega Strike universe a richer experience.

Pyramid

While August may be synonymous with “vacation” in many parts of the world, in my particular academic discipline, August is currently one of a number of months synonymous with “conference submission deadlines” (my field of computer architecture being one in which conferences, rather than journals, are the primary paper targets).

As some of you may have noticed, I’ve been (mostly) incommunicado for the last few weeks, and I’ll continue to be out for at least the next couple of weeks (until after the HPCA deadline). However, if anyone does need to reach me, I’m still checking my VS-related e-mail, just not keeping up on forums at the moment.

Graduate school has been particularly demanding of my time in 2008 (thesis proposal and related prep taking up much of the first quarter of the year, and then much of the next several months trying to make up time lost working on the proposal rather than paper-oriented research :-P), but, with any luck, I’ll both have some new publications to show for it in the not too horribly distant future, and some breathing room in which to commit larger time blocks to VS. With luck or without, there are no deadlines in September, so I’ll at least be much more involved than in August :).

For those of you who get to take some time off - enjoy yourselves

For those of you poor fellows who’re  slaving away at conference deadlines - if you hurry, you can still make ASPLOS instead of HPCA ;-).

Recently, there were a lot of questions on why we are renaming extensions for image files and textures. The changes were started after the 0.5.0 release and can be found in SVN only at this point in time. They will be in released versions from 0.5.1 on.

In 0.5.0 we had png, jpg, and bmp and the extensions did not necessarily represent the codec used in the file. Having files with .bmp extensions that in fact were .jpg, or .png, was completely messy. Also, with 0.5.0 we have switched all in-game graphics (images and textures) to use one of the S3TC DDS compression algorithms (DXT1, DXT3, or DXT5. See info on compression in http://en.wikipedia.org/wiki/S3_Texture_Compression). This means that the exiting extensions became misleading and obsolete.

The S3TC (DDS) compression is currently the most widely used and has the best tradeoff between memory/bandwidth consumption and graphics quality for most of the cases as compared to other compression algorithms like Dithering, 3Dc, or FXT1 (see comparison in http://www.digit-life.com/articles/reviews3tcfxt1/) and is being supported by all GPU manufacturers and the two most prominent graphics APIs, DirectX and OpenGL. This still does not mean that it will remain that way in the next 2-5 years (for example see the specialized normal map compression algorithm in http://ieeexplore.ieee.org/iel5/4089190/4089191/04089271.pdf).

The above issues (compression and naming mess) are the two main reasons that have lead us to the conclusion that renaming graphics extensions is of advantage giving us at the same time clarity about the contents of the image or texture and preparing the ground for any future codec changes that might come on the way. With this changes we are bringing our support for texture compression up to state-of-the-art.

The renaming is well underway with only small portions of data still open up for conversion. The new extensions come in 2 flavors:

• .texture contains, besides the base texture, mipmap levels and is used everywhere where objects are drawn at different distances, i.e. in space. The GPU will automatically switch the mipmap level according to the object’s distance from the viewer. There is no reason to draw 1024×1024 pixels when a ship is 15km away and only visible as one or two pixels on the screen. Textures can come with transparency (e.g. sun flares) or without (ship diffuse textures).

• .image files are graphics without the mipmaps and are used for all graphics where the distance to camera does not change. Space backgrounds, cockpit gauges and HUD images are the places where we apply the image type in space. Mipmap-less images are also used for splash screens, cargo/weapons/upgrades, base and planet backgrounds, to name some of the used places. They equally can come in transparent or opaque flavors.

There is no association whatsoever with specific directories where the files reside. For example, under the animations folder we will find subdirectories with .image types (for comm animations or splash screens) and other subdirs with .texture types for example for explosions or blinking lights.

The idea was that .image and .texture aren’t misleading, there are no existing file formats with that extension. And, since it’s format-agnostic as well, it will also make things easier to maintain in the future since a change in format (say, make them png) needs no change to the resources referencing them (like sprite files, animation files, meshes, or system definition files). And this is the point that makes the rename really necessary, since especially mods have asked for support of higher-quality textures by replacing the dds textures with lossless png textures, or high-quality jpegs. If we said “let’s rename them to .dds”, then the mod would have to have a dds file that was a png. So the only real choice is the format-agnostic choice. Since, over time, the desired codec used for images has changed and will be changing with the available technology, we decided that a codec agnostic extension was the best course of action to stop the constant confusion that people have been experiencing when the filename’s extension doesn’t match the real codec used.

The renaming might be annoying for those who have to re-download all graphics again. Though we were very careful to use the svn move command for renaming, it appears that svn doesn’t want to behave correctly in all the cases and, instead of moving also the files in your working copy, makes a completely new download. But this one renaming and re-download is to stop any need to change the names ever again whenever we change the underlying data type and to stop user confusion over conflicting info. It should have been done long ago, but has always been put aside until today.

The recent folder structure was also changed on they was and is now as follows:

• data holds the dds compressed images and textures
• masters holds the source and project files used to create the art and master images with the correct codec-dependent extensions.
• hqtextures holds the non-dds compressed high quality png or jpeg files (though with the same extension as in data).

This means that the data folder isn’t intended for artists at all. It’s only VS UTCS game data. You have the masters repository where things have proper extensions and are artist-friendly, but data needs not be so. This means that you shouldn’t be editing data images but always edit/generate master images and then export to data. hqtextures are optional if you want to see in-game high quality graphics. It will not be compressed on loading into the GPU, so beware, the memory consumption will increase. You have been warned.

With the renaming comes the question: how can I view the images and textures without resorting to a complete masters repository download? It is possible, however your viewer will be required to understand the dds format. For GIMP (Win/Posix) and IrfanView (Win) there are plug-ins available that can read dds files (see http://vegastrike.sourceforge.net/wiki/Links:Graphic_Applications#2D_Graphic_Converters for a list). Several viewers come with native dds support (e.g. KDE supports DDS hence also GwenView, KView, and Konqueror). If in trouble, try renaming the graphics to .dds or .png and see if your application can read it.

Actually, all software should rely on file magic mime typing to determine the codec type of the file (where such a distinction can be made) and not extensions. Extensions are for humans. In theory, no application worth using should give any problem about .image or .texture file loading if it has the appropriate decoder installed. Unfortunately, the reality can be different and a bit more annoying. In Windows, there are several ways of associating extensions with specific applications (e.g. Open With../Always use this program…), which should ease the desktop integration of the new extensions. In Linux you can do a similar operation (Open With…, select the application e.g. GwenView or KView, and check “Remember application association…”) and will be able to view the images directly from Konqueror. While there might be other ways under Linux which I haven’t yet explored, Mac remains black magic to me.

Hopefully this clarifies things up a bit.

I just felt bored at work and decided that it would be good to give a heads up on what’s going on with things.

First, we have all the svn activity lately.  This is going to probably annoy everyone because of all the redownloading and annoy those who package VS even more.   We’re sorry.  This had to be done sometime, so we figured early on in the next dev cycle was better than later.   Basically, all the images in VS’s data repo are named based on their original extensions.  Over the years the datatypes changed, but the names remained, due to people not wanting to edit all the files that referenced that image and potentially break something, so out of laziness.   Then the switchover to DDS further compounded the problem becuase now, most image viewing apps would error because they didn’t have the dds viewing plugin and the user would see the filename as being a plain .png or .jpg and get all confused.   So we felt the need to standardize the naming extensions of the various images in VS based on usage.   No longer using the codec extensions frees us from ever having to do this again. 

Second, 0.5.1 is coming along nicely.   Code-wise, we have only a few (but important) changes left to get done.   Most of the work left to do for the release is data side.  Most of that is shader specific.  Best estimates right now put the release at a month from now.  This is a bit more trustworthy than the estimate for 0.5.0 that was about 6 months off target. 

 Thirdly, we’re working very hard at being more cohesive in direction and communication. Any users reading this, would be well informed to visit freenode’s irc network and join #vegastrike.  The plans we’re making and the directions we’re taking are being followed and taken seriously by all working on VS, and that will translate into faster and tighter releases as we approach 0.6.0.   Users who wish to have a more weighted effect on the roadmap should try and have more directed and explicit feature / bug fixes.   That is to say, rather than suggest something that has no hope of being worked on in any immediate release, try and think of things that bug you or could be tweaked that are neither vague or require rewriting huge parts of the game.   More pinpointed suggestions for pet peeves I think are better.   A list of things that bother users about how the game currently works would be neat too. 

 I guess that’s all i got to say about that.

This has been discussed for a while, but there are going to be some major SVN repository changes for all users.  As you know, we have released 0.5.0, yet our repository is still called “data4.x”!

A “4.x” is terribly confusing, so I have moved the repository from “data4.x” to “data”.  Oh great, you are probably thinking, now I have to wait for another Gigabyte of Vega Strike data to download.  Well it turns out that luckily for you, SVN will not require you to waste bandwidth if you follow certain steps that I’ll outline below, and document in more detail on the Wiki.

Also, we are making one other change as well that will help users of all platforms download the necessary files… we will make a “win32″ and a “mac” folder that you can download and have a working application.

See the Wiki for more information on how to convert an existing repository:
http://vegastrike.sourceforge.net/wiki/Moving_data4.x_to_data

or, for information on how to download from SVN, see:
http://vegastrike.sourceforge.net/wiki/HowTo:Checkout_SVN

Hi Folks! I just wanted to let everyone know how excited I am that we got this release out the door! First of all it should be fun to have a system that should work on all modern platforms with installers for 5 major platforms (Windows, Linux-32, Linux-64, Mac Intel, Mac PPC).  

Since pyramid just made a post about the artwork, I’d like to talk some about the code. This release should finally provide some polish to the new warp system, some interesting and improved gameplay and very scenic systems that are now populated with hundreds or even thousands of ships each.  To do this we needed to completely revamp the physics system with jacks idea of asynchronous physics simulation atoms.  We also needed to optimize the heck out of the game. Thanks to Safemode’s DDS code, we can load compressed textures directly onto the GPUs without decoding them from png first. And our talented artists just keep on contributing, from beautiful models to high resolution planets! What really needs doing now is for the artists to come together and start generating normal maps for our ships so they appear to have higher detail geometry. Take a look at the starting ship, the llama in game and notice the high resolution bump maps!

And most importantly of all, with Safemode’s contributions to the collision library we are legally allowed to distribute this game again after a brief period where it was discovered that the Crystal Space collision system was using GPL-incompatible code!  So we’re 100% free software again: congrats Vega Strike.   

This occasion also marks the 10 year anniversary of Vega Strike.  If you go back to the archives and find the first blog posts, you can see the first public release was in april of 1998.  With any luck, since this is 0.5.0, that means we’ll have 1.0.0 (the space sim to end all other spacesims) out in 2018 ;-)   

Speaking of game changing features, 0.5.0 marks a very nice place since it allows us to become more experimental in the subversion head.  This means more development focus on multiplayer, which we will allow users to test in spurts (right now public access to the MMO version is blocked…but that’s simply because the server has a few bugs that we didn’t want to delay the release for).  But multiplayer is coming–all of the feature-driven code is there and it’s mostly just bugfixing from here on out!  This means in the next few releases we should start to see more heavy multiplayer integration–and in this release you can setup your own deathmatch servers with the provided vegaserver executable! 

So as you can see the state of the Vega is strong. 

Not yet.

Soon, though.

I’ve been working on the past few week (maybe month?) on getting movies support (using the ffmpeg library to decode pretty much about any format you could think of). I’ve already commited video playback code, but video streams without sound are boring… right?

Lately I’ve been working on getting audio streams out of video files, and it’s been quite some work. For one, I didn’t want all that work to go to waste later, so I’ve been trying to code it in a useful, reusable way. I think I managed to write it in a way that could be reused in the eventual rewrite of the audio system. For two, I’ve been greatly tempted to start that rewrite right now - getting streaming using the current audio system in VS is… challenging. I’ll probably be hacking my way around VS’s aldrv API (the one that handles audio calls).

As much as I’d like to rewrite the entire audio system, the reality of things is that movies are required by many ASAP, so I will struggle hard to overcome the temptation

The code to handle various codecs, needed since we want ffmpeg to be a compile-time option, has just been finished. I’ll probably commit it as soon as it builds without issue, although it will not be linked to any part of VS.

Those curious to know how the upcoming audiosystem will look like are welcome to peek into that code (src/audio), to get an idea of, at least, the coding style involved.

Stay tuned - you may even get radio support on VS after all! (ffmpeg does support network streaming) *

* disclaimer: theoretically possible, but nowhere near available right now. However, the guys against it have one reason less to think so :-p

To slightly sweeten the remaining time while (impatiently) awaiting the 0.5 release, here’s a short update on the recent graphics developments.

Support for mipmapless DDS textures for space backgrounds has been enabled in the recent version (thanks go to safemode), which will reduce the memory footprint used by your graphics card and further speed up system loading. Two missing backgrounds have been also added to the data set.

More planet textures have been improved over the last month. Now all 74 exo-planet textures are of high quality (though I think I will go back to the gas planets and remake them after 0.5). The remaining 46 textures are from solar system planets and bodies. Here, the previously existing 2 different data sets have been joined inheriting the best textures and more than half of the solar system bodies have got additional improved textures. While all solar system planets have high quality textures (2048×1024 resolution ), I wanted to keep the remaining bodies as close to the reality as possible. However, freely licensed high quality maps for moons and other significant bodies are not readily available, so the approach was to reduce the release quality resolution requirements to 1024×512. Still 11 maps remain with lower quality (512x), probably until our solar system has been better researched and photographed. Nevertheless, the phase of improving planet textures is considered closed for now, and I will focus on other future tasks.

Finally, new and better planet rings are now available in the data set. They are of reasonable quality so that you may still enjoy them when flying close by. Further, 20 of the upgrade images have been provided with better quality pictures. And last, on your HUD you will notice that 3 indicators - the weapons capacitor charge, the FTL and JUMP drives energy, and the fuel status - have now a text overlay, so you don’t need to remember the meaning of each one.

You may wait for the new release or check out the SVN version to start enjoying the improvements already.
I hope that you will like those changes.

 Courtesy of Pyramid: 

Those who have been playing Vega Strike (the game) version 0.4.3 surely remember those blurry planets seen all over the universe. While a lot of work has been and is being invested into the game engine, we will also see many visual improvements in the upcoming release. I would like to give you here a heads up and share of taste on the changes you will find in the next release, some of which were only introduced after the last beta.

To the hangar and off we spec!

ps. 

if you notice weird stipled white bars across any graphics, please post your gl_version and gl_renderer lines from glxinfo or related app in the bug triage forum  http://vegastrike.sourceforge.net/forums/viewtopic.php?t=10588

As many of you know, our rapid collider is not 100% GPL compatible.  Thus, the mission of replacing it became a top priority for 0.5, and is one of the major reasons why it’s not released yet.

Well, after a lot of learning how our basic collider works (and still needing to learn more) I’ve got the basic opcode collider functioning somewhat in vegastrike.    That is to say, there is no raycollider yet.   Things are going to be slower than the rapid collider until we work out the general bugs, then we can start turning on optimizations and getting things streamlined.  At that point, we will probably remove the old collider from SVN.   And then after that get things using the raycollider.

In the coming couple of weeks, we’re gonna need people to test the svn head with –enable-opcode turned on in the ./configure script.  Backtraces of any segfaults are good, so are descriptions of performance (both speed and accuracy).    Compilation issues as well.   my hacks to opcode may mean that it doesn’t work on non-64 bit cpu’s or non-intel compatible ones…i dont know.  it’s gotta get tested on those archs.

The first person to leave such a report should do so in the bug triage forum under a topic to the effect of “opcode collider errata” or something.

When using vegastrike with –enable-opcode, dont be surprised if it segfaults or you can fly through things you shouldn’t.   We’re not really using opcode the way it should be right now (so we can mimic rapid collider’s api) so I may have done one or two stupid things in the process.   Hopefully now that it’s in a testable form, other devs can help me fix it up.

Thanks for testing.