why fix what isn't broken in this regard?

Because version control is framestepping for software development.

You won't know why it's essential unless you have seen it work well¹. Why should people use convenient, efficient engines like NL or Lix, when they can play L1? Why should the USA switch to metric, even though they have archaic units to measure everything?

git is an extremely lightweight, powerful, local content tracker. For normal development, there is no server involved. Removing git-tracking from a project is equal to deleting a single .git dir inside the project root dir.

Local branching, merging, and reverting are the main points. They're akin to framestepping with possibility to insert or reorder.

Lix on github is 40 MB, complete with 4.5 years of history. If you clone this, you get a full-fledged local copy of the repository. You get side branches that I chose to make public, right now 1 out of maybe 20 local branches, for physics discussion with geoo. From the 40 MB of data, you get to build any version back to March 2011, complete with levels and graphics.

and ultimately has no effect on the end code

It has an effect, because people are encouraged to help.

I don't care much if you hack NL using Windows Notepad, or some fancier editor. I'm not affected by your editor choice. I do care whether you publish source using version control, or in a plain archive. It's harder to talk about changes, and to make patches, which git could transparently merge in. It will record what happened when and why, so if you've merged crap, it's always possible to revert precisely.

Even if you never get a patch, it's convenient for others to follow your thoughts, and easier to look at what's new.

Similarly, it's convenient for me that geoo maintains the community levelpack on github. I can pull from him whenever I want to release the main game, and suggest patches for him to merge automatically.

These are the benefits from publishing git history. The even more important thing remains the local control.

6 Myths Preventing Developers from Using Git -- the first being "I back up regularly, so I don't need source control".

-- Simon

---

[1] About source control working well: I've never liked centralized version control like SVN, where you either push your buggy code to a server as soon as you're done writing it, or can't commit for days. Committing should be different from inflicting changes on the world. When I was doing a SVN-managed university project 6 or 7 years ago, my policy was: Nobody but me works between 2 a.m. and 7 a.m.

Right-clicking fast forward when already in normal FF ends FF, instead of starting turbo-FF.

I thought about both ways and chose this (back to normal speed), but I'm unsure about what's better.

The alternative (ffwd -> turbo) the problem that the user must remember what ffwd mode is active, and when cancelling ffwd is important, it should not matter. They should be able to hit any ffwd button to cancel.

The counter-argument is that the user would cancel ffwd with pause in this case anyway.

With 1 button/key for each non-normal speed, there is no stateless implementation, except for going over pause (hit pause, then ffwd, and you will end up in ffwd mode guaranteed, no matter where you came from) or requiring 2 presses in general for a particular function.

Good to have separate mouse controls for adjusting SI and instant min/max. Now we just need a hotkey for instant min/max.

I can make keys if the need is there; I'm merely getting worried about the ton of different keys.

After reading all hints, "+/-" buttons are replaced by highlighted "?" but this displays penultimate hint again, rather than hiding hints as one would expect. To hide hints after reading them, one has to "-" back through them, which is hardly intuitive. Also, restarting a level should hide hints.

Agree on restarting. Hiding hints makes this button a universal reset button, something everybody likes.

Browsing after the last hint: The current hint interface is bad in the first place, and should be redone thoroughly. It stems from lack of panel space.

[14:17] <SimonN> Ramond: no zoom button: this is an older design issue in Lix; the panel space is so crowded that I resorted on having either zoom or hints in the panel. When the zoom button is hidden, its hotkey doesn't do anything either

This design issue needs some more attention. Hints are getting more love these days than months ago.

I can't find anywhere that names of skills are displayed any more. New players need to know the names to understand hints.

They appear when hovering over a working lix. Enough or too little?

Hint for "Any Way You Want" may need changing in view of instant bombers?

Agree. It's an issue for the pack, not for the game. Reword the hint and post the updated file in the pack thread, or wait until geoo resolves/delegates this.

---

geoo and Proxima have suggested frameskip-ahead-by-right-click should skip 10 seconds, not 1 second. Reasonings:

• There was no good reason for 1 second other than symmetry with the value on framestep-back-rightclick.
• User can wait 1 second easily by normal speed anyway.
• Skipping large amounts of time is easier and faster with repeated 10-second-skips than with ffwd/turbo. Also more precise if you know the exact time at which interesting stuff will happen.
• Lemmix/NeoLemmix have this. The main reason there is chaining builders, which you don't have to do in Lix, where you can queue instead. Nonetheless, 10 seconds seem useful for more than only chaining builders. You can judge how much it is.

I'm slightly reluctant to make the value user-settable, unless people demand it. Lix doesn't have about:config. >_>

-- Simon

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