Hi,

Double resolution

Lemmings 1 and Lemmings 2 were written for 320x200 VGA mode. The playing characters are 8 or 9 pixels high, walk ahead by 1 per frame, and builder bricks are 1 pixel high.

Lix is double-resolution: Characters are about 17 pixels high, walk ahead by 2 hi-res pixels, and builder bricks are 2 pixels high. More precisely, physics work with 2x1-pixel-chunks. All lix' x-coordinate is always divisible by 2. Only the y-coordinate may be any integer. A 2x1-chunk of land counts as solid as long as at least one of its two pixels is solid.

Where does this concocted rule come from?

In early 2003, I scripted levels for the freeware game Gravity Strike, this ran with hardcoded 640x480 fullscreen. In the early 2000s, CRT monitors were widespread and could display any resolution sharply -- up to a point. But every monitor could display 640x480, thus Gravity Strike's author decided to hardcode this size.

I wrote GS Lemmings, a Lua script that ran in Gravity Strike, removed everything that the game normally provides (spaceship, terrain, enemies, status panel) and instead loaded my own graphics and ran my own logic. This is the birth of double resolution: It was easiest to work with what I had.

In Lua, apart from numbers, everything is a reference type, everything is garbage collected. I had no idea what was happening under the hood. Would arguments be passed by value or by reference? What is the difference between calling functions object.func() or object:func()? No idea. Programming was magic. If it failed, I would guess and re-try. I would never search the web for help because I found the technical explanations hard to understand. (Solution: object:func() is equivalent to object.func(object)).

In 2006, I finished my civil service -- back then, it was mandatory for every male German to either serve in the military or work civil service for 9 months. I had some time before university started in fall 2006. What to do?

I learned C++ and began the work on L++, a Lemmings variant with hardcoded 640x480 fullscreen resolution. Why would I do that? It worked in Gravity Strike, and I still had a CRT monitor that could display any resolution well. I kept my rule that the tiles could be anything and need not stick to 2x2-blocks. I would not upscale. I would load the tiles as they came from disk. That was easiest.

The 2x1 physics instead of 1x1 come from the desired walker speed. It was simpler to move always by 2 horizontal pixels than to write a basic walk action for 1 pixel, then call that twice per frame. The walk cycle would look at two pixels and deduce from them together whether the 2x1 chunk was air or solid. I didn't expect any odd cases from the rule.
Of course, there are odd cases (I should link the example gifs).

L++ became Lix in 2010 and got ported to D in 2015. Like Theseus's ship, all code, graphics, etc., got replaced over the years, but really, 2006 L++ was the first version of Lix.

With my own game project at 640x480 fullscreen hardcoded, I spent considerable time on choosing my first laptop in 2007. I wanted 4:3 aspect ratio for my laptop screen, but that was getting unpopular. Laptop computers were booming, and widescreen displays had gotton common. I loved 4:3, why would anybody want 16:10? Documents, websites, code, etc., everything is vertical, but most importantly, 16:10 TFT displays would blur at 640x480 hardware fullscreen.

Lix/L++ is now 12.5 years old and programming been my longest-standing hobby. Now, Lix supports any screen resolution, windowed or fullscreen. The user interface scales smoothly, a major design goal during the 2015 rewrite.

Even with the user interface resolution decoupled from the physics resolution, Lix still has 2x1-hi-res-physics. I don't like how confusing the 2x1-block rule can be. But it has been so deeply ingrained since the beginning. It allows for more graphical details on tiles. On the other hand, it forces tiles to have more details to look good.

tl;dr: It was easiest because of the hardcoded 640x480 resolution in the early versions. And now too much depends on it to get rid of double resolution.

---

Passage of time

More rambling, because I'm in the mood.

I feel like time is passing much quicker now. In 2003, GS Lemmings was released with 20 levels after maybe 2 months of work, with some bugs of course, some crashes, some reliance on 60 FPS -- Yes, the game would skip some physics logic, but not all physics logic, when the machine was slow! Horrendous bug! -- but it worked well enough to play. The 2-3 regulars on the Gravity Strike forums loved it.

