Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Mar 2006
Offline Last Active Apr 07 2015 08:28 AM

Posts I've Made

In Topic: How to Separate the Rendering Code from the Game Code

15 October 2014 - 03:35 AM

Thanks again all, I think I'm starting to get it now. 


I think the heart of my problem is that I'm not encapsulating the details of the renderer, so for example my Terrain class doesn't have a simple Material and Geometry but instead has much lower level information, such as:

	// The Vertex and Index Buffers describing a tile
	ID3D11Buffer*					m_TerrainVB;
	ID3D11Buffer*					m_TerrainIB;

	ID3D11Buffer*					m_SeaVB;
	ID3D11Buffer*					m_SeaIB;

	ID3D11Buffer*					m_BoxVB;
	ID3D11Buffer*					m_BoxIB;

	ID3D11VertexShader*				m_TerrainVS;
	ID3D11PixelShader*				m_TerrainPS;

	ID3D11VertexShader*				m_SeaVS;
	ID3D11PixelShader*				m_SeaPS;

	ID3D11VertexShader*				m_BoxVS;
	ID3D11PixelShader*				m_BoxPS;

	// The input layout for terrain vertices
	ID3D11InputLayout*				m_TerrainInputLayout;
	ID3D11InputLayout*				m_SeaInputLayout;

	// Constant Buffers
	ID3D11Buffer*					m_PerFrameCB;		// Per frame constant buffer
	ID3D11Buffer*					m_TerrainObjectCB;		// Per object constant buffer

I guess I need to better encapsulate these, so that I just have higher level Material and Geometry classes, and then I can use the above advice to just send the Material and Geometry to the renderer.


It's all starting to make sense, and should help to simplify and tidy up the code too (I hate messy code, so I've not been happy with this for a while now).




In Topic: How to Separate the Rendering Code from the Game Code

14 October 2014 - 03:52 PM

I've just read the 2 articles on Component Entity Systems, and they're pretty interesting and I can see how the memory layout is efficient from a cache point of view, but I'm not sure how well it would work in my case.


Lets imagine a an RTS game, with potentially thousands of units in play at any one time. You might use a Quad tree to partition the space and only update the units in view with every frame, and objects just outside of view are updated every other frame (Some on the odd frames and some on the even frames to balance the load) and units even further away are updated even less frequently. I'm not sure how this fits in with the CES idea.


Also, imagine if a have a world that can potentially support a theoretical 100,000 entities (Maybe 2000 units + loads of bullets, rockets, missiles and other objects). In reality most of the time you'd only have an average of 1,000 entities, but in the heat of a massive battle this could increase significantly. Having your systems walk all 100,000 entities every time when most of them will be empty seems inefficient. 


One final comment, for worlds with a large number of potential entities it may be better for createEntity and destroyEntity to maintain a list of the index to free entities so that creating a new entity can be done in constant time, rather then potentially having to walk up to 100,000 items in the array.


Interesting concept though and definitely looks like a good idea for many applications, but potentially doesn't work for everything, but then nothing ever does.


Thanks again


In Topic: How to Separate the Rendering Code from the Game Code

14 October 2014 - 09:42 AM

Thanks both for your replies,


GK, I'm actually reading Game Engine Architecture 2nd Edition right now, but I haven't got to that part of the book yet. 


Previously I'd read the otherwise excellent Game Coding Complete book but this was the one area that I found confusing in that book.




In Topic: Building Assimp in Visual Studio

06 July 2014 - 12:38 PM

Just for future reference if anyone else has the same question.... I downloaded CMake and followed the instructions here:



And to my surprise it actually worked. By worked I mean that it generates Solution\Project files for the versions of Visual Studio you select (As well as different target platforms, such as x86 or x64) and they build just fine.


The solution\project files it generates are a good starting point, and it builds, but they're a bit of a mess as they use absolute full paths instead of solution relative directories etc, but it's only a minute of 2's work to tidy that up.




In Topic: Building Assimp in Visual Studio

05 July 2014 - 01:17 PM

Thanks LennyLen


Yes I initially downloaded the binary install but it only includes the release lib files and not the debug versions. I'm not sure if this is an issue though.


I eventually found the build instructions (Not in the most obvious place I have to say), and so I'll try using CMake later (HAving never used it before).


Thanks for your help