Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Dec 2012
Offline Last Active May 10 2016 02:39 PM

Posts I've Made

In Topic: Pimpl and potential alternatives

26 July 2015 - 10:29 AM

Thank you all for your replies.



NVI is a better alternative to PIMPL much of the time.


I will take a closer look at this option.

Based on your link this seems to work quite good for a log system (though a pretty simple one):



class Logger {
    void log(const std::string& message) {
        // get the time etc.
        auto completeLogMessage = /* build one */

    virtual void log_impl(const std::string& completeLogMessage) = 0;


class CommandLineLogger : public Logger {
    virtual void log_impl(const std::string& completeLogMessage) {
        std::cout << completeLogMessage << std::endl;

It would also be possible to add a specific implementation that is logging to a database etc. which is pretty cool.

This surely does not represent the full potential of this idiom but I will keep this in my mind and try to apply it when dealing with a more complex scenario.



This is the way my prototype is working at the moment since I didn't trust the pimpl tongue.png


@Servant of the Lord:

Thanks for pointing out Qt - I will have a look at the source code so some things might get more clear when seen in production code.

Based on my limited experience I would tend to not trust anyone especially after reading through some posts of the "Coding Horrors" section tongue.png



Since my project is not going to be a library you might be right. But in my opinion there's nothing wrong with trying to apply some techniques primarily used for APIs to the internal stuff if it makes some things cleaner. I will see how this works out and the good thing is the project is nothing mission-critical so learning new things is what it's all about.

In Topic: Improving my architecture design and career

15 July 2015 - 05:29 PM

Hi ArThor,
my opinion might not be the most valuable because there are much more experienced and skilled people on this forum but I was in a very similar situation trying to find a solution. So here are my 2 cents:
As I was starting to find a solution to this problem a pretty long time ago (1 year+), I was constantly browsing the web trying to gather as much information on this topic as I could. Relatively early in this process I noticed that most of the information were based more on experience than on some recipe that could be applied. This is also the reason why I would say the solution is not always in the books, regarding this topic.
Later on I stumbled upon a slideshare of Joshua Bloch stating the following: "Write to your API early and often."
This is what helped me a lot.
But this statement can be expanded even more - to something like: "Let others write to your API early and often."
In this way you can easily locate issues with your code design because others might not think the way you do and the code was designed for. Furthermore you can get input from someone that might use your code in the near future and you will know how he expects to interact with it.
As soon as the API design is on a pretty decent level you can start implementing your code. And because the API acts as kind of a boundary, your code (the actual implementation with all its details) is forced in the right direction. Yeah, it's still possible to create a monolithic class handling all different things but it will feel wrong because you will need to work against the API.


The slideshare mentioned above can be found here: Google API Slideshare

In Topic: Are you the "From Scratch" type?

19 June 2015 - 05:11 PM

I would say that I'm a "From Scratch" type all the way.


I like to have full control over the things I do. This extends to "I NEED to have full control over the things I do" if there is anything mission-critical involved. The latter is not always possible when using 3rd party code.


Another point that's great about writing stuff from scratch: you will learn a lot.

And that's a huge benefit in situations that might force you to decide whether to write the thing from scratch or go with an existing solution. The reason for this is that your knowledge empowers you to take several things into account that you might not really know about if you weren't writing something similar from scratch in the first place. You are even able to compare existing solutions on a more fine grained level which is always a good thing if you're trying to find something that fits your needs.



It would also be great to hear from people that were mainly using 3rd party solutions on projects that failed by doing so. (What are the reasons for this?)

In Topic: Gathering information on input systems

04 February 2014 - 04:00 PM

It depends on where you draw the border. I've running a thread to gather input, to translate it from OS to engine events, and push them into a queue. The thread that runs the game loop reads the queue when the InputServices is updated. This services instance has the ability to plug-in input listeners, so to say. Entity components like the PlayerController puts to use this, as well as sub-systems can do so. E.g. the Graphics sub-system can install an input listener to get window size changes. And the loop itself could install a listener to detect quit conditions if wanted so, or even better the GameServices instance should do so.

Yeah that's right.

The procedure that you've explained will get important right after the input has been gathered in a raw state.

Nevertheless i would separate the window input and the usual game input. A very raw sketch of my thoughts to this is attached to this post.

The "IOHandler" will be the entry point to the system. One can't dive deeper into it to keep it as high level as possible. So in order to this, you need to register or deregister listener right there.



Btw if you want multi-platform in input, you are going to have to write platform specific code, dealing with hardware devices is pretty hardwired into the platforms. Even between console generations of the same manufacturer this is different. The only other way out is writing your own HID interface but even then you run into platform differences, when dealing with hardware on different OSes sadly you will always have to write platform specific code.

I guess you are right.

One way would be to implement a high-level api that uses low-level stuff depending on the platform that you're using. So you have to deal with platform specific stuff just at a single point in the low-level part (Please correct me if i'm wrong).

For sure it's sad to see everything being high-end and then one is struggling when implementing an input system caused by platform specific "standards".


But libusbx needs a chance. Even if it's just for the sake of learning something new i'll go to try it out.

Thanks for the feedback so far.

In Topic: Gathering information on input systems

04 February 2014 - 01:51 PM

Hi NightCreature83,


thank you for your reply.

Your offered links are pretty interesting and cover a lot of things i was thinking about.

Unfortunately it is based on Windows and i want the input system to be running on other platforms as Linux and Mac as well (sry, i didn't mention this in my initial post).

So in order to this there is a need for some standard that needs to be supported by all of these platforms and USB seems to get it right (on a low level).


While looking for some HID APIs, i came across the following one:


It looks right for testing some stuff and trying to implement a prototype using it.