releases and such

[safemode]

on a topic other than switching how we distribute binary releases.

We should really start updating the wiki to reflect 0.5 no matter how long it drags out until release, this can be done now..

Of course, i suggest focusing on the development section.
pages like http://vegastrike.sourceforge.net/wiki/ ... erformance need to be written better. Like, what is the test rig? What mission file was used to run the simulation that the results some from? Plus it should be updated to reflect the current svn (which is much different from a year and a half ago).

A lot is fairly relevent still though.

The other thing that would be good to have is a Modding guide wiki, rather than just a list consisting of mostly defunct mods. Basically a set of pages that outline api's for modding and things you need to do to VS to get it to correctly use your new data set. Perhaps also a guide to incorporating dyn_universe for those mods that aren't strict remakes. In fact, the Mod link on the dev section is wrong. It's pointing to the mod list on the "end user" section.

The vast majority of the outdated material is the player's guide
Features list needs to be updated to 0.5
manual needs to be updated.
artwork throught the guide should reflect new look of VS

[chuck_starchaser]

Bit OT, but, started a little Engine Documentation for Modders WIKI page.

[ace123]

I am kind of getting into the middle of a midterm schedule, and I know some of the other developers have been pretty busy.

I'm thinking that a final release might take place in 2-3 weeks... there are still some pretty big bugs around but no time in which to fix them.

[safemode]

besides the orbital bug, what are they?

[safemode]

can we put a freeze on features in VS trunk? no more new features. I know klaus said he'd allow the disable of video and if no video exists, it shouldn't introduce any bugs into the release, but we really ought to be serious about squashing only bugs from now until 0.5 and not providing any means of introducing new ones.

maybe a declaration from here on out the only thing that gets committed to trunk is a bugfix. Maybe even tag 0.5 so those who dont listen dont pollute it with anything but bugfixes. Otherwise i'm not seeing an end to this perpetual 0.5 beta ...especially not if we keep delaying it for the sake of fixing that "one last bug"

[chuck_starchaser]

I the particular case of video, I wouldn't think it necessary to disable the feature. If the feature is enabled but not used, the chance of a bug in it showing up is dismal. And PU has needed this feature for the intros for such a long time... Disabling it till 0.5 would make us wait yet longer, unless we forked the engine.

[safemode]

disabling meaning, make it not on by default, but enableable by ./configure .. and not having any video in data4.x for 0.5

Then a full freeze on 0.5, either via /trunk head or via tagging it now.

[ace123]

I am going to commit a change in a few minutes that will allow video to be disabled (configure will check for it, or support a --disable-ffmpeg option).

Honestly I was not expecting this new change, but Klauss did a good job of keeping all the code in one place, so it shouldn't cause any issues.

[charlieg]

0.5 can be followed by 0.5.x bug fix releases. I wouldn't worry too much about disabling features that are not used by VS default, then releasing bug fix updates for mods later on.

Also don't tag 0.5 - branch it: trunk->branch->tag - tags should never be committed to, they are the state of a release. Use a branch to work in feature freeze.

[safemode]

when i get some time this weekend, i'm going to be removing the masteres repository, Then renaming masters2 to masters.

I'm going to try and continue the documentation of code i've played with as well. Mostly probably DDS related.


I also want to avoid reading in the entire DDS file when we dont have S3TC support. That fix shouldn't be a big deal.


I'm guessing the blacklist for nvidia people is working for our userbase, as i've seen no reports of white stipled images. The lack of a fix from nvidia means this will stay in place for now.


Other changes i have planned for or after 0.5 is moving _ALL_ options into structs that get initialized after the config file is read in one single place.

much like how we use gl_options, all options will be organized this way. This eliminates duplicate variables holding the same config option, and two instances of that option having possibly different defaults, since the call is what sets the default.

I'd like to have gl_options, game_options
gl_options would encompass all gl and gfx related options.
game_options would contain everything else.

they'd consist of the correct datatypes, all set in an init function. the init function would get executed before a game is loaded, so we dont have to worry about anything being unitialized, and the defaults would be set in the init function just as they are now.

