eKommune 2012

Monday September 24th and Tuesday 25th over 300 souls - mostly IT personell, a pinch of sales people and a handful of municipal top leaders - met in Trondheim for the annual eKommune conferance. There was a great variation of talks, as might be expected. Most notable was possibly a mismatch between the view of central government and local administration about what needs to be done to optimize IT spending in the public sector.

Municipal CTOs agreed across the board that there needs to be architectural and protocol standards to facilitate integration, intermunicipal cooperation and municipality-to-state reporting. To achive this, we need action from central government. This is in tune with my article series about consulting in the public sector.

Central government, on the other hand, were afraid to touch anything that might reduce local self governance. One claim was that the differences between municipalities may be too great.


I got to chat with the CTO of a much larger municipality (withholding name to protect the CTO), and learned that we were technically not that different. In fact, we shared the same major challenge, which is a political challenge, rather than a technical challenge: How non-IT public workers - the very ones that we support - view IT and how methods of accounting IT costs obscure the big picture within the organization.

Indeed, I have had the same chat with the CTO of a large private company, who experiences the same organizational issues. It makes me wonder if we have ourselves to blame, in that we really are technologists, not politicians. Our message gets lost in our willful haste to get things done.

Games coding

A friend, whom I usually consider well educated in IT, came with a rather unexpected comment the other day. "I would like to know how to write games." What, any programmer can do that - albeit, there are many genres of games and therefore the required arts will depend greatly on the type of game you wish to create. However, if you're looking for a place to begin, here's the basic skeleton:

while(game_is_running){
controls();
physics();
render();
sync();
}

Each of the looped stages above will be greatly different from game to game. From the beginning of time, I can no recall any game that is not a combination of object oriented and map oriented - that is, the method you use to keep track of each element in your game is picked for CPU efficiency. You want to use the least amount of processing power possible.

Typically, the user and aliens are considered objects, though environment may be a map or object oriented. Controls() include receiving user input to manipulate the user object as well as any artificial intelligence you may need for computer generated players. In MUDs (broad sense), this may also include receiving updated data about another player.

Physics() should theoretically be the same in every game, except it's not. Is it a 2D or 3D game? Do we need gravity? Do we need gravity between objects? Object collition detection? Does anyone die? Is there acceleration going on, or are things moving at linear speed?

Render() should really be the same for every game of the same kind. In a 3D world, the world should render the same way at all times. It is common to create a rendering engine that is reused in every game from the same company. Except, of course, the technology changes and the rendering engine must follow suit. And when technology doesn't change, the programmer may still find things to do in a more clever way.

Sync() is possibly the simplest stage: The three previous stages will take different amounts of CPU time for every frame of the game. In order to get a smooth game, one must wait until the next "tick" of the clock - whether it is every 50th of a second, 30th, 20th or 15th of a second. Or even every second.

Within each of the stages above, the details become a science of its own. It's not tough, though, you just need to break it down to bit sized chunks.

Image zooming

A friend of mine posed the following problem to solve for his VB-in-Excel application:

In a view of 846 x 660, an image is rendered. By clicking anywhere on the image, zoom is multiplied by 1.2. However, and this is the important part, the part of the image clicked on shall remain the center of the zoom and remain in place of the part of the view clicked - i.e. directly below the mouse.

Since I'm not a VB-coder, my reply is in C-like quasi code.

Input data


To solve the problem, we need to be absolutely clear about what the input data is, which in turn is dependent on the source of the data. We start off with the follwing information:

// STATIC DATA
int imageWidth, imageHeight;              // Size of source image
int viewWidth=846, viewHeight=660; // Size of onscreen view 

// VARIABLE DATA
// Position of view/sliders on the projected (zoomed) image
int scrollX, scrollY;
// Size of projected (zoomed) view/sliders
int scrollWidth, scrollHeight;
// Bar/slider size represents the view compared to projected image
int barWidth=viewWidth, barHeight=viewHeight;
float zoom=1; // Current zoom

Then you have the mouse click. We need to know two things from the click: Visually where in the view you clicked (viewX,viewY where top left of view is 0,0), and what position this represents in the image (imgX,imgY). The image coordinates can be calculated from viewX,viewY this way:

int imgX=(viewX+scrollX)*zoom, imgY=(viewY+scrollY)*zoom;

However, in my friend's case, the input data had the entire zoomed image as its reference, so top left of entire zoomed image represents 0,0 and bottom right (with sliders also bottom right) represents scrollWidth,scrollHeight. Hence, the parameter representing the clicked position (clickX,clickY) is the position in the view (viewX,viewY) PLUS the position of the slider bar (scrollX,scrollY).

Since we need to know the actual visual position on screen, relative to the top left corner of the view, the two coordinates must be calculated as such:

// Position unzoomed to fit zoom=1
imgX=clickX/zoom; imgY=clickY/zoom;

// Pos. shifted to visual position
viewX=clickX-scrollX; viewY=clickY-scrollY;

User control

New zoom is calculated per policy defined by my friend - basically:

int zoomstep=1.2;
if(leftClick)zoom=zoom*zoomstep;
else if(rightClick)zoom=zoom/zoomstep; 

Calculating new scroll bars


We now know the new zoom and want to render the view with (imgX,imgY) located where the mouse is on screen (viewX,viewY). First step is to tell the scroll bar control what the new sizes are:

// Size of projected image changed with zoom
scrollWidth=imageWidth*zoom; scrollHeight=imageHeight*zoom;

// Size of bar/slider doesn't really change unless you change size of view
barWidth=viewWidth; barHeight=viewHeight;

If we set scrollX to imgX*zoom (image coordinate projected to new zoom level), our point ends up in top left corner of the view. However, we want this point at viewX,viewY, so we must offset the X-coordinate to the left, i.e. subtract the viewX,viewY coordinate:

scrollX=(imgX*zoom)-viewX; scrollY=(imgY*zoom)-viewY;

Edge adjustment

Unless we want to scroll off edge, we may need to adjust:

if(scrollX<0)scrollX=0;
  else if(scrollX+viewWidth>scrollWidth)scrollX=scrollWidth-viewWidth;
if(scrollY<0)scrollY=0;
  else if(scrollY+viewHeight>scrollHeight)scrollY=scrollHeight-viewHeight;

Rendering

If you need to render the image manually, the typical approach is to find the source rectangle within the image and project it to the full view.

int left=scrollX/zoom, top=scrollY/zoom;  // Reduce position to zoom=1
int right=(scrollX+viewWidth)/zoom, bottom=(scrollY+viewHeight)/zoom;

Then complete the operation using StretchBlt (if in a Windows development environment) to stretch-copy the rectangle from the source image to your new view context.

Other

Feel free to ask for further calculations or other parameters in the comments. If the above code fails, it may be that you have other input parameters or need to calculate some other numbers than what this article has attempted to convey.