chuck_starchaser's .plan

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

chuck_starchaser's .plan

Post by chuck_starchaser »

So, just to put some new ideas into writing. Things are starting to move, now
that Klauss has committed the cubemaps code, and that Safemode is back, and
that Jason is making headway with the windows build; and all this puts me in a
mood to set realistic goals, and getting them done.


The way this is taking shape in my mind, shader development-wise, is, --starting as
soon as someone creates a windows branch or tag, so that I can commit to trunk
without worrying about breaking windows...

1) Commit the basic upgrade for all shaders to use cubemaps.

2) Commit the sheet_glass technique and shaders, and the mining base update
that calls for the technique.

3) Update the High End shader just a tiny bit, namely: Use appropriate math for
shininess, LOD and all that, and use stars' solid angles. About the same number
of instructions; a zero-cost upgrade.

4) Work on something less than the UberShader, but more than HighEnd; call
it HighEndPlus or something. Basically, NO texture changes; just adding a basic
materials AI and fresnel for paints. Unlike UberShader, HighEndPlus would be
a "default" shader, in the sense that, currently, if a mesh doesn't specify a
technique, the engine picks the highest the user setting allows. But we can't do
the same with Uber. We can't assume Uber for a mesh not specifying a shader,
even if the user would select Uber in vssetup. But HighEndPlus will be in the
same family as HighEnd and its lessers, and defaultable to. Besides metal vs.
paint, HighEndPlus will give the option to use detail textures, which is one
thing Fendorin wants very badly, and the option to have AO in glow alpha;
--but not the obligation. Shininess will be computed ad hoc, like it is in HiEnd.

But yet... Before the UberShader...

5) A flat_shader, for greebles, that shades faces flat even though the mesh is
smooth-shaded, to allow high boxy greebling complexity without pushing vertex
counts through the roof. Yes, Fendorin; so go ahead and put greebles in a separate
mesh; might as well; with this special shader we'll gain performance a lot, which
will offset the impact of having separate meshes.

6) A shader for ship and missile exhausts, to replace those awful blue sparkly things.

7) A shader for in-cockpit front-windows, with glare effects.

8) A shader for rock, for rocky planets and asteroids and mining bases.

9) Finilizing Klauss' Planet Shader.

9.5) Perhaps a shader for jump-points/wormholes, whatever.

Then...

10) UberShader. It will impose new texture packing requirements, though not too
many: AO in glow.a, gloss in spec.a, and detail control in damage.a. Among its new
features will be rough, AO-based shadows and specular occlusion, and inter-unit
shadows using "negative lights".

Then...

11) CineMut.


As far as modeling is concerned, I'll play it by ear. My sights are set on Uber Shader,
minimum, for any models I'll do, but there are more urgent shaders to be written.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: chuck_starchaser's .plan

Post by charlieg »

