[DISC.][PLAYER] High-res support

[WillLem]

I agree with IchoTolot that upscaling might look a bit odd... I think it might be simpler to make it so that if a user chooses high-res mode, they only have access to content that has high-res graphics created for it (and vice versa). This would encourage creators to provide custom graphics in both resolutions in order to reach maximum people.

That sounds like a bit of a content maintenance and user experience nightmare, to be honest. Users who select the high-res mode might be confused as to why some levels disappear when they select it, while content creators would have to either give up styles that lack high-res versions or pester people to change their graphics settings in order to play their levels. There's few enough original styles as it is anyway, as the vast majority of custom styles are game rips. Forcing people to provide two sets of graphics in order to avoid having their style cause issues with the player will exacerbate this problem as well as create bloated style downloads: high-res graphics necessarily significantly increase the size of the style, since now there's two copies of everything, but styles created in low-res may simply be upscaled to prevent the game from hiding levels from high-res users, resulting in a style that is at minimum twice (plus probably extra because the second copy has 4x the pixels) as big as it needs to be if the game could simply upscale the graphics itself.

Good point, well made. In that case, probably best to go with up/downscaling (as is Namida's preference anyway) - as mentioned in my post, I'm for whichever method is easiest for everyone.

[namida]

(nt)

[namida]

Getting better.

Objects are upscaled (they could theoretically be loaded from a file instead; the code's there, the graphic isn't). Everything else is currently just zoomed in to "fit" with the high-res objects. I'm not sure what the cause of the terrain glitch is near the top yet, but it's purely visual.

The upscaling is done at load-time, not run-time, so it doesn't impact performance compared to having a proper high-res graphic provided. So my focus for now, is to get everything working (just using the upscaler); once it's all working, then I'll start worrying about providing high-res graphics (most likely ripped from WinLemm or Mac).

[WillLem]

Getting better.

Objects are upscaled (they could theoretically be loaded from a file instead; the code's there, the graphic isn't). Everything else is currently just zoomed in to "fit" with the high-res objects. I'm not sure what the cause of the terrain glitch is near the top yet, but it's purely visual.

The upscaling is done at load-time, not run-time, so it doesn't impact performance compared to having a proper high-res graphic provided. So my focus for now, is to get everything working (just using the upscaler); once it's all working, then I'll start worrying about providing high-res graphics (most likely ripped from WinLemm or Mac).

Looking nice so far, glitches aside. What are you using to upscale?

[Proxima]

Once it's all working, then I'll start worrying about providing high-res graphics (most likely ripped from WinLemm or Mac).

I'm going to put in a vote for Mac. I grew up with that version, and the graphics look beautiful. Yes, there were slight problems with the high-res adaptation of the graphics (looking at you, Steel Mines of Kessel...) but I'm sure a few small tweaks could fix those

[namida]

Getting better.

Objects are upscaled (they could theoretically be loaded from a file instead; the code's there, the graphic isn't). Everything else is currently just zoomed in to "fit" with the high-res objects. I'm not sure what the cause of the terrain glitch is near the top yet, but it's purely visual.

The upscaling is done at load-time, not run-time, so it doesn't impact performance compared to having a proper high-res graphic provided. So my focus for now, is to get everything working (just using the upscaler); once it's all working, then I'll start worrying about providing high-res graphics (most likely ripped from WinLemm or Mac).

Looking nice so far, glitches aside. What are you using to upscale?

It's a custom algorithm, fairly similar (but not identical) to Super Eagle. It only looks at the horizontally / vertically adjacent pixels (not diagonal ones) and has a few edge cases that it has special handling for. I also don't consier it "finalized" yet, I might improve it further (especially with what it does in corners). It works very nicely for pixel art styles; it isn't very impressive on full-color art (like the LPIV onwards ones) and mostly just ends up producing something similar to nearest-neighbour on those.

Once it's all working, then I'll start worrying about providing high-res graphics (most likely ripped from WinLemm or Mac).

I'm going to put in a vote for Mac. I grew up with that version, and the graphics look beautiful. Yes, there were slight problems with the high-res adaptation of the graphics (looking at you, Steel Mines of Kessel...) but I'm sure a few small tweaks could fix those

After a quick Google for some screenshots, I'm inclined to agree here - provided we can rip the graphics from the Mac version, and there aren't too many places where tweaks are needed. Of course, NL will still be using low-res physics anyway, so the tweaks would be purely for visual clarity anyway.

[ccexplore]

provided we can rip the graphics from the Mac version

Um, hello, hi there!  That had already been done you know :

https://www.lemmingsforums.net/index.php?topic=1567.0 (Lemmings)
https://www.lemmingsforums.net/index.php?topic=4078.msg73863#msg73863 (ONML and Xmas Lemmings)

Granted, there may be some further tweaks to better fit with the format expected by NeoLemmix.  Please let me know what kind of file format (eg. BMP, PNG, etc.) is preferred, and how to handle background pixels, plus whatever else is appropriate (eg. any metadata that needs to be specified outside of the graphics files), and I can modify my existing rip program to make it spit out exactly what NeoLemmix needs.

I can also take on the task of having the program compare the ripped terrain graphics with NeoLemmix's existing low-resolution graphics, to detect potential physics discrepancies to correct.  You do need to tell me how you decide to map hi-res terrain pixels to lo-res physics terrain pixels.  Mac Lemmings' rule is that at least 3 out of 4 of the 2x2 hi-res pixels must be solid for the physics to count the corresponding lo-res pixels as solid.

(I estimate this to be maybe a 1-2 day task if I put my full attention to it.  Fortunately there are some holidays coming up so I should have some time available.)

[namida]

Having the graphics, in a form that distinguishes between "solid black" and "nonsolid" (which the posts in those linked topics suggest these rips achieve), is all that's really needed. I'll likely need to do some tidying up of them, but that's well within what I can manage (and I'm guessing 95%+ of it will be possible to automate).

