Versions

[Stan`]

Hi all,

Today, I was trying to compile the code with the 2013 version of Visual Studio, which was nicely provided by my school, and I wasn't able to because the most recent project is for 2012. And so I get an error like

can't find gl.h

or if I use the wrong toolset

rror LNK2038: mismatch detected for '_MSC_VER': value '1700' doesn't match value '1800'

Anyway, I wanted to know why you guys don't include a version.mk to get information about the release in the file ? That way you would solve lobby incompatibility between versions

Regards stan

I attached a mk version to see you what i'm talking about.

Version.7z

Edited January 10, 2014 by stanislas69

[historic_bruno]

VS2013 isn't supported yet, one problem is the Boost static libs for it aren't included - the latest version of Boost doesn't properly support it, much less the version we're using. Once Boost fixes that, I will look into installing 2013 and building the Boost libs. Actually it would be nicer if we migrated to git first and split the precompiled libs, because it's annoying for everyone to download the thousands of Boost headers after each upgrade

[Stan`]

I'd like to be able to compile it with minGW, would that be hard to do ? Would be nice to have a nice little make all command

[Loki1950]

I'd like to be able to compile it with minGW, would that be hard to do ? Would be nice to have a nice little make all command

Good Luck minGW is not complete yet so most of the external libraries would need to be compiled as well do get the needed .dll`s that would work with gcc.

Enjoy the Choice

[Radagast.]

Can't we change to eclipse? Is this complicated or is eclipse not strong enough? I don't know visual studio too much, because that it's not open source compelled me ...

I personally use a simple text editor or eclipse (what is especially strong for debugging hardware of almost any architecture in combination with OpenOCD).

Not sure, but the herding/coralling should be possible with scripting only, I still have to dig deeper into that, but I have pseudo code somewhat ready and in a preliminary state. Will look into this after failing/succeeding in my studies, will see in March.

[Stan`]

I guess the problem is dependencies. It wouldn't be too hard to convert the visual studio project to eclipse, even to make a makefile, but the problem would be to get all the libraries given by visual studio to eclipse.

[historic_bruno]

I'd like to be able to compile it with minGW, would that be hard to do ? Would be nice to have a nice little make all command

Yes, it would be very hard and I can't imagine why you would want to in the first place. IMO it's enough to have one well-tested working build platform on Windows (because almost all Windows devs will be using VC++, yet they will make up only a small number of the people using the game on Windows; another build platform is a lot more code to be maintained, etc.)

If you really wanted to do that, you would need to substantially alter the game's premake build scripts. Premake may have working MinGW support, but our build scripts certainly don't. They assume that Windows build environment implies the VC++ toolset. You would also need to add MinGW-specific code paths throughout the engine where it also assumes that Windows builds are on VC++, and you would probably need to rewrite most or all of the lowlevel Windows code in the engine. Not sure if all the win32 dependencies would need to be rebuilt for MinGW as well?

A more useful task IMO would be setting up MSVC projects for the various dependencies of the game, so they can be easily rebuilt with different versions of the compiler (some of them are straightforward, others like Spidermonkey are not), possibly by the autobuilder itself. Even getting a 64-bit Windows build working would be more practical and interesting, but still lots of work

