About Gallery SF.net Project Bug tracker Downloads Forums Manual Wiki DevBlog News

Archive for the ‘Uncategorized’ Category

Python3 support comes to Vegastrike

Sunday, February 24th, 2013

In preparation for what will ultimately become 0.6, after many hours and an angry girlfriend or two, we give you python3 functional vegastrike along with updating boost to 1.53.0 (in-tree).

Get vegastrike’s repo at

https://vegastrike.svn.sourceforge.net/svnroot/vegastrike/branches/py3/vegastrike

and the data dir at

https://vegastrike.svn.sourceforge.net/svnroot/vegastrike/branches/py3/data

You need python3 to run this and the default option for system boost is reversed from normal trunk.   So disable the option if your in-system version of libboost_python is not up to 0.5x.y and doesn’t have a python3 target.

Right now we need as many people building and working off of the branch as possible to iron out any remaining bugs and issues.   It seems to be much less forgiving of code errors so that should help track down problems and get things even more stable than in the 0.5.x release.

NOTE:

It should work with your current savegame data, the python files will be re-compiled automatically.

This has only been tested on unix.  The Win32 side of things needs to update their build files to point to 0.53.0 for in-tree boost.   Though, that’s all they’d have to do.  There are no changes in defines needed or differences in filenames (added or removed) from the old 0.45 version of boost that was in the repo.

 MODS:

Those mods out there wishing to port to python3 need to first process their files with 2to3 and an indent cleaner.  Then go through and any non-loop uses of “range” need to be wrapped in list() to get the same functionality..  Also, they need to go through all their uses of division and ensure any int/int divisions are handled with // to keep the same behavior.  There aren’t many other issues that VS comes across other than that…. but little things may turn up so the porting process is a handle-as-needed thing.    Keep in mind, the current rev  13522 is identical in functionality to the 0.5.1r1 release but updated to handle python3 and boost 1.53.0 so any mods working with that but just want to run for the foreseeable future without needing users to downgrade libs can use this.  0.6 will contain many other changes that will certainly break 0.5.x mods .   

Vega Strike splits the Atom

Thursday, May 31st, 2012

Meaning… if you run it in an Atom, be ready to watch it break in half due to the load!

Vega Strike has always been GPU-hungry, there’s no denying. Ever since the 0.5.0 release, it has also been RAM-hungry (or, more specifically, ever since we had to retire soundserver). But, as those that tried may have noticed, and as those that read the forums may have read, this description isn’t entirely accurate on the netbook front. There, rather than hungry, I’d call it starving.

Now, I’ve only toyed a little bit on an N5xx, so this is far from a thorough report. But, since the devblog has been rather quiet lately, I started writing.

Compiling

Right before building for the N5xx, I thought, I need proper optimization settings. There’s no point in benchmarking the game if the build won’t be optimized for the (rather different) hardware. Luckily, gcc “recently” added a nifty “native” optimization option - it just detects the CPU being used, and optimizes for that.

Building on the dual-core HT netbook was great. That little machine managed to build in about half an hour, which is what it took to build VS on a P4 1.7Ghz I had, or a P3 1Ghz - they both took the same time. Given that the netbook consumes a whopping 8.5W, I was surprised. That is undoubtedly the “quad-core” effect - I had heard HT on these architectures worked a lot better than in newer ones, say Sandy Bridge, and I could go lengthy about why - but suffice it to say: it’s true. “make -j4″ really paid off here. Beautiful.

RAM

This little thingy I borrowed from my sister has an astonishing 2G of RAM on it. It’s the maximum the chip can handle, for those that don’t know, so you don’t get a bigger Atom. VS can  run with 1G and some swap, so 2G was plenty. Still, I could feel the poor thingy ask for mercy. Atoms, small as they are, are 64-bit. That makes VS use some more RAM than it would on 32-bit, and on a 2G system with no video RAM whatsoever, it was pushing it.

I think the worst thing is that APUs (and other onboard GPUs too) have to share system RAM with the CPU - they have no dedicated RAM, and that’s a big disadvantage for OpenGL. OpenGL has to keep a copy of all textures in case they have to be swapped out of VRAM, and APUs, which have no RAM but do have reserved RAM are no exception. So all textures use up memory twice - once in system RAM, and once in video RAM. On a 2G system, you feel it. A 1G system would be swapping and stuttering constantly (I’ve tried), and if you don’t decrease texture resolution, even crash.

Which brings me to N5xx APU’s limit of 256MB texture space. This is plenty, but since intel doesn’t support DXT compression (they market it as DXT de-compression, which means the driver expands the texture when loading it into RAM, a big lie that retains none of the benefits of DXT), those 256MB run out quickly.

