GSoC Week 2

GSoC 2017: Sludge Engine Week 2

Week task conclusion

In general, the second week of GSoC project was quite good: all goals achieved one day in advance, though the work was not as easy as the first week. Again, a huge thank you to my mentors _sev(Eugene Sandulenko), t0by(Tobia Tesan) and all scummvm team members that has helped me on graphics during this week.

To make a brief conclusion about what we have and have not achieved for this week :

Tasks completed:

  1. Get backdrop (background) reading and displaying work
  2. Get the sprite system up based on 1
  3. Get spritebank up to have animations and display transparent sprites

And :

  1. The segmentation fault caused by animation nullptr has been fixed
  2. scummvm can compile on windows

For later (They don’t have much effects for now):

  1. There are shaders used in graphics in scummvm waiting to be rewritten (normally we rewrite it by figuring out what they do and reproducing the same effects by c++ code)
  2. OOPifying the code should be something coming quite soon, as we still work with global variables now and it begins getting complicated. Maybe for next week or the week after if time permits

Some problems left to be solved :

  1. The code don’t compile for Mac yet

What’s for next week: Text & Sound

There is still some work before getting all sludge graphic features up, but I reckon that’s enough for now and we will add them later when we need. What we will move on to next week are:

  1. Get texts displayed (Graphics::FontManager and Font)
  2. Play sound (Audio classes)

And this makes the first game demo “Welcome” work completely. And we can see dialogues for “Verb coin”.

Problems encountered during week 2

As in this week, I was stuck several times with different problems (solved thanks to help from mentors and scummvm team members), I think it’s good to talk about them.

1. Graphics format

First of all, we need to determine which graphic format is used in Sludge to initGraphics.

As a result of lacking basic graphic knowledge, I was wrong about the graphic format because of the existence of palette structure in Sludge, which is actually used for transferring 256-color image (8-bit image) to 32-bit image.

There is a number of way to see the graphic format, for example:

In the graphic initialization code of the engine, there will be clues like :

1
if (SDL_SetVideoMode(realWinWidth, realWinHeight, 32, videoflags) == 0) {

The input parameter 32 shows that sludge is using 32 bit images.

Besides, if we can have access to specific image byte loading code like:

1
2
3
4
5
target = snapshotTexture + 4 * picWidth * y + x * 4;
target[0] = (byte)redValue(c);
target[1] = (byte)greenValue(c);
target[2] = (byte)blueValue(c);
target[3] = (byte)255;

We can clearly see that they are reading at an offset of 4 bytes, which also means that sludge uses 32-bit images.

Another funny mistake that I made during image loading is that I got wrong with PixelFormat and mixed up the channels, which gives an image like:

which actually is

Just scrutinize the bit shift code of PixelFormat, there will be a clue.

2. Sprite loading error

Another interesting problem is that I got distorted sprites at first when I tried to load them. We can see that all bytes of the sprites have been correctly read but to the wrong place. Normally, there is a sprite dimension error for such problems. It’s strongly suggested to log the sprite width and length of the image loading procedure to see if everything goes well.

In my case, sprites’ width and length were modified halfway by some improper manipulation.

3. Sprite flickering

I also met a sprite flickering problem due to multiple updateScreen() calls.

The entire screen is in practice updated when updateScreen() is called, so if there is image flicker then you’re presumably not producing the same frame consistently.

For instance, multiple updateScreen() calls are made for an actual frame, and some of those overwrite something that’s been previously rendered, then that could generate such errors, since you’re effectively producing as many frames as you have calls to updateScreen().

Some findings about sludge

  1. Graphics format used in Sludge is true color (32 bpp)
  2. Character animation is saved as a series of sprites and a looping sound
  3. Sludge has 3 versions of sprite image (version 0, 1,2 saved as 8-bit image, version 3 as png)