[Stan`]

Yes, it would be very hard and I can't imagine why you would want to in the first place. IMO it's enough to have one well-tested working build platform on Windows (because almost all Windows devs will be using VC++, yet they will make up only a small number of the people using the game on Windows; another build platform is a lot more code to be maintained, etc.)

If you really wanted to do that, you would need to substantially alter the game's premake build scripts. Premake may have working MinGW support, but our build scripts certainly don't. They assume that Windows build environment implies the VC++ toolset. You would also need to add MinGW-specific code paths throughout the engine where it also assumes that Windows builds are on VC++, and you would probably need to rewrite most or all of the lowlevel Windows code in the engine. Not sure if all the win32 dependencies would need to be rebuilt for MinGW as well?

A more useful task IMO would be setting up MSVC projects for the various dependencies of the game, so they can be easily rebuilt with different versions of the compiler (some of them are straightforward, others like Spidermonkey are not), possibly by the autobuilder itself. Even getting a 64-bit Windows build working would be more practical and interesting, but still lots of work

I'd like to help, i also love programming as much as 3D modelling, but unfortunately didn't spend enough time to do what I want. Could you be more specific ? I'm not a complete newbie, nor am I an expert X)

[Radagast.]

That's a topic we have to dig into anyway for our MOD - or rather kind of feature development branch.

IBM:

Development

Visual Studio's most interesting feature is its resource editor. Whether it's the SDK or MFC resource editor, both are used extensively to develop the static UI controls for the application. Today, Eclipse CDT offers no support to develop a UI. Consider using the Eclipse visual editor project when generating .rc files for Windows development.

Microsoft changes its compilers between versions, which makes it a challenge for Eclipse CDT to support the various versions of SDK tools Microsoft releases.

It is not viable today for you to migrate MSVC code totally to open source. In Linux, such an undertaking is complex. The SDK tools of Microsoft cannot run on open source, such as Linux. The SDK tools have to be run within the Windows emulator to make the SDK tools run on Linux.

However currently in Windows platform, developers with the help of platform SDK, Eclipse CDT and Debugging Tools for Windows can see Eclipse platform as an alternative for MS Visual Studio.

In Eclipse, create a new project, empty.

Copy all relevant source files from your Windows machine to the correspondent folder in your Linux machine (under $HOME/workspace/{project name}...)

In Eclipse, add all .cpp[, .h, .rc, .mak] files to your project.

Make them compile: this will take some time, particularly if your "stdafx.h" file includes some Windows-specific headers (Windows.h, ATLBase.h, ...); any calls to the Windows API is non-portable by definition.

I'd suggest to start with a simple 'Hello, world' project, and only then move to production code.

Hope this helps,

Pablo.

I have found this too, that's our best bet:

As a start: Windows VisualStudio -> Windows Eclipse (keeping up compatibility)

http://www.drdobbs.com/cpp/cross-platform-cc-development-with-eclip/232300575?pgno=2

Then it's becoming more difficult: Win VS -> UNIX and Win Eclipse (keeping up compatibility is difficult here due to the GUI that pyrogenesis uses, but we must give it a try).

http://www.drdobbs.com/cpp/cross-platform-cc-development-with-eclip/232300575?pgno=3

We might not succeed very quickly in keeping up compatibility to Visual Studio, but we will get pyrogenesis to work in Eclipse on Linux somehow (as historic_bruno said this will require heavy changing where the VisualStudio libraries were used).

If we fail, we still have a Virtual machine where we can run VisualStudio. 0 A.D. should not use VisualStudio because it's not Open source, but I understand that this is for historical reasons and I'm not angry or such, because no doubt VStudio might not be a bad choice.

Edited February 13, 2014 by Hephaestion

[Josh]

That's a topic we have to dig into anyway for our MOD - or rather kind of feature development branch.

IBM:

I have found this too, that's our best bet:

As a start: Windows VisualStudio -> Windows Eclipse (keeping up compatibility)

http://www.drdobbs.com/cpp/cross-platform-cc-development-with-eclip/232300575?pgno=2

Then it's becoming more difficult: Win VS -> UNIX and Win Eclipse (keeping up compatibility is difficult here due to the GUI that pyrogenesis uses, but we must give it a try).

http://www.drdobbs.com/cpp/cross-platform-cc-development-with-eclip/232300575?pgno=3

We might not succeed very quickly in keeping up compatibility to Visual Studio, but we will get pyrogenesis to work in Eclipse on Linux somehow (as historic_bruno said this will require heavy changing where the VisualStudio libraries were used).

If we fail, we still have a Virtual machine where we can run VisualStudio. 0 A.D. should not use VisualStudio because it's not Open source, but I understand that this is for historical reasons and I'm not angry or such, because no doubt VStudio might not be a bad choice.

I think you might be a little confused here, most of the dev team actually uses Linux and compiles 0 A.D. with a completely open source toolchain. See BuildInstructions#Linux. (as a side note towards some of your quotes, we don't use Visual Studio's UI development stuff at all)

[Radagast.]

This is good news Josh! Thanks for throwing it in. I wondered alot the last days about how I get to a toolchain working on Linux without loosing compatibility ...

Your hint will speed up my venturing into the Entity/Actor/Object system and how we relate all objects.

Edit: Has anyone some tips of how to debug on Linux? In the Wiki I found only the entry for Windows so I guess here Visual Studio step in.

Well .. it's possible without, but for a project of high complexity I'd not really embrace having to go without code stepping or least some breakpoints. I'm still heavily involved in the teachers' project whose goal is nothing less than to introduce teaching modularity (online versioning, splitting and joining of created exercises and exams) and if I consider I'd had to do that without stepping the code at execution time ... oh oh, I guess I would still try to track down the odd bugs from the last autumn offensive.

Despite all this I rather go the hard debugging way before leaving Linux behind.

Of course we could try to setup a debugger ... hm .. but really I'm currently only interested in getting my ideas into a small virtual universe from 2000 years ago.

Long speech short: Anyone some hints for C++ and especially JavaScript?<-- found it

(the latter probably being harder if I consider how crazy it is to debug JavaScript once you attached events to content that got replaced by a delayed AJAX request in the meantime. Whenever time enters the equation, we are in serious danger and immdieately forced into a improvised retreat. Interestingly time travel would solve this problem and it's the only solution should the universe be non-deterministic. Luckily string theory seems to boild down to quantuum theory too. Physicists from China made the experience and Americans expressed their support too. This could render gravity an illusion, completely following of quantuumtheory. I wonder it would open up anit-gravity once we figured how to derive gravity from quatuum. It'd open up very interesting possibilites, would turn our world into a fantasy world. I guess we'd then not be far from creating a universe ourselves, would be like 0 A.D., model the physics, model the art, figure that AI and be amzed by the planets and rives ... then someone comes up with an AI that reinvents itself and it turns this AI is just like we work. So what'd we do? Probably enter the fantasy world into Blender Guru Competition and shift to new frontiers [while our tribes on that world spin out of control, from water to land, from land to water, animal eats plant, plant eats animal, warfare everywhere, people starting world wars because of 'technical reasons' (Nicholas, Tsar of Russia, 1914 [sic.]), converting green and blue planets into yellow and grey]. Welcome to our world.)

That you don't use it is great! To use JavaScript for the UI is a good choice, blender's doing the same with python. This is also great news for my hybrid AI plans ... btw, they are getting forward, I think a few months we can see it in action. Can't await it!

Edited February 16, 2014 by Hephaestion