Page 1 of 6

Elite Strike pre-release patch!

Posted: Tue Jan 17, 2006 4:14 am
by Halleck
Elite Strike has been under development for some time now, but has yet to be officially released. There is a short list of non-critical tasks to be completed before the first release. However, instead of making you all wait until these tasks are completed, Nózmájner and I have decided to give the public a chance to sneak a peek at what's in store.

This is almost exclusively a content package. Stuff like new stats, etc. will have to wait until the Alpha 0.1 release or later (nobody is working on them at present).

This pre-release patch (Alpha 0.0.1) includes:
  • Tons of new ship models by Nózmájner
  • Classic elite midi arrangements by George Hooper, and new playlists to use the music
  • Some save files I hacked together so users can test each ship (because I haven't made them purchasable yet) and a mission file
  • A new elite-style control scheme, and a few other config tweaks
  • A new splash screen and program icon
So, without further ado, you can Download Elite Strike here!

We are already well towards the original goal of getting all the Elite ships in. Nózmájner has proposed remodelling them in higher resolution/better quality, but I'd like to lay the groundwork with low poly ships first, which can be drafted and added quickly, and will serve as placeholders until such a time when higher-rez models are available.

Any help that can be rendered to assist with ship stats or anything else on the Todo list would be highly appreciated.

Posted: Tue Jan 17, 2006 9:35 am
by hellcatv
trying it again :-)

Posted: Tue Jan 17, 2006 5:30 pm
by Halleck
Cool. 8)

FYI, The only difference between this version and the one I was passing around (0.0) is that it has improved savefiles and a few crumbs of documentation.

Posted: Wed Jan 18, 2006 3:37 am
by Halleck
D'oh... hellcatv informs me that I made a few glaringly obvious errors in this patch, such as forgetting to include the save files. :?

Please refrian from downloading 0.0.0 for now... I'll have 0.0.1 up in a jiffy.

Posted: Wed Jan 18, 2006 4:43 am
by hellcatv
lookin forward to it

Posted: Wed Jan 18, 2006 6:15 am
by Halleck
Alpha 0.0.1 has been released!

Fixes:
-coriolis stations no longer have gravity wells the size of solar systems (autopilot now works in troy)
-save files now included
-default mission now places you in the dock of a coriolis station (instead of in one)
-starting ship is no longer a hacked taurus.blank with a cobra mesh, but a true cobra mk. III with taurus.blank riggings.

Get it at the downloads page!

Posted: Wed Jan 18, 2006 8:05 am
by chuck_starchaser
Tried 0.0.0.0 so far; so that's why autopilot wasn't working, eh? I still managed. I like the continuous acceleration and decceleration. It's ironic how it can take so long to fly between stations, and still be entertaining, from having to guess when's a prudent time to let go of the afterburner...

Good stuff; it really feels like the flight model of FFE, which is the best I know of.

I'll try the new patch.

Posted: Wed Jan 18, 2006 8:56 am
by Halleck
The autopilot was broken because of a problem with the coriolis station mesh (which was an issue for some time now, I only realized how to fix it today.) The issue was that the mesh itself was quite small, so I set the unit_scale factor to 500 in units.csv. While the model appeared at about the proper size, the scaling factor would have made the original mining base model larger than the solar system itself... and the engine was treating it as such. :shock:

I remembered that jackS once mentioned the unit_scale factor multiplied the mesh's internal scaling factor, so I figured I should try setting it in there. Hellcatv pointed out that this could be done easily by editing the xmesh files, which I did, and set the unit_scale back to 1.

Bingo! The model itself remained the same size, but didn't have an invisible solar-system sized girth. I hope this answers your question. :D

So yes, please get the newest version.. 0.0.0 is very poor by comparison.
You should be able to extract it over your current elitestrike installation without issue, except you might want to start a brand new game (so that you can take advantage of the updated cobra mk. 3 unit.)

Posted: Wed Jan 18, 2006 11:03 am
by chuck_starchaser
Haven't downloaded the patch; it occurred to me you might have a use for an FFE kind of dashboard, so hacked one up.

Image
Image