What also needs deciding is what goes in to 0.5.1
- I guess this is somewhat dependent on Jason getting the Windows build process to work
- Cubemaps must now be in, since they are done (one or two issues left, right?
- and all the new sounds since 0.5.0 (Turbo, Clonewolf)

What else is there?
- What ships by Fendorin need to go in? Is anybody capable of doing this?
- Klauss's planet shader - or is it nearly ready?
- What on your list, chuck, should be a 0.5.1 target, if any?

0.5.0 saves should work in 0.5.1 - if you want to break anything then that goes in 0.6.0 IMHO.
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: chuck_starchaser's .plan

Post by chuck_starchaser »

In terms of shaders, for now I think I will stick to the plan above, and which, if any, make it
to the next release will depend on when the door closes. Debugging is something full of
uncertainty. Like pulling cans of soda out of a machine, you never know when the last bug
is out until it is. With the glass shader, things went really well. I got two bugs I'm hunting
down, and I'm deleting any code that doesn't contribute much, as I go along; so, very final
stages. The other shader, the opaque, it's got more bugs than lines of code. That's why I
decided to change plans. There's a couple of jewels in the UberShader that can be ported
to the high end, already. Why wait? Like the shininess math.
So, for sure, I could pledge a new and improved high_end shader, a brand new sheet_glass
shader, and possibly the high_end_plus and/or flat_shader. These should not take
very long at all.

As for putting Fendorin's models in-game, I'll do that to whatever extent mesher permits.
I tried mesher with the Seaxbane mesh and it crapped out, segfault. But then I used it
successfully with the mining base and the Schroedinger; no problemo.

In terms of modeling, I'm promising nothing right now. Well, I'm upgrading a few simply
because I went in to change their normalmaps to the new UUUV format, and got tempted
to add an AO... which couldn't be done without cleaning the mesh... same old story. Plus,
I might just throw in the towel and finish the mining base, which I started redoing long
ago but lost the files. Now I found half of them in the masters repo.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: chuck_starchaser's .plan

Post by safemode »

Since it was decided to move to cubemaps and do away with spheremaps, breaking is going to occur, this means that the next version should probably be 0.6.0, as there simply wont be any backwards compatibility there and too much new data has been introduced.

As soon as you start adding new models and such, that pretty much means new minor version ...and not simply a revision to a minor version.

As for waiting to commit these non-backward compatible changes, you dont need to. The 0.5.0 version of vegastrike is only guaranteed to work on 0.5.0's release of the data repo. Not the svn head. The only thing that should be expected to work with svn head is an svn head of the code, and it's fairly obvious nobody in windows land is using that. So i say go for it. But once that does happen, any sort of ./configure flags that enable or disable it have to be removed and the default behavior is then set.

Dont bother doing any of that until you have both the /data and the /vegastrike changesets ready for commit, so they can be done one after the other.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: chuck_starchaser's .plan

Post by chuck_starchaser »

Alright, then; I'll go through all the shader and technique changes one more time, and maybe update the Agricultural Station to use the sheet_glass shader; so probably in a couple of days I'll commit all the new stuff.
But I still don't understand what windows users will do when they update data and everything breaks. They are going to flood the forum screaming murder... There should at least be an announcement post for them NOT to svn up; --and how to fix things if they did, and want to revert.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: chuck_starchaser's .plan

Post by safemode »

I really dont think there are that many users who are using 0.5.0 binaries with svn data. Most windows users who can't compile are not likely to take up svn.

svn head is way way beyond 0.5.0, and anyone who thinks the bin from 0.5.0 should work with svn head is not living in reality. But like i said, i think those people are few and far between. The only thing a user should expect is that the svn head of /vegastrike is compatible with the svn head of /data and also tag for tag and release for release.

We're not gonna get into compiling a new win32 binary everytime the svn head gets a commit that changes things. Bins should be created upon release, and used with data tagged at that release and that release alone. Using it with other data is at your own risk. It may work, it may not. It's not expected to.

That's the only real warning we need to make. If someone in win32 land wants to use the latest svn of /data, then they can compile the latest svn of /vegastrike. The complete lack of (until recently) of anyone talking about doing that leads me to believe most people are still running the 0.5.0 release of both /data and /vegastrike in win32 land. Hell, the majority of users are doing that in unix too. Our real problem isn't with svn, it's with us not making smaller incremental releases more rapidly and instead telling people that it's fixed in svn and to use that. And part of that problem is the reluctance to tarball up /data every other month. Until we solve how to incrementally update a 700MB dataset, we wont do releases fast enough to take svn out of the "use this for now" place it has no business being in.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: chuck_starchaser's .plan

Post by chuck_starchaser »

Gottcha. Yeah, I'm used to thinking of everybody being on svn head, because that's
the way we set it up with PU.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: chuck_starchaser's .plan

Post by safemode »

Thought I'd post this query here since it's fairly related to this type of work going on.

basically, we've been really focused on getting the high end of the game looking right. We're making very good head-way in that direction too. But in doing so, we've completely neglected the other end of the spectrum. To the point where i dont even think it's possible to play the game on low end machines.

It would be ideal to eventually look into the low end spectrum, and while we probably wont be able to help much in the area of hdd install size without implementing texture packs (which is not a generally agreed upon thing) we can still do something for actual gameplay for these people.

What i was thinking was maybe adding a set of really _REALLY_ minimal textures that can be shared across multiple ship types (basically maybe just a square of color that can be plastered over a mesh - grey for some ships, brown for others. etc and the same for planets). In addition to this, and why i thought to discuss this idea here, was that we would also need to generate very low poly meshes for the units, as the number of polys greatly effects performance for the lower end of the spectrum, both in gpu and cpu as the complexity of the mesh directly influences the complexity of the collider mesh and collision detection.

In this way, selecting "low" would not only reduce the number of textures active at any given time in addition to their size but it would also reduce the gpu and cpu horsepower required to render the meshes. Basically what drives me to want this is wanting vegastrike on my phone :) if i can have wingcommander running in dosbox, then i should be able to have native vs :)
Ed Sweetman endorses this message.
snow_Cat
Confed Special Operative
Confed Special Operative
Posts: 349
Joined: Thu Jan 05, 2006 12:43 am
Location: /stray/
Contact:

Re: chuck_starchaser's .plan

Post by snow_Cat »

^- - ^ While I agree that including resources for low end systems is important in retaining/growing our user base; having the very high-end makes us more attractive to all users, incl. those who won't enjoy the high-end graphics but will still have a 'warming' effect to their experince with the more 'economical' stuff.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: chuck_starchaser's .plan

Post by chuck_starchaser »

safemode wrote:Thought I'd post this query here since it's fairly related to this type of work going on.

basically, we've been really focused on getting the high end of the game looking right. We're making very good head-way in that direction too. But in doing so, we've completely neglected the other end of the spectrum. To the point where i dont even think it's possible to play the game on low end machines.
Not sure what you're talking about; maybe there's been a divergence between vegastrike and PU, but there are PU players playing with very old machines, with TNT's, and playing without problems.
One problem with Vegastrike's compatibility with old hardware is with alpha-blending, with glass looking opaque in old videocards; which I solved in PU: The secret is to put a low alpha in the diffuse texture's alpha channel, as old, fixed gl gpu's only seem to look at the alpha channel for alpha info. I've updated vegastrike's transparencies to use a black diffuse texture with 0.1 in alpha; just haven't committed the bfxm's that use it, yet; still debugging the shaders.
It would be ideal to eventually look into the low end spectrum, and while we probably wont be able to help much in the area of hdd install size without implementing texture packs (which is not a generally agreed upon thing) we can still do something for actual gameplay for these people.
There won't be any trouble for them yet. The shader plan right now is,
a) An upgrade of the "default" and "highend" shaders (no change in texture packing; just hegemonizing the lighting equations with the newer shaders, for consistency. Highend will now use the AO if it is present in glow.alpha, but won't require it.
b) Introduction of two new shaders, at the highshader level: "highshader_flat" and "fireglass". No changes to the texture packing.
c) Introduction of a new, higher level across the board; the "plus" family of shaders, like "highshaderplus", which will use a new texture with one channel for smooth/flat shading and three channels for detail control; but which will require no change to the packing in the other textures, making the packing compatible with fixed gl hardware.

And then, after that will come the uber shader and then cinemut which will indeed require a new packing, but maybe the CPU can produce compatibility textures on the fly when needed.
The only current incompatibility I'm about to commit is with normalmaps. No gpu can decode them without shader support. Very easy to convert on-the-fly, however, if you want to write the code for it. To go from our proprietary normalmap packing (dUdUdUdV, or uuuv for short) to standard, blue normalmap (dUdVZ), the function would be,

Code: Select all