Full-size planet textures, for instance, use up 160MB on their own. Add a few stations and ships, and texture swapping is pervasive. In fact, I’ve had it crash on me when textures were at full resolution - especially when looking at earth, which has the biggest, bestest and meanest texture set - because if an object’s textures don’t fit in that limit, the driver will kill VS.

So… disabling faction textures and lowering texture resolution was a must. I must say I didn’t notice a performance impact - it was mostly about crashing than performance.

Shaders and whatnot

Now, surprisingly, the on-chip GPU (APU for the knowledgeable folks) on those tiny processors is quite decent on per-pixel stuff. It’s not super fast (or fast for that matter), but it’s surprisingly capable given the low power budget (TDP for the geeks). It means, it can run all the shaders that can run on other intel onboards, albeit slower.

A lot slower. At the rather humble resolution of 1024 x 600, I could get maybe 4 fps looking at Serenity. But, check this out, the pixel pipeline wasn’t the bottleneck! These intel APUs have poor hardware vertex shaders. So much so, that for a while I thought they were running on the CPU!

All of the 2 shaders units run at 200Mhz, which is half the clock rate of the CPU. But, more importantly, I think full-precision floating point arithmetic must be working in scalar mode rather than vector mode (only 1 operation per cycle, instead of 4), because the difference in speed compared to the pixel shaders is astonishing.

Update it seems that they do actually  run on the CPU, according to tech report: “Integrated graphics processors typically lack dedicated vertex processing hardware, instead preferring to offload those calculations onto the CPU. As a unified architecture, the GMA X3000 is capable of performing vertex processing operations in its shader units, but it doesn’t do so with Intel’s current video drivers. Intel has a driver in the works that implements hardware vertex processing (which we saw in action at GDC), but it’s not yet ready for public consumption.” This means that, coupled with the rather slow CPU, vertex shading is severely underpowered. We can only hope driver improvements will revert this situation.

This situation was unheard of before APUs came inside netbooks. It was always the case that the pixel pipe would be the bottleneck, and if you wanted to accelerate stuff you pushed some calculations out of the pixel shaders and into the vertex shaders. With a few thousand vertices per object vs a few million pixels, it was a clear win. Not anymore - not on netbooks - the underpowered vertex shader can’t keep up with a tenth of the workload the pixel shader can handle, and all our shader optimization just doesn’t make sense anymore.

For instance, many shaders perform multiple passes, in order to avoid computing the expensive pixel shading on occluded pixels. This is such a dumb thing to do when vertex shaders are the bottleneck, that I’ve been considering adding a “Netbook” shader setting that will disable that. It could possibly multiply FPS 2x or perhaps even 3x. Some other “optimizations” would beg revising too, so this will take time.

And the bug in Vega Strike

If this wasn’t enough, bugs in VS contributed to the slowness. Especially a rogue high-quality shader that slipped into low-detail modes. Other intel GMAs handled it pretty well, in fact, but not this APU. After fixing that, things improved a great deal. I still get unplayable FPS when running shaders, but I can see a small light of hope - maybe if I can rebalance the shaders with the underpowered vertex pipeline in mind, maybe it might work.

Python universe

That’s another resource hog for the Atom. This lowly processor isn’t up for the task of running VM bytecode, which is what Python runs on. Java and Dalvik, two other technologies that run VM bytecode, have a JIT - a module that spits out optimized machine code to replace the Java bytecode, which makes it fare a lot better in the Atom, as evidenced by the abundance of Atom hardware running android.

But Python has long wished one, but not gotten it. So it still emulates the running program by reading the bytecode and performing the operations in a very Atom-unfriendly way.

The Atoms’ simplistic architecture isn’t well suited to run this kind of generic, utterly suboptimal code. It shows. When python scripts start running in VS, the stuttering is immediate. Spawning ships, a very Python-heavy part of VS, is worst.

I don’t see a way to fix this, other than moving most Python universe simulation stuff to a thread. But VS is years from becoming thread-safe in that way, so… bad mojo. For now, all I can do is try to optimize the python scripts. I can’t make Python fast on the Atom, but I can probably use better algorithms to do less work in Python. I’ve been slowly groking through Python code trying to find obvious places to optimize, but I haven’t been able to measure anything yet.

Conclusions

The conclusion is I have to do more testing. There’s the new N2800’s which run a lot faster, and features a tile-based GPU. I have absolutely no clue how this GPU will fare, but I can imagine it will pose its own challenges. Even on the N5xx I should be able to streamline shaders a bit and perhaps optimize python scripts. Hope is not lost yet.