Well, it's far from perfect yet; I could get it closer to the original if I didn't have just one hour left for catching some sleep.

Here's the file:
http://www.deeplayer.com/dan_w/FFE/dash/FFEdash.zip

I don't know how to unwrap; maybe Ryder could do it; but what I'm thinking is you might need the rest of the cockpit to be able to turn the head. So, if you want, let me know how you'd picture the rest of it and I'll finish it.

Getting Sol and Barnard's Star would be a good start. If you have pics I could do a couple of stations.

Posted: Wed Jan 18, 2006 1:56 pm
by Halleck
Wow, thanks Chuck!

I've never tried 3d cockpits before... it will be an interesting challenge. (Especially the elite-type radar... that will require some code modding methinks.)

Posted: Wed Jan 18, 2006 2:46 pm
by chuck_starchaser
Nah, should be easy with klauss' new cockpit interface. He writes to a texture, and you map the texture to the ellipse.
By the way, his interface needs for each display thingy to be a different material, and that's what I did. The fuel bars' material is called MA:Fuel; the radar's MA:Radar. The arching buttons area has individual rectangles inside, all sharing one material, MA:Function. The three little pyramids share a materia, MA:Triangles, and there's also MA:TimeComp and MA:LeftDisplay I think I called it. Anyways, whoever does the unwrapping, all these special thingies should map to separate pseudo-textures (dynamic ones) and have uv coords from 0.0 to 1.0 in u and v, I suppose; but klauss can confirm it or correct it.

But in any case, it's not finished yet; the curve with the buttons isn't right yet; the fuel bars are too close together, etceteras; and if you want to sketch how you'd like the rest of the cockpit I could add that. I have a nice bucket seat I did for the Hellcat, I can throw in.

Posted: Wed Jan 18, 2006 2:59 pm
by klauss
Not exactly. That is... you can go that way, but if you have many it will hurt performance. I'll wiki that.

Posted: Wed Jan 18, 2006 3:33 pm
by Halleck
You forget that the elite radars showed a plane, with a line drawn to each blip (its length delineating y-offset of target). I doubt that can be reproduced without changes to the radar code.

It's exciting to note that 3d cockpits support displays being rendered to them, I'll wait on klauss to explain the proper way to do it.

Granted, I prefer the HUD/external views myself... I like to see out into the universe. Still, I know that a lot of people are going to love this, so improve it however you can.

Posted: Wed Jan 18, 2006 3:51 pm
by klauss
Halleck wrote:You forget that the elite radars showed a plane, with a line drawn to each blip (its length delineating y-offset of target). I doubt that can be reproduced without changes to the radar code.
True... but it's there already.
I'm not sure how to activate it... something in vegastrike.config, like <var name="elite_radar" value="true"/>, but don't remember the actual names.
Halleck wrote:It's exciting to note that 3d cockpits support displays being rendered to them, I'll wait on klauss to explain the proper way to do it.
Will do, but have in mind that such thing is planned for the Ogre version, and not any earlier one. It's just too complicated to support render-to-texture in a portable way... one more reason to use Ogre.

Posted: Wed Jan 18, 2006 4:00 pm
by Halleck
Okay, I guess we can wait then... better to have a semi-functional 3d FFE cockpit than an old 2d privateer one.

Posted: Wed Jan 18, 2006 5:49 pm
by klauss

Posted: Thu Jan 19, 2006 1:02 am
by Halleck
Wow... sounds really complicated. :?

I think I will need some help getting this to work in-game once we move to ogre.

BTW, you can already do viewports in the 2D HUD... see the latest Vega Trek. Hopefully this functionality can be re-used for the 3D VDUs.

Posted: Thu Jan 19, 2006 4:23 pm
by klauss
Nah... sounds being the keyword.
Once you see an example, you'll get it.
I just don't have any yet.

Posted: Fri Jan 20, 2006 2:46 am
by Halleck
I await one with anticipation. :D

BTW, will we still have to sort polygons by z-depth or whatever to get them to render properly with OGRE? I belive this has to be done now with cockpits in order to make them draw correctly... evidently there are not enough resources to do occlusion testing or something of that nature.

