Only a first draft:

Options to get the Allegro debugging libs and dlls are nuget package or (mingw) release from the github page of Allegro 5.
From my experience: Running after building with the nuget release ones would need as extra dependencies Microsoft building tools (debugging variants of standard dlls, not tested since no access to these tools). Whereas the github release needs mingw libraries (which have a better availability).

For the dlls just choose the ones with 'debug' in the name.
For libs I know no other way than to rename them. (This means you can't have non-debug and debug libs at the same time in your toolchain.)
For nuget you already have lib-files and you have to choose the ones with 'debug' in the name. But for using them I had to remove the '-debug' part of the name, so that they look like the non-debug ones.
For the github release there are no libs. (For build with optlink you can use implib to create some.) As one way to get files that work like libs, you can rename the liballegro_....dll.a to lib files. Again you have to choose the ones with debug in their name but rename them without the '-debug' so that they look like the regular lib files, e.g. 'liballegro-debug.dll.a' to 'allegro.lib' or 'liballegro_acodec-debug.dll.a' to 'allegro_acodec.lib'.
There are maybe/probably more elegant ways to achieve this but this is how it worked for me.

Building is as usual.

If building with Allegro debug libraries was successful there should be an allegro.log (gets huge fast) created after starting the game.

It might be more convenient to have a fixed choice of common resolutions for hardware fullscreen and windowed instead of having to type it oneself.
I would suggest: 640x480, 800x600, 1024x768, 1280x720, 1280x1024, 1600x900, 1680x1050, 1920x1080 (and maybe 1366x768)

1366x768 is a common resolution for old non-hd laptops. Windowed is fine for me but it doesn't work in hardware fullscreen (defaults to 640x480 window). My standard resolution is 1920x1080.

The option to put in custom values could be left to editing the options.sdl.

Maybe add a confirmation window for changing the resolution, that you have to confirm within x secs or it resets to the previous value and add an information when it defaults to 640x480 window for nonviable resolutions.

At the moment there is only a button to flip tiles horizontally in the editor. There is a feature wish issue 115 to add a button to flip tiles vertically to the editor as well.
You can at the moment have the result of flipping vertically by turning two times and flipping horizontally.
The question is if nevertheless a button to directly flip tiles vertically would be helpful.

Nepster Lix has 3 Outtakes levels that have time requirements in the title. The question is how to make them viable.
There is an option meant for debugging to turn on phyus and FPS. phyus (physics units) count like a clock, currently start in singleplayer at 45 phyus and first lix spawn is at 60 phyus, 15 phyus are 1 second. So as a rather hidden option there is already a clock in the game to give some legacy support.

This question was topic of an IRC (#lix) discussion, which is included at the end of the post.

The spirit of the game is to have no skill external requirements like a clock. Nevertheless is it not fully against this spirit to have a counting up clock, especially since there is already a phyu counter. Having a proper clock option would only make it more accessible but could lead to time limit desires. I think it is worth the risk.

In my view if it is introduced there should be the option between no clock, normal clock and phyus.
Normal clock should start at first spawn for overarching compatibility. (Though maybe there are reasons to do it otherwise.)

(If it is implemented there could be a need to adjust the time requirements in Nepster Lix levels according to the start of the normal clock.)

Full discussion w/ further details of possibilities and problems:
[14:18] <F_> Nepster has 3 levels in outtakes with time requirements in the title, question is if the phyu count is added to the title to help tracking if it was successful.
[14:20] <F_> Problem is that phuys are not shown by default.
[14:21] <F_> Further problem is if it is wanted to discourage such possibilities of external challenges like beat levels in such and such a time.
[14:27] <@SimonN> Hi
[14:28] <@SimonN> Yeah, time limits in titles are in seconds, and the engine measures in phyus that are nowhere shown.
[14:29] <@SimonN> My hunch is not to support this further. But Proxima likes a general clock (counting up) in seconds. Thus there is weak argument to support this kind of level.
[14:30] <@SimonN> The fear is: When clock is too prominent, people will make time challenges, and then the engine should support those.
[14:30] <@SimonN> The absence of the clock is really a nudge away from making time challenges.
[14:31] <F_> I understand, yeah that's a legitimate concern. On the other hand it would show the desire for such chanllenges.
[14:31] <@SimonN> Hmm
[14:32] <F_> It is a deliberate decision which had it's reasons I can understand. Time limits can be used in some cases very detrimentally.
[14:33] <@SimonN> It's hard. I cut it in one go with cutting variable spawn interval, and the focus was always on cutting VSI.
[14:34] <@SimonN> No clock means less things to worry about.
[14:34] <@SimonN> Frees space in the panel.
[14:34] <F_> yeah by default
[14:35] <@SimonN> Well, technically, there is a clock whenever you have the tweaker open, it shows the current phyu.
[14:35] <F_> The phyu counter on the other hand is in some sense a clock though it's mainly meant for debugging.
[14:35] <@SimonN> And that, yes
[14:35] <@SimonN> We have to reel Proxima into the discussion.
[14:36] <F_> yeah, it's generally the question if there should be a forum post for broader discussion or not
[14:36] <@SimonN> Time in seconds is also ill-defined. In 2009, time ran from 4 seconds before first spawn. Then later, it ran from 2 seconds before first spawn.
[14:37] <@SimonN> Makes sense to warm it up again, yeah
[14:37] <F_> Well that's not different for the phyus either?
[14:37] <@SimonN> Phyus always have first spawn at 60.
[14:37] <@SimonN> Singleplayer merely starts at phyu 45 and multiplayer starts at phyu 0. It's all smoke and mirrors
[14:38] <F_> ah I see
[14:38] <@SimonN> Reason for this: I didn't want to break replays that count in phyus and assume first spawn at phyu 60.
[14:38] <F_> okay
[14:38] <F_> You could start the clock with spawn.
[14:39] <@SimonN> Pre-placed lix are interesting feature and need a decision for how long before first spawn they start walking.
[14:40] <@SimonN> It's possible to nail it all onto first spawn. Everything before is just eye candy.
[14:40] <F_> I see yeah.
[14:41] <@SimonN> In NL, pre-placed lemmings walk from start of time, which is ~4-5 seconds before hatches open.
[14:41] <F_> In that case it would just have to move to when that happens.
[14:42] <@SimonN> Yeah, difference between stragglers walking and first spawn is not so big in NL either. We may as well remove all difference and have stragglers start on first spawn.
[14:43] <F_> one possibility
[14:44] <F_> This depends in the end what the feature is ought to offer. But it is not implemented yet.
[14:46] <F_> If a clock is reintroduced then I would want the option to decide if phyu or time or no clock is shown. If you have to feature to disable clock then it would be an argument against supported timed levels.
[14:56] <@SimonN> Hmm. No clock by default, and you can choose to see phyus (with first spawn at 60) or seconds (with first spawn at ?, probably 0.00)
[14:57] <@SimonN> And trophies will always save with phyus, but display nothing/phyus/seconds according to clock on end-of-singleplayer.
[14:57] <@SimonN> * according to clock option.
[14:58] <@SimonN> I have a soft spot for no clock, because it clearly shows what the game is about.
[14:59] <F_> hmm
[15:01] <F_> That sounds like a good compromise. My perspective comes from level maintainance, how to make them viable.
[15:01] -__:#lix- lemmingsforums.net: Re: Different Types of Levels [Proxima] <https://www.lemmingsforums.net/index.php?topic=5787.msg93908#msg93908>
[15:02] <@SimonN> Level archaeology >_>;;
[15:02] <F_> yeah
[15:05] <@SimonN> Brushing and polishing them.
[15:06] <@SimonN> It's sensible and supports the general idea that Proxima wants the clock even for normal play.
[15:07] <F_> In a hidden way it's in already with phyu count, it just makes it more accessible. (Which can on the other hand in turn wake up desires.)
[15:08] <F_> I think it's worth the risk, but it's your decision and of the community.


The issue #208 'Editor: re-click window-opening button closes modal window' is I think an important quality of life feature wish. I think I'm quite used to the mechanism that reclicking closes the opened window in games or that one can click on another button to go to another window.

Issue#421
There is technically no error since if you download ldc2-1.26.0-windows-x64.7z as said in the build notes there is only one lib folder.
Dullstar probably downloaded the multilib version to which there is the installer as well, so it is nevertherless right to add the instructions for multilib as well.

(The build notes state explicitly: "Download the D compiler LDC, version 1.21.0 or newer;
choose the download that ends in "-windows-x64.7z":"
Nevertheless multilib should become standard since that's what the installer installs, Win 7 and Wine have only at the moment the known problem with LLVM. lib64 is as well the name for the 64-bit folder with dmd as well, so this would benefit from a rename as well.)

Nasty compiler bug as a reminder:
Class with unimplemented interface method compiles, links, then segfaults, if inherited through abstract base class -  Bugzilla 21321

"DMD 2.094.0 on 64-bit Linux.

    interface I {
        int f();
    }

    abstract class A : I {
    }

    class B : A {
    }

    void main()
    {
        I i = new B();
        i.f();
    }

This program compiles, links, and then segfaults at runtime once i.f() is called. The call to i.f() is necessary to trigger the segfault.

Expected instead: This program fails to compile.

The compiler should recognize class B as wrongly implemented because B doesn't implement int f(). This definition of class B shouldn't compile. (Or, if you disagree whether the definition of class B should compile, then, at the very least, the compiler should recognize B as abstract and the line "I i = new B();" should error. But I encourage that this empty definition of B itself be an error.)

The impact of this bug is that programs will compile even though their types do not satisfy their interfaces. This breaks a basic promise of the type system: We shouldn't have to call all possible methods in all possible derived classes at runtime merely to find what we should implement.

Workaround: Write "class B : A, I" instead of "class B : A", then we get the correct compiler error already for the definition of the class, even when we delete all code in main().

Related but different bug: "Unimplemented methods of interface are not reported as errors during compilation."
https://issues.dlang.org/show_bug.cgi?id=21184
In that bug, the program compiles, but fails to link."

Lix went through multiple physics changes. This affected levels and lead to adjustments. Although most levels is cared for it could be good to have an acessible documentation of physics changes across versions (from C++- to D-Lix and across major D-Lix versions).

For the change from C++- to D-Lix there are some aspects documented in a thread about singleplayer migration e.g.