struct rgb { float r, float g, float b };
struct rgba { float r, float g, float b, float a };
rgb std_normalmap_texel_from_uuuv( rgba uuuv_texel )
{
    rgb result;
    //unpack:
    result.r = 0.3333f * ( uuuv_texel.r + uuuv_texel.g + uuuv_texel.b ) - 0.5f;
    result.g = uuuv_texel.a - 0.5f;
    result.b = 0.25f; //a convenient way to scale up on renormalizing
    //normalize (and divide dU and dV by two for signed encoding)
    float adj = 0.5f / sqrtf( result.r*result.r + result.g*result.g + result.b*result.b );
    result.r *= adj;
    result.g *= adj;
    result.b *= (2.0f*adj);
    //finalize signed encoding for dU and dV
    result.r += 0.5;
    result.g += 0.5;
    return result;
}
What i was thinking was maybe adding a set of really _REALLY_ minimal textures that can be shared across multiple ship types (basically maybe just a square of color that can be plastered over a mesh - grey for some ships, brown for others. etc and the same for planets).
If you're talking about video memory usage and you go way back, you'll find videocards with only a few megs. Probably a solution like that might work; it might be doable via the techniques files. There's already gray and metal textures under /textures; just a matter of, in the code, reverting to them and ignore textures specified in meshes. Not sure how much coding work.
In addition to this, and why i thought to discuss this idea here, was that we would also need to generate very low poly meshes for the units, as the number of polys greatly effects performance for the lower end of the spectrum, both in gpu and cpu as the complexity of the mesh directly influences the complexity of the collider mesh and collision detection.
This is a HUGE amount of work.
Why is it important to support old hardware, anyways?
In this way, selecting "low" would not only reduce the number of textures active at any given time in addition to their size but it would also reduce the gpu and cpu horsepower required to render the meshes. Basically what drives me to want this is wanting vegastrike on my phone :) if i can have wingcommander running in dosbox, then i should be able to have native vs :)
I see. No logical connection, though: You can have wingcommander on dosbox because it's very old and tiny (had to fit in a meg of memory). Vegastrike is a more modern game, and there's no reason why it "should" be able to run on minimal hardware; and it'd probably be quite a project to make it be so.
Would have been trivial if we had adhered to having LOD's from the beginning, but many models (I daresay most) don't have LOD's. And before you ask, no; there's no automatic mesh poly reduction programs. None that work, anyways.

EDIT:
Have you looked into Boost Properties Tree? It can serialize complex data structures to XML or to Json and other formats and back. Maybe the whole savefile code could be rewritten in one line.

EDIT2:
Also BOOST::TEST could replace all our message logging. Very easy to write, like:
BOOST_CHECK( i == 4 );
...and if it fails you get file and line number in the log, saying "the test i == 4 failed".
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: chuck_starchaser's .plan

Post by safemode »

well, mostly I'd like the game to not just run on 9800+ series graphics cards (talking in terms of nvidia here). While it's important to not let old hardware hold you back, it's also important to not find ourselves in a niche of users too small to support interest in the project.

I'd much rather have the annoyance of needing to maintain support for at least 6000 series graphics cards and have a hugely larger userbase pool and thus, possible project activity than the ease of only supporting CUDA type cards and only having a handful of people who can play the game and it not run and look like blah.

The extreme of running it on my phone was kinda just a joke. Although, i could plug a joystick in to it .... :) anyways, I'm not saying we should go as far as needing to make integrated intel graphics usable with the game, but at least we should be able to say that people with graphics cards in the 6000 and up series can play the game without it dropping frame rates into the teens even on lower quality settings and such.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: chuck_starchaser's .plan

Post by chuck_starchaser »

Let me put it this way:

1) Nothing I'm working on will cause someone playing VS on a P2+TNT system to not be able to play anymore. I'm not dealing at all with that end of things. In fact, the changes I did to how we represent glass will benefit those without shader support; --they will see transparency for the first time. (Before there was no alpha channel in the texture; now there is.)

2) Nothing at all we do needs CUDA.

3) The highshader (Nicest) will continue to require a 6600 or better (ps3.0) gpu. Same applies to its sister shaders: highshader_flat and fireglass.

4) The default shader requires much less, but I'm not sure what's the exact lowest model.

5) The newer shaders in the pipeline, the highshaderplus family, will probably require an 8800 minimum to get playable framerate.

6) The biggest killer for old systems is probably not the shaders or the polygons, but the amount of textures competing for video ram space.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: chuck_starchaser's .plan

Post by safemode »

well, i know on my 6600, which has i think 256MB of ram, i start out with a shader (i have vssetup set to nicest) and flying around a bit causes it to drop to no shader, or what i assume is no shader.

Somewhat on that subject:
I'm wondering if perhaps the dynamic selection of shaders is unable to differentiate cpu bound low framerate with gpu bound low framerate. Since the shader should be gpu bound, it should only matter if we fall back when the gpu is being pushed too hard, but if all we use is framerates to decide this, then we could be dropping to a lower shader when the cpu is to blame. Is framerate all we look at or do we look at framerate + cpu load to see if cpu is 100% _and_ framerate is suffering and if so, ignore it and dont fall back. But if framerate is low but cpu is not 100% then back off because it's the gpu that's at 100%. ??? just guessing out loud .
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: chuck_starchaser's .plan

