New Release - Whats left to do?

[Deus Siddis]

For realism, space elevators are very possible.. just too costly. I have read several articles, one from popular mechanics that shows we can use carbon nanotubes to create a working space elevator easily. Its just way too expensive

They wouldn't be too expensive in the distant future setting of VS though. . . except for a mysterious alien plot device that eats all other nanotechnology in the universe.

Actually just nothing us poor gamers could afford you mean. Most sci-fi series/movies no longer use models like they once did for the original Star Wars trilogy. Its all CGI on graphics cards that run circles around what we use for gaming.

Nah, it's not at all the expense of your graphics card. It's if you have an entire render farm crank out pre-rendered footage at .0001 frames per second for several months.

I think as long as we have one or two nice HUGE ships we should be ok.

A 1 kilometer long Aeran Leonidas and probably much stouter 600 meter Rlaan Dezong. Then a few battlecruisers in the ~400m length range, a shit load of cruisers around the size of RL super carriers or battleships, etc.

In other words I'm saying we'll have those two huge ships plus a lot of other quite big ones. And then you have stations too.

As for walkable interiors.. we don't need the ENTIRE interior just parts of it. And this is where we CAN get away with reusing the same stock models over and over again. How often are the corridors going to change appearance? I think huge ships should realisticly be modeled in section anyway then pieced together when completed.

The repetition of elements to varying degrees will be necessary for any capital vessel. But when you get up to measuring things in kilometers, the repetition goes beyond intense. We shouldn't push the limits like this more than a half dozen times or the technique will begin to show through.

[pheonixstorm]

The thing is we don't even need the entire interior. Even repeated. Any boarding actions or combat ops would only require a trip to the bridge or engineering. For some large cap ships, stations, and shipyards certain elements will be reused but as long as we can use different placeables (to use the nwn term) we can more easily get around the reuse limit. If a certain hallway used a few dozen times has different light fixtures, rails, piping, etc placed in different spots each scene then the reused hallway will almost always feel different

[greenfreedom10]

The thing is we don't even need the entire interior.

Regardless, a 1 km ship is still enormous. Any bigger just seems ridiculous (to me). In-game, even a 500m ship should look impressively large. And would it not look weird to see ships that dwarf stations?

[breese]

I have attached another patch that fixes more memory leaks.

If you start the game and exit immediately again from the main menu, the game leaks 13Mb. With the attach patch we leak 8Mb less.

Most of the memory leaks are due to global caches and not particularily dangerous by themselves as they do not accumulate over time. Still, I wanted to get rid of these because their sheer size makes it difficult to detect the fatal memory leaks.

Part of the problem is how we exit from the game. VS uses the ancient C exit/atexit idiom for this, which prevents us from using RAII to do proper resource management. I have changed the exit functions (winsys_exit and winsys_shutdown) so that the main loop will return gracefully and we can clean up in the main() function. This is the biggest change to the application logic that I have made. The other changes are mainly about using smart pointers.

This patch was made against svn, so it includes my previous patch.

[charlieg]

Good work breese.

[pheonixstorm]

I can't remember who posted about smart pointers before.. either klauss and chuck went over it or maybe safemode and one of the two but there was a discussion on what smart pointers to use.. general c++ or boost I think. You might want to look it for it and check out what was written. Klauss might know what im talking about whenever he gets back to the forums again. I will go over the patch plus another I got and see if I can't commit tonight or tomorrow.

[klauss]

Smart pointers are generally a lot better than raw pointers. But they have performance issues and... complications.

Like, shared pointers (reference counted pointers) don't work in the face of reference cycles. People don't know how to properly use them, they tend to think they're magical, and end up with worse memory leaks than before.

But I'm a big advocate of (well used) smart pointers.

[pheonixstorm]

I have attached another patch that fixes two memory leaks and an uninitialized array.

It won't compile so it will be added after I merge my branch with trunk. It keeps getting hung up at two places. One is an error the other is just a warning but could give an additional memory leak I think.

The error:

