Developing “Rush for Glory” game is going to be finished. so I decided to rewrite some parts of the engine recently. this may cause you to rewrite the whole source code. In the first step, I rewrote the containers library. in this new version, I changed the structure of containers to decrease the usage of templates<> to more easier to understand. I used a sampler to decrease allocations. also implementing memory allocators is more easy than before and changeable during the code in some cases. finally implementing a new memory allocator that uses stack memory to avoid calling the malloc function.
Note that some new features are not designed for general purposes. there are many limitations to using them and must be used with care because those features are designed to develop the game and most of the capabilities depend on the needs of a game engine.
Here are some highlights :
Added math base functions to the library with some fast functions like :
float sx_sqrt_fast( const float x );
// return sine( x ) from table. maximum absolute error is 0.001f
float sx_sin_fast( const float x );
// return cosine( x ) from table. maximum absolute error is 0.001f
float sx_cos_fast( const float x );
// compute the sine and cosine of the angle x at the same time. maximum absolute error is 0.001f
void sx_sin_cos_fast( const float IN x, float& OUT s, float& OUT c);
and some useful conventional functions
MemManFixed::SetBuffer(void* buffer);
I can change the memory buffer of the allocator by setting a new buffer. this feature is available only on the fixed memory manager. it means that it’s suitable just for arrays and strings.
For example, I wanna change/fill a string in a structure. in this example when I set members of the structure to the allocator, all string functions can be applied easily.
wchar path[256];
wchar name[64];
wchar type[32];
}
FileIfo fileInfo;
MemManFixed memTmp;
String strTmp( 0, &memTmp );
// extract file path from file name and copy that to fileInfo.path
memTmp.SetBuffer( &fileInfo.path );
strTmp = fileName;
strTmp.ExtractFilePath();
// extract the name of the file and copy that to fileInfo.name
memTmp.SetBuffer( &fileInfo.name );
strTmp = fileName;
strTmp.ExtractFileName();
// extract file type and copy that to the fileInfo.type
memTmp.SetBuffer( &fileInfo.type );
strTmp = fileName;
strTmp.ExtractFileExtension();
MemManFixed_inline<memSizeInByte>
This memory manager uses a memory stack of functions. by the way, this feature is available only on the fixed memory manager. this means that it’s suitable just for arrays and strings.
In this example, I try to collect some nodes from the scene manager. this will happen at each frame more than once, at the renderer, AI system &, etc. Implementing a new Array class causes calling allocation/deallocation. the other solution is declaring a static array. the other solution is using a memory stack with some limitations but fast and easy memory management.
example :
Array<Node*> nodes( 0, &tmpMem );
// collect nodes from the scene manager
g_engine->m_scene->GetNodesByFrustum( cameraFrustum, nodes );
for ( int i = 0; i < nodes.Count(); i++ )
{
// ... do something !
}
Although there are some changes like adding new functions and changing algorithms in the other stuff to increase performance and capabilities, but those still need to be optimized more and more.
that is depend on programmer’s manner. I was used namespaces in my last engine. after a while I found no two structs/classes with the same name and that’s really not necessary to limit them in the namespaces. namespaces make code lines so long and ugly. I had to hold shift over and over. using namespaces led to hard management because some classes were shared between namespaces and I couldn’t classify every thing in engine.
anyway as I said that’s just programming style 🙂