Post by chuck_starchaser »

safemode wrote:well, i know on my 6600, which has i think 256MB of ram, i start out with a shader (i have vssetup set to nicest) and flying around a bit causes it to drop to no shader, or what i assume is no shader.
I'm curious why that's happening. Could you, next time it drops, quit the game and check the stderr? It could happen because of some mesh calling a technique that doesn't exist, though I'm not sure ANY meshes call for particular techniques except the ones I'm modifying right now.
Somewhat on that subject:
I'm wondering if perhaps the dynamic selection of shaders is unable to differentiate cpu bound low framerate with gpu bound low framerate. Since the shader should be gpu bound, it should only matter if we fall back when the gpu is being pushed too hard, but if all we use is framerates to decide this, then we could be dropping to a lower shader when the cpu is to blame.
I think I once heard about this "feature", but I'd forgotten all about it. This is WRONG. It should be removed. It should be the user's decision to switch to a lower shader for the sake of frame-rate; the app should NOT presuppose what the user prefers, for one thing; and for another it doesn't know that the low frame-rate has anything to do with the shader. That is an EVIL feature. A bug.
A user might prefer to remove FSAA, or window size, or level of detail, or anisotropic filtering, or... There are many ways to address low frame-rates. That feature should be removed; erradicated.
Is framerate all we look at or do we look at framerate + cpu load to see if cpu is 100% _and_ framerate is suffering and if so, ignore it and dont fall back. But if framerate is low but cpu is not 100% then back off because it's the gpu that's at 100%. ??? just guessing out loud .
The cpu cannot be the cause of low frame-rate. It simply cannot.
And the shader can be, but probably isn't either.
The most likely cause of low frame-rates is texture trashing due to insufficient video ram; or excessive texture bandwidth, or excessive bandwidth to the framebuffer.
If someone's going to write a full graphics pipe diagnostics, that would be great; but in the absence of that, software should not automatically blame shaders for low frame-rates.
Mets
Mercenary
Mercenary
Posts: 115
Joined: Tue Jun 10, 2008 12:52 am

Re: chuck_starchaser's .plan

Post by Mets »

safemode wrote:I really dont think there are that many users who are using 0.5.0 binaries with svn data. Most windows users who can't compile are not likely to take up svn....If someone in win32 land wants to use the latest svn of /data, then they can compile the latest svn of /vegastrike.
On windows, I use the latest SVN data and whichever binaries are associated with that (in the /bin folder). I don't think it's a good idea to ask people to recomplie every time there's a new data update...0.5 is so old at this point, that most people have migrated to the SVN release anyway.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: chuck_starchaser's .plan

Post by safemode »

there is no /bin in /data So what you are using is a bin that's not associated with the data (svn HEAD) if you're running in win32 land unless you compiled it yourself.

The correct location for the svn bins in win32 is the svn repository "win32" which was last compiled 10 months ago.

That is the latest bin for win32 land that anyone around here knows of. It is not expected to be on-par with the svn head of /data.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: chuck_starchaser's .plan

Post by chuck_starchaser »

Check my last post, if you missed it. It kind of got lost in the previous page.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: chuck_starchaser's .plan

Post by safemode »

chuck_starchaser wrote:
safemode wrote:well, i know on my 6600, which has i think 256MB of ram, i start out with a shader (i have vssetup set to nicest) and flying around a bit causes it to drop to no shader, or what i assume is no shader.
I'm curious why that's happening. Could you, next time it drops, quit the game and check the stderr? It could happen because of some mesh calling a technique that doesn't exist, though I'm not sure ANY meshes call for particular techniques except the ones I'm modifying right now.
Somewhat on that subject:
I'm wondering if perhaps the dynamic selection of shaders is unable to differentiate cpu bound low framerate with gpu bound low framerate. Since the shader should be gpu bound, it should only matter if we fall back when the gpu is being pushed too hard, but if all we use is framerates to decide this, then we could be dropping to a lower shader when the cpu is to blame.
I think I once heard about this "feature", but I'd forgotten all about it. This is WRONG. It should be removed. It should be the user's decision to switch to a lower shader for the sake of frame-rate; the app should NOT presuppose what the user prefers, for one thing; and for another it doesn't know that the low frame-rate has anything to do with the shader. That is an EVIL feature. A bug.
A user might prefer to remove FSAA, or window size, or level of detail, or anisotropic filtering, or... There are many ways to address low frame-rates. That feature should be removed; erradicated.
Is framerate all we look at or do we look at framerate + cpu load to see if cpu is 100% _and_ framerate is suffering and if so, ignore it and dont fall back. But if framerate is low but cpu is not 100% then back off because it's the gpu that's at 100%. ??? just guessing out loud .
The cpu cannot be the cause of low frame-rate. It simply cannot.
And the shader can be, but probably isn't either.
The most likely cause of low frame-rates is texture trashing due to insufficient video ram; or excessive texture bandwidth, or excessive bandwidth to the framebuffer.
If someone's going to write a full graphics pipe diagnostics, that would be great; but in the absence of that, software should not automatically blame shaders for low frame-rates.

