Angelus blog

In  Part 1  I described the configuration system in the engine. In Part 2  I described the reason and thoughts behind the topic: Designing intuitive API that makes sense. Now time for Part 3. This time we will analyze changes in script and reason behind it.  Compute shader script Let's start with the simplest compute shader script that doing anything : Compute {      ShaderFile  =   "sys://Shaders/ComputeShader.glsl" } New version: Compute {      Shader .Bind ( "sys://Shaders/ComputeShader.glsl" ); } This may look like a small change but it brings consistency to script. From now on there is only function style calls with ';' at the end. Defines Let's now add Define to script. In original format this would look like this: Compute {     Define ( "MY_DEFINE" )      ShaderFile  =   "sys://Shaders/ComputeShader.glsl" } The new one is more flexible and allows to do it i...

In Part 1  I described how my configuration script system works. Part 2 will focus more on the real reason why I decided to write this post: Designing intuitive API that makes sense. The more I code and work on complex systems the more I see how important good API is. There is of course 1001 articles describing how to do that and if you are searching for one of them you are not in the right place.  My focus will be on my personal evolution in a way how I think about API. Whole thought came from improving compute shader scripts. They had a really simple form: Compute {      Define ( "MY_DEFINE" )     Reg (0) = UserImage (0, "Write" , 0)      Reg (1) = UserTexture (4)      Reg (2) = UserTexture (5)      Reg (3) = UserTexture (6)      Reg (4) = Texture ( "sys://Textures/Texture.dds" )      Reg (5) =  UserTexture (7)      ShaderFile ...

This may sound weird in days where everything needs to have some kind of UI but the recent time I spend upgrading some of my configurations scripts. My current workflow is to define parsing rules and generate from them parser. To give you an idea what I talk about this is simple rules for the logging configuration file: %name     = LogConfig   %% .input : /* empty */        | LogAllow .input        | LogBlock .input        | AllLogBlock .input        | AllLogAllow .input ; LogAllow        : 'LogAllow' '(' $(CStringID) ')' ';' ; LogBlock        : 'LogBlock' '(' $(CStringID) ')' ';' ; AllLogBlock        : 'AllLogBlock' '(' ')' ';' ; AllLogAllow        : 'AllLogAllow' '(' ')' ';' ; %% It allows me then to parse a file that looks like this: LogAllow("Crash"); LogAllow("Assert"); LogBlock("Scripts"); Lo...

Life bring to us surprises everyday but today I was impressed how fate works. Whole story started few years ago when I decided to make my own RTTI system for White Rabbit Engine. Then I was still young and naive and thought like everybody at this age that I know how to write complicated systems. This experience teach me that I really can write complicate systems ... but not necessarily should. System was working fine but was over complicated and resulted in lot of stability issues. This realization lead to the series of improvement. I like to call it 2nd generation of RTTI system. Changes are covered by  on of my posts . This was already big step: system was simpler, easier and what most important more stable. This sentence could probably end this story if not the fact that I always felt that it is still not final form of this piece of code. This wasn't what I fully wanted. There was one particular feature that I struggled to add but failed to achieve: virtua...

Well time fly by and animation system starting take shape. Thanks to it I could do even some not bad looking animations in game (http://coffemonsters.blogspot.co.uk/2016/05/lba-preview-15.html) but well this is just another milestone in road to finished game.  Because of this thoughts I already moved to next issue: recovering of movie system. So far its going fine I added new movie resource, movie editor module. No I starting adding basic functionality: adding keys. This operation require list of selected objects in level. This part was designed great :D Because I can have N levels loaded in memory in the same time I created new level component which exist only in editor. It contain some editor specific data i.e. selection. It's added on loading from editor and it's not saved with level. When you want list of selected objects just pick component from level and I have access to selection. Great idea right ?  I thought this way when I was writing it. Right now I...

Funny thing about planning is that sometimes its not working out the way you want. This was case this week I planned to work on animations and ended doing small upgrade for resource system. The best thing is that I don't even feel bad about stuff ending this way :D  How I ended doing that is other story. Because I have policy of moving everything what I can to resource system which I have (this make stuff more consistent) I moved my rendering script to it. Everything would be good if not the fact that render script is initialized on main thread and my resource system never was prepared for request from other thread than game thread. So it was time to do improvement to allow for this :D This was even more important because there were sometimes crashes at startup of game. I split my task on 3 sub task: Access to resource data require locking of resource (i.e. meshRes->lock()->getMaterial();) Separation of resource from data so you could have resource handle and it ...

I took some break from writing on this blog but I had busy last few months. In this time I done a lot of changes in engine one of biggest "finished" one are changes in file system. But this time I don't to talk about what I done but more about what will come and what I working on right now. And I do some stuff with which I'm not feel most comfortable: Animation system. So I decided to seek some advice and explain what I do, why and how I would like to improve it. So be free to comment and critique. I don't fell that system I have right now is what I really want to have. This is this weird felling when you fell that system that you created is working but you fell that it's limiting you. Because of this felling recently more often I turn of computer and sit down with pen and notebook and think what I really want to do with this system. So far my conclusion is because I'm iterative develop White Rabbit Engine technology I didn't notice till n...

When two months ago I created generator for RTTI code I didn't realize how this one script will change so much in my programming style. Right now I have already four of generators in my code base: RTTI - Generate part of my RTTI code. SID - Generate CStringID with already calculated hash Pimpl - Generate interface class. Enum - Generate toStringID, fromStringID functions. So what changed for me after writing this one generator that make difference ? I try not to do monkey job . To show you how this improve my workflow let's look on generator I wrote today: Generator of Enumerator functions: toStringID, fromStringID. This is simple problem where for some enumerators we want to have conversion from value to some verbose type. Some people may claim that this is not issue. You write functions once and they work. Later you just need to modify them when you do some changes in enum. This take like about half minute work  ... if we don't do mistake there. Then thi...

This will be story, my story based on true events. Hour 0 Recently I start using project generator not only to generate makes, projects and solutions but also to generate some code. Because of that from time to time I need to run one python script. This is not big problem but I decided to make my life easier and add button in Visual Studio 2010 (I'm working slowly on progression to new one) which will trigger this task. Sound simple right ? 

After weeks of work (probably I could even say months) and hundred resolved tasks and bugs new animation system finally start working ;] Check final effect: If you think that it is look no different from my old animations then you are almost right :D Currently this new system have even less functionality than old one. Because of that I needed to disable big part of gameplay. Was it worth it ?  Short version : I think that: YES. 

As some of you may know White Rabbit Engine use it's own R un T ime T ype I nformation  system. And well like with everything else sometimes come time when you need to upgrade stuff. Recently I had another occasion to do iteration over this system. In this post I will try to give you a little bit insight how m  RTTI  look is engine, what changed and what are plans for future. But well let's start from begin.

Funny thing about doing your own tech is that you sometimes need to do some funny stuff. This week I needed done  Short Term Memory Manager. My comment in code describe it like this: Short Term Memory Manager (STM Manager). STM is memory which you want to use for short one-shot tasks:             Create->Execute->[GetResult]->Destroy It is limited by capacity so you never can use more than you pre-allocated for it. Right now it's use to transfer resource data CPU->GPU and in  animations tasks. For me this is temporary memory which I use for example to load texture data and then passing it to GPU upload (which will remove it). There are also other usage where I think using normal allocation...

This time some more technical post about components system that I work on. So lets start from begin :) Making decision about switching to components took me almost year. Seem like pretty long time to rethink everything. But not necessarily when you need to change big part of your code base. So I focused on finding all pros and cons behind new system. In meantime I had a lot of talks with programmers friends in Poland and here in Canada. Thanks to them I was able to create my own opinion and vision what I want to achieve with this new code.

Time is something funny we don't notice when but it pass by so quickly. Few months ago I announced release of this pre-alpha build. Then it was so far away right now only a little bit more then month left. You probably wondering what changed in this time. So below you will find some summary of biggest changes (from my point of view): Component base architecture  Decision on big changes in engine architecture aren't easy. I think that transition from class base approach which looked like that : class CGameObject class CModelObject : public CGameObject class CPuppetObject : public CModelObject class CChcaracterObject: public CPuppetObject  to component base ( like in Unity 3D ) was one of the biggest and most problematic changes that I done in White Rabbit Engine in last years. I needed to change a lot of code, don't break the game that I have and in the same time change my approach to resolving problems.  Level Editor : New com...

So another post under sign of programming. This time: placement new. So lets's look on this part of code :     ... if (techData.texturesCount[idx] > 0) {     tech->m_textures = new(memoryPtr) STextureSlot[tech->m_texturesCapacity];     memoryPtr += sizeof(STextureSlot) * tech->m_texturesCapacity; } else {     tech->m_textures = NULL; } ... It's a part of White Rabbit Engine materials creator. It's purpose is simple : allocate memory for material + techniques + textures slots. And use placement new to create objects. Everything so all materials data was put in continuous memory. Of course it's nice but there is one problem : this part of code is wrong. Everything look nice but placement new for arrays add additional data about array before objects. So   new(memoryPtr) STextureSlot[tech->m_texturesCapacity] use more memory than :   sizeof(STextureSlot) * tech->m_texturesCapacity; For me this m...

After "little" break lets return to topic. Last time we ended on system that was already split on two threads. This week we will focus how to change it so it work the way we wanted: So let's start from analyzing a little more situation on which we ended  in last part : This model look already pretty good and would be enough in some situation. We can use it in this way : Place marked as " Sync " mean time in which "Gather Data" wait till rendering finish using  rApi render list (buffer contain all information's need to render frame). As we see game can update in meantime of rendering. So everything should work faster than in one thread.

