Excellent reading. I don't understand everything, yet I'm looking forward to the Fun compilation video like a 5-year-old for christmas.

Precise definitions wanted! PUC is what?

A frame is an update of the emulated hardware (roughly 50 per second), not an update of the physics (roughly 17 per second).

What, then, is a lag frame -- it cannot be purely a frame in which the physics don't advance, even though they should. Is it an extra frame (in the 50-frames-per-second meaning) that is inserted between two physics updates? Which would mean 3, instead of the regular 2, non-physics-updating frames between physics-updating frames?

-- Simon

Quote from: namida on March 02, 2016, 07:49:08 PM

QuoteLix multiplayer trap handling

I'm meaning in terms of graphically - how does it handle drawing the correct colors?

General color handling: We generate multiplayer spritesheets at runtime from the spritesheet and a table of color replacements. This works when we constrain ourselves to 10 to 20 colors.

Traps aren't recolored like that. The trap killing anim shows whatever is drawn in the file. Looks hackish. It's expensive to implement trap recoloring in my program design.

-- Simon

Lix multiplayer trap handling: When a trap is open, lems from different teams can be eaten at the same time, but at most 1 per team. When at least 1 lemming has been fed to the trap, it starts one cycle of killing animation. During the killing animation, the trap is safe for all teams, even for those that haven't fed it.

-- Simon

It's design debris.

I've planned two buttons in the D replay browser: One to play the included level, one to play the pointed-to level.

I haven't yet considered to apply replays to a third, pickable level. But I'd like to support the renaming workflow. Many people work like that. When you routinely edit replay/level files by hand, that's a sign of missing functionality.

QuoteTry to load the level that is specified in the first line of the replay file. Currently this is only used to display the level title. So why not use it as well to load levels?

This inconsistency is a bug. The program may get away with opening fewer files. >_> But it has confused me, too, when I ported the replay browser. It's annotated in the D source as an opportunity to redesign.

QuoteHow can I play the replay abc-Nepster.txt with the level abc_V2.txt?

Your way is already the easiest. >_> Erase the level from the replay, and change the pointed-to-level filename. When you erase the level from the replay file, the game uses the pointed-to level.

QuotePS: Line 5 in the replay files reads +PLAYER 0 Garden Nepster. I can make sense of most of the other stuff in the replay fine, but what information does Garden store?

Garden is the player's team color.

The singleplayer lix coloring is implemented like the multiplayer syles. I named the singleplayer color "Garden" in 2008 and haven't changed it since. Inspiration came from the Lemmings Revolution manual: The manual called the regular strain of lemmings "Garden Lemming", to distinguish it from water and acid lemmings.

-- Simon

Excellent and detailed feedback, thanks!

I will keep the manual management in the back of my head. VRAM allocations are wrapped in GC-ed D classes. The VRAM is disposed on GC, or on manually calling the dispose method. Mistaken accesses to freed VRAM should fail asserts in my wrappers. This shouldn't be too error-prone to manage manually.

Good to see that frequent GC'ing doesn't affect the performance much.

-- Simon

Thanks for the reality checks!

I had the bug on the backburner for a while. I haven't yet investigated any documentation or forums. >_>

Debugging build with and without GC-hack. 0.2.32 is the commit right before the hack, 0.2.33 has the hack. Built with debugging symbols in the D code. Regular C debuggers understand them, they read like mangled C++ symbols.

There are debugging DLLs of Allegro 5. I haven't built against them. If you consider them a good idea, I'll try building against the debugging DLLs. For exact info about what my build uses, see my build notes for Windows on github, section "Installing Allegro 5".

I haven't tried whether the existing Lix Windows executables still run when we swap the DLLs, maybe with renaming the DLLs, but without recompiling Lix. I don't know how DLLs are linked in -- by symbol name or by binary interface. I'd assume by symbol name, so swapping DLLs might work.

-- Simon

My solution to Laser Deathroom 2 is less fiddly than Nepster's. Yet I see how the level attracts fiddliness.

Ramond loves Mile High Club. I have seen the solution and consider it more interesting than Laser Deathroom 2. The trick to Mile High Club is exciting, and will certainly stay in C++ Lix. It's the same in D Lix, but I'm unwilling to guarantee whether it stay in forever.

<Ramond> yes, are you planning to [change related physics?]
<SimonN> No. But I don't want to give a final word on this.
<Ramond> who will? the userbase?
<SimonN> nobody will give you powerful guarantees on this. If you want stable physics for the next 10 years, build against nuke-glitch-Lemmix.
* Ramond has left

Stop reacting like an offended teen girl :> I don't want to make the decision. Has anyone solved the level? Would like strategic input on the trick.

-- Simon

Icho and I have have looked into the joystick crash on Windows. This bug is very hard to trigger, we've hit it only once. Key ingredients, as Clam and Nepster have suggested, are turbo-fast-forward, then framestepping back.

Theory: I don't run the D garbage collection (GC) during the game, only after each level. Automatic GC would kick in when RAM is scarce, which doesn't happen during play. But maybe VRAM gets scarce? This doesn't trigger the automatic GC, because RAM is not yet full. Yet somehow, we might get bad VRAM bitmaps, even though A5 always returns meaningful pointers on bitmap creation.

Therefore: From 0.2.33 on, I'm forcing the GC to run during play, whenever old savestates aren't needed anymore. GC'ing frees the savestates' RAM and VRAM. Let's see whether you can repro the crash still. When you framestep back in large jumps, holding down the button, this can make the GC run every frame. Let's see how much of a performance hit you take.

