How to switch of Asteroids?

Master Wooky

Spaceman
Might it be possible to do something which allows switching old/new asteroids in the settings? First i thought the new asteroids are great (which they really are), but my machine is a little slow. It's no problem as soon as i am in the field but as long as i have the whole field on the screen i really can't play anymore...not to think about fighting.
I first switched down visual effcts and resolution but playing this way all the time in case there might be one asteroid field... I don't know...
Editing every System is a lot of work so one switch would be fine.
 
Actually, asteroid fields need some heavy work. There's no reason they should be impacting performance like that. There must be something that can be done to avoid that, have the new look/feel and still run smoothly.
 
in vegastrike.config you will find several instances of the following var, one for each detail level: <var name="asteroid_detail" value="?"/>
Find the one corresponding to your chosen detail level and set the value to 0 (how many of the new fields can be in one system). If there are more fields than that number, it will use the old style, so if you set it to 0, you should always see the old style. I do believe this will go into the FAQ ;)

The new style will drain resources unfortunately. Each roid is now an individual unit, and keeping track of them drains resources. The old field was made up of 5 units or so. It was a lot easier to keep track of them, but there was no way to destroy part of a unit's mesh, so they were indestructible. To make an individual roid destructible, each has to be an individual unit.

Someday we hope to have a system more like freelancers, with roids generated dynamically in close, and a couple roid field textures for far away.. Until then, on a slower computer, you can either destroy rocks, or have good performance :-/
 
John Cordell said:
...or reduce the density of the asteroid field.
Yes, but that is a much more difficult change than just tweaking a config file.

Once more advanced graphics processing is available in the Vega Strike engine, such as pixel shading, will that help with performance?

I have a 6800GT on the way. We shall see if it can handle Rikel's 5 fields if I force them all to the new style.
 
I'm afraid those asteroid fields are CPU bound. I tried one out with 6 poly rocks and it madelittle difference. It's keeping track of the position and state of all those units that is the biggest drain, and has little to do with how they are displayed.

Still, 6 poly rocks did make some difference, so please do tell how well rikel works wth the new style fields and a sweet graphics card :) Turn on your cockpit's fps display..
 
MamiyaOtaru said:
I'm afraid those asteroid fields are CPU bound.
Ah, nuts. Not getting a new one of those anytime soon, I'm afraid.

Still, 6 poly rocks did make some difference, so please do tell how well rikel works wth the new style fields and a sweet graphics card :) Turn on your cockpit's fps display..
Will do.

CPU limiting may be the bigger constraint for the asteroids, but there's definitely some GPU limiting as well with eye cnady turned on. In 1.0 pre-releases I played around lots with AA/AF settings versus asteroid filed framerates. I found that as I went farther into the greek letter systems, I had to reduce the AA and AF more and more to maintain 30+ FPS. With no AA and no AF on my 128MB 9800 Pro, I could peg the framerate at 85 (I play with Vsync on @ 1600x1200) while viewing multiple fields. With 6x temporal AA and 16xAF, that same view would run around 15FPS.

Now, I'm not saying I expect anything to be playable all the time at 6xTAA and 16xAF - that would be ridiculous. But, crank up the eye candy high enough and you'll drag anything away from a CPU limit. :)
 
Just a random query - I have been told that using quaternionic math is very good for dealing with orientation, position, rotation and rotational orientation. Are you using them in your 'roid mathematics? If not, it might help.

My favorite way to do it has always been to just use an x,y,z grid and some fairly cheap vector math for rotation and point position off of base plane (allowing you to specify the location in all dimensions easily) however from what I understand that's going to be a good 20% less effective then quaternions, which figure it out in fewer operations. Five, I think, although that is a higher-level mathematic as well.

I do not know how the compiler optimizations will translate either one into machine code, nor which one would be more expensive. Don't know how much this helps, but one of the quakeforge devs and I got into a discussions about cheap (CPU-wise) ways to figure these things out.
 
Actually, it's much more complex than that. Asteroids are represented as Units, so they're entangled with the unit management system, and with all its overhead. However, the problem is not controlling asteroid position and rotation. I'm not sure where the problem lies. I was going to do some profiling when I had the free time, to find out. Anyway, if I'm not wrong, quaternions are being used.
 
Ah. That makes alot of sense. I hope to get to playing PR 1.1 later on today - I've already got the basic 64bit file system intact. It's just a matter of polishing my toolchain one last time, making sure I got rid of an NPTL bug and switching over.

After all this cross compiling, building X.org should be a piece of cake.

(I'm insane. Shoot me now.)
 
Back
Top