Really tough times came to project. To be precisely it's developed on really powerful netbook acer Aspire One 522. Right now I don't have access to my normal computer and this is only hardware that I have. But don't worry project didn't stop but only going a little slower. To show how much: on my PC project fully recompile in around 3 minutes on netbook the same thing take more than 20 minutes. The same problem is with loading of game which time also extended few times. So it's not easy but I use this time to speed up everything so I could normal work. It's going really nicely: Right now loading time decreased. In the same time performance increased. Everything mixed with stability changes which are done every time when there is occasion. Only problem right now is that game is in a little stagnation but I believe that in few nearest weeks this state should change.  I think that in next post I will return to multithreaded rendering topic. Right now...

So like always start with problem description: I have some pool of command represented as enumerator. Each of command can have unique data that size can be different. I wanted to create system that allow me in easy way iterate over them and execute.  After some time I created this implementation: template<ECommands::enum cmd> bool execCommandTemp(ECommands::ENUM a_cmd, void* a_data) { if (a_cmd == cmd) { SCommand<cmd>::execute((SCommand ::SData*)a_data); return false; } return execCommandTemp<(ECommands::ENUM)(cmd+1)>(a_cmd, a_data); } template<> bool execCommandTemp<ECommands::WRAP>(ECommands::ENUM a_cmd, void* a_data) { return true; } bool execCommand( ECommands::ENUM a_cmd, void* a_data ) { return execCommandTemp<(ECommands::ENUM)0>(a_cmd, a_data); } where SCommand look in example such a way: template <> st...