Get 0.2.33. You don't have to test immediately. But please report the crash again, should it occur from now on.

-- Simon

Quote from: namida on February 28, 2016, 04:49:10 PM
I don't feel it's appropriate to give an explicit guideline of "use regular autosteel, not simple autosteel", precisely because of the kind of levels mentioned before.

So mossy steel decoration is still common, and people want it in contemporary levels? Then yeah, recommend either autosteel.

Quoteis anyone seriously going to think the mossy parts in Steel Works are, in fact, not steel?

Many authors feel the moss should be steel.

I feel the moss should be destructible.

The indestructible moss has always rubbed me the wrong way as a child. I've never talked about it much. I should probably make a dedicated thread for steel decoration. I have to solve this design question for Lix anyway. Lix enforces regular autosteel, and NaOH has reacted by duplicating some of her tiles: one as steel decoration, one as dirt decoration.

QuoteThe ultimate logic behind this point is that autosteel usually ends up being more accurate and easier to do than manual steel ever does. Many situations in where it is incorrect, Simple Autosteel solves the problem. Ultimately however, there is no difference to the person playing the level between a level that uses autosteel, or even one that uses manual steel areas that just happen to be laid out exactly the same way that autosteel would; so it really does come back to "don't be deceptive" more than anything else. One reason for stressing it is that in DOS / Lemmix levels, and possibly even Lemmini levels, steel areas often tend to extend a bit beyond the edge of the actual steel terrain; this is nessecary in those engines, but gives very undesirable results in NeoLemmix due to the better handling of steel. Made-for-NeoLemmix levels would, I imagine, rarely use manual steel areas in the first place - autosteel was a feature long before any dedicated NeoLemmix content (even my own) existed.

I agree that "don't be deceptive" is the most important goal.

I have read this quoted paragraph 3 times now. Is this (a reason to discourage manual areas), or (a reason to want (simple autosteel along with regular autosteel) instead of only regular autosteel)?

-- Simon

Quoteregular terrain piece is positioned over the top of the steel piece, regular autosteel will mean the affected pixels are now non-steel.

Understanding the difference, I'd formulate the guideline as "use regular autosteel", a stronger guideline than "rely on autosteel". What looks like steel is steel, and what looks like dirt is dirt. That's good and conforms to the guideline to be explicit.

-- Simon

Very comprehensive.

I love how use-fewer-lemmings is already a guideline. I've thought it meaningful, and it improves NL performance on my old machine, but never wrote a post on it.

About 2. (Avoid deceptive elements)

Do note the "mislead the player in a negative way".

What is a negative way? Rule of thumb: Players with perfect judgement could solve the level by merely looking at it. They don't have to explore the level for hidden gadgets. This rule-of-thumb oversimplifies slightly, because entrance order isn't visible. Yet level designers shouldn't have to visualize entrance order.

About 3. (Indicate unobvious elements, such as entrances spawning lemmings with pre-assigned skills)

the eventual plan is to [...] should that example be removed?

Point out that the change is on the radar. Leave in the guideline nonetheless. I estimate that you won't implement hatch icons in the upcoming month.

VGASPEC files for these, but if you don't already have them, you can download them here.



About 4. (Rely on autosteel wherever possible.)

I have no idea about the difference between simple autosteel and regular autosteel. Which should we use? Why is it best?

About 7. (Unless only using the traditional 8 [...], remove unused skills.)

I'm leaning towards two rules. Traditional 8 with whited-out skills are much easier to locate.

-- Simon

Object-oriented design with Simon, part 7
"Object" must be empty

It is an egregious offense to call a self-defined class Object or Instance.

If you name your own defined classes Object or Instance, you will unnecessarily overload human language. There is always a better name than Object, and almost always a better name for Instance.

The only merit to have a class Object is to have a universal root class. D defines Object as such, which would be no problem if it were an empty class, usable like C++'s void*. But this was before D got powerful templates. Therefore, Object defines opEquals as a hook to override == instead of leaving comparison to templates and duck-typing. I ran into subclassing problems intrinsic to D's Object.

D is still a low-Simon-rant-% language. :>

-- Simon

Yeah, we have good topic titles often. Authors are aware.

The rant was prompted by the IRC bot relaying "NL doesn't work on my computer [Simon]". Clam wondered if it was my machine, or if I had replied to someone else. geoo suggested that I collect my rants in a new topic, "My new topic where I post my new rants that I have typed on my new computer."

Ordering of fields in namida's list: namida has to look at the list more than anyone, and he wanted the list with tags in front, so it's okay. Right, a forum isn't a featured bug tracker. It's best for NL, because the NL users all are LF posters and don't have to register anywhere else.

-- Simon

Agree with "../" not descriptive enough. In the root dir's blah-blah text, I've told people to play the tutorial, then click ".." when they're done. Instead of telling people what a button does, we should try to improve the button first.

I have never allotted vertical space to anything but the file list. With the file list's paging button, there are 20 files per dir shown at once. The lemforum pack has 40 levels per dir, a multiple of 20, probably because of this restriction. With a scroll bar, there is no advantage anymore in sticking to a multiple of max. visible entries. We can shorten the file list vertically.

I like ccx's breadcrumb navigation with buttons per nesting level, [levels] -> [single] -> [lemforum] -> Simple. Either in addition to an improved "../" in the top left, or instead of it. I haven't yet pondered how much screen space we should invest on the tree navigation.

-- Simon

An excellent suggestion. I'm looking forward to see exactly what an undoable unit of work should be.

-- Simon