Sunday, April 20, 2014

Few words about remake

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 components system.
Right now transition going nicely and I'm happy with achieved results but if somebody ask me: if I would decide to do it again. I would need to think twice before answering.

New game GUI system

Old GUI system shown in previous presentation was only some base prototype. It was hard to use, hard to extend and didn't allow on creating anything very efficient. But it worked so at that point it was enough. 

But at some point the change was needed and it happened. Following ideology that GUI should be something that is easy to use and have quick iteration speed new system was created. This time with dedicated editor. 

GUI Editor : Opened L.B.A. in game menu.
For me system itself is some kind of experiment. It's base on a little bit weird approach that when you thinking about GUI but we will see how it will end. From my experience with it (till now): I like it. But how it will end in long term I don't know. We will see.

Development speed

White Rabbit Engine is gathering all my experience and ideas about how quick and efficient development of game should look. It's possible because I works on tools that I develop which is sometimes surprising/terrifying experience. 

Level Editor: Prison level
So because of that I developed one rule to deal with it. If something irritate me: it need to be changed. I follow this rule in code and tools. Sometimes this changes take one day, sometimes week but I see that in long term all of them allow me to increase speed of development. Which is good.


So a lot happened in last few months but this is only beginning. I work really hard on game and technology behind it. It's not easy. Project growing and right now contain : 
  • 605 header files (*.h)
  • 484 source file (*.cpp)
We need to add to this all other things : plugins, scripts, models, textures, icons and few other things I don't complain that I don't have anything to do. But still I try really hard to finish public pre-alpha build on time.

So to next post.

Saturday, February 22, 2014

True remake

And once again I will use one of your comments as topic for post (I will try to keep it short because I'm in meantime of work on project).
LBA is arguably the best game created. A true remake of this game, therefore, would not be easy. Keep up the great work!
I really agree that LBA have some unique charm which you can love all your live. Because of that I'm almost sure that I will fail in recreating it for you. Probably you wonder why I said it that way ?

Answer is easy, each of as like different aspect of the game. I know what I liked about it and few other people that described their thoughts in comments. But I don't know what you liked the most. That's why what I will serve you will be only my interpretation how this remake should look. Some of you will probably like it other will hate it. I'm prepare on that, such a life.

But I want to believe that after I will release tech demo there will be really allot of people that will share their thoughts about it. They will tell me what they like and what don't. Allowing me to change it the way it will be the real remake of game that they like so much.

Sunday, December 29, 2013

New year coming ..

.. and so some news related to L.B.A. Remake and I think it's something good. This last few months were I would said pretty tough. A lot thing changed in this time I changed my job and with it place where I currently live but there are things that never change. One of them is my family other are friends and the last one is that I never stopped doing L. B. A. remake :] 

So once again : project is still alive. But this time I have some proof for that :] 

This may look not too much at first sight but truth is that behind a lot of things changed and changed on better. But better solutions came with price: doing them consumed more than two months of work. This is a lot of time at last for me.

But this time is behind me and from now one there should be only better. In the fact effects of the changes that I mention before are still visible and not everything work the way it should but each day stabilize everything and even make some things work a lot better.

So you are probably wondering what will happen next :] and here small announcement : I plan in next few months prepare playable version of game (You can call it like you want: prealpha or techdemo). It will contain only prison map and it purpose will be collecting support from people about game play, mechanics, stability and performance. Everybody will be able to help in future development of project because there will be open access to this version. 

For me it will be first really big test because I need to finish a lot of things and create some others that still don't exist. In the same time I know that the version of game will be far from finished but this release should help me in making it the way every L.B.A. fan want it to go.

So till next post.

Wednesday, December 11, 2013

Small surprise

Today when I was looking on my blog control panel I find out something surprising. On Frédérick Raynal website: 
in Little Big Adventure section I found out link to my blog. For some people this probably not mean to much but for me it's really something (I wasn't expecting this). Things like that really help a lot in tough moments of development.

I will also add in this place that project is still alive :] I only don't have any proof for it right now. But as history of blog shows this is not first and probably not last situation like that. In most cases this long time of silence is due to my programmer nature. I try to focus on game development itself rather than trying showing each week stuffs that not necessary are made because of need. Good thing about this is that after break I try to return with new stuffs that should show that this time of waiting was worth it.

So till next post folks.

Sunday, November 3, 2013