Code: Select all

1>   Creating library E:\Visual Studio 2008\Projects\Vegastrike\vega-vc9\Release\VegastrikenonPGO.lib and object E:\Visual Studio 2008\Projects\Vegastrike\vega-vc9\Release\VegastrikenonPGO.exp
1>stardate.obj : error LNK2001: unresolved external symbol "class std::vector<class Faction *,class std::allocator<class Faction *> > factions" (?factions@@3V?$vector@PAVFaction@@V?$allocator@PAVFaction@@@std@@@std@@A)
1>E:\Visual Studio 2008\Projects\Vegastrike\vega-vc9\Release\VegastrikenonPGO.exe : fatal error LNK1120: 1 unresolved externals

The Warning:

Code: Select all

1>e:\Programming\VS9\VC\include\memory(721) : warning C4150: deletion of pointer to incomplete type 'Unit'; no destructor called
1>        e:\visual studio 2008\projects\vegastrike\vegastrike\src\hashtable.h(34) : see declaration of 'Unit'
1>        e:\Programming\VS9\VC\include\memory(720) : while compiling class template member function 'std::auto_ptr<_Ty>::~auto_ptr(void)'
1>        with
1>        [
1>            _Ty=Unit
1>        ]
1>        e:\visual studio 2008\projects\vegastrike\vegastrike\src\faction_generic.h(76) : see reference to class template instantiation 'std::auto_ptr<_Ty>' being compiled
1>        with
1>        [
1>            _Ty=Unit
1>        ]

It seems some of your changes had already been made priot to patching. Anyway, i'm tired so I will continue this later. If not I will probably cause more errors than I fix

[breese]

It won't compile so it will be added after I merge my branch with trunk. It keeps getting hung up at two places. One is an error the other is just a warning but could give an additional memory leak I think.

This error is genuine. I have changed the type of the "faction" global variable, but did not change it accordingly in stardate.cpp.

This made me wonder why my compiler did not complain about it. It turns out that I had compiled all the code before I made the change, and therefore relied on our dependency system to rebuild the affected sourcecode files. However, because the global variable was "included" with an extern directive, our dependency system did not detect a dependency, so it never rebuilt stardate.cpp. Another reason to avoid externs (of which we have over seven hundred).

The warning is simply a matter of including "unit.h".

It seems some of your changes had already been made priot to patching. Anyway, i'm tired so I will continue this later. If not I will probably cause more errors than I fix

Finish your merge without my patch. When you are done, I will create a new patch against the trunk, which also fixes the two problems you found.

[pheonixstorm]

Merge is done.. got stuck staying awake.. baby is teething and wont let me sleep.

[breese]

Here is my memory leak patch again. This time against svn trunk.

[Deus Siddis]

1) Missions do not pay enough. . .
2) Most medium ships (corvettes) not available for purchase (the Goddard-Clydesdale Gap).
. . . .
3) Turning accelerations insanely high on light craft.
4) Movement acceleration and governors far too high on light craft.

I have finished my balancing of these things (plus the rescaling) for the next version and attached the changed files. Please apply them as soon as possible so that wider testing may commence over the beta.

EDIT: Phoenixstorm I just noticed you applied changes to units.csv and master_parts_list.csv within the last day. My re-balancing changes these files in a number of places, but based on how they were before your last revision. Do I need to grab the lastest versions of these files and reapply my changes manually or is there another way to handle this?

[pheonixstorm]

I can probably manage to merge them manually I think. The changes were due to the radar code change added 2 new radars to the units.csv and master_parts_list.csv I don't think it changed anything else.

[Deus Siddis]

I thank you, sir.

[pheonixstorm]

I added gtk2 into the mix and it turned out ok. There are some gui differences though that may confuse some people. I have to rebuild all the libraries by hand later before I commit to trunk though as adding gtk2 just based on downloads from gtk.org adds too many new lib, includes, and dlls for windows development.

