feature freeze time

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
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 »

Techniques don't have alpha testing?

How could I forget that?

About fades, there's been a technique developing hardware support lately for order-independent transparency: the alpha to coverage function.

Basically, if you're using multisampling, with alpha to coverage enabled, the alpha value gets translated in a "coverage percentage" C, which randomly picks C% subpixels to write. The effect is order-independent alpha blending.

It only works for a couple of situations, because there can only be a handful transparency levels like that, but it works wonders for antialiasing alpha-tested impostors.
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 »

klauss wrote:Techniques don't have alpha testing?

How could I forget that?
Watch out! Don't make it a blending mode, as, if I'm not mistaken, alpha-testing and alpha-blending can be intermixed. I think it needs to be a separate thing, like cull mode, etceteras. Default threshold I'd make it 0.05, to avoid glass looking like holes in TNT's.
About fades, there's been a technique developing hardware support lately for order-independent transparency: the alpha to coverage function.

Basically, if you're using multisampling, with alpha to coverage enabled, the alpha value gets translated in a "coverage percentage" C, which randomly picks C% subpixels to write. The effect is order-independent alpha blending.

It only works for a couple of situations, because there can only be a handful transparency levels like that, but it works wonders for antialiasing alpha-tested impostors.
Nice! I heard of alpha-testing anti-aliasing but didn't know how it worked.
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: feature freeze time

Post by pheonixstorm »

safemode wrote:
I dont know what happened to our two intrepid win32 porters that were around a month or so ago, but apparently they gave up.

