Sunday, March 1, 2020

Hobby or Work

Interesting topic for a post came recently to my mind when one of my friends commented on me taking a day off from work to relax as:
"Anyway, you will wake up that day and work."
This was, of course, comment on me developing LBA remake in my free time. What is interesting about it I'm not fully sure what to think about it. Because how what I doing in my free time is different than other people's hobbies? On another hand how it is different than what I do in a work?

What is a hobby?

All of this thinking brought me to this simple question on which I don't have really a definite answer. In the end, what is a hobby for one person can be a work for others. There is a lot of examples of that: 
riding a bike, skateboarding, painting, drawing, writing stories, creating graphics, woodworking, restoration of items, fixing electronics, traveling, singing, dancing and even stuff like cosplay. 

All of that and a lot more can be a hobby but at the same time, it can be a work. So where is the boundary that separates these two states of a mind? Let's select two of the examples and focus on them more. My not random choice will be woodworking and dancing


Woodworking can be not only a job but also a hobby, if you don't believe check youtube there is a lot of hobbyist youtube channels that do awesome stuff. Another personal example is my dad that also do it for fun in his free time. What is interesting about this example is the wording we use regards it:

"Woodworking skills"
"Working in wood"
"Working with wood"
"Tools for woodworking"
"Woodworking equipment"

All of them talking about working, skills, equipment, and tools. I don't want to enter here some specialized naming of techniques and tools but I think you see mine point.


Just like woodworking, we know dancing can be a hobby but at the same time it can be a work. That is why we have all these professional competitions, dancing schools and so on. Just like in the previous example let's find some wording that comes to my mind regards it: 

"Dancing skills."
"Dancing moves."  
"Dancing choreography."
"Dancing styles"

I had a really hard time to come with some examples here. I can write a lot about dancing about feeling regards it but not a lot of these short more technical sentences. So let's try some other example:


Not everybody travels as a hobby for a lot of people this is part of their work. Where they go to different places and meet people they need to meet for business reasons. Like in the previous two cases lets think about wording that comes to my mind:

"Travel destination"
"Traveling guide"
"Traveling equipment"
"Meeting new people"
"Seeing new places"

This was a lot easier than Dancing so the choice was right.


While writing these examples I found that I myself am very biased in regard to how I feel about them. Look that in case of woodworking I was from start pointing out that this can be a hobby while in the other two cases I was pointing opposite proving that they are not only a hobby.

Then came the wording and this proves the same thing. In the woodworking case, the first things that came to my mind contained "work", "tools", "skills", "equipment". Which is not so much truth in other examples. So even I am biased here. And I know that activities like woodworking can be a hobby.


With this, I can see how my friends seeing me, programming and developing a game in my free time as work and not a hobby. But it still hurts because for me I have a lot of fun doing it, learning new skills and seeing the result of my efforts (If you think that efforts sound weird here it is because I thought about using word "work" but I don't really want to use it here in this context).

If you think about it more as I struggle to convince others that what I do after work is a hobby there are also pepole that have a hard time convincing others that what they do is a work and not a hobby.

Now I'm curious if I overthinking stuff or not. What is your opinion about all of this? 

Tuesday, April 9, 2019


I recently were introducing friends to constexpr and I'm super surprise how inconsistently it works between different compilers. I will need to look more into my code to assure that its do what I want. 

Saturday, April 6, 2019

Clean design ...

I would love to say you a story how awesome my code designing skills are but with time I learned that I still have long way to go. Now we know what this story won't be about and focus on what we will be talking about: My recent issue and how I solved it.


The story taking place in one of many days when I was doing something for project. I was working on content an once again stumble upon problem with editing multiple terrain groups. I knew about it and delayed it already few times but this time it finally blocked me from further progress. This meant only one thing: fixing day arrived. 

"Cool" I thought and started checking what going wrong. Destiny wanted that in meantime of testing some irritating issue surfaced: I was not able to display in inspector properties of World Terrain System. I was trying to select it in hierarchy but only level properties were displayed. 

And this will be topic of my story: How I approached fixing this "trivial" thing.   

Stage 1: Investigation

There are two use cases to display properties inside the inspector: 

Color of nodes are important here because green nodes mean that selected object have EntityID and orange that it uses something different. Following this thought process I quickly checked which objects I could select and turned out that only levels and entities worked. This was some good lead.

In code this two system are supported differently: 

As you see the selecting of Level/Entity in hierarchy windows works different than selecting of systems. When you select the Level/Entity item, UI send SelectObjectEvent to back-end which update the selection. This operations triggers the  SelectionChangedEvent which then processed by UI update hierarchy windows and Inspector. Uff... this was intense but let's continue.

In case of selecting in the hierarchy, the information what properties should be displayed going directly to the inspector. This would be whole story ... except that when you select System/Level you inform back-end that you deselected all entities. As you probably figured out : I using SelectObjectEvent to do that :]

