Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 14 Oct 2009
Offline Last Active Jan 11 2015 02:35 AM

Posts I've Made

In Topic: Movement system low or high level in ecs design

07 January 2015 - 02:22 PM

What's with the EntityXY framework? I look at this, while implementing my framework, the system manager is greatly the same.


But my question to the post of crancran remains, could the message queue for moving the entities combined with an event manager which I need anyway?


The reason you find so many variants of an entity framework is because there is no standard practice.


As for the queue, you could implement a single or multiple queues depending on your needs.  Chances are a single queue would be sufficient as a starting point and build upon that idea long-term if you find you need to separate the queues for any particular reason.

In Topic: Movement system low or high level in ecs design

05 January 2015 - 06:51 AM

In your first approch, do you mean that in this queue, there is a move entity position to ... entry, for the scene manager of irrlicht?

Correct.  Think of this as a message that contains the id of the entity, the position, and orientation.  The render system takes the entity id, locates the Irrlicht scene entity by a reverse lookup table and then modifies the render scene node appropriately.



The second approch would be a special irrlicht wrapper system, which do all the things with the scene manager, and the irrlicht render system only do the update?

Correct.  The wrapper system transfers all information from the entity's components into the Irrlicht scene such as position, orientation, setting appropriate mesh, material, etc.  After all that has occured, this same system could just then call Irrlicht's update to send the render queue to the graphics card and swap buffers.

In Topic: Movement system low or high level in ecs design

04 January 2015 - 10:36 PM

The movement system must change the position component, and the render system request the position and renders the entity.

There are two approaches you can consider for replicating information to your render system and a lot of it depends on how coupled you want your code.


The first approach would be to decouple your entity system and rendering system entirely.  There is lots of benefits to this approach as it will allow you to easily replace your rendering engine with another but does come with it's own set of concerns.  To decouple the two entirely, you would use a command queue where your ECS systems emit commands as they perform various operations.  These commands are placed into the said queue and during the render system's update phase, it would parse these commands and perform the necessary rendering operations.  It's important that all pertinent information be included in the command to avoid the rendering system having a need to query the ECS at all.  


The second approach would be to live with the fact there will be some coupling.  In this case, you would have a specialized ECS system or game loop step that runs after you have completed your logical updates and would query various entities and replicate necessary information from the ECS into the render system's scene manager.  This system acts as a wrapper around calling Irrichlt's "render/update" call as it would perform the various scene updates and then render a single frame.


Both approaches have advantages and disadvantages and you can easily change between one or the other.  Pick one that makes the most sense for now and move on.  You can always come back later and change it and improve upon it as the need arises.

In Topic: Game State management in Entity Component System architecture

24 October 2014 - 09:44 AM

Programmers tend to start with a clean design that works well, which then gets buggered about with to handle edge cases. Then a few more edges cases come around, the system stops being clean and becomes a mass of inefficient code.


To avoid this, edge cases should be worked in not as hacks to the existing code base but as full fledged iterative parts of the overall solution.  But unfortunately, developers tend to be lazy and take the least path of work due to various reasons and this is one of the largest contributors to the problem you described above.  Whether you're doing something insanely simple or something far more complex and involved, the same series of iterative steps should be considered, validated, and executed.  

In Topic: Making a Form that doesn't freeze from Console Application

02 October 2014 - 09:33 PM

If you ever create a simple basic windows based application, you'll notice that shortly after the window has been created, you enter into an infinite loop that looks something like the following:

MSG msg;
while(GetMessage(&msg, NULL, 0, 0)) {

This message loop calls GetMessage which blocks until a message arrives on the event queue.  When an event arrives, the loop translates it's information into locale-specific values and then dispatches it to the appropriate receiving window's procedure (WNDPROC) handler.


The above code works well if you want your main UI thread to be dormant while it waits for incoming events from the operating system, but is far from ideal if you want to continue doing things in the loop.  This is where PeekMessage becomes useful.

MSG msg;
while(!bExit) {
  while(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) {
    if(msg.message == WM_QUIT) {
      bExit = true;
  /* do your stuff here */

Whether you're doing console-based or window-based Win32 applications, the above loop will allow you to handle operating system events, allowing the window to remain responsive while also allowing you to perform whatever tasks you need to do for your main loop.  


The biggest downside to the above is that if your stuff takes a bit of time per main loop iteration to complete, this can introduce input lag to your window message loop and could still make the window's title reflect "(Not Responding)".  You'll need to experiment to see whether the above approach with PeekMessage will be sufficient for your needs or not.  Chances are it should be more than sufficient at first but as your processing for stuff takes more and more time, you might find the need to split the two loops into two separate threads.  The general idea here is that you'd use the first loop I presented above in conjunction with a bit of logic to capture input from the message loop, convert it into some data structure and dispatch it to a command queue that your second stuff thread inspects during each of it's loop iterations and processes input.  


My suggestion is not to introduce any parallel threading to the mix until absolutely necessary as it does add a layer of complexity which can be hard to manage if you're not familiar with multithreading and shared data access requirements across multiple threads.