Code reformatting project [DONE]

[chuck_starchaser]

Got a brand new error message I never saw before, and I don't understand why it
never came up before; looks like it should have been caught earlier:

Code: Select all

#ifndef __ANI_TEXTURE_H__
#define __ANI_TEXTURE_H__

#include "aux_texture.h"
#include "vsfilesystem.h"
#include "vid_file.h"

#include <stdio.h>
#include "../SharedPool.h"

class AnimatedTexture : public Texture
{
    Texture    **Decal;
    unsigned int activebound; //For video mode
    double physicsactive;
    bool   loadSuccess;
    void AniInit();

//For video mode
    bool vidMode;
    bool detailTex;
    enum FILTER ismipmapped;
    int  texstage;
    int  timeSource;

    vector< StringPool::Reference >frames; //Filenames for each frame
    vector< Vector >frames_maxtc; //Maximum tcoords for each frame
    vector< Vector >frames_mintc; //Minimum tcoords for each frame

    VideoFile *vidSource;
....

VideoFile is ambiguous:

• vsfilesystem.h declares VideoFile in an enum of file types.
• vid_file.h declares a class VideoFile.

Isn't it kind of standard to prefix e for enumerations?
Vsfilesystem's should be "eVideoFile", IMO; otherwise it looks like a type.
But if I rename all enums now it will take a week to fix all the code that
references them; probably easier to change the class name to VidFile...

[chuck_starchaser]

Renamed class VideoFile to VidFile, no problemo.
Added,

Code: Select all

#VEGASERVER_COMPILING added by chuck_starchaser, to switch between
# unit.cpp including unit.h, and unit.h including unit.cpp
vegaserver_CXXFLAGS = -D VEGASERVER_COMPILING

to Makefile.am, and did a horrible switcharoo:
At bottom of unit.h:

Code: Select all

//#include "unit.cpp" --chuck_starchaser commenting out the root of all evil
#ifdef VEGASERVER_COMPILING
#include "unit.cpp"
#endif

At top of unit.cpp:

Code: Select all

#ifdef VEGASERVER_COMPILING
#ifndef __UNIT_CPP__
#define __UNIT_CPP__
#endif
#else
#include "unit.h"
#endif

#ifndef __UNIT_CPP__
......

Added .h file style

Code: Select all

#ifndef __XXX_CPP__
#define __XXX_CPP__
..................
#endif

to the included .cpp files (which should really be named .h, as they only
have templates); and had them include unit.h, which they needed to.
Vegastrike compiles and links; vegaserver compiles but doesn't link, BUT the
linker errors are few and look specific:

Code: Select all

src/cmd/vegaserver-faction_xml.o: In function `Faction::beginElement(void*, char const*, char const**)':
faction_xml.cpp:(.text+0x10cf): undefined reference to `FactionUtil::createAnimation(char const*)'
faction_xml.cpp:(.text+0x141c): undefined reference to `FactionUtil::createAnimation(char const*)'
src/cmd/vegaserver-pilot.o: In function `Pilot::SetComm(Unit*)':
pilot.cpp:(.text+0x11): undefined reference to `FactionUtil::GetRandCommAnimation(int, Unit*, unsigned char&)'
src/cmd/vegaserver-pilot.o: In function `Pilot::getCommFace(Unit*, float, unsigned char&)':
pilot.cpp:(.text+0x3a): undefined reference to `FactionUtil::GetRandCommAnimation(int, Unit*, unsigned char&)'
src/gfx/vegaserver-mesh_bin.o: In function `Mesh::LoadBinary(char const*, int)':
mesh_bin.cpp:(.text+0xc4a): undefined reference to `FactionUtil::getForceLogo(int)'
mesh_bin.cpp:(.text+0x146b): undefined reference to `FactionUtil::getSquadLogo(int)'
src/gfx/vegaserver-halo_system.o: In function `DoParticles(QVector, float, Vector const&, float, float, int)':
halo_system.cpp:(.text+0x1221): undefined reference to `particleTrail'
halo_system.cpp:(.text+0x133a): undefined reference to `ParticleTrail::AddParticle(ParticlePoint const&, Vector const&, float)'
src/gfx/vegaserver-camera.o: In function `Camera::UpdateCameraSounds()':
camera.cpp:(.text+0x4fb): undefined reference to `AUDListener(QVector const&, Vector const&)'
camera.cpp:(.text+0x515): undefined reference to `AUDListenerOrientation(Vector const&, Vector const&, Vector const&)'
src/gfx/vegaserver-camera.o: In function `Camera::UpdateGFX(unsigned char, unsigned char, unsigned char, unsigned char, float, float)':
camera.cpp:(.text+0x57c): undefined reference to `PhysicsSystem::Update()'
camera.cpp:(.text+0x586): undefined reference to `GFXLoadIdentity(MATRIXMODE)'
camera.cpp:(.text+0x5f8): undefined reference to `GFXPerspective(float, float, float, float, float)'
camera.cpp:(.text+0x664): undefined reference to `GFXParallel(float, float, float, float, float, float)'
camera.cpp:(.text+0x742): undefined reference to `GFXLookAt(Vector, QVector, Vector)'
camera.cpp:(.text+0x74c): undefined reference to `GFXCalculateFrustum()'
src/gfx/vegaserver-camera.o: In function `Camera::Camera(Camera::ProjectionType)':
camera.cpp:(.text+0x848): undefined reference to `PhysicsSystem::PhysicsSystem(float, float, QVector*, Vector*, Vector*, Vector*)'
src/gfx/vegaserver-camera.o: In function `Camera::Camera(Camera::ProjectionType)':
camera.cpp:(.text+0xa8e): undefined reference to `PhysicsSystem::PhysicsSystem(float, float, QVector*, Vector*, Vector*, Vector*)'
src/gfx/vegaserver-camera.o: In function `Camera::RestoreViewPort(float, float)':
camera.cpp:(.text+0x481): undefined reference to `GFXSubwindow(float, float, float, float)'
src/gfx/vegaserver-camera.o: In function `Camera::GetView(Matrix&)':
camera.cpp:(.text+0x4c8): undefined reference to `GFXGetMatrixView(Matrix&)'
src/gfx/vegaserver-camera.o: In function `Camera::UpdateGFX(unsigned char, unsigned char, unsigned char, unsigned char, float, float)':
camera.cpp:(.text+0x780): undefined reference to `GFXSubwindow(float, float, float, float)'
collect2: ld returned 1 exit status
make: *** [vegaserver] Error 1

Looks as if vegaserver's make list needed to include faction, faction_util, physics and camera;
but I'm wary of adding modules that might cascade even more dependencies...
I'm also rather curious why vegaserver now refers to things it didn't refer to before...
Should I, perhaps, try removing pilot and faction_xml from the vegaserver link list,
instead of adding stuff? Not sure. It's time to go to bed, though.

[pheonixstorm]

Seems to me some of the features such as vegaserver got a bit rushed to release and shares far more code than it should. I wonder what else is that way...

[chuck_starchaser]

"rushed to release" is the mantra, it appears.
Everything looks rushed. Like gazillions of variables in classes just made public, like
they couldn't bother writing get functions...

Indeed, the thing about templates is that they get special treatment from the
compiler AND the linker. Multiple definitions are okay, for example. More to the
point, a template class that has functions that are never called in a module gets
them automatically stripped off. Functions that are so stripped off have no linker
dependencies.
But when I set unit.cpp to compile to an object file of its own, I had to add
explicit instantations. But explicit instantiations instantiate every part of a class,
whether it is used or not, and that's what caused cascades of unresolved depends
when linking vegaserver.
So, the only clean solution is to do what Klauss wants to do: have a stripped unit
class for vegaserver. For now, vegaserver will have to get unit like a header.

I'm down to just a handful of linker errors for vegaserver:

Code: Select all

src/cmd/vegaserver-pilot.o: In function `Pilot::SetComm(Unit*)':
pilot.cpp:(.text+0x11): undefined reference to `FactionUtil::GetRandCommAnimation(int, Unit*, unsigned char&)'
src/cmd/vegaserver-pilot.o: In function `Pilot::getCommFace(Unit*, float, unsigned char&)':
pilot.cpp:(.text+0x3a): undefined reference to `FactionUtil::GetRandCommAnimation(int, Unit*, unsigned char&)'
src/vegaserver-universe_generic.o: In function `Universe::Init(char const*)':
universe_generic.cpp:(.text+0x85b): undefined reference to `Faction::LoadXML(char const*, char*, int)'
collect2: ld returned 1 exit status
make: *** [vegaserver] Error 1

That's all.
But these are hard ones. Adding faction_util cascades more dependencies. Can't
remove universe_generic or pilot from the file list for vegaserver either.
Between a rock and a hard place...

[chuck_starchaser]

Update:
Working on an idea... One thing I forgot to mention is that the last time I ran configure, I ran it with
--enable-release=s, which causes configure to pass a "-Os" switch to gcc, which tells it to optimize
the generated code for size, which may result in its not inline-ing functions it might have, otherwise.
All of which means, those two functions the linker doesn't find it shouldn't find, because the files
that define them are not in the make lists for it, and never were, BUT, they may have reached the
the vegaserver linker, before, as a side-effect of getting inline'd.
So, I've just done a make clean, bootstrap, and configure with plain --enable-release; and gcc is now
working on it; I'll post an update when it gets to linking vegaserver.

@storm: By the way, if this works I'm going to commit, but not before harmonizing CMake to Make.am,
so you and jsnmtth have a good CMake to work from.

[chuck_starchaser]

Well, that got rid of one linker error, at least...
Down to a single function not found:

Code: Select all

src/cmd/pilot.o: In function `Pilot::SetComm(Unit*)':
pilot.cpp:(.text+0x11): undefined reference to `FactionUtil::GetRandCommAnimation(int, Unit*, unsigned char&)'
src/cmd/pilot.o: In function `Pilot::getCommFace(Unit*, float, unsigned char&)':
pilot.cpp:(.text+0x12c): undefined reference to `FactionUtil::GetRandCommAnimation(int, Unit*, unsigned char&)'
collect2: ld returned 1 exit status
make[1]: *** [vegastrike] Error 1

[chuck_starchaser]

I seem to be out of luck. As mentioned in the last post, after removing the -Os switch, I went from three
missing links to two (single missing function); but later I hit make vegastrike again, and it went back to
three missing links as before, even though I changed nothing.
Then I tried to force the missing functions to inline using pragmas, but
#pragma gcc optimize ("always_inline") was not recognized, for some reason, so now I changed it to,
#pragma gcc optimize ("inline_limit=7777") and...

Code: Select all

In file included from /usr/include/c++/4.4/tr1_impl/hashtable:48,
                 from /usr/include/c++/4.4/tr1/hashtable.h:46,
                 from /usr/include/c++/4.4/tr1/unordered_map:45,
                 from ./src/gnuhash.h:49,
                 from src/cmd/faction_xml.cpp:5:
/usr/include/c++/4.4/tr1_impl/hashtable_policy.h: In member function ‘std::pair<bool, long unsigned int> std::tr1::__detail::_Prime_rehash_policy::T.1205(size_t, size_t) const’:
/usr/include/c++/4.4/tr1_impl/hashtable_policy.h:488: internal compiler error: in tree_nrv, at tree-nrv.c:143
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions.
make: *** [src/cmd/faction_xml.o] Error 1

In any case, this shouldn't work, because if faction_xml.cpp is not in the vegaserver link list, then
it doesn't matter how strongly a pragma may suggest inlining; it won't even be looked at.
How the hell did this thing compile and link before?
I'm almost tempted to turn some classes into template classes...

EDIT:
One problem of this approach of defining VEGASERVER_COMPILING when compiling vegaserver
is that all the .o's that are common to vegastrike and vegaserver have to be recompiled each
time one switches between compiling one or the other... So, I'm counting on you, Klauss; this
needs a better solution.

[klauss]

VideoFile is ambiguous:

• vsfilesystem.h declares VideoFile in an enum of file types.
• vid_file.h declares a class VideoFile.

Isn't it kind of standard to prefix e for enumerations?
Vsfilesystem's should be "eVideoFile", IMO; otherwise it looks like a type.
But if I rename all enums now it will take a week to fix all the code that
references them; probably easier to change the class name to VidFile...

No, actually the solution is to use namespaces correctly.

VS pollutes the namespace a lot with "using <namespace>" in header files - that's wrong. If you don't pollute your namespace, there's no ambiguity at all.

Just for purity, I wouldn't rename the class. If anything needs renaming it's the enum, which should follow naming conventions for enums. But we have none.

[klauss]

EDIT:
One problem of this approach of defining VEGASERVER_COMPILING when compiling vegaserver
is that all the .o's that are common to vegastrike and vegaserver have to be recompiled each
time one switches between compiling one or the other... So, I'm counting on you, Klauss; this
needs a better solution.

Perhaps we should dial down our ambitions. Removing the template in full may be too troublesome yet.

What about extracting the common functionality that needs not vary between server and client code?

I'll have to study this further, but I think it could be done by moving those functions to a base class the template class inherits.

[chuck_starchaser]

Well, I have good and bad news.
Good news: Everything builds now.
Bad news: I'm not sure if the things I had to do might have broken vegaserver. Namely,

• In file cmd/pilot.cpp,

  Code: Select all

  void Pilot::SetComm( Unit *parent )
  {
      this->faction = parent->faction;
      //GET BETTER REACTION TIME AND RANK HERE
  //this #ifndef hack below by chuck_starchaser, to get around missing faction_util.o in vegaserver make list
  #ifndef VEGASERVER_COMPILING
      comm_face     = FactionUtil::GetRandCommAnimation( faction, parent, gender );
  #endif
  }
  Animation* Pilot::getCommFace( Unit *parent, float mood, unsigned char &sex )
  {
      vector< Animation* > *ani = getCommFaces( sex );
  //this #ifndef hack below by chuck_starchaser, to get around missing faction_util.o in vegaserver make list
  #ifndef VEGASERVER_COMPILING
      if (ani == NULL) {
          ani = FactionUtil::GetRandCommAnimation( parent->faction, parent, sex );
          if (ani == NULL)
              return NULL;
      }
  #endif
      if (ani->size() == 0)
          return NULL;
      mood += .1;
      mood *= ( ani->size() )/.2;
      unsigned int index = (unsigned int) myroundclamp( floor( mood ) );
      if ( index >= ani->size() )
          index = ani->size()-1;
      return (*ani)[index];
  }

• and in file universe_generic.cpp,

  Code: Select all

  void Universe::Init( const char *gal )
  {
      ROLES::getAllRolePriorities();
      LoadWeapons( VSFileSystem::weapon_list.c_str() );
  
      this->galaxy = new GalaxyXML::Galaxy( gal );
      static bool firsttime = false;
      if (!firsttime) {
  //this #ifndef hack below by chuck_starchaser, to get around missing faction_util.o in vegaserver make list
  #ifndef VEGASERVER_COMPILING
          LoadFactionXML( "factions.xml" );
  #endif
          firsttime = true;
      }
      script_system = NULL;
  }

EDIT:
The pilot.cpp hacks I'm sure they are okay, as the vegaserver shouldn't need to load faces and stuff.
What I'm really worried is the universe_generic.cpp hack... Does vegaserver need factions.xml?
Probably...
What I could do is make LoadFactionXML a bogus template function and put it in a header.

EDIT2:
I'm thinking, what we need for vegaserver is simply a unit_server.cpp that duplicates the
GameUnit template class, but with the unused functions defined as {} so they don't call
anything else. Then, unit_server.cpp could use the same header as unit.cpp, namely unit.h.
Then, vegastrike's make calls for unit.cpp, while vegaserver's calls for unit_server.cpp.
Problem solved. No need to dial down any ambitions.

[klauss]

I'm thinking, what we need for vegaserver is simply a unit_server.cpp that duplicates the
GameUnit template class, but with the unused functions defined as {} so they don't call
anything else. Then, unit_server.cpp could use the same header as unit.cpp, namely unit.h.
Then, vegastrike's make calls for unit.cpp, while vegaserver's calls for unit_server.cpp.
Problem solved. No need to dial down any ambitions.

Many other classes do exactly that.
That's another option.

Too many options.

[chuck_starchaser]

Too many options can be a paralyzing conondrum, but if doing this is the tradition, then
might as well go with it.
I could do it in 5 minutes if I knew what can be left out. But this is a big question. Thing
is, I could comment out all functions, try to compile, and based on the missing linker
defines, un-comment them; but that's only half the story: Thing is, some functions will
seem to be used but not actually be called at runtime, and those could be defined as {},
but the question is which.

[chuck_starchaser]

Question: What IS vegaserver? What does it do? Is it for multiplayer? Does it need
to know anything about HaloSystem's, whatever the hell that IS?
(Asking because GameUnit<>, in unit.h, has a HaloSystem member, and much of the
code in unit.cpp has to do with it.)

[klauss]

vegaserver is the multiplayer server, and no, I don't think it needs to know about halo system and anything graphics related.

It may need mesh data for physics, I don't know, but halo systems (ie: engine exhausts) aren't physically active anyways.

And I'm not implying I know anything at all about vegaserver.

[chuck_starchaser]

Alright, thanks.
So, I made a first attempt at creating a unit_server.cpp, but it flopped.
Thing is, unit.h needed a cleanup, starting with that HaloSystem member. So, I changed that
member to a pointer and made it allocate in the ctors and deallocate in the dtor. But while I
was at it, decided to do a deeper cleanup of unit.h. Managed to move all the headers to
unit.cpp, except for <vector> and <string>.
What makes cleaning up vs code is the obsession with parameter defaults. Almost every
goddam function has two or three defaulted parameters, so you can't remove the headers
that define the types of those defaults without splitting the defaulted function into a whole
bunch of functions with different numbers of parameters, and no defaults.
God damn these Berkeley guys...

But now I'm having a run-time problem; the game crashes while loading a savegame
No useful info in stdout or stderr...

[klauss]

What makes cleaning up vs code is the obsession with parameter defaults. Almost every
goddam function has two or three defaulted parameters, so you can't remove the headers
that define the types of those defaults without splitting the defaulted function into a whole
bunch of functions with different numbers of parameters, and no defaults.

I don't get your problem with defaults...

[chuck_starchaser]

What makes cleaning up vs code is the obsession with parameter defaults. Almost every
goddam function has two or three defaulted parameters, so you can't remove the headers
that define the types of those defaults without splitting the defaulted function into a whole
bunch of functions with different numbers of parameters, and no defaults.

I don't get your problem with defaults...

Well, case in point:

Code: Select all

#include "transformations.h"
#include "matrix.h"
class x
{
    virtual void Draw( const Transformation &quat = identity_transform, const Matrix &m = identity_matrix )
    {
        ............
    }
};

You can't easily change it to,

Code: Select all

class Transformations;
class Matrix;
class x
{
    virtual void Draw( const Transformation &quat = identity_transform, const Matrix &m = identity_matrix );
};

because even if the definition is moved to the cpp file, your defaults are undefined.
So you have to,

Code: Select all

    virtual void Draw( const Transformation &quat, const Matrix &m );
    virtual void Draw( const Transformation &quat );
    virtual void Draw();

And most programmers I've known avoid using parameter defaults, if at all possible.
Not to mention constructors with defaults that can act as a single parameter ctor
and you tend to miss the need for explicit.
One of the most hated features of C++ I'd say.
Have the caller supply default values. Why mess up the interfaces of classes with all
that crap I'm not even sure it's used? I think these guys put defaults by default, just
in case they may be needed.

I'm going nuts.
Compiles and links but keeps crashing.
What's the function to send messages to stdout/stderr?

[chuck_starchaser]

Backtrace:

Code: Select all

#0  0x0000000000bb8934 in std::vector<AtmosphericFogMesh, std::allocator<AtmosphericFogMesh> >::size (this=0x8)
    at /usr/include/c++/4.4/bits/stl_vector.h:533
#1  0x0000000000f729fa in GamePlanet::AddFog (this=0x6c29050, v=..., opticalillusion=48) at src/cmd/planet.cpp:179
#2  0x0000000000d47760 in UnitDrawer::draw (this=0x7fffffffbd70, unit=0x6c29050) at src/star_system.cpp:300
#3  0x0000000000d477c6 in UnitDrawer::grav_acquire (this=0x7fffffffbd70, unit=0x6c29050) at src/star_system.cpp:308
#4  0x0000000000d45738 in GameStarSystem::Draw (this=0x6630920, DrawCockpit=true) at src/star_system.cpp:398
#5  0x0000000000d4b9ba in GameUniverse::StartDraw (this=0x226ccf0) at src/universe.cpp:306
#6  0x0000000000d3ac35 in main_loop () at src/main_loop.cpp:1067
#7  0x000000000102bb6f in winsys_process_events () at src/gldrv/winsys.cpp:479
#8  0x0000000001007dc5 in GFXLoop (main_loop=0x102dba0 <bootstrap_first_loop()>) at src/gldrv/gl_init.cpp:615
#9  0x0000000000d4b1b2 in GameUniverse::Loop (this=0x226ccf0, main_loop=0x102dba0 <bootstrap_first_loop()>) at src/universe.cpp:185
#10 0x000000000102d0c9 in main (argc=1, argv=0x7fffffffe3f8) at src/main.cpp:309

[chuck_starchaser]

Well, maybe this is not my fault, after all. Look at UnitDrawer::draw(Unit *unit):

Code: Select all

    bool draw( Unit *unit )
    {
        if ( parent == unit || (parent && parent->isSubUnit() && parent->owner == unit) )
            parent = NULL;
        if ( parenttarget == unit || (parenttarget && parenttarget->isSubUnit() && parenttarget->owner == unit) )
            parenttarget = NULL;
        float backup = SIMULATION_ATOM;
        unsigned int cur_sim_frame = _Universe->activeStarSystem()->getCurrentSimFrame();
        interpolation_blend_factor = calc_blend_factor( saved_interpolation_blend_factor,
                                                        unit->sim_atom_multiplier,
                                                        unit->cur_sim_queue_slot,
                                                        cur_sim_frame );
        SIMULATION_ATOM = backup*unit->sim_atom_multiplier;
        ( (GameUnit< Unit >*)unit )->Draw();
        interpolation_blend_factor = saved_interpolation_blend_factor;
        SIMULATION_ATOM = backup;
        return true;
    }

Like, what the hell is that? It casts whatever unit comes in the argument to GameUnit<Unit>*, then
calls Draw() on it. Why cast like that, subverting every safety?

EDIT:
Commented out the stupid cast and now the game runs okay. And, frankly, I don't care why the
cast was there, if the author didn't care to explain it in a comment.
So, back to work on unit_server.cpp.

[klauss]

Well, case in point:

Code: Select all

#include "transformations.h"
#include "matrix.h"
class x
{
    virtual void Draw( const Transformation &quat = identity_transform, const Matrix &m = identity_matrix )
    {
        ............
    }
};

You can't easily change it to,

Code: Select all

class Transformations;
class Matrix;
class x
{
    virtual void Draw( const Transformation &quat = identity_transform, const Matrix &m = identity_matrix );
};

because even if the definition is moved to the cpp file, your defaults are undefined.
So you have to,

Code: Select all

    virtual void Draw( const Transformation &quat, const Matrix &m );
    virtual void Draw( const Transformation &quat );
    virtual void Draw();

Yes you can.
You merely add an

Code: Select all

extern const Matrix& identity_matrix;

To the header file and the corresponding

Code: Select all

Matrix _identity_matrix = Matrix::identity_matrix();
const Matrix &identity_matrix = _identity_matrix;

...in the cpp file

The indirection through the reference (which is a pointer) allows you to use an incomplete type.

And most programmers I've known avoid using parameter defaults, if at all possible.

Not the ones I know. I've never heared that before you saying it.

Not to mention constructors with defaults that can act as a single parameter ctor
and you tend to miss the need for explicit.

That's messy only if you don't add the explicit. Common rookie mistake, forgetting about the explicit.

One of the most hated features of C++ I'd say.

Ya, everybody gets confused in C++, but not only because of automatic copy/conversion constructors, it's because C++ does too much automatically and implicitly, and sometimes following it is hard.
I bet Python's zen was inspired on C++, when it says: "explicit is better than implicit".

Have the caller supply default values. Why mess up the interfaces of classes with all
that crap I'm not even sure it's used? I think these guys put defaults by default, just
in case they may be needed.

No, they're useful a lot of the time, but you need keyword arguments as python has them. Anyway, if you don't abuse of defaults, they're very useful.

What's the function to send messages to stdout/stderr?

You have vs_dprintf and vs_fprintf.

[chuck_starchaser]

Ok, thanks, and good points, all. And that's a nifty trick, the reference thing.

EDIT:
The problem right now with unit_server.cpp is that some of the GameUnit<> class
functions are defined in those included .cpp files, and the code in those functions
needs modules not present in the vegaserver makefile lists; so I guess unit_server.cpp
will have to NOT include those files, but define those functions itself, possibly as {}.

[pheonixstorm]

Does anyone whos left here know much about the vserver code? Or how many people use the code to run a server? If we few start a rewrite of any portion of the code I think we should split out vs from vserver, unless the shared code can become more refined/optimized. It sounds like too many things inherit(sp) from too many other things which in turn are derived from too many other things yet again.

*OT

This reminds me of something a game programmer I know once wrote... C = speedy, C++ = mind mess. Makes me wonder how much C++ he is using lately in some of the newer game designs...

Sadly I just read of the studios demise at the hands of "Corporate restructuring"

As part of this process Eidos confirms that, despite reviewing a number of alternative options, we are closing Pivotal Games – but we will be keeping a team of 10-12 specialists in Bath, who will work on specific projects for group.

Pivotal was best known for its Conflict series - the most recent of which, Conflict: Denied Ops, was released in February this year. It had also worked on Conflict: Global Storm, Conflict: Vietnam, Conflict: Desert Storm II, Conflict: Desert Storm, The Great Escape and Warzone 2100. Based near Bath, the studio employed over 100 people and was, up until a few months ago, actively recruiting for more staff.

Warzone2100 was made open source many years ago and still has a strong following though they havent made many changes to the graphics engine... The programmer I refered too is probably one of those in Bath they are keeping.

[chuck_starchaser]

Getting closer...
Vegastrike still runs, and now vegaserver's linking only gives me a few missing links:

Code: Select all

src/cmd/unit_generic.o: In function `UnitImages::~UnitImages()':
unit_generic.cpp:(.text._ZN10UnitImagesD1Ev[UnitImages::~UnitImages()]+0x57): undefined reference to `VSSprite::~VSSprite()'
src/cmd/unit_generic.o: In function `UnitImages::~UnitImages()':
unit_generic.cpp:(.text._ZN10UnitImagesD0Ev[UnitImages::~UnitImages()]+0x57): undefined reference to `VSSprite::~VSSprite()'
src/cmd/pilot.o: In function `Pilot::SetComm(Unit*)':
/home/d/vs/vegastrike/src/cmd/pilot.cpp:28: undefined reference to `FactionUtil::GetRandCommAnimation(int, Unit*, unsigned char&)'
src/cmd/pilot.o: In function `Pilot::getCommFace(Unit*, float, unsigned char&)':
/home/d/vs/vegastrike/src/cmd/pilot.cpp:145: undefined reference to `FactionUtil::GetRandCommAnimation(int, Unit*, unsigned char&)'
src/universe_generic.o: In function `Universe::LoadFactionXML(char const*)':
universe_generic.cpp:(.text._ZN8Universe14LoadFactionXMLEPKc[Universe::LoadFactionXML(char const*)]+0x22): undefined reference to `Faction::LoadXML(char const*, char*, int)'
src/gfx/mesh.o: In function `Mesh':
/home/d/vs/vegastrike/src/gfx/mesh.cpp:241: undefined reference to `Mesh::LoadBinary(char const*, int)'
/home/d/vs/vegastrike/src/gfx/mesh.cpp:241: undefined reference to `Mesh::LoadBinary(char const*, int)'
collect2: ld returned 1 exit status
make: *** [vegaserver] Error 1

This is with the new unit_server.cpp.

[chuck_starchaser]

Man! This is so hard!
I'm down to this:

Code: Select all

src/cmd/unit_generic.o: In function `UnitImages::~UnitImages()':
unit_generic.cpp:(.text._ZN10UnitImagesD1Ev[UnitImages::~UnitImages()]+0x57): undefined reference to `VSSprite::~VSSprite()'
src/cmd/unit_generic.o: In function `UnitImages::~UnitImages()':
unit_generic.cpp:(.text._ZN10UnitImagesD0Ev[UnitImages::~UnitImages()]+0x57): undefined reference to `VSSprite::~VSSprite()'
src/universe_generic.o: In function `Universe::LoadFactionXML(char const*)':
universe_generic.cpp:(.text._ZN8Universe14LoadFactionXMLEPKc[Universe::LoadFactionXML(char const*)]+0x22): undefined reference to `Faction::LoadXML(char const*, char*, int)'
src/gfx/mesh.o: In function `Mesh':
/home/d/vs/vegastrike/src/gfx/mesh.cpp:241: undefined reference to `Mesh::LoadBinary(char const*, int)'
/home/d/vs/vegastrike/src/gfx/mesh.cpp:241: undefined reference to `Mesh::LoadBinary(char const*, int)'
collect2: ld returned 1 exit status
make: *** [vegaserver] Error 1

But I'm trying to resolve that reference to VSSprite and it's almost impossible.
I can replace unit.cpp by unit_server.cpp for vegaserver, but I can't easily replace unit_generic.cpp,
because then the classes that inherit Unit would have to inherit a different Unit. Ehm... no; it would
still be the same unit.h... Hmm...
Thing is, unit_generic.cpp is chock-full of code having to do with UnitImages, from image.h; very hard
to take out all that code, because some data in UnitImages has to do with the physics, which maybe
vegaserver needs, maybe not... And UnitImages needs VSSprite; but if I add VSSprite (gfx/sprite.cpp)
to the make list for vegaserver, it produces an explosion of other cpp files needed.
Well, I guess there's no choice but to make a unit_generic_server.cpp file...
I don't understand how this ever compiled. The server presumably needs physics; no? But things like
the physics atom get multiplied by some parameter in UnitImages, in functions in Unit.

[klauss]

Man! This is so hard!

The cost of bad design.