Flash news.. I'm very busy at work 8)

I could work less, but I want to produce something good. I like the idea to take a more general approach to problems and make something bigger out of it.

One of my current goals is to develop in a scalable manner. In order to do that, things need to be rethought in a more generic form.
For example one can have a triangular mesh, or could develop a system to do a remeshing to turn the original geometry into a semi-regular data structure that can easily be compressed and streamed progressively.

I think that scalability is really a key to the much needed productivity improvement in game development.

At work we talk every day about how to go about some solution, and there the key question is always: "can we use a scalable and generic solution ?".
This is usually about development pipeline.. not about actual code. The idea of code reusability is less straightforward. I actually aim more at providing simple implementations, to modularize code so that it can easily be grabbed without too many dependencies.. rather than trying to fit all in a supposed grand scheme of hierarchy of objects and whatnot.

In the end the harder problems are really those about how to organize data and how to transform those data across the development pipeline.

On the side, I also used OpenMP for the first time. After a few odd results, I managed to parallelize a loop that uncompresses images in that progressive-JPEG-like format that I've been working on.
Like for JPEG, the image is processed by 8x8 sub-blocks. Using OpenMP pragmas I set the parallel section to happen on rows of blocks.
Parallelizing every row of blocks makes sense, but I could probably try to do multiple rows at once to see if I can reduce overhead of context switching and potential cache trashing. Parellelizing every block instead turned out to be overkill.
As a rule of thumb, if I think that I could wrap some code into a function with practically no overhead, then perhaps I can make parallel section out of it. In fact, I think that OpenMP eventually grabs that section and makes a function out of it anyway...

Aside from some early decoding artifacts due to my inability to share some variables from outside the "parallel for" (see the example at the bottom here), using OpenMP was really easy. Definitely much simpler than manually creating and reusing threads, also less involved than using Threading Building Blocks because one doesn't need to create functor objects and also because OpenMP is readily available with modern compilers with minimal effort.

cool
zzzzzzzzzz

In Japan the fiscal year starts in April. Newly graduated students start officially working on the 1st. Contracts are renewed or not renewed on the 1st. People go picnic under blossoming cherry trees in parks (花見, hanami).

A few things have changed in my company. I can't say about others publicly, but personally I still work there, which is nice 8)
I was offered to become a full-time employee, but other than the prestige of receiving the offer, if I had accepted I would have taken the pay cut on the first year !
The way it works is that when one becomes a full-time employee, he or she gets less monthly salary but overall more by way of 2 yearly bonuses.
However the bonus starts counting from January, while job positions change in April. So, one ends up with a lower salary to be compensated by a first-year-crippled bonus (!)
So, I signed (actually, stamped) another yearly contract and I'm looking forward to get some good work done.

I've been already working pretty long hours. Generally over 10 hours per day, towards 12, 14, sometimes more.
I wasn't specifically asked to, but I've been doing some interesting stuff and I like to hurry up at first to get to a point where I'm comfortable. Basically, I want to get good tangible results fast, so that the project picks momentum with the coworkers on board.
This is all the more true as a team leader, because I'm responsible for setting the groundwork for other people to work as smoothly as possible.. (basically trying to keep people happy with their tasks 8).
Most people mood about things can turn on a dime. Sometimes there are internal power struggles. Sometimes power struggles are out in th wild, sometimes are half concealed and fermenting in the background.
As criticism came form lack of sharing of information, I proposed daily morning meetings. Conceptually, 5 minutes standing meetings.
Though one can and will definitely sit, and sit for more than 5 minutes, the idea is to routinely update each other every morning. This beats longer more formal weekly meetings as much happens in a week and by the time one has to report, a lot gets forgotten. Generally it's just hard to get good feedback once per week.
Ideally people would work along and consult each other frequently during the day, but not everyone works with everybody else and it's nice to get a light update on things every day.
Also, because the meeting is meant to be brief and informal, one doesn't have to stick around and go too much in deep about other people's work (possibly the principal component of boredom in meetings).

Let's get busy !!!

P.S. I guess we're using a Agile software development practice without knowing it explicitly 8) ..but frequent updates are really just common sense (and I must have heard about stand-up meetings somewhere already).