Where GS Lemmings took 2 months, L++ required 3 years before I felt ready to post it on Lemmings Forums including networking mode. A more complicated feature, sure, and I wrote the game engine from scratch instead of relying on a host game.

It's been nearly 4 years since I started the rewrite to D in early Feburary 2015. I'm very very happy with the rewrite, I've pushed the game further, and I'm supporting different operating systems better than ever before. But are there killer features in D Lix that weren't already there in C++ Lix? Did the fundamental game take 2-3 years to implement in 2006 to 2008, and the 10 years after it has been only polishing?

Sometimes, I miss the days where I would implement buggy crap with trial-and-error, but have something cool to show after minimal development time. The 15-year-old kid inside me wants to feature-bloat on some side project. And the 5-year-old inside me wants to play that and get even more wild ideas.

When time passes linearly, memories increase only logarithmically. You remember so much from when you start a new activity. But then you get proficient, and you don't remember as much when you're performing by routine.

Consider the time after my civil service. I learned a good chunk of C++ and wrote a prototype-ish game, L++ with some singleplayer, in half a year. Then, I had nearly no other hobbies, obligations, or girlfriends, and could focus fulltime on L++. Now, 12 years after, I had comparable time after finishing the PhD, but I haven't started a new hobby in that time. But I already have so many hobbies -- games, Lemmings Forums, speedruns, tech projects -- that I've enjoyed in that time. They merely generated less impactful memories than starting a new hobby typically generates. That's why time seems to fly quicker.

At least I've finished xmas2018 on time.

-- Simon

Hi,

Let's play Lix Multiplayer on Sunday, December 2 Saturday, December 1 at 19:00 UTC. Who's in?

New and exciting! At latest 3 hours before the session on December 1, I will release Lix 0.9.22 with:

• Bugfix against the crashes on huge maps: I'll provide a 64-bit executable that shouldn't crash anymore, and will encourage you to play the multiplayer session with that. Let's test some huge maps that night!
• Xmas2018: a Holiday-themed Lix singleplayer pack with 24 levels by Forestidia and me. Dedicated topic and preview images will appear next week!
  

-- Simon

Flopsy found: https://www.youtube.com/watch?v=JpekjPkzN24&t=380

Has some similarities to the intended route. Looks hard to prevent, merely finnicky.

-- Simon

Hi.

Lix die when they leave the map. I'd certainly like to keep this. But how should the terrain check beyond the ceiling behave?



0.9 ceiling rule: When a lix checks terrain beyond the ceiling, the game answers with the highest pixel still inside the playing area.

Problem (see gif above): Walkers see the final builder brick as an infinitely tall wall and turn at this brick.

One may consider this a logical corollary from a reasonable rule. But many consider this unintuitive. In particular, the builder herself dies because she doesn't check again for terrain after building the infinitely-tall brick.

Here's an alternative to the 0.9 ceiling rule:



Open ceiling rule: When a lix checks terrain beyond the ceiling, the game answers with air.

Problem (see gif above): This thin bar is only 8 hi-res pixels thick. The lix have to climb 12 hi-res pixels to get out of bounds, and they happily do that because they can ascend up to 12 pixels into air.

One may consider this a problem of the level and thicken the steel bar here.



Compared with the 0.9 rule (left gif), the open ceiling rule (right gif) has another downside: Before climbers die, they see a ledge on top of the climbable wall. Instead of peacefully climbing into their death as in 0.9, the open-ceiling-rule climber will now ascend/hoist into death.

One may consider this a cosmetic problem and not care.

Or one could special-case the beyond-ceiling terrain check per skill: Climbers check with the 0.9 ceiling rule, and walkers check with the open-ceiling rule.

What are your opinions?

-- Simon

NL 12.3.0

Install freshly. Start game, start a level with small width and small height. Have a huge screen. The map is blurred. To fix, disable smooth resampling, both for menu and for game.

Expected instead: Smooth resampling for game is alrelady off by default.