most options currently are static so they are only set once, but some aren't and many are set more than one time in different variables. So i think this will be a good optimization.

It also makes it easier to see what is a config option.

my plan is to create a new set of files. options.cpp and options.h. the call to init it would be right after the config file is read in.

[ace123]

So the idea of this "options" class is to hold everything that is currently in static variables?

I like the idea of this... but, one reason that was never done before is because it would require that every file be recompiled whenever a new option is added.

Of course, with computers as fast as they are these days, it only takes a few minutes to recompile everything, so maybe it's not as much of a problem.

I suppose, a similar solution would be to still make a "options.cpp" and "options.h", but only include options.h in a few places that need access to them--for example in the configuration manager, and everywhere else, just use external variables, like
namespace GameOptions { extern int spec_distance; extern bool use_antialiasing; }

Another thing is that we can initialize all the options at the very beginning by setting a pointer in each DOM node to the corresponding global variable. Then, we can change variables during the game by means of vs_config->setVariable()--right now that just sets stuff in the DOM tree but doesn't notify anything of the update because it can't.

[safemode]

So the idea of this "options" class is to hold everything that is currently in static variables?

I like the idea of this... but, one reason that was never done before is because it would require that every file be recompiled whenever a new option is added.

and how often is that? Options are rarely added.

I suppose, a similar solution would be to still make a "options.cpp" and "options.h", but only include options.h in a few places that need access to them--for example in the configuration manager, and everywhere else, just use external variables, like
namespace GameOptions { extern int spec_distance; extern bool use_antialiasing; }

i dont like the idea of extern global variables and such. even if they're inside namespaces

Headers should only be included on an as-needed basis anyway. That's part of the reason why i want to rewrite Unit. It includes everything so anything needed a reference to a Unit pointer has to include everything.

Options aren't used all over the place. It should be an extremely small issue to have to recompile those source files that do access them.

Another thing is that we can initialize all the options at the very beginning by setting a pointer in each DOM node to the corresponding global variable. Then, we can change variables during the game by means of vs_config->setVariable()--right now that just sets stuff in the DOM tree but doesn't notify anything of the update because it can't.

we dont need to set variables during game except in rare circumstances...usually as hacks.

There would be no issue with just doing game_options.whatevervariable = newvalue;

no need to access a function to get a variable value, no need to use a function to change the datatype to what it should be. No need to use a function to set the variable.

when we start the game the config file will be read.
we init the options structs, it sets it's variables up and returns.
then we use the variables. done.

[safemode]

I've started work on the game_options class ...i should have it done on sunday. things are coming along nicely with it.


I really can't wait for 0.5 to be released so i can start cleaning out obsolete files and getting rid of at least 2 of the boost directories in /boost. pkging boost constitutes 1/2 of our download size, it's a shame we can't count on windows and mac users to have boost installed with their development environment.




I also plan making a repository for binaries. One mac, one win32...
The cool thing i plan on doing is making external definitions in these binary branches such that data4.x is downloaded too.

So we have these two modules
trunk/mac
trunk/win32

inside we have the skeletal top level directory of data4.x with the /bin directory filled with either mac binaries or windows binaries

Each other directory is an external definition of data4.x's module, so downloading trunk/mac will pull the mac binaries and data4.x seamlessly, same for win32

this way both can share data4.x, without us having to make and maintain two copies and the end user wont have to copy around binaries, they wont have to do anything. Just pull the svn of their OS and they're done.

This is in preperation for moving to an svn centric distribution system. Even if we dont go that route, it will make pkging vegastrike releases that much easier.

[ace123]

I'm not really in favor of using SVN externals for every single data folder--it will cause a lot of duplication in the root files and I just don't like the idea of having a lot of externals.

Also, it doesn't matter for the mac since it has a different .app structure it enforces for applications

Here's what I'm thinking, similar to what you are saying, but not doing the messy externals thing with embedding them inside of data4.x

Code: Select all

