Hi everyone!
Time for this weeks A&O report.

As indicated by last weeks objectives, I've started reducing the Fixed Function Pipeline (FFP) code,
which became obsolete with GL2 and finally deprecated with GL3/GLES2.

In particular I refactored pretty much all of the matrix related code.
So for me it was just doing some applied linear algebra that week.

OpenGL1 had a so called Matrix stack functioning like this:

glPushMatrix:
Backs up the current matrix.
Most GL implementations don't provide pusing more than 16 times, however Hedgewars required only one time.

glPopMatrix:
Restores the most recently pushed matrix.

glLoadIdentity:
Sets the current matrix to identity (1)

glScale, glTranslate, glRotate, glOrtho2d, (gl utility funcs gluPerspective gluOrtho):
Multiply the current matrix with specific matrices thus chaining the mapping.

These functions allowed for easy chaining of transformations like:
glRotate(), glTranslate(), glScale() would first rotate the object around its center
then move it along the rotated coordinate system and then scale the object.

As already stated this functionality became completley stripped at some point.
So I either had to emulate existing functionality with an own matrix stack and replacement versions of all the above functions, or I could explicitly calculate matrices
as needed.
The later option was quite a nice way to go, as Hedgewars first of all just uses 2d transforms
and futhermore all of them were composed like "translate rotate translate".

Thus replacing the reoccuring pattern of:
glPushMatrix() glTranslate(x, y, 0) glRotate(angle, 0, 0, 1); glTranslate(s, t, 0); glPopMatrix();

with:
m = calculate(x, y, angle, s, t); glLoadMatrix(m);

was a quite straight way to go, as opposed to use full blown matrix multiplications.

To keep the impact of the changeset low I decided to not have some god-function as calculate() above,
but provided utility funcs that semantically m

Weekly A&O report Hi everyone! I'm back with a new weekly A&O, trying you to illustrate what changed since last week. As planned, I refactored the encoding of sprites. But imagages probably tell more than words:

The image to the right shows the old encoding sprites had. TTexture described a sprite/texture as a single, shared entity defined by it's width (s.w) and height (s.h), together with the actual image data of the sprite (the rect portion within the black rect). However due to hardware restrictions the actual texture might need to be of a certain size and thus to be larger.

The new encoding splits TTexture to two independant entities. A sprite now stores information about its size and references to physical image by storing a link to it and a position where the sprite is located.

This encoding allows to pack multiple sprites (red rects) into a shared image (black rect). Doing so may reduce the amount of unused empty space as well as the total count of black rects. Graphics hardware generally benefits from both.

Right now however each sprite (red rect) will be created together with a unique texture (black rect) and stored in the lowever left of it, mimicing exactly the original behaviour. The next step on this frontier obviously will be taking the rectangle packer and allocate multiple sprites within shared textures.

Before doing this step however, I'll continue with removing as much deprecated OpenGL1.x as possible and probably write some GL2 renderer.

Weekly A&O report

Hi everyone!
This is the very first of my weekly "Achievements and Objects", which will give you some ideas on what I've done so far and what i've planned for the next week.

Achievements

The first big piece of work that I already finished - actually I have done this during GSoC application period - is the rectangle packer.

The general problem is to fit a set of given small rectangles inside a larger rectangle which shall be as small as possible. The reason for wanting this is that graphics hardware prefers working with a single or few large textures over hundreds of small ones.
Unfortunateley there are no known algorithms that solve this problem perfect within feasable time.
Thats why some algorithm that doesnt necesarrily produce perfect results but at least "quite good" results is required.

In particular I've ported the MAXRECTS packer using the bssf heuristic as described here:
More Rectangle Bin Packing
This page contains quite a lot of in depth information about the general problem and as well visualizes different approaches.

The packers are licensed as public domain and thus the port is safe to be used for hedgewars.

You can take a look at my port here uBinPacker.pas.
As well try the test app test.pas

Last week I pretty much started messing around with the games code base.
Currently in the engine a sprite is represented like this: (ommiting irrelevant members)


TTexture = record
w, h: LongInt;
rx, ry: GLfloat;
vb, tb: array [0..3] of TVertex2f;
end;


w and h represent the physical dimension of the sprite in pixels.

The goal of the project is to port the game to web browsers so that people can enjoy it without installing and it runs on all platforms with a modern browser. Furthermore, web is the future and there will be more and more games that are web compatible. I'm proud that I can be one of the pioneers to try some new things and know how to get it to work.

Since the technology is not mature enough, there are a lot of problems that I can or cannot foresee. The project is not to "hardcode" the game using javascript but rather find a clever way to convert the game engine automatically, which facilitates update and generally is aimed to develop a workflow or framework to automate the conversion process. Pascal and javascript are two different languages; native and web are two different platforms; these differences in terms of language specification and API compatibilities makes the conversion challenging and is basically the problem my project is going to solve.

My proposal divides the project into three phases:
(1) Port run-time library functions that pascal uses into C, which can be converted into javascript using empscripten.
(2) Port SDL functions into C or javascript if needed.
(3) Port the OpenGL code into Web GL.

Phase 1 and phase 2 are pretty much project independent, i.e. I don't need to depend on others' work much. However, I still need to dig into existing tools like empscripten and pas2c to see how smart they are. Phase 3 depends on the optimized rendering system since WolfgangSt is going to rewrite it to make it ES 2.0 compatible, and without the migration, I cannot do the conversion either. Finally I will integrate all things together. If everything works neatly, then it is time to write a web front-end and invite people to play it!

I feel very lucky since I have an awesome mentor nemo who always gives me great help and inspires me a lot. Here I'd like to give my sincere thanks to him and all mentors in advance. And good luck to all participants!

Greetings to all!

My name is Szabolcs Orbán, also known as belphegorr on IRC, I come from Romania (Transylvania more specifically) and I am one of the students who got a chance to work on the game.

I will be working on a new campaign for Hedgewars. At the moment, the only options for a player eager to play against the computer offline are quick game and some (training) missions. What I will try to achieve are introducing support for interrelated missions (campaigns) and creating an introductory campaign that would also teach newcomers how to play.

A result of my work would be that performance/decisions made on a mission will be able to affect the behavior of future levels, thus allowing the creation of somewhat more complex stories, with multiple endings, surprises and nigh infinite drama!

I'd like to thanks the developers for giving me the chance to improve the game and mikade for mentoring my work! I'd also like to apologize in advance to all the mentors I will be bugging as I chew my way through the source code!