Update 62

After finishing to colorized a map I have realized that the map was only a small part of a bigger drawing. And I need to color everything because  the big view is also used in the game for another map.

It takes a lot of hours to colors 1920*1080 picture with lots of small things, so the tree is not finished. There are so many leaves, I am trying to have the same texture but with a pencil.


I have a bigger picture than this, so it’s easy to see the leaves but also time-consuming.

I have also retried emscripten to see if the library has progressed.

So I want to import Jpeg I have to port libjpeg and modify SDL2_image, I have already spent two weeks on SDL and Emscripten to find out the library is not yet mature.

I have changed libraries so I do not use SDL_images, I directly load the image with SDL_gpu which use stbi_image for the loading. The compilation of SDL_gpu is complete. After a small display test, it’s working fine with OpenGL ES2. I can port the game with emscripten now but there is a major downside compared to pixijs.

There are two alternatives for how files are packaged: preloading and embedding. Embedding puts the specified files inside the generated JavaScript, while preloading packages the files separately. Embedding files is much less efficient than preloading and should only be used when packaging small numbers of small files.

So the best way is to preload right? I have 60mb of resources files for the demo, so preloading seem not very efficient the person will wait maybe 10 min and it will take a lot of memory. With pixijs I can load on the fly the textures in OpenGL without having the preload all the files. There is a way to load async data with emscripten : emscripten_async_wget. So I have to change the loading system of the game to use emscripten functions, the point of emscripten is to port the c++ game without having to redo a lot of work. I have ported the demo for pixijs so I know what it means to change most of the things to make it work. The code with pixijs is cleaner because the code is already in javascript.

Note : Use emscripten when you can preload the data without having to pay a big price. If not use port the game in javascript with a good library.

Update 61

I have finished the program to launch batch jobs. Now I can compress efficiently png files with BatchGUI, for now, I can compress files with this simple script :

<?xml version="1.0" encoding="utf-8"?>
	<prog out="$FILE$-new.png" exe="TruePNG" arg="/out $OUT$ /o max $IN$">

		<prog out="$FILE$.png" exe="zopflipng" arg="-y -m --filters=01234mepb --lossy_transparent $IN$ $OUT$">

			<prog out="$FILE$.png" exe="deflopt" arg="$IN$" />


This job consist of compressing the images with three command lines images optimizers :

Img -> TruePNG -> zoflipng -> deflopt -> Img compressed

You can replace the tool with something else and also generate multiple outputs for one input.

The interface is very simple, you load an XML script and then you drag and drop the image you want to add.

BatchGUI screenshot

I am still working on the art of the level 4, more trees, more colors and maybe shaders.

Update 60

I am drawing another tree for the level 4, after that, I need to color one character and one background.

I have an old bug everywhere in the game with the sprites sheet, every object is bonded to another object in the sprite with no margin.


But when the images of the door are displayed at lower resolutions we can see a small vertical line belonging to the other object in the sprite sheet. This is due to the round error OpenGL do when reducing the size of the object. The solution is to add a small margin of 2 pixels each side of the object.

In this image, the margin is white because I converted the image to JPEG to improve loading time, in the original margin are transparent.


After doing all the generation of the sprite sheet for the first level, I have big PNG files and I need to compress them but most of the software out there to compress images files are in command lines and not multithreaded. And the GUI programs do not let enough options and are built around one optimizer. For the moment I use PNGGauntlet, I am building a small flexible program with Qt that can use any of the command line optimizers where the user can specify the options in an XML config file.

Update 59

There is a lot of small things to do in the level 4, I am also adding maps because even if there is a lot of things to do, a lot of it is very easy. It’s time to make thing more challenging at least for some parts.

I was also thinking about maybe adding small cutscenes in the games. But how do you do that with SDL? I need a codec library to decode the video, something like FFmpeg but smaller, I only need to read one type of video. TheoraPlay seems nice for that, and there is an example using SDL. Wait a minute, the example only works for SDL 1.2? After spending some time with replacing old functions with new ones and using SDL_Texture instead of SDL_Surface, I came up with something working : Play video with SDL2 

In the game, I use SDL_gpu to render the display, so SDL_Renderer and SDL_Texture  need to be replaced with SDL_gpu stuff like GPU_Target and GPU_Image. But something is quite problematic : no YUV support well I don’t have a choice so I am trying with RGB.

The good new is TheoraPlay can decode these format :

/* NTSC colorspace, planar YCrCb 4:2:0 */
/* NTSC colorspace, planar YCbCr 4:2:0 */
/* 24 bits packed pixel RGB */

/* 32 bits packed pixel RGBA (full alpha). */

RGB is good enough for the test, how do I update the pixels, there is no SDL_LockTexture and SDL_UnlockTexture for SDL_gpu. But there is GPU_UpdateImageBytes which do the work. I can update all the pixels at the same time with RGB. With YUV there is 3 planes to update, multiple calls to memcpy are necessary :

SDL_LockTexture(texture, NULL, &pixels, &pitch);
const int w = video->width;
const int h = video->height;
const Uint8 *y = (const Uint8 *)video->pixels;
const Uint8 *u = y + (w * h);
const Uint8 *v = u + ((w / 2) * (h / 2));
Uint8 *dst = (Uint8*)pixels;
int i;

for (i = 0; i < h; i++, y += w, dst += pitch) {
	memcpy(dst, y, w);

for (i = 0; i < h / 2; i++,	u += w / 2, dst += pitch / 2) {
	memcpy(dst, u, w / 2);

for (i = 0; i < h / 2; i++,	v += w / 2,	dst += pitch / 2) {
	memcpy(dst, v, w / 2);


With RGB and SDL_gpu I can update everything with one call :

GPU_UpdateImageBytes(texture, NULL, video->pixels, video->width * texture->bytes_per_pixel);

Update 58

The level 4 is progressing rapidly most of the dialogs are done, the big trees take a lot of time to draw and space so I will only add a few I think to not have a map with too many details.


My computer was starting to have too many problems (keyboard screen, power cable) and is still under warranties so I decided to send it to a repair center, during this time I use another PC for the development, it’s slower to compile the game simply because this one doesn’t have an SSD and has only 3 Go of RAM instead of 16 Go (yes this is a 32 bits) and an old graphics card. Sometimes photoshop run out of memory with only 3 images opened x). The game only needs OpenGL 3 and something like 128 MB VRAM.