And another more technical post :] Today I had occasion to fix some functions in my rendering code. It was look somehow like this:  struct GPUBuffer {     uint32 openGLBufferId;     uint32 offset;     uint32 size; }; ... class CGraphicsManager {     ...     /** @brief Create geometry buffer. */     bool createBuffers( GPUBuffer* a_buffer,  uint32 a_sizeInBytes,  uint8* a_ptr,  bool a_dynamic);     /** @brief Flush memory of geometry buffer. */    void flushBuffer( const GPUBuffer& a_buffer,  uint32 a_offsetInBytes,  uint32 a_sizeInBytes, const uint8* a_ptr);              /** @brief Destroy geometry buffer. */     void destroyBuffers( GPUBuffer* a_buffer);     ... }; So nothing special but I seen here two inconsistency in code convention. First is that once I use ...

Last two weeks I had pretty busy so I hadn't too much time on working on project. Of course there was few days when I found time then I continued work on prototype of Gui Editor. From point of looking of final users it could be called useless because most functions don't work and this which works are in really raw state. But from my point of view there was big progress because I think that at last I found direction in which I want progress with it. And this mean a lot for me because till now I didn't had any concept how editor will work and how I want work with it. Of course I always try to make things so they could be later extend without bigger problems so here was another challenge. Right now I think that I got some raw concept that will evolve in another nice tool and only time will show if I'm not mistaken. Till the next post.