There's no real "mapping high-res to low res" rule. NeoLemmix will use the low-res terrain graphics to generate the physics map, and the high-res terrain graphics to generate the visual map. Any low-res pixel (= 2x2 high res pixels) that are non solid would be erased. I'm still not sure what to do about the other way around (ie: low-res graphic says solid, but high-res pixels are transparent). It could still be useful to know, in practice, how often there's a discrepancy and where the discrepancies are, though.

[namida]

Getting better. Terrain is actually being drawn with the upscaled pieces now (not just drawn low-res then zoomed). Lemming sprites and all UI elements are still just zoomed - only terrain and objects are actually high-resolution. Also, I think I know what's causing the glitch now, although I still have to actually fix it. As with objects, the code is there to load high-res terrain graphics, I'm just not using that side of it at the moment (just using the upscaler while testing).

The gaps on the diagonal pole to the left are (I think!) an issue with the upscaler, not the high-res mode itself, and I need to investigate this and improve the algorithm.

EDIT: And, the terrain rendering glitch is fixed - which also in the process fixed the destructive skill glitch too!

Not shown: Clear physics mode, which is currently very glitchy in high-res mode.

[namida]

While still buggy in many regards, and missing some things (eg. lemming sprites are still low-res), high-res mode is now useable enough to actually play. :O

Here's a video of it in action: https://www.youtube.com/watch?v=ngR7SyyRC9w

I'd say this is well on track to indeed make it into V12.8.0.

[Dullstar]

From what I've seen of the high res graphics, I recall the Mac ones being a bit better. I've definitely criticized WinLemm's graphics as being too shiny, which gives everything a strange metallic feel. But perhaps offering both would be best, since I imagine many players will probably continue using Low Res mode anyway and then players who want the high-res can download their preferred variant.

Since physics is going to remain low-res in high-res mode, how will this look in clear physics mode? Will the terrain shapes visually show as low-res to accurately reflect physics?

[WillLem]

While still buggy in many regards, and missing some things (eg. lemming sprites are still low-res), high-res mode is now useable enough to actually play. :O

Here's a video of it in action: https://www.youtube.com/watch?v=ngR7SyyRC9w

I'd say this is well on track to indeed make it into V12.8.0.

Exciting stuff!

[namida]

But perhaps offering both would be best, since I imagine many players will probably continue using Low Res mode anyway and then players who want the high-res can download their preferred variant.

This has too much potential for confusion / compatibility issues IMO. I'd rather just settle on one (definitely leaning towards Mac so far) as the "official" high-res graphics for NL, and those who really feel strongly about using the other can make and share an unofficial user-side mod.

[namida]

Since physics is going to remain low-res in high-res mode, how will this look in clear physics mode? Will the terrain shapes visually show as low-res to accurately reflect physics?

Yes. The internal physics map is still low-resolution, and clear physics mode's graphics are generated using this rather than the visual terrain map.

However, lemming sprites / object graphics would remain in high-res when using clear physics mode (though the usual recoloring would apply). Attached screenshot demonstrates this for objects (lemming sprites are still lowres + zoom at the moment). The off-by-1-pixel on the trigger areas is a known issue. (EDIT: Turns out, it's actually the terrain that's off by 1 pixel; the trigger areas are spot-on.)

[namida]

I've taken a closer look at the Mac graphics, and noticed a few things:

1. Every graphic (a terrain piece, or a frame of an object / lemming animation) is a separate file. Annoying, but manageable.
2. The whitespace (or rather, blackspace) on the bottom and right of every piece - but not the top or left - is culled. This is probably the easiest issue to deal with.
3. No matter what rule is used to translate 2x2 high-res pixels to one low-res pixel, the terrain is not always physics-identical. For example, see the attached image - yellow pixels are solid on Mac but not DOS; red pixels are solid on DOS but not Mac; green pixels are solid on both; black pixels are not solid on either. (For the graphic, I translated upwards - a solid pixel in low-res = all four pixels solid in high-res.)

The 3rd one is the biggest issue, and I suspect that manual work would be needed to resolve this.

With this being said: I have not by any means confirmed that WinLemm's graphics don't have similar issues. They very likely do.

If issue #3 does exist to a significant extent in both Mac and WinLemm, I will probably not make the effort to actually prepare high-res graphics myself, as I feel my time would be better spent elsewhere. Of course, I'll still implement the support for it in NL - it'll just be up to someone else to actually convert / prepare the high-res graphics.