GSoC 2017: Sludge Engine Week 5

Week task conclusion

Generally, this 5th week of GSoC project was going smoothly: The z-Buffer zone (multi-layer effect) has been reproduced and fall back detection has been added

Again, thanks to my mentors _sev(Eugene Sandulenko), t0by(Tobia Tesan) and all scummvm team members that has helped me on z-Buffer during this week.

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

Tasks completed:

z-BufferZone : load z-Buffer sprites + reproduce multi-layer effects fall back detection for sludge games

 

To resolve later:

There is a segmentation fault when Robin’s Rescue starts. It may result from the game logo reading in the initilization, which is not implemented yet

What’s for next week: Bug fixes in Robin’s Rescue

Tasks for next week :

Fix the segmentation error in Robin’s Rescue Clear all bugs in Robin’s Rescue

Also, the first GSoc evaluation will take place next week.

Some findings about sludge

z-Buffer Zone

In sludge, z-Buffer zones are different areas of a scene which can obscure character graphics, such as foreground silhouettes, doorframes and furniture. Their display has been ordered by a y-value to create different image layers (up to 16).

The above room image has the following z-buffer image (3 layers) :

  

And characters will change the image layer it lies in, when its own y-value changes. To reproduce this effect in scummvm, we used an array of 16 Lists for different layers.

GSoC 2017: Sludge Engine Week 4

Week task conclusion

Generally, this 3rd week of GSoC project was good: the input works and we are able to reallly “play” the game. Bugs are cleared for the game demo Verb Coins now and there are only z-Buffer stuff left to get it fully work.

Again, thanks to my mentors _sev(Eugene Sandulenko), t0by(Tobia Tesan) and all scummvm team members that has helped me on input and bug fixes during this week.

   

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

Tasks completed:

game input freeze/unfreeze scene Add character interaction object inventory = dark screen effect + paste image to background

To resolve later:

When setting opacity for transparent surface blitting, we need to modify the second parameter of TS_ARGB() instead of the first one, which is strange. Related line

What’s for next week: z-Buffer Image & new game

Tasks for next week :

Get Z-Buffer up: it is used for different areas of a scene which can obscure character graphics, such as foreground silhouettes, doorframes and furniture. Add game fallback detection Add game Robin’s rescue and test

Some findings about sludge

Sludge input

Sludge input is using common sdl input functions

Freeze and unfreeze game scene

In sludge, whenever a dialog, reaction menu is popped up, the scene get frozen. The principle is that they make a screenshot of every thing on the background and copy interactive elements to a temporary variable and set them to null. Then, when we unfreeze, we restore them all.

GSoC 2017: Sludge Engine Week 3

Week task conclusion

Generally, this 3rd week of GSoC project was good: milestone 1 is completed as we are able to display texts and play sounds(wav, ogg) now, although not all sound system works because of the need of implementing advanced module file decoders for XM, IT, S3M formats, which is not a small task at all. So we decided to leave it for later.

Again, thanks to my mentors _sev(Eugene Sandulenko), t0by(Tobia Tesan) and all scummvm team members that has helped me on texts and sounds during this week.

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

Tasks completed:

Display texts in sludge Play wav/ogg sounds Loop wav/ogg sounds Loop a wav/ogg sound list

And :

Some platform specific code removed, code compiles on all platforms now Replace sludge color conversion functions by scummvm PixelFormat functions

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

XM, IT, S3M decoders replace utf8 functions by common/ustr.cpp

 

A minor problem that may not have much effect:

The way I implement “loop sound list’ doesn’t give the exactly same result for the particular case that several same sounds loop together at different time intervals. But I guess it’s something we’ll never really do in games.

What’s for next week: Cursor & Input

In order to have a playable game, we will move to input stuff next week :

Get cursor displayed Replace sludge input event by scummvm ones, all of which are well covered

Some findings about sludge

How texts work

Every font is represented by a series of sprites for characters. Every sprite includes 2 parts:

• the black background that gives a black border for texts: so all texts in sludge have black borders
• a white overlay image, whose colors can be changed by shaders. This effect can be reproduced by changing input parameters of scummvm blit funtion

How audios work

There are 5 sound formats supported by sludge: .WAV, .OGG and .XM, .IT, .S3M. Every sound is played by a call in the game script:

• playSound(…) for WAV and OGG
• startMusic(…) for module sound formats : .XM, .IT, .S3M

We also have the possibility to loop a list of sounds in sludge, which is done by building a circled linked list beforehand and at the end-of-stream callback function, “the next sound” in the linked list is played.

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:

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

And :

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

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

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) 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 :

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:

Get texts displayed (Graphics::FontManager and Font) 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 :

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:

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)