I dont think it's much of a secret that I hate developing on windows (and mac). I hate it so much that i hate how much work is needed to get things going come release time on those archs, and that's why i want to see the whole cmake system come together. When it does, it will be zero effort for a single developer (who has access to the different OS's) to use different compilers even to build VS on each platform and package it up using a central configuration used by all. I'm sick of the having to play catchup on the other archs or needing to deal with new project files for a new version of Visual studio or whatever MS calls their compiler ide setup these days. cmake can handle that crap and all we need to do is handle cmake. Less time wasted in that area is a win for everyone.
Havent given up, just been busy... as for cmake... think of it this way. Your cmake script likes linux not windows... all of you work on LINUX so what you write is mostly LINUX oriented. Anyone who tries to compile on windows using cmake will need to have more than just the vs source. When I tried cmake it kept asking for gtk even though an older version of gtk (even pointed to) was in the vc8 folder. While getting cmake to run under win32/linux/mac is a great idea its going to take a lot more work than you think. At least on the part of the end user who has to compile under windows. Why do you think I had such a frustrating time getting it to compile?

The biggest problem is the lack of a windows developer or at least someone who would run vmware and the latest VC express to keep the VC project files up to date. Just look at the last time either vega-vc7 or vega-vc8 was updated... How many files were changed or deleted from the build? These are the kinds of problems that really should be addressed first. How do you keep the win build from falling behind w/o frustrating and scaring off the intrepid windows developer who wants to compile from scratch? cmake could be the answer.. but only if you can supply all the required files with the svn pull. VC express is an answer, but only if you can keep it maitained and in synch with the cmake build. Either way you need to make sure to keep the end user in mind.

As for nsis.. which is actually better inno or nsis? both are free
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

your second paragraph is the exact reason why cmake is needed. No more falling behind, no more bothering to try to keep ports in sync.

It is going to be done, it's not a maybe or possibility, but an absolute.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

Didn't want to start a new thread and this one is somewhat on topic.

my work has decided to class vegastrike.sourceforge.net as a gaming site ...stupid mcafee firewall software....so i'm unable to browse the forum and svn while at work anymore. That's a serious blow to my time at the moment. blah.

anyways, so if i seem much less around in the near future, that's why. I have off the next couple days from job #2 so i'm hoping to get to some much needed cmake work
Ed Sweetman endorses this message.
Neskiairti
Confed Special Operative
Confed Special Operative
Posts: 334
Joined: Thu Jan 11, 2007 4:10 am

Re: feature freeze time

Post by Neskiairti »

set up a ssh proxy from home? :P
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 »

Neskiairti wrote:set up a ssh proxy from home? :P
Breach of contract, probably. It's one thing to slack off a bit, it's another to circumvent company policy.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
shenle
Confed Special Operative
Confed Special Operative
Posts: 381
Joined: Thu Jan 31, 2008 3:25 am
Location: hiding in a dark corner

Re: feature freeze time

Post by shenle »

safemode wrote:Didn't want to start a new thread and this one is somewhat on topic.

my work has decided to class vegastrike.sourceforge.net as a gaming site ...stupid mcafee firewall software....so i'm unable to browse the forum and svn while at work anymore. That's a serious blow to my time at the moment. blah.

anyways, so if i seem much less around in the near future, that's why. I have off the next couple days from job #2 so i'm hoping to get to some much needed cmake work
Well that sucks. I'm glad my company doesn't use the same filtering software as yours... OTOH my access to userfriendly.org is blocked, also as "gaming" :roll:
make me a sandwich
make: *** No rule to make target 'me'. Stop.
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 »

Fortunately, my company's business pretty much requires many of us browsing youtube and other social (and gaming) sites, so we'll probably always have free internet access

Yay...

But... if filtering came at some point, I would too find my forum time cut down pretty drastically.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Neskiairti
Confed Special Operative
Confed Special Operative
Posts: 334
Joined: Thu Jan 11, 2007 4:10 am

Re: feature freeze time

Post by Neskiairti »

using ssh is a breach of contract? D: not like they can see what the traffic is, only that its going to your home.
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 »

Whether they detect it or not, it is indeed a breech in contract. Well, it depends on the contract - but it is most likely that there is an item preventing you from... um... playing (or otherwise engaging in unproductive behavior) for a considerable amount of time.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

i am crazy productive, sometimes there are boards i test that take 20 minutes or more on the tester, so i peruse a handful of sites. I consider it a cheap perk considering our hours have been cut (32 hours a week) and no raises going on 2 years. They're lucky i'm still there, nobody else really knows how to run the new tester since i've been there since they put it in and i never take off (and i've never been sick or called out or stayed home on a snow day). My second job wants to promote me match my income from my first job, give me > 50 hours a week but dealing with that job for 50 hours a week would require ample amounts of drugs.

anyways, i'll probably get some decent work done tonight and if not, tomorrow evening. I just hate not being able to keep up on the forum while at work. You can only refresh digg.com and physorg so many times.
Ed Sweetman endorses this message.
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 »

I actually consider checking and posting on the forums at work productive for a change.

I get tired of looking at reviews or coding all day... sometimes I have to take a break to remain productive, and my break is checking the forums, instead of going out for a smoke or something like that.

So I don't agree it sucks that they don't let you browse the forums, but not all employees exercise restraint, some really need the prohibition to be productive.

For instance, we had to apply throttling on YouTube and other streaming sites, or people would abuse of them, and completely destroy our bandwidth. When you need some bandwidth for business-critical tasks, sometimes alienating one or two youtube users within the company isn't that bad.

But there's the niceness of my place: throttling. Not outright banning, but throttling.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

