Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Re:creation - a top down action adventure about undeads [hiatus]  (Read 278324 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32502
    • View Profile
    • SFML's website
    • Email
Re:creation - a top down action adventure about undeads
« Reply #375 on: December 06, 2015, 03:07:34 pm »
You don't need to create CMakeLists.txt files in every sub-folder. If they just contain source files and headers, you can reference them from the main CMakeLists.txt with their relative path.
Laurent Gomila - SFML developer

shadowmouse

  • Sr. Member
  • ****
  • Posts: 302
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #376 on: December 06, 2015, 03:53:39 pm »
Just out of interest, why do you have so many files? How much do you put in each? That might well be the reason for your compile time taking minutes unlike the usual few seconds.

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re:creation - a top down action adventure about undeads
« Reply #377 on: December 06, 2015, 04:12:05 pm »
Just out of interest, why do you have so many files? How much do you put in each? That might well be the reason for your compile time taking minutes unlike the usual few seconds.
I would expect to opposite.
With many individual files the amount of code that needs to be recompiled when you change something is likely to be less than if you had a few monster files that are all impacted by every little change.

My personal rule of thumb is one class per .h/.cc file.

shadowmouse

  • Sr. Member
  • ****
  • Posts: 302
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #378 on: December 06, 2015, 04:21:31 pm »
That's my rule as well (except with .hpp and .cpp), I just thought that once you had split stuff up that much, the shear amount of files that would have to be compiled, especially if a header file was changed could be what's taking ages. I just remember Elias saying something about it taking at least 2 minutes to compile, which is weird because in my experience things take 15 seconds tops, usually closer to 2 seconds to compile unless you're doing a full rebuild.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6259
  • Thor Developer
    • View Profile
    • Bromeon
Re:creation - a top down action adventure about undeads
« Reply #379 on: December 06, 2015, 04:43:19 pm »
With many individual files the amount of code that needs to be recompiled when you change something is likely to be less than if you had a few monster files that are all impacted by every little change.
This is definitely true, and a good reason to keep dependencies between different modules low, for example by:
  • Having classes with small APIs and let each reference only a few "neighbors" that logically relate
  • Avoiding central manager- and singleton-style classes used everywhere
  • Using forward declarations or even the PImpl idiom where appropriate
  • Including only the necessary specific headers and no mass includes like <SFML/Graphics.hpp>
However, having many files comes with the problem that often-used external code in headers (from standard and other libraries) must be included in many more files, and recompiled again and again in each of them.

The effect of this depends strongly on the compilers' capabilities to cache code that doesn't change (which is not always trivial, since single declarations or macros can change the behavior of everything that follows). Good compiler toolchains therefore offer an explicit option to precompile headers. Furthermore, with the number of files increasing, the effort for the linker increases as well, thus the linking step may take longer.
« Last Edit: December 06, 2015, 04:48:51 pm by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re:creation - a top down action adventure about undeads
« Reply #380 on: December 06, 2015, 04:51:55 pm »
@Nexus : What you say is true of course. And one should always try to only include what one uses and no more and always use forward declarations where possible etc. On top of that I'd recommend using ccache. It can really speed up your recompiles when most files can just be taken from the cache rather than re-running the compiler.
Ohh and using a fast compiler like clang can also help a lot.
« Last Edit: December 06, 2015, 04:55:59 pm by Jesper Juhl »

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re:creation - a top down action adventure about undeads
« Reply #381 on: December 06, 2015, 09:10:17 pm »
I just remember Elias saying something about it taking at least 2 minutes to compile, which is weird because in my experience things take 15 seconds tops, usually closer to 2 seconds to compile unless you're doing a full rebuild.
That very much depends on the size and complexity of the code you are working on.
Sure, for many personal hobby projects sub-minute build times are probably the norm. But projects grow...
The code base I work on at work is ~60000 files and takes about 30min to rebuild from scratch on a modern 8core machine. With ccache it can then usually be re-built in a few minutes (0.5-3.0) if you only make small local changes..
Also, have you tried building something like Qt5 from scratch? On my (8core) laptop it takes >4hrs.
« Last Edit: December 06, 2015, 09:12:25 pm by Jesper Juhl »

shadowmouse

  • Sr. Member
  • ****
  • Posts: 302
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #382 on: December 06, 2015, 09:20:14 pm »
No I'll be honest I haven't tried stuff like that. I was merely guessing at the amount of code that goes into something like this because it's similar to an unfinished old project of mine which I used to be able to compile in 10 seconds.

Elias Daler

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #383 on: December 06, 2015, 10:53:24 pm »
You don't need to create CMakeLists.txt files in every sub-folder. If they just contain source files and headers, you can reference them from the main CMakeLists.txt with their relative path.
Yeah, but why do most people put them in every sub-folder anyway? Even SFML does it! :D

Just out of interest, why do you have so many files? How much do you put in each? That might well be the reason for your compile time taking minutes unlike the usual few seconds.
I have so many files, because I have lots of code! ~16k lines of code in .cpp and most of the files are 100-200 lines long. Most of the time compilation is pretty fast. Compilation times are bigger when I change some base files like Entity.h or Component.h. But mostly, they're pretty okay. I forward-declare as much as possible and  ECS makes me not make large inheritance trees, so dependencies are minimal.
And btw, my laptop is not very good, so this adds to compilation time. Full recompilation takes around 4-6 minutes.

The biggest problems with compilation times were caused by LuaBridge, but I've already fixed that :)
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32502
    • View Profile
    • SFML's website
    • Email
Re:creation - a top down action adventure about undeads
« Reply #384 on: December 06, 2015, 10:59:21 pm »
Quote
Yeah, but why do most people put them in every sub-folder anyway? Even SFML does it!
There's a CMakeLists.txt file where there is a new binary to configure. There are plenty of sub-folders in SFML that don't have this file, because they exist only to organize source code (the whole headers hierarchy, or the various platform folders in System and Window, for example).
Laurent Gomila - SFML developer

Elias Daler

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #385 on: December 06, 2015, 11:03:56 pm »
There's a CMakeLists.txt file where there is a new binary to configure. There are plenty of sub-folders in SFML that don't have this file, because they exist only to organize source code (the whole headers hierarchy, or the various platform folders in System and Window, for example).
Oh, okay, this makes sense. Hmm, seems like using GLOB doesn't change anything in my case (except that I need to run CMake each time I add/remove file) :D
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6259
  • Thor Developer
    • View Profile
    • Bromeon
Re:creation - a top down action adventure about undeads
« Reply #386 on: December 07, 2015, 08:54:59 am »
The biggest problems with compilation times were caused by LuaBridge, but I've already fixed that :)
May I ask how you did that? :)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 9909
    • View Profile
    • development blog
    • Email
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

