Showing posts from 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

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.

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; } 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 mistake ended long looking for pla

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.

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

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 thi

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

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 wa

Inconsistency naming convention

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 pointers and in other occasions references I didn't thought a lot about this and changed everything on pointer. This was something natural to do for me but here

Multithreaded rendering

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

A little break

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 same t

Gui editor

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.

S2d return ...

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.

Lost in code

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

Source code experience

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

Story about cold coffee ...

Another week of hard work behind me. As you can seem, there are done some changes in blog and a lot of others changes planned. Of course I didn't forgot about development of game. Right now I thinking about direction that I should choose. It's important moment because it will decide about next few months. So I decide to mostly focus on bug fixing and finishing topics that are on my "to do" lists that lie next to my cold coffee. And it's pretty funny to look at it :] not only because there is a lot of finished tasks. But because it's story about how I create my game. Some pages have some coffee mark because I sometimes put my cup on it. On others you can find some quick notes, calculations and weird pictures that describe ideas that came to me in meantime of doing somethings. As you can see some my notes are maybe a little chaotic but this just like myself and that's why I like them so much. Till next week.

Preview 13

After so long time here it come LBA preview 13. So as you can see I try very hard to keep my promise about more frequently updates. But what Is going on: LBA was added to "indie crashe" so if you want this project to get more attention please vote on it here: There is not too much time but I gotten info that LBA remake participating there very late. In game itself I do a lot of work on AI behaviors and try create this fully playable prison with all the details and events. There is still a lot to do but it's worth it mostly because I think about releasing something like "alpha techdemo" where you will be able to play this first location and give me some feedback what could be done better or what will not work. Other thing that I done this week were work on my pipeline to create assets. I done a lot of improvement in this mater one of it was plugin "verbose"

Pirate Crystal's released

I contacted with people from Pirate Cristal's team (with this that I had contact to) and after talk we decided to release game. I'm not 100% sure if this is the final version but it's only I have on my disk so there is no big choice. I think that game is pretty polished but there is small exception: English translation is done today thanks to google translator. I didn't even read them only do them quick and recover installer script (it's still taken me few hours). So text in English version can be weird and to tell truth I'm not feel enough confident in my linguistic skills to do it correct. So if anybody want help and do some normal translation PL->EN or do correction of English version I'm open on proposition and can help with explanation how to do it. So after this short explanation I present you:  Pirate Cristal's Download

Progress update

This time still without any movie but not without anything :] In this moment I spend a lot of time on development so sorry for this long silence. So short what is happened with game in this long time: Animation system changed so it's use was a lot easier in use and effects were better. So moment of playing sounds of steps, action on hits and shooting is a lot better synchronized with animations.  Done support of 3D sounds so everything started to live. Added multiple lights support. Nice water effect. Worked on AI for enemies and they behaviors. Falling from heights have nice effects. Game support multiple CPU (Moved on multithreaded code). A lot of fixes so everything was stable and work nice. Thanks to GIT history I can say that from last post about development in 29 november 2012 I done: Uploaded 144 revision with only code (I often upload change list with multiple things in them). Modified 7577 files. Changed 121890 lines (without files I added and remo

Funny thing.

It's a funny thing when you do cleanup in your old code and find comments like this: /** @brief particle emitter (interface) */ class WRE_API CConfigScript {....} Of course class CConfigScript is use to parse any kinds of config files not only particles emitter:]