Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Jun 2008
Offline Last Active Jun 30 2016 04:05 AM

Posts I've Made

In Topic: Sharing object between 2 threads

30 June 2016 - 03:23 AM

Well, all this makes perfect sense. It seems I got scared (and mixed-up my thoughts) because of the thread, separate entities (exe + dll) and existing code aspect.


The fact that I need different threads is that my game logic already works using several dozens of threads (but perfectly synchronized). So it only makes sense to have a separate thread for the GUI and rendering (e.g. Qt also requires to run the main Qt code via the application main thread)

In Topic: Sharing object between 2 threads

29 June 2016 - 03:26 PM

Phil, perfectly agree with you. If I had to rewrite the whole project, that's how I would do it. Unfortunately I have to modify an existing code (written by another person) that has several hundreds of thousands lines. It would take several months to do that. On the other hand, if I have a solution (maybe not that elegant) that works, and that can slowly be refactored while keeping current working solution, it would be great.


With the initial idea of simply casting an object of class A to and object of class B (where the two classes are identical except for the member functions), I could put a few ifdefs in the class definitions, I could compile class A in item A, and class B in item B, but using the common, existing class AB.

In Topic: Sharing object between 2 threads

29 June 2016 - 01:57 PM

I need option 3 in what you mention.


My problem is not only the rendering, but also all the GUI.

So I have:


Game logic thread: runs the game and modifies the resources.

GUI thread: handles the GUI events and also renders the views.


I want the game logic to be compilable in headless mode, and optionally have a plugin with the GUI and rendering. Think of it as a simulation of some physical process:

a) we can have the simulation configured and modified via a GUI, and also visualized. This situation requires the headless mode game logic executable, and the GUI/rendering plugin loaded

b) But other times, we simply want to be able to run, say, 10 simulations in parallel, in headless mode: in that case, we are only interested in the data the simulation produces. This situation only requires the headless mode game logic executable


So all the dependencies to the GUI and OpenGl should be in the plugin, so that the game logic can also easily run on machines that do not have any display (i.e. no OpenGl or graphic card installed)


So I agree that duplicating the resources is a tremendous amount of work, and many things can go wrong if not done properly. So, let's for now forget the resource duplication, and consider that we have only one thread doing everything.

What I currently have is following:


class CObject_A
    virtual ~CObject_A(); 

    void doCalculationAndModifyObject(); 
    void renderObject() 

    CData* data; 

I basically currently have everything in one class (actually many classes, but for simplification sake). Because of that I cannot compile the gamelogic in headless mode (above class has the dependencies to the GUI/OpenGl). I need to separate the above class in 2 separately compilable entities, with least effort.

For that reason I mentioned the possibility to simply cast a class to another class, if the member variables are the same.


So I want to be able to do following:

// gameLogic executable:
CObject_A* object=new CObject_A();

And in my plugin:
void callPluginRoutine(CObject_A* obj)

If I want to be able to compile my gameLogic executable in headless mode, I am not allowed to have routine "renderObject()" in class CObject_A during compilation.

In Topic: Sharing object between 2 threads

29 June 2016 - 11:52 AM

Thanks for all the good answers. I realize that the better approach would be to use the same data structure in both threads, while having different classes.

What I am actually trying to do is:


The main thread handles the game logic and works on the resources (reading/writing them). The auxiliary thread handles the display only, reading only from the resources.


I want at a later point to be able to either have the render thread:


1. either read from the original data while the game logic thread waits (thus avoiding copying the resources at all).

2. either read from a copy of the original data, while the game logic continues its work.


In case 2 above, copying the resources will be done as a light copy first (i.e. actually sharing the resource until the point where the main thread modifies it: in that case, the main thread will first deep-copy the resource before modifying it, while the render thread will still read from the old, unmodified resource, thus avoiding a crash).

In Topic: Data alignment on ARM processors

29 April 2016 - 12:33 AM

Thanks to both of you for the very clear explanations!