This is my first attempt at compiling Pioneer, and I'm quite the noob at compiling from source anyway but I'm going to persevere...
Downloaded the source code, opened command terminal as super user, entered the following commands:
./bootstrap
./configure
make
bootstrap and configure appear to complete successfully. make throws up the following errors:
custom_starsystems.cpp error: integer constant is too large for ‘long’ type
custom_starsystems.cpp error: integer constant is too large for ‘long’ type
So I go to the src directory and open custom_starsystems.cpp and go to line 42
{ "Phobos", SBody::TYPE_PLANET_LARGE_ASTEROID,
13, fixed(21,10000), fixed(18,10000000000), 233, /* this is line 42 */
fixed(6268,100000000), fixed(151,10000), { (float)DEG2RAD(1.093) }, fixed(11,24) },
Dredging up some rarely used C++ knowledge, I dig into custom_starsystems.h to look at the data structure definition...
struct CustomSystem {
const char *name;
const CustomSBody *sbodies; // 0 to let system be random
SBody::BodyType primaryType[4];
int sectorX, sectorY;
vector3f pos;
Uint32 seed;
const char *shortDesc;
const char *longDesc;
Polit::GovType govType;
};
Looking at this, I'm assuming that sectorY corresponds to "fixed(18,10000000000)" in the .cpp file.
And that's about as far as my knowledge takes me. I don't know what the 'fixed' function does but I assume the compiler is choking on the '10000000000' - is that too large for an int?
I did try playing around with the .h file and change the data type to something larger but it didn't make any difference, so I restored the .h to it's original state...
So...what's going on here? Any help will be appreciated.
10000000000 is to large for an int.
should be int64_t would be better.
Thats for the Custom Systems, however Phobos is a custom Body:
const char *name; // null to end system
SBody::BodyType type;
int primaryIdx; // -1 for primary
fixed radius; // in earth radii for planets, sol radii for stars
fixed mass; // earth masses or sol masses
int averageTemp; // kelvin
fixed semiMajorAxis; // in AUs
fixed eccentricity;
// for orbiting things, latitude = inclination
struct {
float latitude, longitude; // radians
};
fixed rotationPeriod; // in days
int econType; // StarSystem.cpp enum ECON_XXX
const char *heightMapFilename;
};
So that is 'fixed mass; // earth masses or sol masses', and the number is a fraction which is
18 divided by 10,000,000,000 Earth Masses. You could try (1, 10000000), which will give the asteroid thousands of times the mass that it should have, but it should solve that problem.
EDIT// actually this would be better: (1, 2147483647) which is the max number for a long integer in c++ win/linux 32bit, I think.... And the asteroid would have a mass only a few times larger than what it should.
Thanks for that.
Changing the values got the 'make' process past the compilation of the custom_starsystems.cpp files
'make' now chokes at the following point.
Render.cpp error: ‘GL_RGB16F’ was not declared in this scope
Render.cpp error: ‘GL_HALF_FLOAT’ was not declared in this scope
(I'm not used to being this helpless with a computer) What's my next move?
Changing the values got the 'make' process past the compilation of the custom_starsystems.cpp files
'make' now chokes at the following point.
Render.cpp error: ‘GL_RGB16F’ was not declared in this scope
Render.cpp error: ‘GL_HALF_FLOAT’ was not declared in this scope
(I'm not used to being this helpless with a computer) What's my next move?
Try changing those to GL_RGB16F_ARB and GL_HALF_FLOAT_ARB respectively.
What version of mesa do you have on your system?
I have pushed the fixes to the repository.
The big 100000000000 numbers should be 100000000000LL, because they are 'long long' (64-bit) type. There is no need to reduce them.
Thanks guys. The source compiled and ran successfully.
My version of mesa was the latest available (at least according to apt-get...)
Appending the _ARB to the offending GL constants did the trick.
Time for some explorin'
My version of mesa was the latest available (at least according to apt-get...)
Appending the _ARB to the offending GL constants did the trick.
Time for some explorin'
Sweet.
Progress update: I'm fixing the 'temporal aliasing', which is caused by physics having a fixed update rate (60 times a second or so). I am making pioneer smooth out the jumps between physics updates, so that every frame is rendered 'as it should be', and FPS greater than 60 will be worthwhile. I should have done this from the outset, but I had never seriously coded a game before so made mistakes.
Slow progress. The government wants me to get a job. It is worth reflecting that pioneer would never have existed without benefits, the welfare state, etc. Yup, in a conservative/republican universe, I would be put to work coding PHP for some tards, and y'all could wait for elite 4 pie in the sky 😉
Well you could of fooled me, you've done a bang up job mate.
Praise be to the British welfare system. 😆 If ever I have seen a reason for the benefit system, then Pioneer is it 🙂
I can almost see an advert for labour... A vote for labour, is a vote for Pioneer... 😉
Well you could of fooled me, you've done a bang up job mate.
Praise be to the British welfare system. 😆 If ever I have seen a reason for the benefit system, then Pioneer is it 🙂
I can almost see an advert for labour... A vote for labour, is a vote for Pioneer... 😉
Bloody hell, Tomm. You've never coded a game before? 😮 That's...staggering. Pioneer is just so good I'd assumed you'd been tinkering in the field for years.
And don't pay any attention to Cameron: he's a nice bloke, I'm sure he doesn't mean half of what he says. How could he: he's a politician! (And we already have ample proof of Clegg's multiple u-turns). I'm sure that when Dave finds out what you're doing he'll make an exception for your fabulous work. 😎
My dream is to win enough in the lottery to pay people like you for making fabulous games like these. Of course, I may have to actually play the lottery one day... 😕