Angelus blog

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...

So I'm still waiting for starting of my new job in Unity Technologies so I have some spare time. I use it to see Copenhagen, drink coffee, meet new people and of course as always: coding.  This time in my coding journey I try to figure out reason behind my slow reaction time of editor. My windows machine handed everything perfectly fine but my a lot slower laptop with Linux gave terrible results :/ How bad? I tried to rotate scene and there was few second delay between action and reaction So really bad. There was no choice but to fix it. 

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...

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...

Variable Set Editor - Main view Continuation of previous post :] this time with real examples :D Real tools design  This may look like joke but this one window took me ~3 days to do. This include all it's features and communication: Editor Engine. But this is reality. Creating good tools require time and I wasn't joking in  Summary  from previous post: "As you can see creating of good tools is not easy. You often need go back and forth to create something really useful. You don't want to modify everything by scripts in which you can make easily mistake. Good tool will for sure save you a lot of work and return effort that you spend on it." 

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.

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.

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...

So in last post on this topic I described a very general look about what is happening inside threads and show some problems that I found in meantime of prototyping. This time we will look a little more on solution that is use in White Rabbit Engine. And few things here: Starting from this post I will change a little convention of naming rendering Api. I will use name OpenGL  in situation when problem will be 100% connected to it (i.e. extensions, bugs etc.) for everything else I will use rApi so text be a little more general. I don't claim that this solution is something really innovative and I will surprise you with it. I still work on this system and there is really big probably that some part of it will somehow change in future. So after this short intro let's move to main topic. As was mentioned earlier engine slowly switched from single thread solution to multiple. Initial loop looked something like that: First thing that changed was [ IO update ] that wa...

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 ...

This time more technical but I think it's really interesting stuff for some of you :] More than week ago I created new branch on my git repository containing code for "multithreaded rendering". Problem like this are never easy and in my case I needed to deal with OpenGL. And for this who don't know OpenGL is state machine and because of this isn't parallel friendly. All creation of resources, uploads of data, rendering and releasing of it need to be done on the same thread where context were created. So you see a lot of restriction which complicate already not easy problem. Personaly I thought about solution of it from some time already but couldn't found any that would fit my needs. In most cases there were problems how nicely fit it into my architecture, how to deal with synchronization and few other stuff. But not so long ago I found at last way to deal with it and of course didn't started to code it In last few years I learned that if we have an...

As title say a little brief what was happening in this last few weeks. First part was really nice I took two week of break for vacation and was traveling a lot. Thanks to that I meet interesting peoples and I believe that in future there will be a loot of occasion to meet again. Of course this was only begin because after that I started to finalizing some big changes that will happen for me in near future. I will write about them them at some other occasion. After this short and boring part lets move on some more interesting topics: what changed  :]  *** I started work on some few bigger elements. Not all of them were directly connected with game but I would call them "made for fun" i.e:  LBA Remake on Oculus Rift It was funny experience but in the same time it pushed my tech a little forward. Mostly because it need this specific way of rendering and also oculus is optional device of multiple purpose (it control parameters of 3D rendering and in the sa...

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.

Here come another info from progresses. I spend a little more time in this weeks on development. One of the reason is weather (it's really hot in Poland) second is that I played and finished new Tomb Raider. But don't worry everything is still going forward.  And I still do some fixes and changes in technology. A lot of them is could be put in box with label "re-factoring of s2d". S2d was original name of my engine (there still could be find some places in code where I have it in comments)and I try to do some cleanup in code that was write around that time. It's not nice job but must be done earlier or later. I prefer do it now because I will not have to think about later. Other thing is I returned to making some assets. Below you can find some early wip of new location. Right now it's mostly placeholders that I use to check size and feel of location. So that's all for this post till the next one.

Ok, this time two weeks breaks so a little longer than normal. But somehow I were lost in my work and forgot to write some post last week :] Yesterday I finished doing initial implementation of memory manager. Thanks to it engine have another powerful tool to help me in development. Why I moved for this two week on some more engine related stuff? Because good engine is not only rendering, input, audio like some people may think. Of course this is enough to do some small game but in case of bigger projects things start to be more complicated and because of that we need a lot more technical stuff that make our lives as developer easier. It's influence may not be so visible in game as new full screen effect like Motion Blur or Depth Of Field but they are still there. They help us tracing our bugs, making development easier and in the same quicker. Of course creating them take a lot of time so some people don't decide on creating them but in bigger perspective it's almos...

Not so long   ago I was though about how the code gains its own "experience" over time, You could also refer to this process as „leveling up” mechanics featured in most of RPG games. At first this may sound irrational , but I believe that it's a very common phenomenon and most developers, experienced it at last once during their programming adventure (of course I cannot be sure). It is possible to go even further, and compare code writing to a RPG game character building and its developement. Your code when you design it is simple, have functionality that you know that are need or you think that they will be need. It's is like creating characters in some RPG games you decide on gender, class, look and some basics parameters. In this point we programmers decide about path that we want to follow with this piece of code and this decision will influence everything later. Of course hardly ever first decisions are 100% correct. With gaining experience we learn ho...