Thanks for the discussion guys, took me a while to get my head around these replies hence the late post...

@haegarr

Your post makes a lot of sense, thanks for taking the time to write that.

"So, question is to which layer(s) do Game::render and RenderSystem::update belong to?"
Game::render() is called from game::run() so yes I guess it is the top level of rendering.

"If "sprite" is your graphic primitive of choice for both ground and entities, then you will have a ground renderer and an entity renderer in the end, the first using a ground representation as input and the latter using game objects as input, and both yielding in sprites as output."

I think this is where I am confused.

I don't fully understand how Game::render works on scene objects (are objects things in game that *Do* stuff eg my player spaceship and enemy ship..?) Is the way I currently have it? Where by it calls m_systemManager.update<RenderSystem>(frameTime) correct..?

"It may iterate all drawables in the scene and invoke their render() method. That render() methods will be the second layer of rendering and perhaps already output the sprite primitives."
Can you give me an example of what you mean by this?

"and RenderSystem::update(time) should not exists as such."

Thanks I have removed that. I understand that the logic updates need a delay time to work out the correct movements, but for some reason thought the renderer did it, but I forgot that the game engine will be kept at my chosen fps, and therefore it will not matter if I pass in the time.

@CRYP7IK

Are you saying basically label nothing as an actual entity, but just use components and systems to do the work? In this case I can't understand how to get the data into systems? Because so far I only understand the method of "for (entityx::Entity entity : entities.entities_with_components(component1,component2,etc))" for actually getting the entity data into systems...

@L. Spiro

I understand what you're saying and agree. If I had read that post before going down this route I would have stuck with how I was doing it, but I have spent months getting this working and now I feel if I turn back it does me more harm than good... either way I have learnt a lot so I feel it was not entirely a waste.

@ferrous
haha thanks

@SOL-2517
So rather than my old engine where a TILE was essentially a sprite that had a tile.draw() function, I will pass the data to a renderer that has something like drawTile(tile[1][2])? The other thing I am a bit stuck with was in the old approach I would put the tiles where they need to go using tile.setX(), tile.setY(), which updated the underlying spriteData structure which was sent to directXTK to draw. This way, if tiles are plain old data, how do I specify these additional needs, such as tile position X and Y.

Thanks all

@CRYP7IK

Are you saying basically label nothing as an actual entity, but just use components and systems to do the work? In this case I can't understand how to get the data into systems? Because so far I only understand the method of "for (entityx::Entity entity : entities.entities_with_components(component1,component2,etc))" for actually getting the entity data into systems...

No, you would put TileMapRenderer and TileMapSettings onto an entity (This might set the bottom left of the TileMap to that entities position or something) and assign the TIleMapRenderers TileMap to some data.

You could always have a TileMapSystem that manages the tiles of the map. You could model these as entities or simply "renderables" that are passed to a renderer inside that system.

I do it in a deferred way as in when you pass something to the renderer, it doesn't draws it right away, just adds it to a queue. Then after each system passed all the renderables they're in charge of processing, a "RenderSystem" does the actual rendering.

Off the top of my head, if you want to model everything as entities:

You could have something like the TileMapSystem being in charge of loading up a map and then construct entities from the tiles.

Then you'd have different systems (StaticTileSystem, DynamicTileSystem, AnimatedTileSystem, etc) that pick up and process these entities (for dynamic, they can move, for both static and dynamic they can get culled, etc) and send them to the renderer.

RenderSystem would grab the queue that the rest of the systems built before and render it. This means you have a strict ordering in your system update chain, but that's okay, those dependencies are well defined that way and you can easily visualize how the entire game is run.