2x1 grid allows visible gaps that behave like solid ground

[Simon]

Hi,

self-solving level (dumb-grid-physics) attached. Here's how it looks:



This level has about 40 terrain pieces of shape 32x2. Difference between left and right half of this level: On the left, each tile has an x-coordinate of 2k with k integer; on the right, each tile has an x-coordinate of 2k+1.

Lix physics works in 2x1 chunks (2-wide, 1-high). Your lix can be at arbitrary vertical positions. But horizontally, the world consists of 2-wide chunks. A chunk is solid iff at least one of its two pixels is solid. If we examine the top of the terrain in the dumb-grid-physics level and group its pixels into chunks, we find this structure:

XX .. XX .. XX .. XX .. on the left side of the level. .. chunks behave like air.
.X X. .X X. .X X. .X X. on the right side of the level. Only solid chunks.

This bites Flopsy in Lix Cannon (youtube video). All these gaps in Lix Cannon are solid, they behave like the right side of dumb-grip-physics:



Bug in Lix's physics? (This behavior is really deeply ingrained in the physics...)
Bug in tileset that is used in Lix Cannon?
Bug in Lix Cannon level design?

-- Simon

[Proxima]

Combination of tileset and level design. Because there is no small_32x32 tile, I made the wall by tiling the larger tiles and using eraser pieces for the diagonals. If it's okay, I'll add this piece (as well as big_64x64) and use this to make a fixed version of the level.

Another problem on the same level: Flopsy never considered climbing the first step and bashing across the top of the concrete rod, perhaps because it looks like the lix wouldn't be able to walk up through it? I'll move the rods up behind the wall a little to make this clearer.

[Proxima]

Tiles and fixed level.

[Simon]

Level attached in reply #2: The main gap is fixed well, thanks.

The leftover 1-pixel gaps aren't perfect, but I see that they're hard to fix by moving the eraser pieces. Should I manage to fix the gaps while keeping the looks, I'll post a fix.

The two new tiles look like reasonable additions, I'll merge them.

-- Simon

[ccexplore]

Out of curiosity, why was it 2x1 and not 2x2 or 1x1?

Probably the simplest thing is to just encourage level designers to not use those deceptive fake-gaps on purpose.  Good tileset design and grid alignment should hopefully be enough to make it hard to get into such setups by accident or to require too much work to fix.  If you want to change physics so the lixes actually fall through such gaps, the physics will have to effectively check pixels and not chunks, and a lix can wind up in 2x+1 horizontal positions as well as 2x.  All that is arguably more natural behaviors, but maybe too drastic to consider now given how deeply the current behavior is ingrained?

[Simon]

Here's my take to plug the holes, continuing from Proxima's version.

History documentary for ccx must wait for another post.

-- Simon

[Simon]

History about Lix's 2:1 block structure

I haven't ever written Lix with any Lemming source code in mind. Still, in 2006, I wanted to keep certain behaviors and coarseness. I found that logic at 15 fps matched my memories of Lemmings well. Even before framestepping, I found it desirable to have a good chance to assign frame-perfectly, and to predict what would happen before your assignment.

I didn't know the exact Lemmings value of 17 fps, and 15 is much easier to program as a factor of 60 anyway.

Back in 2006, my only programming experience was level-scripting in Lua within a host game. I wrote Lix to learn C++ and Allegro 4. I hardcoded a 640x480 resolution, assuming that every screen could display that in fullscreen. It felt nicer to design menus and graphics in general in 640x480 than it felt at 320x240; also, the host game from my Lua-scripting era ran in 640x480. Surely, it couldn't be a terrible choice.

To get correct-feeling physics at 640x480 and 15 fps, I needed 2x1 or 2x2 chunks of terrain. I chose 2x1 because that wouldn't display lixes partly in or above terrain with odd coordinates.

It would have been possible to compute physics in 2x2 chunks and, if the floor coordinate was odd, offset the lix sprite vertically by 1 without affecting physics. But I didn't think of this idea when I chose 2x1 chunks, therefore I've never seriously considered 2x2. Still, I stick climbers to the wall with such an offest, horizontally instead of vertically, to this day.

The 640x480 resolution was hardcoded in both game and menu. If you had 1280x960 or more, you could integer-scale the internal 640x480 to your screen, and it still looked good. But if you had 1280x800, a popular 16:10 resolution, you were hosed. You would have to settle for ugly nearest-neighbor upscaling, or be content with a 640x480 porthole centralized in a 1280x800 fullscreen.

4:3 and 5:4 screen aspect ratios were still popular for desktop computers, but 16:10 was rapidly killing 4:3 on the notebook market. When I got a notebook in early 2007, I took extra care to choose one of the few remaining 4:3 screens, to have an easier time testing a reasonably-looking Lix on it. I've used that notebook for nearly 10 years since; ccexplore knows it as Simon's slow machine. It had 1 GB of RAM until I bought 2 extra GB in late 2015.

My next machine after that laptop was the fanless desktop in October 2016, with a 21:9 widescreen. D Lix supports any resolution and will scale the UI nicely. This was a design goal from the beginning of D Lix:



-- Simon

[namida]

Suggestion: Store the physics grid in terms of 1x1 cells, and have any "is this position solid" function check two tiles.

Let's suppose then we have a line, in terms of raw pixels: SNNS, where S = solid and N = not solid.
In the current system, the physics grid would represent this as: SS. When the Lix is at pixel 0, it checks the first physics cell, it's solid. At pixel 1, it checks the first physics cell, it's solid. At pixel 2, it checks the second physics cell.
In the new system, the physics grid would also be SNNS. When the Lix is at pixel 0, it checks the first and second physics cell, one is solid so it's treated as solid overall. At pixel 1, it checks the second and third physics sell; both are non-solid, so the Lix falls. Maybe to an exit, maybe to its doom, who knows.

Assuming your "check if pixel is solid" is sufficiently abstracted, this should be relatively simple to implement, I'd think.
Downside: I suspect replay breakage will occur in levels that feature walls.

[Simon]

Store the physics grid in terms of 1x1 cells, and have any "is this position solid" function check two tiles.

I do exactly this, already.

When the Lix is at pixel 0, it checks the first and second physics cell, one is solid so it's treated as solid overall. At pixel 1, it checks the second and third physics sell; both are non-solid, so the Lix falls.

Horizontal movement is only possible in multiples of 2 hi-res pixels (one 2x1 chunk).

Sadly, I don't remember the exact reason and would need more time for a thorough answer. I believe the reason was that walkers would have to move 2 hi-res pixels per frame to get the correct speed at 15 fps.

Your hunch is correct that the 2x1-grid movement and the 2x1 terrain checks are separate designs that both must come together to treat the SNNSSNNS entirely solid.

-- Simon