Try singleplayer in the D/A5 port! v0.2.42

[Simon]

Version 0.2.9 is out, download in the first post.

Comes with a good chunk of bugfixes (changelog). The replay tree mimicks the level tree whenever replays are saved.

I haven't investigated Ramond's problem further yet.

Collectors of C++ Lix replays (geoo, Clam) might try their existing replays and levels on the D port. Find causes and estimate the frequency of breaking replays. Clam: I have written code to convert old C++ replays to the August-2015 replay format, so the D port understands the replays. Ask me in IRC for details.

-- Simon

[Nepster]

I tried your current version 0.2.9 and it works on my Windows 7 laptop.

However here a few little bugs:
1) If I start lix.exe, I get two programs on my taskbar: One corresponding to the proper Lix window and one corresponding to a black rectangle. See screenshot.
2) If I play a level with imploders (and no exploders), the exploder skill is still displayed. Therefore one cannot select any imploders via the skillbar nor via the hotkey. Replays using imploders apply them correctly.
3) Loading levels (or even the mini-image in the level selection menu) takes quite long for levels with lots of terrain pieces. My record is something like 15 seconds. Especially lots of erasing pieces and no-overwrite pieces seem to make it slooooow.
4) The "No Overwrite" option doesn't seem to work for terrain pieces when loading C++ Lix-levels in D-Lix.
5) If one puts a replay file in the replay folder without having the corresponding level in D-Lix, the game does not display the level name in the replay selection menu. Starting the replay, ... works fine though.

[Simon]

Awesome, thanks for the thorough report!

1), 2), 5) are glaring, but easy problems, will work on them next. Disabling the extra console on Windows is a certain build setting; I know exactly what the switch is, but I have to see how it fits best into my build system.

3) and 4) sort of go together. I'm not happy my current level rendering in general. No-overwrite is not implemented at all. Dark pieces are drawn pretty inefficiently. It's important to keep this on the radar, but I won't devote energy to it yet these days.

Clam reported in IRC that floater assignments cancel queued builders.

-- Simon

[Simon]

Version 0.2.10 is uploaded to fix 1), 2), and 5).

I haven't been able to test myself whether 1), the unnecessary extra console, is fixed now.

Relevant github issues with the remaining bugs:

• #37, Drawing dark terrain is slow during level rendering
• #1, No-overwrite terrain drawing not yet implemented
• #36, Floater assignment cancels queued builders

-- Simon

[Nepster]

Bug 1) is fixed .

[Simon]

Perfect, thanks for the quick feedback!

-- Simon

[Clam]

Looks great so far!

I tried my ClamLix (C++) replays, recorded yesterday. About half of them worked . Which I guess isn't surprising (or is it surprising that half of them work? ) given that the physics haven't been copied exactly.

Most fails seem to be due to differences in timing – bashers, as already noted, but also floaters reach the ground slightly sooner (Flotilla is unsolvable as a result, though can be fixed with minor terrain changes).

Another thing that breaks solvability in some cases is bashing under steel. When bashing 16 pixels (one "block") below steel, the basher checks for steel at the top of her tunnel and consequently stops after one swing:


(Loving the extra-close zoom, by the way! )

Also, exploder flinging is different, though I think this is intentional?

I haven't accounted for all reasons for replay-fails yet, though most seem to involve slight mistiming. Will continue the research

[Simon]

Awesome research!

Continuing in IRC right now. I'll be away at uni in a few minutes, but we're uncovering subtle inconsistencies between D an C++ walkers.

Uploaded version 0.2.11 to fix two bugs:

• Left-facing bashers choked on steel in top 2 rows.
• Assigning floater cancelled builder queue.

-- Simon

[Clam]

Here are all the reasons for desyncs in the failed replays (44 total). I'm not suggesting that these need to be "fixed" (some are intentional changes) but users should be aware of these when checking replays.

• Basher starts faster and reaches further: 15
• Floater falls further while opening umbrella (thus reaching the ground sooner): 8
• Exploder flings differently: 6
• Platformer bridge extends further from 2nd brick onwards: 3
• Walker doesn't pause for a frame after turning or cancelling a (non-blocker) skill: 2
• Blocker -> walker transition takes longer: 2
• Runner doesn't pause for one frame before starting: 2
• Tumbler interacts differently with walls/ceilings: 2
• (Fixed: Basher steel-check in top 2 rows: 2)
• Exploder terrain-removal mask is smaller: 1
• (Fixed: Assigning floater cancels queued builder: 1)

[Clam]

Separate post because it's unrelated to the above: I found a couple of graphical glitches while checking the replays.

This staircase piece appears too high, though it's correct for physics purposes. (They actually connect at the bottom)

(Level: Insane/Leaky Building Syndrome)

Stray pixel in the sandstone ribbon tile.


---

You know you've played too much Lix when you try to right-click scroll in Notepad

[Simon]

This is extremely valuable research, many thanks.

