Excellent update! This is my first time seeing the new animations too. They're amazing! I love the purple swirly black hole imploder and the pogo stick digger and everything. The lix carefully planting her shovel and then carefreely swooping the dirt away is really cute.

Happy happy happy, thanks!

I was surprised again by it defaulting to fullscreen. I feel Lix, being a free, 2d indie game not supported on steam, should be humble and default to windowed mode. People will be skeptical already downloading anything from asdfasdf.ethz.ch, and something that takes over the screen is quite scary.

I don't have a strong preference for fullscreen, and that's a reasonable argument to start windowed per default. The A4 version can toggle fullscreen during program run anyway.

fullscreen resolution in options should default to 0,0 with preserved aspect ratio.

Agree. It runs at less than 60 FPS for me with 0x0 and faster with 640x480, but most people won't experience such a slowdown.

the imploder animation doesn't work quite right in frameskip mode

Will examine.

Knockback exploder should be the default ploder in the editor. More mp maps will use ploders than sp, I think, and of the sp maps that do, many may use exploders instead of imploders, whereas few mp maps will use imploders over exploders.

I feel the same. This dialog needs some more attention anyway: The button for classical skills is much more prominent than the button for setting all skills; they should switch places.

We will have a real domain for it one day , when Lix runs A5 I would highly expect.

I've already rented a virtual private server. I want to install a webserver there in the next weeks, and eventually move the Lix site over. Registering a domain is around 10 dollars per year, that shouldn't be a problem.

-- Simon

I'm preparing a Lix release right now.

No physics changes, but framestepping buttons. Several bugfixes, including what geoo reported: Last selected skill should be remembered even if player runs out of skills -> when loading savestate the skill will be selected again instead of no skill selected.

Rubix: If you don't object, I'm going include the archive in the post right above this one. Or are you working on it right now and would like me to wait until tomorrow?

Are you sure you want to tell your story in many one-line hints, instead of one multi-line hint? Lost/"Final Chapter"/1.txt is an example of where you use many hints, instead of one hint with all the text. doc/files.txt explains how you can add manual linebreaks in one long hint, by inserting <br>.

-- Simon

It's great how you maintain this massive pack. I've earmarked the update for the next release!

-- Simon

ccx: Thanks for the extensive feedback and log/profiling files.

Mouse not captured on reentry: I can reproduce this here. It's a general bug, seems be solvable with the correct Allegro calls. Issue tracking for the D port is on github, I've added it.

Mouse doesn't leave small rectangle: Will look into this.

Ichotolot's machine is a few years old, but was top-class when he bought it. He hits 60 FPS on the 3500 gadget map too, and I have the log/profile results.

I'll make a table from the various results at some time.

-- Simon

Point 1 (mouse buttons are keys for remapping): This is exciting, I have considered this myself at least for the right mouse button. Left mouse button is murky. In Neolemmix 1, it's already overloaded: assign, and one-frame-advance-while-paused, is both on LMB. I'd go for full mouse button inclusion in the remapping, let's see whether/when design problems come up along the way.

Point 2 (mutliple keys for same function): My experience has been bad with this. The GUIs where you could define multiple keys for a function were always confusing. It would never delete a binding when I wanted to, it would instead add another binding.

Point 2b (nobody has asked for this): It's good to allow for one key to trigger several functions. You can give out a warning, but you should not reject the choice.

Point 3 reminds me of Clones, where anything that wasn't like Lix felt strange. I don't want to answer this before sleeping over it, lest my answer become overly biased.

-- Simon

I updated my post to reflect accurately determining which GPU was in use, as well as testing with the other one. Interestingly, the low-power GPU actually performed better on the 3500 gadgets level, but didn't perform as well on the "demo" tests.

Yep, interesting results. geoo has made all the different demo tests, to see how they fare against my current drawing code.

I wouldn't call it a "serious" performance hit. 30 FPS is surely adequate for Lix?

This is tricky to answer. It's mostly human perception. The physics run at 15 FPS, so fixing the framerate at 30 FPS would be enough. All that would mean is 16 ms of input lag and a slightly stiffer mouse cursor movement.

If the framerate is wobbling up and down, that might lead to noticeable skips in the physics, even though the physics speed is the same.

Right now, I want to see whether I can reap some low-hanging fruit to boost the graphics performance. If there is nothing much to improve, 30 FPS wobbling up and down is still playable, you're right.

I wonder if it'll be good to have an analogous C++ baseline benchmark program to compare against on the same computer?  Though I realize it may be more work than it's worth.

Currently, there are 3 brakes in the released Windows executable:

• It's a debugging build. It's got name symbols, contract checks, and asserts compiled in. Those are straightforward to remove with a different build command.
  
• It's also compiled with the reference compiler DMD, not with GDC, which is the compiler using the powerful and well-optimized GCC backend. Allegedly, on CPU-heavy programs, GDC produces binaries that run up to 30 % faster. The Allegro D bindings errored out when using GDC, but I can try to iron out the problems in the bindings myself some time.
  
• It's got the profiling code in (what writes to profile.txt). This is not zero-cost. I have profiling even in some inner loops. I could take that out of the inner loops, and only profile the outermost loop; or I could take it out entirely and log only the framerate (log.txt)

Removing brakes 1 and 3 (debugging and profiling), I get a 30 % speedup (10 FPS -> 13 FPS) in framerate on the 3,500 gadget map. On the other hand, I get much lower benefits in geoo's graphics testing, 24 FPS -> 25 FPS in demo mode 4.

We have opted to leave in all the brakes in this first test build, to get the most detailed data. It's possible that brakes 1 and 3 (debugging and profiling) amount to different speedups for other people; that would be left for another test.

-- Simon

Update March 2016: Try D-Lix 0.2.x with singleplayer largely done, and the editor in development.

The topic here is outdated.

---

Hi folks,

I would like to know how well the Lix D port runs on your machines.

• Windows users: download this zip archive. This is not an update of the stable Lix release; it's completely independent. Extract to a new directory.
  
• Linux users: If you feel adventurous, you can look at the github repo and build yourself. There are instructions in doc/build/linux.txt. The instructions aren't 100 % complete necessarily, find me on IRC (irc.quakenet.org #lix).
  

How you can test:

• Start the game.
  
• In the main menu, click the big fat button "Benchmark! Takes 2 minutes to run."
  
• A couple of levels will be displayed, and some expensive graphics rendering will be tried. Something new happens every 10 seconds automatically. You can scroll around the level if you like.
  
• When you're back in the main menu, exit the game.
  
• Send/post the following 2 files: data/log.txt and data/profile.txt.
  
• Give some rough information about your computer: What's your operating system? Average age of your hardware? Screen resolution? In case you know it: what's your CPU and graphics card?
  

And that's it. :-)

If you had weird mouse behavior in the old Lix, maybe that has become better already in the D port.

Skippable background:

In February 2015, I have started a fundamental rewrite of Lix in the D Programming Language, using the newer library Allegro 5 instead of the 15-year-old Allegro 4.4. When geoo was visiting me a week ago, we got the D port to compile on his Windows machine. The choice of D over C++ aims at long-term productivity and convenience, without sacrificing efficiency.

The library upgrade is more important. I have great aspirations for the port. With Allegro 4.4, many different people have had issuses: Lix didn't run at all, it didn't display properly on their monitor, or the mouse behaved weirdly. I want the game to run fine for these users.

Finishing the port will take at least 6 more months. Depending my reallife work, expect it in 1 or 2 years. I will continue to maintain the C++/A4 version until then.

-- Simon