trunk
\- data4.x
\- win
    \- vegastrike.exe
    \- vssetup.exe
    \- data4.x (external definition to data4.x)
\- mac
    \- VegaStrike.app
        \- Contents
            \- Resources (external definition to data4.x)
            \- MacOS
                \- vegastrike
            More Maccy files
    \- VegastrikeSetup.app
        ...

[ace123]

Headers should only be included on an as-needed basis anyway. That's part of the reason why i want to rewrite Unit. It includes everything so anything needed a reference to a Unit pointer has to include everything.

Options aren't used all over the place. It should be an extremely small issue to have to recompile those source files that do access them.

They are used in about half the source files... A grep tells me that it is around the same number that directly include unit_generic.h. This might ened to be changed, but in the past options have been added for anything, such as whether to enable certain hacks, or some constant, even though in all likelyhood those values might never be changed anyway.

we dont need to set variables during game except in rare circumstances...usually as hacks.

There would be no issue with just doing game_options.whatevervariable = newvalue;

no need to access a function to get a variable value, no need to use a function to change the datatype to what it should be. No need to use a function to set the variable.

yeah I agree for the most part, but this will make it hard to have generalized way of settiing individual options in the options menu (a list of options and their values, kind of like Firefox's about:config)...
which I suppose is fine if we only allow for a few things to be changed.

Also, it would be nice to be able to write out the config to the user's settings file. Might be too much work for no,w but keep it in mind.

[safemode]

I'm not really in favor of using SVN externals for every single data folder--it will cause a lot of duplication in the root files and I just don't like the idea of having a lot of externals.

Also, it doesn't matter for the mac since it has a different .app structure it enforces for applications

Here's what I'm thinking, similar to what you are saying, but not doing the messy externals thing with embedding them inside of data4.x

Code: Select all

trunk
\- data4.x
\- win
    \- vegastrike.exe
    \- vssetup.exe
    \- data4.x (external definition to data4.x)
\- mac
    \- VegaStrike.app
        \- Contents
            \- Resources (external definition to data4.x)
            \- MacOS
                \- vegastrike
            More Maccy files
    \- VegastrikeSetup.app
        ...

that's fine. i though we'd want to make the choice of mac or win32 seamless looking (no different than if you grab data4.x as it is now), but that works too.

It basically should make a release just about as easy as svn export win32; or svn export mac; etc.

[safemode]

Headers should only be included on an as-needed basis anyway. That's part of the reason why i want to rewrite Unit. It includes everything so anything needed a reference to a Unit pointer has to include everything.

Options aren't used all over the place. It should be an extremely small issue to have to recompile those source files that do access them.

They are used in about half the source files... A grep tells me that it is around the same number that directly include unit_generic.h. This might ened to be changed, but in the past options have been added for anything, such as whether to enable certain hacks, or some constant, even though in all likelyhood those values might never be changed anyway.

we dont need to set variables during game except in rare circumstances...usually as hacks.

There would be no issue with just doing game_options.whatevervariable = newvalue;

no need to access a function to get a variable value, no need to use a function to change the datatype to what it should be. No need to use a function to set the variable.

yeah I agree for the most part, but this will make it hard to have generalized way of settiing individual options in the options menu (a list of options and their values, kind of like Firefox's about:config)...
which I suppose is fine if we only allow for a few things to be changed.

Also, it would be nice to be able to write out the config to the user's settings file. Might be too much work for no,w but keep it in mind.

I'm already in process for creating an options class. The options class will be a flat list of every option we use in the game (see thread on dealing with galaxy options). Every option is grouped in it's section, every option in the header is in the same order in the source (grouped as well), where it's value is set. No static crap. No duplicate instances of the same option, and no multiple default values for those different instances (and i've seen that).

MOST of these options are not reflected in the options file. I assume they exist for mod use. I have come across some that aren't used at all. They're just set and forgotten about.

I'm about half over. There' are a ton of options and i'm gonna work on completing the class during the week.

Adding an option will require inserting the correct variable in the header, then seeting it in the source file in init() just like you would do in the calling function (only not static). That's it. It's not too hard and it's not inconvenient, it puts all the options in plain view (so you dont duplicate or forget). All you do to use the option is make class vs_options game_options external to your source file, then do game_options.var_name;

very easy, and it'll make mods happy and make tracking down options for us extremely easy.

[safemode]

I propose we add a version to the directory name for generated content. like ~/.vegastrike and such. It should have a version appended that will be looked at by VS when it loads. The old version is ignored and the new version will be created if not found.

We seem to be having too many issues related to the generated content being older than the data that they were generated from..

so basically we'd see ~/.vegastrike-0.5.0 Later on, when something is found to render generated content invalid, we would increment the version on our directory. This way, we dont invalidate content that is still compatible arbituarily.

[pyramid]

Debian is asking for a package or release tag: http://vegastrike.sourceforge.net/forum ... hp?p=95655

Issues with collider and dds are solved. We are mostly hammering on new additions, and I don't think new features or even further improvements (like the performance in the sol system) should stop us from the release (it's <1.0). I don't see any urgent items from the 0.5.0 roadmap that could not be pushed to post-0.5.