-- Simon

Hi,



Over the weekend, I visited Forestidia. We have a relationship; some forumers have already guessed that.

Flopsy and Lucia, his girlfriend, spent a week in Berlin for vacation. We decided to meet them!

At their hotel, Forestidia showed the Prince of Persia 1 and Commander Keen 6 speedruns. I gave the couch commentary. Afterwards, we went into town for lunch and smalltalk.



Here is a picture of Flopsy (left) and Simon (me, right).

This picture is confusing in light of the topic title "Double Date"; Flopsy and I are not in a relationship with each other. But the girls preferred not to have their pictures posted on Lemmings Forums.

---

Forestidia and I went to Tierpark, a large zoo in Berlin.

The Tierpark has porcupines -- both new-world porcupines (these sit in North American trees) and old-world porcupines. The particular old-world porcupine species in Tierpark is the Indian Crested Porcupine, a relative of the African Crested Porcupine that you see in my avatar.



Here's a happy Simon next to 3 porcupines cuddling in the corner. Those 3 porcupines are lying next to each other, touching. The middle porcupine faces leftwards, the othes face rightwards. Such social animals, they don't sting each other with their quills.



Here's a close-up. This porcupine sleeps in the shade, avoiding the afternoon sun. The hair fits along the body, the quills are down in peace. Who wouldn't want to cuddle?

I'm sure Flopsy remembers how much I raved about seeing these porcupines.

-- Simon

Lix 0.9.17 has:

• A level is identified by its full filename (path within levels/ plus the file's basename).
  
• Identical level files in different directories are considered different levels for replay-to-level matching and for trophies (checkmarks).
  
• Within larger sets of levels, it's popular to have ranks, i.e., one directory per 30-ish levels of that larger set.
  

Problems of 0.9.17:

• When a level moves between ranks (e.g., we reorder levels in lemforum), that level's replays will point to nonexistant file and that level's trophies are lost.
  
• The level is the unit of culture. The rank or the pack are arbitrary distribution methods and should not count towards level identity.
  

Ideas:

• Consider two levels the same when they have the same basename (= the tail of the full filename that is independent of directories) and the levels have identical level titles and authors.
  
• This treats the level directory as an associative array (a.k.a. dictionary) where a key is level title plus author plus basename (filename independent of directory). A value is then a level (the data in the file, not the file itself).
  
• Store trophies (checkmarks) by key (basename, level title, author) and let replays point to keys instead of to full filenames.
  
• Given a level file, it is trivial to determine its key. For each level, it remains fast to retrieve trophies.
  
• To match replays back to levels, accept a dent in performance: When you have a key (filename without directory, level title, author), e.g., because a replay points to that key, you must first list the entire tree and then open all listed files with matching basename (usually 1 match but might be a couple more) to compare title and author.
  
• To get the performance back, cache the key-to-full-filename resolution. While Lix is running, slowly index all files in the tree in the background. This would also make the search feature faster on Windows (slow harddisks, Windows itself, and Windows's virus scans nuke the search's performance).
  

Questions

• When do you consider two levels the same for trophies (checkmarks) and replay-to-level-mapping? When only decoration changes, the level should probably still count the same. How about renaming the level file? How about moving the file or changing the level title? How about changing the skillset or number of lix?
  
• Should the basename be part of the key? Or should the key consist only of level title and author? Should it consist of other things?
  
• Or continue to map replays/trophies to levels by full filename alone, accepting above problems of 0.9.17?
  
• For a selected level, I'd like to list all replays that point to this level. How should I implement that? Either I'll have to index the entire replay directory on demand (awfully slow), index the replay tree slowly in the background (feels weird for replays, but maybe okay), or require that replays for a level be put in a certain directory structure (but Nepster complained about Lix's replay directory structure, he wanted to sort replays by level position first, only then by solved/manual/proofs/...).
  
• Can we require that a replay's basename should start with the basename of the level? That makes it much nicer to find replays for a given level file.
  

Older topic: Musings on level culture, 2017-07.

-- Simon