ok, made some ffmpeg cleanups (incorporating klauss's patch) ...

FFMPEG detection should be much more robust now. Plus it will correctly cache information from it.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

I'm hopefully going to have some time to work on the beam passing through units bug... ie, continuing to draw after registering a collision.. Seems this is likely due to the unit being shot at registering a collision but the unit doing the hitting (the beam or bolt) is not ... just a guess. Anyways, that's my immediate focus.

Is there anything else anyone can think of that would prohibit us from putting out a release other than the obvious port issues ? like any actual gameplay regressions or major unfinished milestones ?
Ed Sweetman endorses this message.
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 »

Perhaps the issues that chuck mentioned in the PU bug report thread:
http://vegastrike.sourceforge.net/forum ... 13#p116813
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 »

Indeed. Some of them are game-busting bugs, and probably will manifest in vegastrike as well as in PU; we just
haven't officially asked for game-testing feedback yet. I'd suggest we do so now. Both: Linux AND Windows.
Shenle's binary is in the /win32 folder.
You might want to ask him for a new binary; but I've a feeling most of the bugs would still be there, since
most of the revisions since his last compile have been to branches.
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 »

In fact, game-testing VS would help you track down the bugs in PU, because many, many of those bugs sound like data bugs.

Remember campaign files are python files, so they're "data". Actually they're halfway between data and program, but the point is that they've probably not received any of the updates VS campaign files have received. Nor they should, not without review.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: feature freeze time

Post by Deus Siddis »

You'll get a lot more testers if an actual beta release is put out, like was done last version.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

wow, something is definitely seriously wrong.

i'm getting velocity issues (not responding), damage issues (red screen ), etc.. . all points to some type of memory corruption.

Gotta re-compile and test without cpu specific optimizations and see if any of the aggressive optimizations are causing the problem. If it still exists then, i'm gonna hop back revisions that i synced up to trunk in my branch until it goes away, then we'll know what rev range in trunk to look at.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

may not have much time today to trouble shoot this, but i have the daytime tomorrow and sunday so hopefully we can squash this issue this weekend.

as far bolts/beams .... i dont get it. They must be drawn multiple times before a physics frame is executed on them. That's the only explanation for bolts, and for beams, they must be drawn all at once prior to a physics frame (too fast maybe?) because the physics frames from all the testing i've done seems to be doing the correct thing and destroying them after collision.

this means the only way to fix this, since bolts and beams can be so fast, is to combine the collision detection into their draw functions, allowing the single draw to not over-draw. That's the _only_ way to fix this bug if it's indeed the reason why it occurs.
Ed Sweetman endorses this message.
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 »

Why would a bolt/beam be drawn before the first physics frame?

That's the question to ask.
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 »

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.
Klauss, I know what you're thinking: Only test collisions if they penetrate a ship's collision sphere; but if we consider the speeds of bolts to compute spheres' radii, the spheres will be rather big, which defeats the purpose of having them (will produce too many warnings). I think it would be more efficient to either put collision spheres on the bolts; but those again would be too large, due to their speed; or, much better, use "forward collision rods" for them.
In fact, I think the whole algorithm would benefit an order of magnitude from using forward rods or stretched ellipsoids for all units, assuming that colliding them is not too much more expensive than spheres.
Or perhaps sphere-capped cylinders or cones...

Safemode: I think you'd better ask shenle whether he used those dangerous optimizations in compiling the windows binary. I'd almost bet money he didn't; and if so, that rules out the optimizations being at fault.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

sphere colliding is done regardless. We use a large sphere to test prior to more expensive checking, but opcode uses the radius of the unit as a pre-check as well. Nothing is less expensive than checking for sphere penetration ... What we're talking about when we say sphere testing is just "is X.position <= radiusOFUnit or radius of arbitrary sphere around unit" Where X.Position can be a vector, another unit's radius or their shield radius. It's not really true sphere colliding because we wont return any sort of data about where in the sphere the collision occurred, just that radius1 is within radius2. Now we check against opcode.

this is really quite efficient. Colliding and collision detection, is actually _very_ fast in VS. The whole collision subsystem is actually pretty fine tuned when it comes to bolts,beams, and unit collisions. This drawing after collision bug is the only thing that really needs fixing until we want to start implementing higher level stuff like maybe realistic blast waves (from explosions) and such.

the physics frame should always precede the draw frame, and if this is happening, then we are just not returning the correct position that the collision occured, and so the physics frame says it traveled the full length it can for that frame, rather than getting concatenated by the ship it collided with. This is one scenario, and if everything is coded correctly, the likely one. Since the physics frame precedes the draw, there is no need to create collision rods, as the transform for the new draw is done and that's what is checked for collisions, if found, we modify the transform and return. The draw then draws the new state. The bolt or beam should not be able to progress without another physics frame, so we should never be able to pass through a ship, especially if we register a collision in that physics frame.
Ed Sweetman endorses this message.
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 »

safemode wrote:sphere colliding is done regardless. We use a large sphere to test prior to more expensive checking, but opcode uses the radius of the unit as a pre-check as well. Nothing is less expensive than checking for sphere penetration ... What we're talking about when we say sphere testing is just "is X.position <= radiusOFUnit or radius of arbitrary sphere around unit" Where X.Position can be a vector, another unit's radius or their shield radius. It's not really true sphere colliding because we wont return any sort of data about where in the sphere the collision occurred, just that radius1 is within radius2. Now we check against opcode.

this is really quite efficient. Colliding and collision detection, is actually _very_ fast in VS. The whole collision subsystem is actually pretty fine tuned when it comes to bolts,beams, and unit collisions. This drawing after collision bug is the only thing that really needs fixing until we want to start implementing higher level stuff like maybe realistic blast waves (from explosions) and such.
That's good, I was talking to Klauss, really, about his idea for a new collision system that will use spheres that expand in time. A neat idea, but as trivial as sphere collision is, it wouldn't be useful if it produced too many false positives; so I was trying to tell klauss about a way to optimize the algorithm.
I worked on it in my mind a bit more since the last post.
What's REALLY the best is conical projections with spherical caps at the ends; and while the collision computation is not as trivial as a sphere, it is almost as trivial.
Given a ship at position p and flying in a direction at speed vector v, and a simulation time step of T, the idea is to project a cone forward of the ship, whose section grows in the forward direction, from a basic radius r, to R = r*(1+k*T).
So, say we want to test point b (for "bolt") for a collision, we simply find a point q such that,

Code: Select all

q = v*t; //i.e. linearly extrapolated position
d = distance( b, q );
Now compute sphere size, or section size (for the collision cone):

Code: Select all

s = r*(1+k*t);
and the test

Code: Select all

if( d < s ) collision_warning();
It's maybe twice as many instructions than a sphere test; BUT, it reduces the total test volumes by probably two or
three orders of magnitude.
Perhaps this could be a second layer filter to a simpler sphere-test front-end.
Needs to be fleshed out a bit, to actually use cones of length = v * interpolation_time_step, and to do cone-to-cone collisions.
the physics frame should always precede the draw frame,
I think you mean that the collision frame should precede the draw frame. Note that collisions and physics can be asynchronous, with collisions computed on the basis of interpolated physics frames, rather than real physics frames. Well... at least that's the plan; I'm not 100% sure it's the way it is now.
and if this is happening, then we are just not returning the correct position that the collision occured, and so the physics frame says it traveled the full length it can for that frame, rather than getting concatenated by the ship it collided with. This is one scenario, and if everything is coded correctly, the likely one. Since the physics frame precedes the draw, there is no need to create collision rods, as the transform for the new draw is done and that's what is checked for collisions, if found, we modify the transform and return.
I think you're assuming that collisions computations are synchronous with draw frames; I believe this is not the case.
I argued with Klauss to death over this... --to MY death, that is. He won. I believe collisions are asynchronous, AND will stay so.
BUT, if they work as planned, they will report collisions ahead of time (extrapolated), so that the interpolations done by the graphics frame will get the collision in time.
The draw then draws the new state. The bolt or beam should not be able to progress without another physics frame, so we should never be able to pass through a ship, especially if we register a collision in that physics frame.
I think you need to grep substitute "collision frame" for "physics frame"; --the physics happen a lot more slowly than the graphics (14 Hz currently, 16 Hz soon, at their fastest simulation rate, vs 30 to 60+ FPS for the graphics).
Post Reply