Stage 2: Explanation

We know what happening: 

Turned out that this whole problem was really simple.

Stage 3: Solution 

Finally we got to point where the title of post will be relevant. Figuring out of this particular issue wasn't supper complicated. Fixing it was a little bit different.

Everybody have their own way of handling bugs. I believe that you should always find real source of the issue. This will take more time, will be more challenging if you don't know/remember code you working and may result in bigger changes to fix it. But I still believe that it is worth it. 

In this specific example it is not only important how to fix the issue but also how to prevent more issues with inspector. My conclusion was that whole issue was created by me trying to be smart. I create system that reacted to any changes inside selection. This was done so I didn't miss any of them.

In the reality this turned out fatal. There was so much happening with selection that I missed few cases and lost control over overall system. If you look on graph of interactions between system from second stage it may look easy but it have a lot of this small cases that made whole system tricky to follow.

With this fix I switched to simpler version: 

  1. All interaction with hierarchy inform inspector directly what properties it should display. 
  2. Mouse picking of object from view port also can affect inspector as separate code path.
  3. Updating of selection is done by each operation separately.
I also left SelectionChangedEvent in case that other systems wanted to react on this event. All of this changes resulted in cleaner flow of data that is unified for each of its parts and this is what I can call clean design.

Monday, August 20, 2018

How the fate like to play with us (3rd generation of RTTI)

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: virtual members.

Concept was simple. In RTTI v2 declaration of members look like that:

        .setAlias("Mesh Resource")
        .bindSetCallback(&CMyRttiClass ::setResource)

And I wanted to do something like this:

        .setAlias("Mesh Resource")
        .bindSetCallback(&CMyRttiClass ::setResource)
RTTI_ATTRIB(VirtualMemberOfClass) .setAlias("VirtualMember") .setSerializers(WriteVirtualMember, ReadVirtualMember); RTTI_DECLARATION_END

VirtualMember is variable that don't exist in CMyRttiClass but you can specify custom reader/writer and everything will works like it is a member of the class. I tried  to add it for some time but there were some many issues and edge cases that I gave up because of time constrains. 

Now we are three years later and I already using 3rd generation of my RTTI system which looks like that:


I drop all the edition information from code and moved it to special definition file. Its describe how to display class in inspector. Example of class definition bellow:
    "m_name" : CStringID <"Alias": "Name">;
    "m_meshResource" : FilePath < "Alias": "Mesh Resource", "Filter":"#meshes#" >;
Advantages of this solution is:
  • Thanks to hot reloading I can change this filein run time
  • It created separation between code and edition (I going more and more into this direction).
  • Whole change simplified my RTTI code.
  • I need to manually modify this script when I modify code.
  • I needed to create pretty extensive validation and bug reporting for whole system.
RTTI v3 is in use for some time already and I'm somehow surprised how solid this concept hold. Only thing that I didn't expect from this change is that it will made virtual members concept possible. I can say even more it was pretty trivial to do.

That is why I mentioned that fate like to play with us. When I wanted to add virtual members I couldn't but when I stopped trying it just happened. Of course this is simplification and in practice this it result of all this years of changes. In the end don't think that this feature would be possible to achieve in other way.

Normally I probably wouldn't able to see how much I grow as a developer over the years but I'm one of this few who still work on the same code base after years. This allow me to see where I am, where I was and how naive I was when I was starting this project. Now I'm one step closer to its epic final...

Wednesday, February 7, 2018

Little -> Monster

Often when I do coding I asking myself how this small modification that I wanted to do converted into this monster that I working on ...  Good example is my recent decision to add regressions tests. I want to validating that I'm still able load some of the resources. 

Spoiler alert : I spend already few hours and still don't have this tests. 

Monday, June 5, 2017

Catching up

There is so much going on this year that I don’t have too much time to write posts. For this who don’t follow my other blog this is some summary of most important changes:
  • In February I started working for Unity Technologies.
  • Engine slowly transit to Physics Base Rendering (PBR).
  • I released new video with game progress.
  • Been at Unity HackWeek XII (I’m even on one of photos at blog, find me if you can :P)
  • Dropping kinematic character physics in game.