0.5.1 Beta1 Released

Wednesday, March 9th, 2011

Very little to say other than :D and what has been said in the General Announcement post.

Now, we need beta testers!

Planets, a reality of the hard working

Thursday, September 2nd, 2010

Earlier I posted about a dream I had.

Today I’m posting about a project I have.

Hopefully, soon I’ll be posting about the game we have.

There’s no discussion about it: my areas of expertise in game development are graphics, and sound. I did a tiny bit of sound earlier, with streaming support. I’ll be back in those realms eventually, to complete streaming support for music which won’t be immediately apparent to users but it’s an important step for the audio system. Anyway… I’ll be back with sound eventually, but right now I’ve been taking some time off sound to revitalize my mind. I did that by thinking about graphics this time :)

Yep… switching from task to task is recreational for me - it lets me come back afterwards with renewed ideas and energy. Is that weird? I don’t know… but that’s me.

So, I’ve been playing with planet shaders. I got them looking nice, as I posted earlier, and lately I’ve been hooking those shaders into the system generator. Sorry folks, but I have some bad news in that front:

It’s done.

You say bad news? Ftw?

Well, it’s bad news because for it to take effect (whenever I commit it, which I haven’t done yet) you’ll have to delete all your generated system files. Bummer. All the systems you thought you knew you know no longer.

Sadly, I don’t know of an alternative. There’s no easy way to add the shaders to existing systems, and there are tons of parameters to play with. Texture files have to be set, technique names, parameter overrides… all that is generated pseudorandomly once, and the result stored in a private folder of your system (close to where savegames are stored).

But hold on, there’s more bad news.

I’ve only done the terrestrial worlds. I’ve been working  hard to get gas giants, and although they look cool at the moment, I’m not entirely happy with either the looks or their performance right now.

So I’ll keep working on them, but I’ll commit the terrestrial planets so everybody can enjoy (and comment - feedback is the best development tool, second only to contributors). I may go ahead and tackle rocky planets and asteroids before I get the giants right… the technique I chose for the gas giants bring my GF9800GT to its knees. Knowing a lot of people play with Intel GMA, which is orders of magnitude slower, we certainly can’t afford a shader that renders a planet full screen at a blazing 10fps on that kind of hardware.

The bad news I’m talking about is that this process of deleting your generated system files will have to be repeated every time I commit new planet shaders (if you want them). Which I expect to happen more than once or twice. Sorry folks, it’s the price of progress.

With planet shaders come tons of engine improvements:

  • I finally found how to hook randomizable parameters to planets, so expect more variety than texture changes alone. I’ll probably play with other parameters that make up the looks of a planet, like cloud coloring and whatnot.
  • sRGB framebuffer support is increasingly important with the multipass techniques the planets use. sRGB framebuffers mean you’ll experience improved color reproduction and fidelity. In fact, part of the graphical appeal of the planet shots I’ve been posting come from accurate gamma correction. I’ll be transforming all the other shaders into using those accurate gamma-corrected techniques.
  • Shaders support preprocessor #includes. That sounds technical I know… but it means it will be easier to work on new shaders given that we’ll have a reusable “standard library”. In fact that’s where all the gamma-correction stuff resides.
  • The “reload shaders” hotkey was not working. Now it is :D (mostly) - I kind of needed the key to avoid having to relaunch VS hundreds of times while developing the shaders.
  • City lights and atmosphere glow is now part of a planet’s technique, and not weird hacks in system files. Crafting beautiful systems just got easier :D - the bad thing here is that they don’t work in shaderless systems. Sorry folks, but progress needs programmable shading, if you find yourself forced to disable shaders, VS will start to look uglier every release. I’ll struggle to keep it playable, though… just not pretty.

Well, I think that’s it with the features.

But those features need art.

I’m formally requesting help here… we have quite varied planet textures, but a lot of the “layers” in those planets are missing. We have tons of terrestrial worlds (forest, carribean, etc…), but they usually don’t have neither city lights nor cloud maps or normal maps!

City lights, though a bit unrealistic (in reality, the nightside looks completely black, city lights being just too faint against the bright sunny side), they add a lot of beauty to the scene. So from an artistic point of view, planets need city lights. Besides, they become a lot less faint once you fly up close to the planet (say, while docking).

Cloud maps are obviously important, just take a look at the screenshots, cloud maps are 80% of the beauty of terrestrial planets. 100% of gas giants, and 40% of desert planets. They’re important. Yet we only have one or two of good quality (high-res enough to be interesting and with the proper format). As soon as terrestrial planets become commonplace, this lack of variety will be very very evident. I’m working on techniques that, without adding tons of new cloud maps, will add some variety - but I still need help here… I need contributions in the form of varied and high-quality cloud maps.

