[BUG][ALL] Terrain image is drawn with wrong alpha blending setting.

[namida]

Both the player and the editor show different (and both incorrect) results when terrain has semitransparent pixels. Editor does for objects too, I suspect player does but haven't tested.

The player applies the alpha channel correctly when merging the terrain image layer with other layers to form the final output image; but it's applied incorrectly on the terrain layer itself. (IE: Try placing one piece with some semitransparent pixels, on top of another piece which may or may not have semitransparent pixels. Look at result. Most noticable if the level has a background.)

The editor appears to treat any pixel that isn't completely transparent, as if it had no transparency at all.

For the player, the fix should be as simple as changing [Terrain TBitmap32].DrawMode and [TBitmap32].CombineMode to suitable values. - dmBlend and cmMerge, IIRC. Might be cmBlend. Possibly worth adding an option to disable this for weaker PCs. Not sure about the editor.

(On a side note for the player, I believe it's currently hardcoded to treat any pixel that isn't fully transparent as solid. This may need to be changed, to something like perhaps >50% transparency = solid; with any pixels that end up non-solid being erased - ideally, this should happen based on the final terrain map, not each individual piece.)

[Nepster]

Yes, the editor treats all non-transparent pixels as fully solid and does not apply any blending. I don't think I will change this as long as there are so very few pieces which have semi-transparent pixels.

Regarding the NeoLemmix player:
1) I don't think we need to worry about the performance of creating the terrain layer. This is only done once at the beginning of the level, so it won't slow down the actual game-play.
2) Regarding how to treat semi-transparent pixels in the final terrain image: I would go even as far as erasing every pixel with transparency < 50% and setting all other pixels to fully solid (i.e. alpha=255). Terrain is after all the only layer where it is important to see every single pixel, so I wouldn't want to blur it against the background, etc.

[nin10doadict]

I kinda wondered how the game would handle this, honestly. I figured it could be messy, so I specifically tried to design my tileset pieces so they wouldn't have semi-transparent pixels. Seems like if people keep doing that then this won't really be an issue, but it's still good that it's been noticed if it does come up later.

[namida]

1) I don't think we need to worry about the performance of creating the terrain layer. This is only done once at the beginning of the level, so it won't slow down the actual game-play.

Very good point.

2) Regarding how to treat semi-transparent pixels in the final terrain image: I would go even as far as erasing every pixel with transparency < 50% and setting all other pixels to fully solid (i.e. alpha=255). Terrain is after all the only layer where it is important to see every single pixel, so I wouldn't want to blur it against the background, etc.

This may be acceptable. I definitely agree re: erase any that end up non-solid, whatever cutoff point may be chosen for that. However, I don't know how I feel about setting a=255 for everything else. It might be workable, but I'd want to see it in action before outright saying I approve. And let's not forget - the primary purpose would be, of course, for better-looking levels graphically. We don't need to worry about the normal terrain layer being perfectly clear visually; we have clear physics mode for that exact reason - to allow artistic terrain design while also allowing people to see the functional aspects of the level, without putting restrictions on the artistic side of things.

Alpha blending is something that can be implemented very easily, aside from having to make a decision on the cutoff point to treat as solid vs nonsolid (and I will stress - I absolutely think this should be calculated from the final terrain layer image, not each individual piece). If I remember correctly, NeoLemmix *already* has code to implement a cutoff point; it's just that the cutoff point is currently set as "anything nonzero is solid". All that's needed is a few tweaks when drawing the terrain layer, so that semitransparent pixels blend rather than overwrite - and as mentioned above, this is a pretty simple change thanks to how GR32 handles blending. It would not require any changes to in-game physics, just a few tweaks to the initial terrain layer and physics map rendering.

I don't think I will change this as long as there are so very few pieces which have semi-transparent pixels.

This is a catch-22. There are few (if any) pieces which have semi-transparent pixels because NeoLemmix does not properly support them (and has never claimed to do so - all file formats since the single-DAT-file graphic sets have had support, but at no point has NeoLemmix itself claimed to actually support them functionality-wise). You can't say "I'll add support for something that isn't currently supported once people start using it", because they aren't going to start using it if it isn't supported. Rather, the answer should be either "yes, let's implement this"; or "no, this will never happen". Or, a possible third option - "I'm open to it, but I first want to see how much interest there is in using such a feature". I don't know about editor-side, but game-side this is already partially implemented anyway, and the remainder of the implementation could likely be done in about a dozen lines of code, if that - however, it does raise questions about how certain aspects of physics would function, in particular where partially-transparent steel pixels (or partially-transparent pixels on the top of steel) are involved. So, I could definitely understand the logic behind a decision of "don't support it" due to these complex edge-cases (which would pretty much need to be decided arbitrarily), but I do feel that a solid answer should be given on that matter.