Now that I think about it each of this points could be separate post. But well there is no point in thinking about past and let’s focus on present and topics I work on in the same time:
  1. PBR transition.
  2. Physics changes.
  3. Game not working smooth.

PBR transition

This slow down a little bit because I try to read in free time recommended by friend moving frostbite to pbr. I start to see how much knowledge I missing to do it properly. There is all this sections about lights parameters that I never thought about, lenses configuration and so on.

Maybe you have some other good articles/presentations which explain this in details ? I personally missing some information how to put all this together :( there is so much sources explaining each step of pipeline but non really explain how to put all this together. If you have something like that I would love to hear about this :D

Summarizing: till I figure out all of this and finally define all masks I cannot really start work on game assets. So for now I don’t focusing on new content too much and adding mostly placeholder geometry

Physics changes

Changes in physics are always hard for me because I’m not feeling fully comfortable with whole code base. With each iteration I try to understand how things work internally but this is rather slow process. Problem is that most of stuff I do right now require this knowledge.

Currently my task is to switch from kinematic character physics to just RigidBody + Constraints. This is mostly because I noticed that I paying big price for supporting kinematic body (I spend a lot of time on it and also performance of it wasn’t good). So now I have already some work in progress of new system and slowly progress with more improvements.

Game not working smoothly

This is task I focusing the most and I found out already few different reasons behind it.
  • Wrong organized update loop.
  • Small issue with calculating elapsed time.
  • Issue with physics update.
All of them worked but there were this small issues which combining together gave this weird impression that game not running smoothly. Now I think everything look a lot better but I’m still investigating everything to achieve the best results.

So as you see I doing everything and nothing :/ This is frustrating because I would like to focus on game more but well slowly I will get there.  

Saturday, February 18, 2017

Good programmer ...

I don't know about you but after all this years that I'm into programming (18 year already) I'm still hesitate to call myself good programmer. I have some knowledge and experience but am I really good ? 

This question really often return when you look around in net. You founding another awesome looking project that somebody done. In my case is even worse because most of the time it's also done a lot quicker ( I'm 7 years stuck in the same project). Always then I feel a little bit down because there coming other questions like: what you done in all this time, what you achieved and are you really good.

I still don't have clear answer how to deal with this mood and thoughts. Do you have any ? If you have I'm really open to listen them.

So far I start to thinking that we are in time when a lot of people want to show of their skills and show how better they are than others. I'm sometimes have pity for them when they doing that.

Recently I was asked if one of my friend is better programmer than me and my answer was yes. And the more I think about it's great. By simple fact that I know that there are better people I know I have a lot of new possibilities in front of me. I still can be better than I'm right now.

So in the end who cares if I'm called good programmer. I'm just trying my best in programming and I think this is great because there is so much new interesting things to be discovered.


Wednesday, February 15, 2017

Editor disaster ... update

So I was digging a little bit more into my issue of TCP/IP on Linux and I found out about socket option:

One of description in given link is:
2. For this to be used effectively, applications must avoid doing small, logically related buffer writes. Because TCP_NODELAY is enabled, these small writes will make TCP send these multiple buffers as individual packets, which can result in poor overall performance. ...
In my case default behavior created delay because I was basing (probably stupidly) my whole system on fact that each message will be delivered as soon as possible.

This option switched everything to expected from me behavior. Of course I don't saying this is solution to all problems and probably introduce me some issues somewhere else.

I'm still feel like novice in serious network programming :/ But well as far as project go I'm really happy with all this improvements and knowledge that I gain in meantime of doing them.

But well time to return tracing bugs in my changes so I could push my code to repository before going sleep.


Monday, January 30, 2017

Editor disaster ...

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. 

Wednesday, January 25, 2017

Resource building

As you may notice I like to push my tech to it's limit. Because of that I recently decided to switch to a lot better way of building resources. I took my app that were containing everything and split it on 3 different one.
They run as separate processes which connect with each other using TCP/IP. Comparing to previous setup this solution have a lot of advantages and this is some of them:
  • If one node crash I can just restart it and run whole setup further.
  • Whole node setup is scalable so I can have 100 of nodes.
  • I can run nodes on different machines. 
  • I can dispatch new version of building nodes to different machines automatically.
  • I can build specialized Python nodes for some of work.
  • Application don't need to have all this shitty code of resource compilation.
  • Whole concept became a lot easier to control.
So as you can see there is a lot of improvement :) comparing to previous one.