Smooth is not working since port to SDL2

[DominusExult]

Just running smooth in a folder with rough.bmp and smooth.conf (from mapedit/tools/smooth) should output the same file as mapedit/tools/smooth/smoothed.bmp.
Since our port to SDL2 it outputs the error
ERROR: UNKNOWN pixel format

With smooth's debug enabled (smooth -d 4) I get this output

Reading from rough.bmp
The image file uses 6 colours
ERROR: Unknown pixel format

hinting that the error happens in https://github.com/exult/exult/blob/master/mapedit/tools/smooth/image.c#L61.

[DominusExult]

The last semi working smooth was included in the 1.6 SDL 1.2 release of the tools (dated 17.04.2020) - the SDL2 1.6 release was already not working.

[wench]

I have no idea about anything in regards to that program but to my eyes it is probably an easy fix. I can see what the problem is, it tries to create an RGB surface with only 8 bits with bits per channel not specified. That isn't going to work. It is obvious from looking at the code it should be creating a paletted surface not rgb, If I knew what this program was supposed to do I would fix it

[DominusExult]

The most verbose description of smooth is at https://exult.info/forum/viewtopic.php?t=14942

Its aim is to "smooth" a map picture for the tool mockup so that mockup produces a better U7 map. Problem is that mockup is only accepting 8bit source files (bmp or png). So if that is no longer possible with SDL2 theen smooth has maybe reached its end of life.
Running smooth with the current config (smooth.conf) should alter

to

(both files are as bitmaps in smooth's folder).
But due to another bug #517 that is even not working atm.

[DominusExult]

-	if ((g_variables.image_out = SDL_CreateRGBSurfaceFrom(
+	if ((g_variables.image_out = SDL_CreateSurfaceFrom(
 				 g_statics.image_in->pixels, g_statics.image_in->w,
 				 g_statics.image_in->h, g_statics.image_in->pitch,
-				 g_statics.image_in->format->BitsPerPixel, 0, 0, 0, 0))
+				 SDL_GetPixelFormatEnumForMasks(
+						 g_statics.image_in->format->bits_per_pixel, 0, 0, 0,
+						 0)))

Something like what @Dragon-Baroque did for the SDL3 port might work (only needs to use the right SDL functions in SDL2). I'll give it a try tomorrow.

[Dragon-Baroque]

Something like what @Dragon-Baroque did for the SDL3 port might work (only needs to use the right SDL functions in SDL2).

Perhaps you should first try the SDL 3 variants of mockup and smooth. They build, I think, but whether they work I have no idea.

[Dragon-Baroque]

Kind of progress report.

I made mockup work again in SDL 3 against the map.png. It failed because that SDL 3 reports a 256 colors palette even though only 5 colors are used and the rest are ffffff thus non translatable.
However mockup does not work on rough.bmp in the smooth directory, because SDL 3 reports 4 bits per pixel, not 8.
It works on smoothed.bmp since SDL 3 reports 8 bits per pixel.

[Dragon-Baroque]

I have published a new branch exult-sdl3-smooth-mockup in my Git fork Dragon-Baroque/exult.
I consists of a single commit above exult-sdl3, and it

• Fixes the lack of support of paletted images of bit depth below 8 in smooth and mockup,
• Removes an invalid free in smooth,
• Provides a Makefile for smooth and for mockup, with the all, tests and clean targets.

smooth and mockup depend on SDL 3 and SDL_image 3, they compile using gcc and run on Linux.

Now, mockup produces a u7map of the right size, how do I check that it has the right content ?

smooth produces a smoothed.bmp of the right size, but different in colors from the historic smoothed.bmp in the Git tree. May I admit that the randomize plugin produced different colors, or should I worry that smooth is not working properly ?

[DominusExult]

Awesome!

"Quick" way to test the map mockup produces:
Replace or add it as an additional map in a game and then write the minimap (F3 cheat map) via Shift-F3.
This minimap should look very similar to the bmp you used to create the map. That's my theory at least 🤷‍♂️
I may have time to test this tomorrow

[Dragon-Baroque]

Well, the down port to SDL 2 was easy.

So I have another new branch exult-smooth-mockup ( without the -sdl3 ).

You may prefer to test on the SDL 2 variant...

[DominusExult]

Thank you, this seems to work. When you convert the rough.bmp it is missing the green outline that the bundled smoothed.bmp has but this could be a missing setting (for the smooth plugin?) in the config.
I was then successful in converting the smoothed.bmp to a map via mockup. Using this as an extra map was almost without problems (there was a crash once because of a missing ifix file).

<- that's the generated cheat map.

I think this (SDL2 version) is good to be merged into main.

[Dragon-Baroque]

When you convert the rough.bmp it is missing the green outline that the bundled smoothed.bmp has but this could be a missing setting (for the smooth plugin ?) in the config.

It was. I have added what I believe was the missing line in smooth.conf and expanded some explanations in it.

If you have tested smooth and mockup on macOS, I suppose you have used make CC=clang or whatever you need to pass to identify the XCode compiler. I have added a tiny hint to that effect into smooth/INSTALL, perhaps you would like to expand it.

smooth is rather strange, for it uses char[7] strings to exchange the Hex RGB colors with the plugins. smooth and mockup came in full as commits 0b1069d and d25c9cd back in 2004. Is there any kind of history in SourceForge for these two tools, prior to the move to GitHub ?
Considering that we use at least 32 bits and now mostly 64 bits CPUs that can both encompass a 24 bits RGB, this looks to me as outdated. I shall have a look into this.

I think this (SDL2 version) is good to be merged into main.

Thanks. That was my intention, and I intend to merge the changes because of SDL 3 into the exult-sdl3 branch.

[Dragon-Baroque]

Considering that we use at least 32 bits and now mostly 64 bits CPUs that can both encompass a 24 bits RGB, this looks to me as outdated. I shall have a look into this.

Handled with Uint32 instead. But then handle also the use of a * trigger - for any color - in the Smooth and the Stream plugins.

This is PR #520, which should close the issue #517 too.

[DominusExult]

Is there any kind of history in SourceForge for these two tools, prior to the move to GitHub ?

I think before that it was a private project of @AurelienMarchand and lived in the French translation of SI for a while. There is mostly this post in our forum about both tools https://exult.info/forum/viewtopic.php?t=14942

Looking forward to try it out more :)

[Dragon-Baroque]

There are three plugins to smooth.

Randomize and Stream are sampled by the smooth.conf and the smoothed.bmp.
There is a small discrepancy between what Aurélien stated in the forum and how the Stream plugin works, in that the first in the series of the sixteen colors is supposed to replace the source colour when no trigger object is found around it. Not so, the colour is unchanged instead Sorry my comment is wrong.

The plugin Smooth derives from Stream but does things more subtle and not documented. I figured that it handles the cases where the trigger color is looked for first vertically or horizontally then diagonally in the immediate neighborhood of the source color. There is a quite mysterious formula in the horizontal / vertical search

unsigned int calc_value = lround(1 + (2.4 * a) + (-2.1 * b) + (1.1 * c) + (3.1 * d) + 0.5);

supposed to return an integer from 0 to 8 when a to d are 0 or 1 values that record the presence of a trigger color in the four vertical or horizontal directions near the source color. 6 triggers the diagonal search, the others are indexes into the replacement colors.