Normal maps are in fact normal plus height maps. Normal goes in color, height in alpha. I may change the technique in order to better pack the textures (right now, normal maps cannot be compressed without loosing a lot of precision), but the fact is that absolutely no planet besides earth has a normal map. And that’s very, very bad. Rocky planets, from my musings on the subject, will base their entire looks on complex, interesting normal and height maps. Without them, rocky planets will be dull. Terrestrials can get away without normal maps, but if anyone cares to take a trip to Sol and visit earth, you’ll notice while flying up close how normal maps can actually increase the perceived level of detail when flying close to the surface.

So we need normal maps. I cannot produce them all - in fact I don’t know how to produce even one of them, all the tools nVidia and the other companies provide for authoring normal maps are windows-only :(

I’ll be more than glad to help any generous soul that sets on the task of producing any amount of normal maps for the planet types we already have in SVN. It’s not like ship normal maps. You can’t just draw a random black & white “greeble” bump map and be done, planets are actually all about topography. Of earth we have topographic maps (that’s where its normal map comes from). From mars kind of too. But for our made-up planets?

So my job is far from done, and I’m already asking for help. No wonder commercial games need millionaire budgets ;)

Movies… at last!

Monday, July 26th, 2010

About… er… wow. 2 years ago.

About 2 years ago I gave news about the “upcoming movies support”. It was “soon to be ready”. Well, soon meant 2 years it seems.

You all know how it goes, I guess. One gets inspired, one gets all the right ideas, starts coding, gets 90% there, then real life decides to throw you a curve ball. This time was no exception.

Curve balls come in two flavors: unexpected (or expected but unaccounted for) time-consuming real life stuff. Like school, work… girlfriend ;) … all that which threatens to seriously reduce commitment to any coding project. And, of course, unexpected (or mispredicted) time-consuming coding tasks.

Movies had both of those.

Let me recount the experience a bit.

In my last post 2 shameful years ago, I conveyed my intent not to rewrite the sound system. Really, it would be a huge task for the little time I had left - though it would certainly be a fun task, for me at least - so, in order to get things rolling out ASAP, I said, I would resist the temptation to rewrite the sound system. It turned out harder than I thought.

Getting streaming within VS meant hacking the main loop to perform either threaded or multiplexed reading from several audio streams (yep guys, I was, am, committed to supporting multiple streams playing at once - it’s pretty much required for many of the interfaces I have in mind). The existing sound system in VS had no place in the main loop, so I would have to write bookkeeping routines and data structures from scratch. The more I studied the idea, the more I realized that I would be, essentially, writing a parallel sound system from scratch.

So, eventually I said: “heck, I won’t write a sound system twice - lets start the rewrite, it won’t be less work than trying to hack streaming into this”.

So I did. I started the sound system. I drew inspiration from Ogre’s design, BTW. Thanks sinbad (I really learned a lot from Ogre).

I must say I went straight to the point. In contrast with my attempt to embrace Ogre as VS’s rendering engine, case in which I overdesigned quite a bit, more than once, in this case it was the complete opposite. I designed the minimum functionality to get what I wanted, but always leaving the door open for extensibility (and the features I really really wanted - but weren’t really really needed). In fact,I found myself refactoring things several times because the design fell short in this or that aspect. So I can’t blame the lengthy time it took to roll this out on overdesigning as with the Ogre port. No… this was just a lot of work done in really really short bursts spaced perhaps weeks or months apart.

Which brings me to the other curve ball: real life. I got busy at school. My dad got sick. I left school. My dad got better. I got back to school. I got really busy at school. In the meanwhile, I worked 12 hours a day or so. I traveled a lot too (though this part was fun :D ). I don’t know what else - oh ya, at one point I had two jobs, and no energy left (one coding, one teaching). Real life conspired in a way that I could dedicate only a few hours time, perhaps once a month or so. I’d get nice full weekend sprints every now and then, but I would waste a lot of effort trying to find out where I left. A real waste.

Then came Trac. Our friend chuck_starchaser installed trac in his server at wcjunction, and boy it helped. It so happened that I was very used to working with trac at work, so I started organizing myself just as I did at work. Suddenly, the little time I had really paid off - if I wanted to know where I had left, I would simply log into trac and check. I love trac. Ya, it’s missing a lot of features, but it’s so useful.