Tech talks: placement new

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;
    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 mistake ended long looking for place where I override memory and knowledge about two things:
  • placement new for arrays add this additional data. 
  • it's really nice to have memory guards. But it's even nicer when you check on deleting if it wasn't override :]

Till next post.

Saturday, October 26, 2013

Multithreaded rendering (Part 3)

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.

Wednesday, October 9, 2013

Tough times ...

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 system in engine is really stable and only things that left to do are some polishing of code. So I can finish this article as somebody who wrote fully working system.

So till next post.

Friday, September 27, 2013

Reply to comment

Today I get really interesting comment to Preview 12 from Renkin Hayato. It so interesting that I will respond to it here.
"What do you think about make a team to construct the game? Remake a great game like LBA alone it's kinda suicide! There are very small details that you can forget and i know, do something like this is very wearing and take a lot of time. I hope the project goes forward, unlike other projects remake that were made just to make stupid videos ten thousand years ago!I'm waiting for that since 2009, and i nearly lost the hope of some news about LBA, that stoped to be mentioned at this time."
Question from begin I will leave on a little later :] But about rest you are right. I really know what it's mean to make some good remake it really isn't easy job. Sometimes I even fell little like masochist because my expectation about results are really high. It's event worse because I work in Professional Game Dev as programmer.

But this fact have also really positive aspects: knowledge of techniques, tools and trick that are really handy in development. That thanks to them project is so far in development but in the same time I know that it is on early stage. Why so? Because technology on which it is created still miss a lot to be fully usable.

Great example could be here this projects you mentioned or many indie games. Most people that know about gamedev know that it is easy to create some initial effects: rendering of models, some animations or base mechanics. At this point some people show really nice stuff with all this shaders, particles, models and things like that. But it's still not game it's only some presentation.

This project take different approach which isn't ease. There is created a lot of technology: editor, tools, plugins which are then use to create game. There is no so much pressure to make something to show i.e. in this months shaders were only changed when there was so bug in them (I use glsl and on some cards some construction works on other don't). But in the same time there was really a lot of changes that should influence performance and speed of development.

Right now there stand really big task in front of project : future development. It came to me when I gave access to code repository for one of my good friend. He wrote something like this: I knew that it was big project but never thought that it would be so huge. And it's not that I want do everything alone. Till now I had few proposition for cooperation on project. In most cases everything ended really quickly mostly because I'm looking for people that have skills or real desire to make this project. Of course I found some (or they found me) but it's not easy task. And I think that this is answer for your question.

And to be clear: This project is open on any kind of proposition of help. If your skill aren't enough I can help develop it with knowledge that I have. I have only one request: Think at last twice if you really want to do it because

  •  Time I will spend on all talks about cooperation I could spend on game development.
  •  Work with me can be sometimes hard because I want this project to be on high level.
  •  I sometimes may not have enough time (I'm busy man).

If you want to do it after reading this then ... wait at last the week. And if after this time you still have will to do it contact with me. I will welcome you in development team. If you don't think you have enough strength for this you still can help in a lot of different ways:

  •  Comment this project.
  •  Do some artworks or even concepts.
  •  Share information about this project.

Everything this really help me a lot. Thanks to them I found new strength to continue this project even if it is like Renkin Hayato named it: "kinda suicide".

Wednesday, September 25, 2013

Query commands execution

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)
            return false;
        return execCommandTemp<(ECommands::ENUM)(cmd+1)>(a_cmd, a_data);
    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 <> struct SCommand<ECommands::BUILD_SHADERPROGRAM>
        struct SData
            CShaderProgram*    program;
        static ECommands::ENUM cmdType() { return ECommands::BUILD_SHADERPROGRAM; }
        static void execute( SData* a_data )
So why to bother with templates when you can use simple switch :
  • Adding new command is very simple create new enum and it's SCommand implementation.
  • If you forget about any function it will return error in meantime of compilation.
  • You can create very similar function to i.e return size of SCommand::SData
For some people this may be not enough for me it's really good solution because thanks to it adding new command will be quicker and my implementation will be validated in meantime of compilation.

Tuesday, September 3, 2013

Multithreaded rendering (Part 2)

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 was moved on separate thread. This step was easy other wasn't. There is of course possibility to move [game update] to other threads and left rendering the way it is on main thread. I didn't decide on this mostly because I hadn't any idea on solution which don't have a lot of objects synchronizations (gameplay <-> rendering). And I wanted to avoid it because it connects with big number of critical sections which aren't help later in debugging of code.