• Basher starts faster and reaches further: 15

Basher reaching further: Intentional. Breaking 15 out of 90 replays is OK in light of the following problem in C++ Lix: You can cancel the C++ basher standing inside terrain, potentially falling through the floor then, without others following. Basher starting faster, intentional, but I don't know whether it's good or not. This might cause more problems than reaching further.

These sound like I want to fix them:

• Floater falls further while opening umbrella (thus reaching the ground sooner): 8
• Platformer bridge extends further from 2nd brick onwards: 3
• Walker doesn't pause for a frame after turning or cancelling a (non-blocker) skill: 2
• Blocker -> walker transition takes longer: 2

Consequences of needed changes, or sucky tumbler code that is very hard to maintain:

• Exploder flings differently: 6
• Exploder terrain-removal mask is smaller: 1
• Tumbler interacts differently with walls/ceilings: 2
• Runner doesn't pause for one frame before starting: 2

-- Simon

[Nepster]

Clam was lucky with his replays. Here is my status report out of 108 replays (using v0.2.11):

• Working: 28
• Basher Fail: 53
• Walker Fail: 4
• Platformer Fail: 2
• Fast Floater Fail: 9
• Tumbler Fail: 3
• Miner-Miner-Cancel Fail: 1
• RR-Fail: 2
• Wrong Terrain Fail: 6

Reason for the last fail type: The algorithm to decide what pixels are solid is 1 high-res pixel off. So if precisely one of two high-res pixels next to each other is terrain, C++ Lix might treat it as solid, while D-Lix does not (or vice versa), depending on the precise setup.

And here some more bugs (some might intended design changes though or you might not yet have implemented the stuff):

• The joystick bug is still there. See error messages attached. They appeared when I pressed the hotkey to go 1 sec back (after first hitting "skip 10 sec" several times).
• Start a miner, such that a steel piece reaches slightly into the miner tunnel from above, but such that the miner doesn't stop working. Then the eraser mask of the miner removes the steel as well.
• Clam's graphical glitch appears (at least most frequently) for mirrored erasing terrain pieces (in some circumstances). I have a level where I mirrored one half of the level: The original half is fine, but the mirrored one is a big mess.
• Sometimes a key gets stuck (on the software side, not the hardware side) and the game thinks it is repeatedly pressed. This happened with the arrow keys on the level selection menu and with the FF-hotkey while playing.
• If you start fast FF, the game prioritizes computations of Lix over scrolling actions. In large levels, I had to stop FF, scroll a bit and then start FF again. This might get better after you implement a better terrain rendering, because currently fast FF sometimes reduces the FPS to only 6.
• If a level has a time limit, this is neither displayed nor enforced.
• The screen start is (always?) at the very left-most edge, even if this doesn't make any sense level-wise.
• The hatch opens 30 frames later than in C++ Lix.

[Simon]

Very detailed report, with plausible speculations. Thanks. I'll reply with more detail after sleeping over it.

I see us fixing bugs for a while. >_> There are replay checkers in both games at least, and a working level editor in C++ Lix that builds levels for both games. I'm open for priority suggestions, or for putting back the old basher temporarily.

-- Simon

[Simon]

Version 0.2.13 uploaded, implementing the C++ behavior for all of these:

• Floater falls further while opening umbrella (thus reaching the ground sooner)
• Platformer bridge extends further from 2nd brick onwards
• Walker doesn't pause for a frame after turning or cancelling a (non-blocker) skill
• Blocker -> walker transition takes longer

Graphical glitches, and most things from Nepster's post, I'll remember to discuss them.

-- Simon

[Simon]

Okay, detailed reply for Nepster.

108 replays: With hope, I have fixed the low-hanging fruit already, see post above. I have to dig into the terrain handling code next.

I'm not aiming for 100 % compatibility, but I want to give a solid reason for each incompatibility.

Solid off by 1: Test case (replay with included level) would be nice. I want to get this right at all costs. Let's make it work like in C++ Lix, or come up with a good reason for such a change.

Joystick bug: Collected info on github. I would like to repro this on Icho's Windows machine eventually. This is also rather important. It's very hard to debug: Even a debugging build didn't give a useful stack trace for Clam.

Miner & steel: I haven't been able to reproduce this. Test case please -- can you provide a replay?

Stay pixels: Part of (I have to dig into the terrain-handling next).

Key stuck: Got an idea already, will try it for the next release today/tomorrow.

FF & lag: I have only bad/complicated ideas so far.

Unimplemted: Screen starting position, automatic only, or manual still? As of 2016-02-10, I lean towards allowing both. So, let's treat it as yet-unimplemented.

Time limit isn't implemented at all yet. It would be handy to count updates since level start, for debugging replays.

Singleplayer should start at update 30, not 0, or maybe even later. Action should happen ASAP, while still looking somewhat good. People are impatient and FF through 2 seconds!

-- Simon