Anyway, who has/have the final say seem/s not to advance an opinion on the 0.5 release.
In my opinion, a project should rely on decision makers that are active and present, at least available to make those decisions (release or update roadmap).

[jackS]

HellcatV, ace123 and I are going to take a crack at things this upcoming week (it's spring break for all of us). We should have a release candidate by the end of the week, and with any luck, a release .

[vodalian]

Nice


You guys are doing a great job with this game, thanks again for all the work involved

[chuck_starchaser]

So the idea of this "options" class is to hold everything that is currently in static variables?

I like the idea of this... but, one reason that was never done before is because it would require that every file be recompiled whenever a new option is added.

Of course, with computers as fast as they are these days, it only takes a few minutes to recompile everything, so maybe it's not as much of a problem.

I suppose, a similar solution would be to still make a "options.cpp" and "options.h", but only include options.h in a few places that need access to them--for example in the configuration manager, and everywhere else, just use external variables, like
namespace GameOptions { extern int spec_distance; extern bool use_antialiasing; }.

Guys, have you heard of the "header inversion" idiom? This is a text-book example of what header inversion is for. You can google it for a more in-depth explanation; I'll just comment on how it would be applied to this particular problem. It's usually meant to solve the problem of header dependencies on global sets of variables that are changed or augmented often. In header inversion, the clients of a global interface actually define the interface. The global interface implements, but does NOT declare its methods.

First, the problem, succinctly:

A group of global variables or functions, let's call it the "global interface X", are accessed sparsely, but from many places in the code, and often have to change. Thus, we have X.cpp and X.h. Many cpp files include X.h because they need one or two functions from it, typically; but X.h is updated and changed often, causing all those many modules to have to recompile.

Header inversion:

Step 1:
Instead of X.cpp including a single X.h, we make X.cpp include X.h AND Xinversion.h.
We move most stuff in X.h to Xinversion.h. The only stuff we leave in X.h is those variables and functions that are widely used and permanent. Functions that are used by a single other module we move them (for now) to Xinversion.h. This will not compile; need to continue on to step 2.

Step 2:
We find the module that needs each function now in Xinversion.h. Say, module foo.cpp needs void bar(), and nobody else does.
So, we add a new header to foo.cpp, besides foo.h, and name it something like foo_X_inversion.h. We now move the prototype for void bar() from Xinversion.h to foo_X_inversion.h, and replace the declaration of void bar() in Xinversion.h with a #include "../../xxx/yyy/foo_X_inversion.h".
We continue doing this for the rest of the prototypes in Xinversion.h, until Xinversion.h has nothing but #include lines. This should compile, now.

Step 3:
From now on, every time a module Y somewhere needs some new function from X, say void foobarnot(), we simply create a Y_X_inversion.h header for Y.cpp, which declares void foobarnot(), and we add a #include line to Xinversion.h to include Y_X_inversion.h. Notice that X.h has not changed, as Xinversion.h is included directly by X.cpp; so this addition does not produce widespread recompilation. If we forgot to implement foobarnot(), we'll get a link error, and so we go to X.cpp and write the function.

Step 4:
Now, if X is a class, we cannot declare member functions elsewhere.
In this case, we can use a multiple inheritance trick:
X.h defines

Code: Select all

class publicX {...virtual ~publicX()=0;...};

just so that a few widely use functions can be had by including X.h.
Xinversion.h is for private use by X.cpp, and looks like,

Code: Select all

#include "../../xxx/yyy/foo_X_inversion.h"
#include "../../xxx/yyy/Y_X_inversion.h"
#include .........
class Xinversion
:  public foo_X_inv
,  public Y_X_inv
,  public .............
{
  ........
  virtual ~Xinversion() = 0;
};

X.cpp defines

Code: Select all

#include "X.h"
#include "Xinversion.h"
class concreteX : public publicX, public Xinversion
{
  ...
  ~concreteX(){}
};
//implementation:
...............................

So, now, foo.cpp can get the address to an instance of concreteX and assign it to a pointer of type foo_X_inv, and use the functions it declared on behalf of X.
Module Y can later do the same by declaring yet new functions on behalf of X.
And none of the new additions cause global recompiles.


Header Inversion is also used when low level modules need to access the state of a high level module. Usually, header dependencies flow UP the hierarchy: high level modules include the headers of low level modules. But when a low level module needs to call a function of a high level module, header dependency is inverted relative to the normal dependency flow, and can lead to circular header inclusion loops.
Header inversion breaks such loops by having the low level modules declare new interfaces on behalf of high level modules. Then, all the high level modules do is implement those "requested" functions or interfaces.

[safemode]

Really, I dont care if files have to get recompiled because of an edit to a commonly used header. Recompiling is fast even if every file has to be compiled.

What i care about is files that include uneccessary headers. I also care about part of what you talked about with inversion. Low level files should not include high level in an ideal situation. A properly made API heirarchy should only go in one direction. It should be our goal to make the ideal happen. We shouldn't make it easier to subvert the ideal.


Now that aside. This close to release I think we need to _REALLY_STOP_ adding crap to the project that introduces more bugs. Only extremely benign or bugfix or cleanup changes.

Cleanup:

We need to comb the source and make sure all literals to floats and doubles are suffixed with an f. This is a must. Similarly, we must make sure any mixing of types is properly casted.

We absolutely need to get rid of the "using" keyword in headers. Get used to being absolutely specific about namespaces in headers. If that means you have a header with 1000 uses of string then too bad, you'll be adding 1000 std:: 's to prefix them.

Lets try and get rid of typedef's. They obfuscate things all to hell. How many "Vector" types do we have that are all just typedef's of the same damn thing?

And Finally, we need to work on removing any unused headers that are included in headers and source. This is in prep for the culling that will occur after 0.5 where I hope to get rid of all the dead code in VS that's been leftover from years of work.


Bugfixes:

We hope that the orbiting bug has been fixed in a way that it allows us to fix it's molestation of the simulation priority queue without reversing the orbiting fix/ or nullifying it. Other than that, the rest of the Bugs consist of fixing the sound playing after quit bug and data related bugs (missing unit messages mostly)

Benign Code additions:

I consider the options work to be completely benign. It can be worked on and it changes nothing in terms of functionality or conflicts with anything else. It's simply a shuffling around of code. This can continue to get worked on throughout 0.5

Basically, if it changes functionality, or adds new functionality, then it _SHOULD_WAIT_ until after 0.5.

[pyramid]

HellcatV, ace123 and I are going to take a crack at things this upcoming week (it's spring break for all of us). We should have a release candidate by the end of the week, and with any luck, a release .

There has been a lot of activity last week. Everything seems quiet now. Any progress on the release?

[loki1950]

The windows exe is still broken the @#@$%^manifest file again.

Enjoy the Choice