Friday Facts #9

[slpwnd]

Surprise, surprise. Here come another FFF round: http://www.factorio.com/blog/post/fff-9

[Eruyaean]

Woohoo, XKCD-reference! xD

[FrozenOne]

Guys, don't you wanna extend it with oil industry and give it to us as xmas present instead? ^^

[Balinor]

Oh I wish that was possible. Oil is something I am really looking forward to being a reality in Factorio.

[Gammro]

Did someone say oil?

[SilverWarior]

Includes. They are killing us. Factorio is written in C++ which has an old-school-textually-include-stuff approach to referencing objects in other files. This means that the compile time goes up fast with the growing codebase.

That is why I program with Objective Pascal rather than C++ even thou most of game developers say C++ is one to go.
The biggest advantage of Objective Pascal is that it by default generates precompiled units. This means that when I compile my projects every spource file gets compiled into special precompiled file (delphi compiled unit or *.dcu). These files are compiled in a way so that they can be linked to a project (EXE) at any time in the future by the pascal linker. So this greatly lowers the compile times as only units (source files) that have been changed since last compile needs to be recompiled.
There is one drawback of this system. Usually Executables are a bit larger becouse less optimization is done (not used code from these units is still added to EXE). But to overcome this in final build there is special option which enables best optimization but requires complete rebuild of the project. Usually you use this only before distribution of your final EXE to your users/players.

But before you might start thinking about switching to Objective Pascal for game development you should know about another disadvantage that Objective Pascal has in comparison to C++. And this disadvantage is less game development code examples and lesser amount of game engines available.
So while most C++ game developers could easily find code example for solving some devlopment problem I must solve this problem myself or find some C++ code and translate it into Objective Pascal which isn't usually best idea due to certain changes between C++ and Objective Pascal.

But there are C++ development IDEs which support similar functionality that is present in Objective Pascal by default (precompiled units) so maybe yu might wanna switch to them instead. One of such that I know is Code:Blocks which by using specific plugins supports precompiled units.
Now unfortunately I don't have enough expirience with it to help you guys get set up with it. I just used it for compiling of test builds for game called UFO Aliend Invasion (UFO AI for short) which you can find here: http://ufoai.org/wiki/News
But if you guys ask the developers of previosly mentioned game for help setting up Code:Blocks for compiling factorio I'm sure they will be glad to help you out.

[muzzy]

Includes. They are killing us. Factorio is written in C++ which has an old-school-textually-include-stuff approach to referencing objects in other files. This means that the compile time goes up fast with the growing codebase.

That is why I program with Objective Pascal rather than C++ even thou most of game developers say C++ is one to go.

The advantage of object pascal in this regard is the separation of interface and implementation, and this can be achieved in C++ with the pImpl idiom to produce the same benefits in reduced compile time. With the pImpl technique, changing the implementation (adding new private methods and variables etc) won't cause changes in the public class, and thus won't trigger recompilation of things that depend on it. The public header usually doesn't need to include its dependencies, just forward declare the classes used in method signatures etc.

[Zinzin]

I want another FactorioCon

[Gryzorz]

Isn't there a way to adopt a modular approach ?

The goal is to split the code into modules.
Each module produces a library.
When doing a complete compile, the compiler only compiles if there were changes in the code base, otherwise it just takes the latest generated module library.

I haven't been developing with C++ for 10 years or so, but I'll dig into that a little bit eventually.

Thoughts ?

P.S : hey first post o/
P.S : love your work guys, I can literally _feel_ the passion in this game when I discovered about modular armors. You're just putting all you ever dreamt for about a game, and I just LOVE it <3

[slpwnd]

But before you might start thinking about switching to Objective Pascal for game development you should know about another disadvantage that Objective Pascal has in comparison to C++

I think we will stick with the C++ for now

I mean it is a tradeoff right. The C/C++ has a lot of bad baggage from the past, on the other hand it has three great advantages:
1) speed
2) a lot of existing libraries
3) speed

One of the options that kovarex considered when starting the project was to do in the D language. I believe the compilation would be orders of magnitude faster there and the code would be more pleasant to write. When it comes to speed I believe it is on par with the C++, except for having an automatic garbage collector. That is not such a big deal if we could allocate a specific amount of time per tick to the garbage collector and collect the garbage incrementally. The biggest issue I imagine we could have had with the D language is the maturity of tools and libraries. I just don' know what the state of GameDev libraries is for D - whether we could get something like Allegro there for instance. Anyway, often when we are really frustrated with C++ (includes are a common source of that) we are like "what if we have just rewritten the whole thing into D ... ":)

P.S : hey first post o/

welcome

P.S : love your work guys, I can literally _feel_ the passion in this game when I discovered about modular armors. You're just putting all you ever dreamt for about a game, and I just LOVE it <3

We try. happy to hear you like it

Isn't there a way to adopt a modular approach ?

The goal is to split the code into modules.
Each module produces a library.
When doing a complete compile, the compiler only compiles if there were changes in the code base, otherwise it just takes the latest generated module library.

This is tricky because of the dependencies between the modules. At the moment our engine is more like monolithical than a set of pluggable libraries that can be taken in and out of the compilation. At one time we were playing with the idea of unity builds (all cpps put into one file and then compiled - saves a lot of time because the includes are included just once). In the end we do it only for the final build (we have a single allinone.cpp file and build from there - but here the reason is mostly optimization - we can easily inline across the cpp - hpp boundary).

Anyway, kovarex spent some time with the includes and it is now much faster. We have extended our common.hpp (precompiled header), cleaned some unused includes, changed some performance irrelevant member objects to pointers, etc. and the speedup is > 20%.

[wrtlprnft]

This is quite obvious, so you'll probably already have tried that: Have you tried to use a lower optimisation setting for test builds? At least gcc is a lot faster with -O1 than with -O2.

[slpwnd]

This is quite obvious, so you'll probably already have tried that: Have you tried to use a lower optimisation setting for test builds? At least gcc is a lot faster with -O1 than with -O2.

Yup. We have a debug and production builds. For many things the debug one is enough (and takes again like 20% faster to compile than the production one).

[SilverWarior]

I mean it is a tradeoff right. The C/C++ has a lot of bad baggage from the past, on the other hand it has three great advantages:
1) speed
2) a lot of existing libraries
3) speed

I totally agree with second advantage.
As for 1st and 3rd advantage you mentioned: They are strongly affected by the way you code. You can get excelent speed from C++ or you can get terible speed from C++ and it all relates to your implemetation.
I don't want to start a "programming language flame war" here. But last time when a friend of mine which is a C++ dveveloper started and argument with me saying that C++ us much faster than Objective Pascal I hapily showed him that he is wrong.
I asked him to present a programming problem to me (what needs to be done) and finally we would compare both of our implementaions. So in just about weak time I managed to make a simple program to solve that challenge and it greatly outperfrmed the one my friend made. And when my friends boss found out about that it nearly fired him.
Finally I helped my friend to implement similar solution that I did in C++ so he didn't get fired in the end.

So you see it is not the programming language that plays the most inportant role in the speed of final application but the implementation of the code itself.
It is true that some "Highe level" programming languages have quite poor performance but that is due to por implementation of "Low level" functionality. This is especially noticable in interpreted programming languages like C#.
Best advantage of Objective Pascal is that while it is "Higher level" programming language you can still go down to "Love levels" programming with it to get the most performance out of it. But in contary to C++ you are not forced to go to do this "Low level" programming as the "High level" functionality bases on good implementation of "Low level" functionality.