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

[Simon]

Hi folks,

This topic is outdated. Download the newest Lix at lixgame.com!

This is a test release, with singleplayer mostly complete. This port is not finished yet -- it lacks a level editor, and it lacks multiplayer. Physics are unstable and may change between bugfixes.

Minim has designed several scaled-up versions of the internal graphics. They're visible whenever the game's resolution is at least 1.5 times as big as the old 640x480. Many thanks to Minim for this work!

Levels and terrain graphics are the same as in old C++ Lix.

I'm cross-compiling to Windows from Linux now. Let me know of any problems. Report bugs here, or open issues on github.

-- Simon

[namida]

Options do not appear to save after exiting and re-starting Lix. This in turn means, it seems, that I cannot try windowed mode (I tried Alt+Enter, but it does nothing).

When playing a level that's too small to take up the full screen area, it seems to be centered horizontally, but pushed to the bottom vertically. I'm not sure how I feel about this.

Also note the glitchy fake cursors here: http://i.imgur.com/MGCFgom.png

These things aside, performance seems pretty decent, and while I didn't test extensively, it hasn't crashed yet.

[Simon]

Thanks for trying! If it runs reasonably performant and doesn't crash, awesome.

Options not saved: Right, can reproduce this here on a fresh installation. Enter a username, then it should work. This is completely unobvious right now, which is bad. Asking for username at start is the next feature, then. Windowed mode in arbitrary resolutions can also be forced with a parameter: lix --resol=1024x768

Glitchy cursors: A design mortgage from deferring changable spawnint yes/no. Agree, doesn't look too exciting in a demonstration. >_>

-- Simon

[Simon]

Resolved bug #15, basher always left relics.

Everybody: The basher starts faster by 2 frames than in C++ Lix, and the basher mask reaches further by 2 hi-res pixels = 1 lo-res pixel. What do you think? The faster it starts, the better it feels, but maybe it's getting too overpowered in multiplayer. On the other hand, the miner is absurdly strong in multiplayer still.

