Good luck pushing this neat set!

Even though I'm no match as an artist, I have a secret hint for spriting: Don't be afraid to use light and dark colors within the same tile, or several different hues within the same tile. Things will look more engaging. Compare my boring 2006 bricks (left) with geoo's nice construction bricks (right).



-- Simon

Thanks for taking the time to reply in detail.

We have similar opinions and judgements on VSI. Nonetheless, it's valuable to distill a longer argument/opinion from IRC into a summarizing post.

I've claimed that the bad existing user interface for VSI is a reason to for everywhere-fixed SI. That wasn't a valid argument, because the user interface can be made better. You've focused purely on game design, that holds more water.

-- Simon

Thanks! Happy happy about the improved rendering.

It's interesting how the number of lix makes such an impact on speed. Will think about it more. They're not optimized in memory for fast copying. I haven't put detailed profiling for savestating/physics updating in.

-- Simon

Status: Added a copy of the player to the ZIP.

---

The editor has not been updated. The latest version remains V1.40n, which can be downloaded here:
http://www.neolemmix.com/old/neolemmixeditor.zip (For new users)
http://www.neolemmix.com/old/NeoLemmixEditor.exe (For existing users with older versions)

Contents of the new-user-package:
NeoLemmixEditor.exe  styles
NeoLemmixEditor.ini  ReadMe.txt

I recommend to add the NL player to this new-user bundle.

Reasoning: People get stuck on how to test levels. Improving the error message is good. Designing the error out of existence is better.

-- Simon

"Transforming" a lemming into a new class seems "unnatural" to me.

Yes, I agree that the lemmings should not be replaced. Many of their fields are persistent between jobs. Objects should model the real world: if we don't think of lemmings to be replaced, we shouldn't replace them. My proposed solution is to replace the behavior object instead.

This solution is compelling in hindsight. I have described its advantages in parts 2, 3, 4. But a class hierarchy is costly, even though it's idiomatic in OO design. To justify that cost, I will compare alternatives. It's a difficult design problem, and personal preference plays a role, too.

OO with Simon, part 6
Comparison of all-in-base-class, tagged union, and state pattern

Bloated single class: You put special fields for builder, special fields for faller, ..., all into the Lemming class. They're right next to job-independent fields like position or exploder timer. All fields are mutable, and all jobs can access everything.

Widespread access to mutable fields is a concern. Whenever you have a bug, you must inspect lots of code for how it affects the memory. The compiler cannot help.

Dispatching from the monolithic class via manual function pointers (end of part 5) doesn't solve the problem of widely-visible mutable fields.

Tagged union: I assume this is meant by the Delphi cased record trick. You reserve enough memory to hold the job-specific fields for any single job, and put this as a value field (struct, record) into the Lemming class.

Even though the builder variables now sit in the same memory location as the faller variables, you get to name them per job as bricksLeft and pixelsFallen.

This even more type-unsafe than the bloated base class. You can access the builder's fields even when you're a faller. But because they're in a union, not in separate locations, you overwrite the builder's fields when you write to the faller's fields.

A feeble benefit might be speed while making a savestate. You can memcpy the Lemming to save it entirely, and copy fewer bytes in total than with the bloated base.

State pattern: This is my solution explained in part 2. We make an abstract class for the behavior, subclass it many times, then have the lemming carry a dynamically allocated object for the behavior.

A lemming can have only one state at a time. It's not possible to access wrong fields, and the compiler checks that for you.

Old state objects don't cause long-term psychologic damage to the lemming when he gets a new state object of the same type.

Sometimes, you must access fields of different state classes nonetheless, especially during transistion between states. You can use an explicit dynamic cast -- which angers the object-oriented deities --, or write lots of specialized methods. And herein lie the problems of the state pattern.

About that, I would love to ask someone stronger than me at design for ideas.

NL might not get additional skills. In that case, don't trade a debugged design for undebugged theoretical soundness. The point of a design to minimize the cost of changing and maintaining it. If you don't want to change much, keep the existing thing.

-- Simon

Version 0.2.17 uploaded, with faster dark drawing.

To improve the performance of turbo-fast-forward, I'd like to try savestating less frequently during turbo. Right now, performance is mediocre, and Nepster is right that it should be faster.

-- Simon

Here are hands-on profiling results from my 9-year-old laptop. This is from a build with profiling, but without other debugging instrumentation. Dark drawing (eraser piece drawing) sucks. The testing map was geoo's playground, a huge map with about 10 % dark pieces.

Lix version 0.2.16 profiling results from 2016-02-09 17:49:01.
Unit of time: 1 us == 1 microsecond == 1/1000 of a millisecond.
At 60 frames per second, 1 frame takes 16666 us.
                                       avg/us   min/us   max/us   amount
Level.drawPos to RAM DARK                 269       25     3407      123
Level.drawPos to RAM NOOW                 610      418      803        2
Level.drawPos to RAM NORMAL               428       10    10693     2789
Level.drawPos to VRAM DARK              47191    39122   131871      246
Level.drawPos to VRAM NOOW               2615     2431     2742        4
Level.drawPos to VRAM NORMAL              156      142     1190     5578

The averages are average times per piece, not average times of rendering the level.

Drawing no-overwrite pieces is also slower. But the sampling rate is too little, geoo's playground uses only 2 no-overwrite pieces.

Good suggestion by namida from IRC:
<namida42> wouldn't it make more sense to test with *several* real life maps, since that's going to give a more reasonable picture of how ti performs in actual usage, rather than unlikely test scenarios?
<SimonN> yeah, I should set up some kind of automated test >_>

-- Simon