[SUG][PLAYER] Don't delete pixels from high-res tiles

[Proxima]

I would like to add high-res graphics to proxima_tile, which is after all my "flagship" tileset in the same way that willlem_lemminas is WillLem's.

The biggest problem with doing so is the spheres:



(Left: the high-res tile as seen in NL. Right: the actual tile, pasted in with GIMP.)

As I understand it, NL deletes pixels where the low-res graphic has an empty pixel. I understand the argument for doing this -- that it makes the physics clearer -- but choosing high-res is in any case a decision to prioritise appearance over physics (look at the lower-right of the sphere; you cannot tell exactly which pixels are solid at all), and the player always has the option of turning on clear physics mode if they need to check the precise physics for any reason.

I want my high-res tiles to look hi-res rather than having the janky, pixellated edge seen in the above screenshot.

[namida]

Let's suppose the user places a destructive skill, such that it removes all the physics-solid pixels but does not touch one of these "physics non-solid high res" pixels.

If we are okay with that random midair pixel remaining there - this is an easy change. But personally, I don't know that I am okay with this. There is a difference between "not completely clear about physics" vs "outright misleading about physics".

If not - this is going to need significant changes to how visual erasing of terrain is handled, in order to handle this kind of edge case.

[Simon]

Hmm. Consider to re-interpolate the hi-res filler pixels whenever a nearby lo-res pixel is built/bashed.

It will be an elaborate feature, sprouting through many layers of the program. But it will design the misleading visual debris out of existence. Hi-res will work like a graphical scaler for pixel art.

Hi-res is a rabbit hole, there is no 100 % right answer.

-- Simon

[WillLem]

It seems that there are three ways of looking at this:

1) Lix is Lix; it's smooth and soapy. NeoLemmix is NeoLemmix; it has pixelly charm (even in high-res). Maybe it would be OK if it stayed that way.

2) NeoLemmix is all about custom-content, and players should be able to create graphic sets for it knowing that the platform will do their work justice. If there is a way to integrate the smooth & soapy stuff whilst keeping physics clear and non-misleading, maybe it's worth it.

3) An alternative way of looking at it that isn't 1) or 2)

[Proxima]

If we are okay with that random midair pixel remaining there - this is an easy change. But personally, I don't know that I am okay with this. There is a difference between "not completely clear about physics" vs "outright misleading about physics".

If not - this is going to need significant changes to how visual erasing of terrain is handled, in order to handle this kind of edge case.

That's a very good point. For my part, I am completely okay with "phantom" high-res pixels being left over, and accept that as a necessary drawback if that lets me have my spheres

It would be ideal if phantom pixels could be erased, but I don't see it as essential if that would be too hard to code. Maybe a rule such as "erase high-res pixels with no corresponding low-res pixel, if there is at most 1 orthogonally adjacent low-res pixel" ... that would seem to cover it, although maybe there is yet another edge case I haven't thought of

[namida]

Maybe a rule such as "erase high-res pixels with no corresponding low-res pixel, if there is at most 1 orthogonally adjacent low-res pixel" ... that would seem to cover it, although maybe there is yet another edge case I haven't thought of

I had been thinking of applying a "corner" rule. Basically - assume we have a setup like this, with each letter representing a low-res (physics) pixel.

ABC
DEF
GHI

We'll further divide the high-res (visual) pixels of E up as follows:

12
34

In this example, we would erase visual pixel 1, if all four physics pixels A, B, D and E are nonsolid. Likewise, for visual pixel 2, it'd be based on physics pixels B, C, E and F. And so on.

Perhaps we want to disregard A and C, and only look at B/D/E and B/E/F respectively. I'm not sure, I think I'd have to try out both to decide.

It must be seperate from the upscaler itself. High-res graphics can either be provided by styles, or automatically generated by the upscaler. The latter is nominally a fallback, but in practice over 95% of styles (including all of my own) still rely on it, and I don't expect this to change, nor am I pushing for it to.

I'll note that the upscaler does not produce this pixelly cutoff; it happens during the rendering of the level's terrain map. In particular, you'll note this cutoff only occurs on physics-non-solid pixels, and that these pixels will still be visible in cases where the terrain piece overlaps another terrain piece.

[Dullstar]

I don't use high-res mode, so I wanted to see how stuff like slopes and destruction masks are currently handled. Here is a screenshot of high-res mode with a miner tunnel and some sloped terrain pieces present, using the built in upscaling functionality.

The miner tunnel appears particularly blocky, probably still matching the physics pixels exactly. However, this isn't entirely consistent with how the slopes are drawn - you can see a few areas on the sand and on the decorative slope pieces where the pixels shown don't align perfectly with the physics pixels, though I believe in all these instances it's a corner missing out of a low-res pixel.



(link to full size image)