Also, I am going to be looking into using 1.44 boost and both python 2.7 and 3.X to see how those go. 2.7 will get the update, but 3.X will need some heavy testing I think. Depends on if py3 breaks any of our scripts due to code changes within python.

Working on getting the last memory diff by breese in as well as the changes by Deus. Not sure if they will be done before I go to bed.. up too late as it is. Good thing the kids are sick and sleeping in late

[strook]

I don't know it seems there are 3 branches now.
The ogre, yours, pheonix, and the main trunk.
Development should go to the ogre tree.
It is a complete trunk apart from the main tree.
Maybe we should update that tree first with newest libs and code?
We decided to use ogre, not?
I don't have access to the ogre branch and diffs aren't a solution, to cause it is too outdated.

So what do we do will you give me access to it?

[charlieg]

Isn't phoenixstorm's branch being merged with trunk - thus they are currently equivalent?

Strook, perhaps as a temporary solution you could use github.com / git to host your changes whilst the admin side of things gets solved here.

[breese]

Strook, perhaps as a temporary solution you could use github.com / git to host your changes whilst the admin side of things gets solved here.

Or better yet, use git directly on our svn repository. This way you can commit your changes locally, while you keep your repository updated with the svn repository.

This is how I do it: http://vegastrike.sourceforge.net/forum ... 5&p=119643. Since that posting, there has been an important change in my workflow. I discovered that "git format-patch" did not work as I expected it to. Instead I create a branch ("git branch mybranchname" followed by "git checkout mybranchname") and only work on that branch. I use the trunk (called master) to update with svn, and move these changes to my branch with "git pull . master".

Maybe I should write a wiki page that describes it all...

[pheonixstorm]

Go for it, would be a good tutorial for those that prefer git over cvs or svn.

I got the memory3.diff worked in, now i'm working on getting the data diff merged in. After that i'm going to work on the asteroids and/or some more data changes/fixes.

[breese]

Go for it, would be a good tutorial for those that prefer git over cvs or svn.

Done

I got the memory3.diff worked in, now i'm working on getting the data diff merged in. After that i'm going to work on the asteroids and/or some more data changes/fixes.

Thank you for keeping us updated on your progress.

I noticed that even though we use an OpenGL wrapper, there are some places in the code where OpenGL is accessed directly and not through the wrapper. For instance, glLineWidth() and glBegin() are called directly in src/gfx/cockpit.cpp.

Should I fix these now, or wait until after the release?

[pheonixstorm]

Talk to klauss. There could be some odd reason for it. If not go for it though there are probably other sections of the code that need refactoring or cleanup far worse

[klauss]

Sometimes, direct OpenGL calls means the wrapper does not provide the required functionality.

In fact, there's way too much functionality in OpenGL to efficiently wrap it all. The GFX wrapper merely helps in state tracking at places where it's really necessary, like textures and stuff like that.

I agree that, if it's easy to make the code use the wrapper, it should be done. But it's not priority, not by far. Wrapper or no wrapper it's still OpenGL, the wrapper doesn't provide a radically different or more convenient interface, and it's idle effort.

[pheonixstorm]

Boost 1.45 is now being pulled as an external. Since 1.28 is no longer used or supported I will be removing it for those that have to pull the whole vegastrike tree. CMake is not updated nor is VC9 as of yet. Most linux users will probably be pulling from system boost anyway.

If someone gets 1.45 compiled in let me know. My Ubuntu build is using system boost (1.40) though.

[breese]

If someone gets 1.45 compiled in let me know. My Ubuntu build is using system boost (1.40) though.

Attached is a patch for autotools that adds Boost 1.45 and removes 1.28.

Remember to run bootstrap-sh before running configure.

Compiles just fine without changes to the sourcecode.

[breese]

Attached is a patch for autotools that adds Boost 1.45 and removes 1.28.

Use this patch instead. It includes both the autotools and cmake changes.

CMake will use Boost 1.45 by default. If you want to use the system boost, then you have to use the "-DUSE_SYSTEM_BOOST:BOOL=TRUE" option.