Or has this already been dealt with?

Posted: Fri Jan 20, 2006 3:48 am
by chuck_starchaser
Halleck, while you wait for klauss' correct answer, I think that's a problem of z-buffer precision, which is a limit of hardware, unrelated to what engine you use. Basically, if you're modelling a whole planetary system, with planets 100's of millions of km away, and you want to also be able to distinguish distance differences (in the cockpit) of 1 cm or even less, you're necessitating a dynamic range of the order of 100 M k / 0.01 = 10,000 B or 10 trillion to 1. But with a 24-bit buffer you got 2^24 = 16 million to 1 of dynamic range. Klauss made that happen somehow, but it takes a bit of hacking, like displaying short ranges and far ranges separately. Most games don't have this problem, as they limit your visual range much more.

Posted: Fri Jan 20, 2006 8:08 am
by Halleck
Ah, that would make sense.

So, are you saying that klauss has devised a workaround for the precision issue? Or do we still have to sort the polygons?

(BTW, for a cool reference of what the inside of an elite cockpit might look like, see here.)

Posted: Fri Jan 20, 2006 12:38 pm
by chuck_starchaser
Sorting the polygons could very well be the workaround, or part of it; but we'll know soon enough.

Posted: Fri Jan 20, 2006 4:13 pm
by klauss
Halleck wrote:So, are you saying that klauss has devised a workaround for the precision issue? Or do we still have to sort the polygons?
I'm not sure he's saying it... but I did, and current CVS VegaStrike already handles this properly.
Most certainly, I'll do the same with Ogre. Actually... a bit more sophisticated (the exterior scene will also be partitioned that way, to handle correct rendering of planets on the background - allowing more interesting stuff the size of them)

As I mentioned somewhere, the combined precision of the Z-buffer (not counting the cockpit area) would be somewhat around 56 bits, providing 1cm accuracy for a bit over 27 light-days away. Neat, huh? I hope the implementation lives up to those theoric predictions 8)

Posted: Fri Jan 20, 2006 4:51 pm
by chuck_starchaser
Actually, you only need precision of 1 cm at close range, but you know that. I suppose your hack is sort of turning the z-buffer qty from an integer into a float...
How about this:

Code: Select all

double distance;
float unit_scaling_factor;
float logarithmized_distance;
float adjusted_unit_scaling_factor;

/*
  we want the z-buffer to stay linear at close range to avoid artifacts,
  but we could live perhaps with a logarithmic linearity at long range,
  so assume we decide on a crossover range, below which we move
  more towards linearly, and above which we turn more logarithmic..
*/
const double logarithmic_distance_threshold = blablabla.5; //~777km?
const double logarithmized_raw_threshold = log(logarithmic_distance_threshold;
const double multiplying_factor = logarithmic_distance_threshold/logarithmized_raw_threshold;

double raw_log_distance()
{
    return multiplying_factor * log( distance + 1.0 );
}

/*
   we want our final distance to be the lesser of the two, so that it
   is logarithmic at long range and linear at close range; BUT, we
   want the transition between them to be rounded and smooth, so...
*/

void compute_logarithmized_distance()
{
    double RLD = raw_log_distance();
    double product = RLD * distance;
    double sum = RLD + distance;
    logarithmized_distance = float( product / sum );
}

/*
   now we need to adjust our scaling accordingly...
*/

void compute_adjusted_scaling()
{
    float factor = float( logarithmized_distance / distance );
    adjusted_unit_scaling_factor = unit_scaling_factor * factor;
}
Just for display purposes, of course.

Halleck, sorry for the OT-ness.
Do you have a wheel station already?
Image

Posted: Fri Jan 20, 2006 5:59 pm
by klauss
Hehe... nothing that fancy.
I just render in multiple stages, with different and carefully tweaked z-near/z-far values.

In the Ogre framework, I'll be using 5 such stages: background (complex ones - not only the cubic map), far, medium, near, cockpit - each with its own z-buffer range. It makes it really hard to do stencil shadows... but we can't have the cake and eat it too... plus I already thought of a few hacks for shadows.