Then came testing time. Lipsync issues, crashes, segmentation faults, it didn’t build in windows I think at one point - minor stuff anyway. All expected, in fact. After all, who writes 8700 lines of code that work flawless from the get go in multiple platforms? who writes 8700 lines of code in two years, btw? 12 lines of code a day. That’s snail pace - I guess a lot of thought went into each line ;) (I sure hope so).

Yeah, you may have noticed I’m ashamed of how long it took me. Lets say that again: I’m ashamed of how long it took me. There.

In any case, the effort, the design, the thought that went into every step, and the sweet time it took really paid off. The final phase (testing) went as smooth as I could ever had hoped. The system isn’t flawless yet, there are issues with slow computers, there’s a lot of room for optimization, there’s still a lot of features to implement, not the least of which are threaded background loading and proper resource budget management. There are bugs. Known bugs to resolve. But the foundation is there, and it works.

Hurray!

So… I have to thank a few people who really contributed to this:

  • chuck_starchaser: you know… without trac I wouldn’t have gotten anywhere. Our talks also shaped the sound system in some of the pending features… with luck, in less than 2 more years you’ll see the features in all their splendor.
  • hellcatv: with the needed windows testing. I can’t even build in windows anymore.
  • sinbad: inspiring my design with Ogre’s design is no small contribution. I just hope mine is up to par.

I’m probably forgetting someone, I apologize in advance. Shenle for instance helped in getting a windows build, and even though the job was finished by hellcatv, getting it started wasn’t small either.

Now… lets put the feature to use?

Note: at the time of this writing I haven’t merged it into trunk - but it’s coming, a helluva lot sooner than the last time I said “soon”.

Klauss++

August, or things like it

Tuesday, July 29th, 2008

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 ;-).

svn, 0.5.1 and organizing.

Friday, May 16th, 2008

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.

Enjoy the release

Saturday, April 26th, 2008

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. 

Movies!

Friday, April 25th, 2008

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

Graphics and Artwork

Friday, February 29th, 2008

 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.

For one, many planet types have new textures with better resolution and visual aspect. They will be more realistic and less blurry than the previous ones, trying to represent more or less realistically how extra terrestrial planets might look like.. Almost all of the previously missing textures, resulting in untextured white planets, will be included now. All in all, against the 8 out of 120 planet textures with release quality present in the previous version of VS, now all planets will have textures with 60 percent of them being of acceptable quality. Besides the planets themselves, each of the 27 planet types has now its own HUD image as well as the planet type being shown.

Another one of the changes that will be immediately visible, is the armor and shields status indicators for your own vessel on your cockpit. Four gradually semi-transparent arcs have replaced the simple curves used before as simplified status representations. Though some of the cockpits have been currently disabled due to their quality and believability being very limited, they still have their individual armor and shield gauge styles in the data set.

Many new cargo images that were missing were added to the game. Besides the fact that there are now 34 new images, they are also of relatively high quality as compared to those previously available.

Besides the very visible changes, there are other changes which are less obvious at the first glance. One of them is the default number of concurrent comm message lines on the HUD which has been increased from 2 to 5. In addition, the default time before scrolling the messages has been increased from 5 to 30 seconds, while the user or modder can still adjust both in the config file. Another, less apparent, feature is the ability to disable, via the config file, the cursor and the target arrow for two specific cameras, the external view and the target view making the cameras bare of any HUD elements and very well suited to take screen shots. In addition to that, the pan and yaw speeds of the cameras have been lowered and are now configurable, too.

The HUD has been given some additional status indicators. You can now see new stati for flight computer, autopilot activity, SPEC drive, governor control, total vessel mass, docking readiness, turret control, cloaking device, and electronic countermeasures.

Further, three new splash screen images have been added. The first one is an advertisement for the SMC, the Shmrn Medical Consortium. The other one is a call by the Botete Merchant Fleet for supplies shipment to a planet during Aeran blockade. And the last one is a Luddite virus hack screen.

Though not directly graphics or art related, I thought I should mention one more point here. In order to speed up game execution and optimize memory usage, all images and textures have been converted to dds format. Unfortunately, during this process incompatibility with some nVidia drivers on some card families has become more apparent, which, adding fortune to infortune, can be solved by using the latest nVidia driver release (169.12). We greatly appreciate any failure or success reports on our bug triage forum.

You might be on the right track if you are expecting more changes to be coming along. Some of the ideas for further (non-engine related) graphics and artwork development include but are not limited to:
* substitution of the remaining 40 percent of low quality planet textures
* complementing missing cargo, upgrades, and weapons UI images
* extending the variety of space backgrounds
* improving planetary rings
* making own vessel shields and armor be made up of 8 faces each
* providing visually improved shield status for targets
* throwing in a little surprise for enjoyment by VS gamers

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