Yea, it needs to go. Just gotta find some time to hunt it down and get rid of it.
Ed Sweetman endorses this message.
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: chuck_starchaser's .plan

Post by pheonixstorm »

Has all the cubemap code been commited to svn? I see the data side has but nothing newer than 2 weeks in the src side.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: chuck_starchaser's .plan

Post by chuck_starchaser »

pheonixstorm wrote:Has all the cubemap code been commited to svn? I see the data side has but nothing newer than 2 weeks in the src side.
Yes, Sources were committed 2 weeks ago; but weren't usable without the shaders using the cubemaps; and the shaders would be useless without .technique's, which would be useless without meshes invoking them; but now everything's in, including updated agricultural and diplomatic bases.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: chuck_starchaser's .plan

Post by klauss »

chuck_starchaser wrote:
Somewhat on that subject:
I'm wondering if perhaps the dynamic selection of shaders is unable to differentiate cpu bound low framerate with gpu bound low framerate. Since the shader should be gpu bound, it should only matter if we fall back when the gpu is being pushed too hard, but if all we use is framerates to decide this, then we could be dropping to a lower shader when the cpu is to blame.
I think I once heard about this "feature", but I'd forgotten all about it. This is WRONG. It should be removed. It should be the user's decision to switch to a lower shader for the sake of frame-rate; the app should NOT presuppose what the user prefers, for one thing; and for another it doesn't know that the low frame-rate has anything to do with the shader. That is an EVIL feature. A bug.
I agree.

However I think I never experienced that, techniques-based configuration got rid of that behavior since it wasn't compatible. I'll have to check.
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: chuck_starchaser's .plan

Post by chuck_starchaser »

Glad you're back, klauss. Yeah, I've never experienced it either, but just as a matter of principle, useless code should be removed; dead code should be removed... Why not? If you find out you couldn't remove it, for some reason, at least you learn something :D But chances are some bugs may be fixed while removing dead code. And if the code is not officially dead, but rather masked, and it's evil; all the more reasons to get rid of it.
By the way, you were telling me that cloaking was never used; could we get rid of cloaking related code? There's probably megs of it.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: chuck_starchaser's .plan

Post by klauss »

chuck_starchaser wrote:By the way, you were telling me that cloaking was never used; could we get rid of cloaking related code? There's probably megs of it.
Never used in VS or PU. I think vegatrek does use it.

So you can remove it from the techniques and shaders (just remove the corresponding auto_param), but not from the engine.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: chuck_starchaser's .plan

Post by pheonixstorm »

I think if the cloaking code is so scattered it needs a nice cleanup to its own set of files. At least then working or not we will know where to go to fix or delete. Just another eventualy cleanup project...
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: chuck_starchaser's .plan

Post by chuck_starchaser »

klauss wrote:
chuck_starchaser wrote:By the way, you were telling me that cloaking was never used; could we get rid of cloaking related code? There's probably megs of it.
Never used in VS or PU. I think vegatrek does use it.

So you can remove it from the techniques and shaders (just remove the corresponding auto_param), but not from the engine.
Okay , but I don't understand how VT are using it, when the blend mode for most things is ONE ZERO. Or, are they just letting the ships snap booleanly to full invisibility at once through alpha-testing?
In any case, what we could use for VS and PU would be to use the existing cloaking code to command silent running mode.
Post Reply