optimisation idea: do some fancier movement collection where possible like you do with objects

[increpare]

trafficstars

[ moving player ] -> [ player ]

produces

(83) DOWN [ up player ] -> [ player ]
(83) DOWN [ down player ] -> [ player ]
(83) DOWN [ left player ] -> [ player ]
(83) DOWN [ right player ] -> [ player ]
(83) DOWN [ action player ] -> [ player ]

Why not allow "moving" to remain on the lhs if it's not needed on the right? (A: because it makes things complicated ^^ )

I mean, just to have

DOWN [ moving player ] -> [ player ]

in the compiled version

[increpare]

todo: try track down again what happens with property-objects and do something parallel (Why can't these two systems work uniformly?)

[increpare]

[moving barrier]->[barrier]

goes to

(100) DOWN [ up barrier ] -> [ barrier ]
(100) DOWN [ down barrier ] -> [ barrier ]
(100) DOWN [ left barrier ] -> [ barrier ]
(100) DOWN [ right barrier ] -> [ barrier ]
(100) DOWN [ action barrier ] -> [ barrier ]

but

[barrier]->[stationary barrier]

goes to

(100) DOWN [ barrier ] -> [ stationary barrier ]

lol

[ClementSparrow]

In concretizeMovingRule, you do something that I have always found strange, which is that when a rule contains a single instance of an ambiguous movement keyword on the left-hand side, then the rule is expanded for all possible values of that keyword, and all of its instances in the right-hand side are replaced with that value.

I think it is what happens here, even if "moving" does not appear in the right-hand side. The rule gets expanded anyway.

So, one simple fix seems to only do that expansion if the keyword appears at least once in the right-hand side? (It seems sensible to apply the same logic on object properties, too.) But that code is complex and so are the implications of changing it.

[increpare]

This touches on the core of how pattern matching works, and isn't necessarily an optimisation because some trade-offs might have to be made.

Right now knowing that the LHS is fully concretised allows for easier pattern-matching in the core-engine. Trying to change it would necessitate changes to, for example, checks for the movement masks - instead of checking for checking that all bits are set in the mask cellRowMask_Movements.bitsSetInArray(level.mapCellContents_Movements.data) I'd want to check that there's at least one common bit per movement layer, which is a bit more complicated...