Note to self: Make topics from (namida's recommendations in IRC) either here, or on github.

-- Simon

[Ramon]

As anticipated, still won't work on my laptop. Same problem that I had when you were in Vienna.

[Simon]

Nonetheless, thanks for trying again. Can you describe the behavior in 2-3 sentences for posterity?

Even if it won't help much: Run lix -h from a shell. That will only describe all available command-line parameters and then exit immediately. See if this text-only output works at least. If yes, try lix -w to force windowed mode. I expect that to fail for you.

-- Simon

[Simon]

Roadmap of large features for the D port:

• Automatic replay checking. done, test it in the current releases
  
• Editor.
  
• Declare the D port to be the standard version for singleplayer. Expect level designers to build against this engine, and expect all singleplayer replays to use a recent D port version. This also means that physics should not change erratically from here, at least in the master branch.
  
• Work on stuff that level designers suddenly need/miss, to easen the switch.
  
• Netplay, including the server code.
  
• Declare the D port to be standard Lix in every regard. Retire C++ codebase for std::basic_ios::good();
  
• Continue fixing bugs. I don't strive to make the D port as well-debugged as the C++ port before making it standard overall. Migrate early, expose bugs together, and fix them quickly.
  

The idea behind this ordering is that I want people to test the port. People will test much more happily if they can accomplish real work with the D port. Automatic replay checking is both the fastest to implement, and provides real benefits, for physics are slightly different than in the C++ version. On the other hand, the C++ editor can be used to make levels for the D port for a while.

-- Simon

[Ramon]

It's hard to describe. When I start the game, a cmd window will pop up, and then there is a white window animation that repeatedly goes fullscreen (but each time it reaches fullscreen size it reverts to windowed size from one tick to another), this will keep repeating for the first 15 seconds, then the speed and frequency of the fullscreen animation approximately doubles, then after 15 more seconds the whole thing stops (and lix.exe is closed).

When doing lix -h, I do get the text output. When trying lix -w, I do get a lix program running in the taskbar, but no visible window. However, when I hover over the lix icon in the taskbar, it will show the normal Lix main menu (asking for first-time player name) in the mini-preview window.
One more peculiar thing, it seems to accept keyboard inputs, as I was able to enter my name, hit enter and then it showed the main menu.

[ccexplore]

I remember someone reporting their computer couldn't go fullscreen for anything (not just Lix), I guess that must've been you?

Sounds like a video driver problem.  Is this Windows or Linux?

[Ramon]

It wasn't me, I play lots of things fullscreen.

I'm using Windows 7, AMD Radeon HD 6630M. It's true I have minor problems with my video card, but only in very specific situations. It also doesn't seem like the drivers are being updated anymore.

[ccexplore]

Since it's a laptop, it's probably best to go to the laptop manufacturer's website for drivers.  Though I suppose it is quite likely that you already have the latest given that it's hardware from Windows 7 era (presumably).

Anyway, since this sounds more Lix-specific now, I should probably let Simon look at it first, maybe he can provide you a debug build with more verbose logging or something.

It might also be useful to collection some additional data with dxdiag, see this post.

[Simon]

<SimonN> Ramond: thanks for the description; the Windows build uses OpenGL, maybe geoo can try to build D Lix and hope to get a build using DirectX instead
<Ramond> what did the c-lix use?
<SimonN> OpenGL
<SimonN> at least the cross-build I made here
<SimonN> IIRC Allegro 4 and 5 have the ability to bind to both, and I don't know the decision is made

Thinking this through, geoo has built D Lix for Windows in August, and it didn't run for Ramond...

The game seems to run fine in the background, and fails to bring its working display to the screen. So, I'm not sure if more debugging output from Allegro would help, but could try eventually. I haven't read any Windows-specific docs in A5 yet, either. In short: I want to read more before making a diagnosis.

-- Simon

[Simon]

Version 0.2.4 uploaded (link in first post), with automatic replay verification. This must be called from the command line or a custom shortcut, like in C++ Lix. Read the C++ Lix readme for instructions, or ask in IRC.

I still don't mimic the level directory structure in the replay tree. I should implement that before I can reasonably ask people to use D Lix for serious level/replay handling.

There's an editor button in the singleplayer browser, but it doens't do anything when clicked.

-- Simon

[ccexplore]

I messed around a little in Google and while it's far from definitive, it seems like the AMD Radeon HD 6630M is often used in laptops with dual graphics card setup.

http://www.notebookcheck.net/AMD-Radeon-HD-6630M.43963.0.html  (see bottom for list of laptops reviewed, and note how many of them mentioned having two graphics cards)

So I'm starting to wonder if that's the culprit here.  dxdiag unfortunately I'm not sure checks for this setup so it may not be sufficiently informative even if you upload the logs from that tool.  It should at least tell you the manufacturer and model of the laptop, but some models may ship in both single- and dual-graphics configurations, so it may not be sufficient to determine the exact setup from those alone.

From limited reading, it sounds like in most laptops with dual graphics setup, there should be some utility you can run to assign a particular program to run specifically on one of the two graphics card.  If that's the case it may offer a workaround for the issue you are encountering?

[namida]

From limited reading, it sounds like in most laptops with dual graphics setup, there should be some utility you can run to assign a particular program to run specifically on one of the two graphics card.  If that's the case it may offer a workaround for the issue you are encountering?

You can do it in the AMD Control Center (I forget the name) if it's an AMD GPU setup. If it's an NVidia one, simply right-clicking and selecting "Run with graphics processor" then selecting the right one will work.

I messed around a little in Google and while it's far from definitive, it seems like the AMD Radeon HD 6630M is often used in laptops with dual graphics card setup.

This is generally only true for those that have AMD CPUs as well. For those with Intel CPUs (especially if their high-power graphics card is NVidia), it's usually some kind of Intel HD GPU.

[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

[Nepster]

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.

As the replays are for not yet released levels, I will send them via PM.

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

Sorry, my bad. I checked the original level with C++ again, and the problem was with the missing no-overwrite handling: The steel piece was set to no-overwrite and placed above usual terrain. So the miner removed only usual terrain in D-Lix (as it should), even though parts were displayed as steel.

[Simon]

Okay, thanks for checking back with miner & steel, and for the PM.

Yes, no-overwrite is a huge mess right now, if presentation and physics differ. I have to invest time and energy into drawing next.

-- Simon

[Simon]

Here are hands-on profiling results from my 9-year-old laptop. This is from a build with profiling, but without other debugging instrumentation. Dark drawing (eraser piece drawing) sucks. The testing map was geoo's playground, a huge map with about 10 % dark pieces.

Lix version 0.2.16 profiling results from 2016-02-09 17:49:01.
Unit of time: 1 us == 1 microsecond == 1/1000 of a millisecond.
At 60 frames per second, 1 frame takes 16666 us.
                                       avg/us   min/us   max/us   amount
Level.drawPos to RAM DARK                 269       25     3407      123
Level.drawPos to RAM NOOW                 610      418      803        2
Level.drawPos to RAM NORMAL               428       10    10693     2789
Level.drawPos to VRAM DARK              47191    39122   131871      246
Level.drawPos to VRAM NOOW               2615     2431     2742        4
Level.drawPos to VRAM NORMAL              156      142     1190     5578

The averages are average times per piece, not average times of rendering the level.

Drawing no-overwrite pieces is also slower. But the sampling rate is too little, geoo's playground uses only 2 no-overwrite pieces.

Good suggestion by namida from IRC:
<namida42> wouldn't it make more sense to test with *several* real life maps, since that's going to give a more reasonable picture of how ti performs in actual usage, rather than unlikely test scenarios?
<SimonN> yeah, I should set up some kind of automated test >_>

-- Simon

[Simon]

Version 0.2.17 uploaded, with faster dark drawing.

To improve the performance of turbo-fast-forward, I'd like to try savestating less frequently during turbo. Right now, performance is mediocre, and Nepster is right that it should be faster.

-- Simon

[ccexplore]

So is dark drawing to VRAM now at least comparable perf-wise to NOOW?  I'm actually quite surprise at the performance reported before 0.2.17--conceptually an eraser and a normal draw seem almost identical, just that instead of overwriting with the terrain's pixel value, you overwrite with a black (or the background color) pixel instead.  Feels like I must be missing something there conceptually.

[Simon]

Before 0.2.17, I looped manually over the image, and for each opaque pixel, I drew a transparent pixel to the target. That was a naïve implementation, mostly copied from A4 Lix. While I used calls to the video hardware, they were many, many calls per tile.

In 0.2.17, I have a fully white, fully opaque copy of the tile in VRAM. For drawing dark, I blit the white piece with a blender that deducts from the target pixels (colors and alpha) the source pixels (colors and alpha).

Now, dark drawing has about the same VRAM performance as a normal blit.

-- Simon

[Simon]

Version 0.2.18 uploaded, with more performant turbo-fast-forward.

• Preview renders much faster than in 0.2.16 or before.
• How fast is the transition from menu to game? In addition to rendering the VRAM bitmap, as I do for the preview, I also generate the RAM physics map. That's still implemented a bit naively. I don't know whether I should work on faster physics map creation, so feedback would be cool.
• Clam: Is that bug fixed? Misalignment of physics/graphics in Leaky Building Syndrome
• Nepster: What's the performance of turbo-fast-forward now? A rough estimate is OK.
• Nepster: I've tried something at random against stuck keys. Complain in case they get stuck again. :]

-- Simon

[Nepster]

How fast is the transition from menu to game? In addition to rendering the VRAM bitmap, as I do for the preview, I also generate the RAM physics map. That's still implemented a bit naively. I don't know whether I should work on faster physics map creation, so feedback would be cool.

Much better. Now it scales roughly with the total number of terrain pieces, without a great influence of erasing/no-owerwrite pieces. My computer manages approx. 2000-3000 terrain pieces per second.
I don't see much differences between the time to create the preview image and the actual map creation.

Nepster: What's the performance of turbo-fast-forward now? A rough estimate is OK.

Approx. three times as fast as in previous versions.
- In levels with ~10 Lix, the game runs smoothly in turbo-FF.
- With ~50 Lix, scrolling gets noticable slower, but is still workable.
- With ~100 Lix, the FPS go down to 16-18 and scrolling speed is greatly reduced.

Nepster: I've tried something at random against stuck keys. Complain in case they get stuck again. :]

Haven't had any stuck keys yet, but then I only did a quick check.

[Simon]

Thanks! Happy happy about the improved rendering.

It's interesting how the number of lix makes such an impact on speed. Will think about it more. They're not optimized in memory for fast copying. I haven't put detailed profiling for savestating/physics updating in.

-- Simon

[Simon]

Version 0.2.19 uploaded.

Only Ramond needs to update to this one.

The switch --hardfull=1600x900 forces hardware fullscreen at the given resolution. Hardware fullscreen can't be accessed by setting user options right now, it must be wanted via command-line switch. This enables the game to run on Ramond's computer. I advise Ramond to run the game via a Windows shortcut that calls lix.exe --hardfull=1600x900, until I make a proper user option for hardware fullscreen.

I don't believe that hardware fullscreen affects performance in any way. On my Linux machine, hardware fullscreen prevents alt-tabbing. >_>

Also, little bugfix, singleplayer browser crashed for new users.

-- Simon

[Clam]

• Clam: Is that bug fixed? Misalignment of physics/graphics in Leaky Building Syndrome

-- Simon

It's fixed . The level now looks exactly like it did before.

Previewing and loading levels is noticeably faster compared to 0.2.9 (the last one I downloaded). A reasonably large level took half a second to load, now it's less than half that (though it's hard to measure times on this scale).

[Simon]

I'm fixing one bug a day -- or, when only hard bugs remain, trying to write enough code for a meaningful commit each day. Can't interrupt a 2-month streak. >_>

No need  to update, because the changes aren't that big. Summary of recent changes up to 0.2.22:

- Fixed #44: We sort dirs and levels according to the listing _order.X.txt.
- In singleplayer, lix start spawning 1 second after level start, not 4 seconds.
- Fixed #48: Assertion failure of climber on torus maps.
- Fixed sprite positioning of the climber.
- The panel displays elapsed minutes and seconds since level start.

But there's always need for your guidance. Is there something urgent to fix or implement? Issue list on github. Without good targets among the issues, I'd continue on the editor.

-- Simon

[Simon]

Screenshots from the early editor development. Hidden in a spoiler because of large image dimensions.

Spoiler (click to show/hide)

-- Simon

[Simon]

Nothing exciting to test yet.

I've been working on bugfixes and editor tile hovering. The editor understands that terrain has solid and transparent pixels. When hovering over multiple tiles, the editor chooses the topmost tile that's still solid at the mouse position. Priority invert selects the bottommost tile.

I'd like to have a mostly-functional editor before our next large test.


Update 2016-03-02: Attacking the joystick bug in separate topic.

-- Simon