Compiling Pioneer

[nick]

Many thanks.

Tomorrow I'm going to have a look for the existing JSON code, and see if it contains functions for serialising the various data types required for the savegame process.

I'll start to code the new JSON save system if I get that far. Plan is to write a save system side by side with the existing one, saving the exact same data but as a JSON tree. The new save file will be readable text, encoding the nested objects.

Before I do any of that though, I'll run Pioneer in debug mode and step through the existing savegame process (there are a few things I couldn't figure out looking at the code).

I've spent enough time thinking about this, so I'm going to make a start :)

FYI: I don't have access to the internet during the day (it's through the mains, and the extension cable has to be put away).

[DraQ]

Sounds good, personally I'd have done it with some sort of TLV encoding (more compact), but space is rarely an issue these days and plaintext has its advantages (mainly when something goes wrong) and if we can handle the required data types already not having to write serialization code is definite plus as well.

Not having to mess around with MS trialware or jump through the hoops when cross-compiling would be very handy when working with Pioneer under Windows, so I'd love to have working C::B project or some alternative.

[FluffyFreak]

Well Luomu did document what he had done using Premake, and had provided some binaries etc.

My suggestion would be to grab those, try and get it to generate the C::B projects and then find out what's wrong with it.
You don't have to solve all of the problems, just create a branch with everything and then ask around on here for help.

One idea might be to update from Premake to Genie at some time.

[DraQ]

Ok, so far:

• in src/graphics/opengl/LineMaterial.cpp:16 no match for Program(const std::string&, const std::string&, bool), only Program() and Program(const std::string&, const std::string&) defined in src/graphics/opengl/Program.cpp
• in src/graphics/opengl/LineMaterial.cpp:29 EFFECT_LINE bwuh?

After having worked around the above (through use of // and /**/ "code optimization operators" in the mentioned lines ;) ):

• multiple definition of main() - eliminated by removing linking against libmingw32.a in linker options

Then:

• Warning: corrupt .drectve at end of def file - with no further explanation
• A whole lot of opengl linking errors along the lines of undefined reference to `_ptrc_glDepthRange'

Sadly, I'm still not very good at this compiler/linker options sorcery. :(

[FluffyFreak]

Ok well from the top.

The LineMaterial isn't used in any of the other builds so it's probably being included by mistake, either because the build just grabs everything in the folder or because it was just incorrectly included.

I have no idea what the ".drectve" thing is.

The OpenGL linking errors are because those files were created before we switched over to using the gl_core_3_x.h/c files which is where all of that stuff is defined.

Do you have a GitHub branch with the various files and things checked in? I could take a look at it.

Andy

[DraQ]

The LineMaterial isn't used in any of the other builds so it's probably being included by mistake, either because the build just grabs everything in the folder or because it was just incorrectly included.

Shouldn't obsolete source files be removed?
And, yeah, the build just grabs everything it can - what should be excluded?

I have no idea what the ".drectve" thing is.

I presume it has something to do with with .def files in 3rd party libs.

The OpenGL linking errors are because those files were created before we switched over to using the gl_core_3_x.h/c files which is where all of that stuff is defined.

Premake script specifies those links:

Code: Select all

links { "mingw32", "SDL2main", "SDL2", "SDL2_Image", "png",
	"sigc-2.0.dll", "freetype", "assimp", "vorbisfile",
	"vorbis", "ogg", "opengl32", "shlwapi"
}

What to change?

Do you have a GitHub branch with the various files and things checked in? I could take a look at it.

Not yet. I wanted to get it to compile and link first.

Then I figure I could give this save system a shot.
I have coded a TLV system recently so the topic is relatively fresh on my mind and what we need may even be less messy (well, depending on whether or not we serialize a lot of deep structures and whether or not the data serialized could be described by trees) by the virtue of not needing to go too clever in order to scrounge up a handful of bytes or modifying individual records in file separately, while keeping track of deleted ones.

JSON would probably be a better idea after all (if only for debugging needs), but if coding something to parse it is in any way problematic, I should be able to make a fairly robust TLV based system, I just need a working project and someone pointing me at the current save code - at worst I'll just run away screaming.

[FluffyFreak]

Probably, the LineMaterial was something I was working on and forgot about it, feel free to delete it from your own branch.

You don't need to change the linked in libraries, they can stay as they are. The gl_core_3_x.h/c files just need to be built as part of the "graphics" library so can you tell if they're being added and that opengl is being linked against that library?

[DraQ]

Ok, gl_core_h_x.c wasn't included in the generated project. Fixed that.

Will post when anything else inevitably surfaces.

[DraQ]

Getting a lot of:
undefined reference to `Assimp::Intern::AllocateFromAssimpHeap::operator delete(void*)'s as well as some other Assimp stuff in libscenegraph.a(Loader.o).

[FluffyFreak]

Great on fixing the gk issue :)

The Assimp one I'm not sure about, did Luomu originally build a version of Assimp for the C::B project? Or does it use the pioneer-thirdparty stuff?
If he built an "Assimp.lib" then you might have to do that as well, or figure out how else to use it with C::B. Otherwise, if it uses our thirdparty folder, see when we updated it and if there are missing or broken files/links needed by C::B.