feature freeze time

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: feature freeze time

Post by charlieg »

chuck_starchaser wrote:Bolts should be treated specially. First, they don't need physics; as they travel in a straight line, at constant velocity; they can use extrapolation exclusively. BUT, they need to be collided, probably at each graphics frame.
Oooo nonononononononononono no.

So if the framerate drops all of a sudden bolts start missing ships the would otherwise hit?

There's a reason you separate out drawing from important calculations like physics - other than performance - and that is consistency.

If you start making anything depend on the graphics frame you'll introduce some horridly subtle bugs down the line.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

Hahaha, I had a big argument with Klauss about that a while ago.
You're right. The thing is, I tend to think of graphics frames as happening MUCH faster
than physics frames; but that's not necessarily the case.
And in any case, information has to flow both ways between physics and collisions, so
it's much better to keep collisions in the same thread as physics.
However, in the more general case where graphics DO run faster than physics and
collisions, graphics needs interpolations; but collision RESULTS cannot be interpolated;
only positions can, which leads back to my original point: perhaps graphics interpolations
have to compute collisions in addition to the collisions running in the physics thread.
Or, perhaps the physics thread could compute "safe collisions" (using rods), so that
the graphics thread knows which interpolations warrant a collision test.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

No, the graphics thread has to perform piecewise three-point interpolation.

P0@t0 - P1@t1 - P2@t2

Normally, t/p1 == t/p2, but when a collision happens, t1 is the collision time, and P1 the collision position. P0 is the starting position, and P2 is the leaving position. The graphics thread interpolates between the three points, rendering a collision correctly.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

Can't judge from parameters without definitions, but what I'm saying is the graphics thread can
only interpolate postions and times; it cannot interpolate collisions; since they are boolean...
Unless you're saying that collisions already extrapolated forward and passed a predicted
collision time for the graphics to use.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

Something like that - only not predicted. Evaluated.

The physics system should simulate one physics frame ahead of graphics, then graphics interpolate the "keyframes" produced by physical simulation.

That would introduce a lag of 1/14th (or whatever physical time step is implemented), but that's ok, such a small lag isn't noticeable anyway.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: feature freeze time

Post by charlieg »

So...

new windows build *check*

What else?

When is the release? ;)
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

Okay, I guess I'd better get back to work on the technique and shader reorganization; as the new physics is not going to make it to the release, I don't think. There's also a bunch of bugs in PU I haven't looked into yet... Donno if they are data or engine side.
Has anybody tested vegastrike on shenle's win binary?
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

chuck_starchaser wrote:Okay, I guess I'd better get back to work on the technique and shader reorganization; as the new physics is not going to make it to the release, I don't think. There's also a bunch of bugs in PU I haven't looked into yet... Donno if they are data or engine side.
Has anybody tested vegastrike on shenle's win binary?
I've been updating the SVN on my old windows 2000 installation... it took all day long (a lot to download).
I think I only downloaded the source and data, so I'll have to do a fresh checkout of the win32/bin folder too.
I'll try it when I'm done (that would be VS, not PU, which should confirm whether the bugs are code or data issues).
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: feature freeze time

Post by charlieg »

The new physics most definitely should *not* be in this release. There's a reason the thread is called feature freeze and that's because, to release, sometimes you need to move upcoming features to the next release in order to get this release out.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
Post Reply