Jabberwocky

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #388 on: December 09, 2015, 01:42:18 am »
Voted!
Looking great, Elias.  :)

This is definitely true, and a good reason to keep dependencies between different modules low, for example by:
  • Having classes with small APIs and let each reference only a few "neighbors" that logically relate
  • Avoiding central manager- and singleton-style classes used everywhere
  • Using forward declarations or even the PImpl idiom where appropriate
  • Including only the necessary specific headers and no mass includes like <SFML/Graphics.hpp>

All good suggestions, except for the singleton-style critique.  There's nothing inherent about a singleton that makes it any better or worse than a non-singleton for dependencies.  Sure, you can design a singleton poorly, but you can design a non-singleton poorly as well.

Singleton talk is one of those "holy war" type coder conversations.  If anyone wants to debate them further (as if everything hasn't already been debated 1000x over ;)) I'd suggest we start a new thread on it.

Elias Daler

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #389 on: December 09, 2015, 01:04:25 pm »
Thanks, Jabberwocky!

Yeah, let's not discuss singletones. :)
Here's a thing I want to discuss: Manager classes.
There are some useful managers in my game: ResourceManager, LogManager, LuaScriptManager, etc.

I store pointers to them in a global structure named engine_system.
struct EngineSystem {
     LogManager* log;
     ... // etc.
}
To write something in log, I need to do it like this:
engine_system.log->write("Something happened");
This allows me to do some cool stuff, like making FileLogManager and ConsoleLogManager and then replace simple LogManager with FileLogManager which writes to file. Or, I can create NullLog which will ignore all the messages.
This is a Service Locator pattern. So, here are the things I want to discuss

1) How do I make a better interface to this? Maybe I should do something like this?
engine_system.getLog()->write(...);
Or maybe there are better alternatives?

2) Avoiding usage of global engine_system.
Sometimes I can pass needed managers to functions, like this:
void handleInput(const InputManager& inputManager);
But sometimes there's no such possibility, because it's hard to predict which managers will be needed (especially hard with virtual functions!)
So, what are your tips on dealing with this?
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

 

anything