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)
        {
            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 <> struct SCommand<ECommands::BUILD_SHADERPROGRAM>
    {
        struct SData
        {
            CShaderProgram*    program;
        };
 
        static ECommands::ENUM cmdType() { return ECommands::BUILD_SHADERPROGRAM; }
 
        static void execute( SData* a_data )
        {
            a_data->program->build();
        }
    }; 
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.