Screen updating

[Simon]

Hi,

here are some issues and questions from the most recent Neolemmix session at Ichotolot's.

1. Pause the game. Right-click a lemming. That lemming will get the highlighting arrow once the game unpauses. There is no other feedback. Expected instead: The screen updates immediately after the click and shows the highlighting arrow, so we can correct a mistake before unpausing.

2. Beat or fail a level. The level exits to the results screen. The replay cannot be saved anymore at this point, and playing the level again does not replay the old replay. Expected instead: The game should not erase data only because the last lemming left. Replay can be saved after level beat.

[23:31] <Akseli> "Beat or fail a level. The level exits to the results screen. The replay cannot be saved anymore at this point, and playing the level again does not replay the old replay."
[23:31] <Akseli> ---> can be saved
[23:31] <Akseli> by normal means
[23:32] <Akseli> (pressing u)
[23:32] <geoo> sure didn't work for me in the lemmix editor playtest mode
[23:33] <Akseli> yeah not there, there isn't even results screen in that case
[23:34] <SimonN> that is the standard method of playing levels though

geoo had this issue, not I myself. I don't know what has been tested exactly.

3. What's the order of drawing one-way arrows? What's with terrain drawn on top of one-way arrows? The cog contest level has lots of terrain, some behind, some in front of the arrows. I believe you aren't rendering the level 60 times per second, what is the magic behind this?

4. During the game, there is no visual feedback whether a replay is running or not. Expected instead: Large fat visual clue during replay, because this is an important mode different from normal play.

-- Simon

[ccexplore]

3. What's the order of drawing one-way arrows? What's with terrain drawn on top of one-way arrows?   The cog contest level has lots of terrain, some behind, some in front of the arrows.

I'm not sure what NeoLemmix may or may not have changed in this regard, but have we ruled out errors in level authoring?  Traditionally in regular Lemmix, one-way arrows are just like any other objects like traps or water.  They are rendered after terrain, unless a flag is set to tell the object to not overwrite terrain pixels, in which case they end up behind terrain instead.  This is not normally used (nor encouraged) for one-way arrows, but it's certainly at the discretion of the level author to do so.  There is also a flag to only draw pixels of an object over terrain.  That flag is primarily designed for one-way arrows so that when the object (which is rectangular) is overlaid over non-rectangular terrain, you only see the arrows over the terrain and not also in the surrounding empty space.  That flag is recommended to use for one-way arrows, but also at the discretion of the level author.

Or perhaps I totally misunderstand what you are reporting here, since I don't quite understand the comment about rendering 60 times per second.

[Simon]

It's possible to mark both the arrows and lots of the terrain as no-overwrite, then add some normal-overwrite pieces. Ignoring how terrain overlaps other terrain pieces, this gets us two layers of terrain for the OWWs, one in front and one in the back. Is that how it works, and is it feasible and fast?

In the questioned level, there are arrows that appear both in front of some pieces, and behind others. Strange and exciting!

Gadgets, including OWWs, are drawn individually every physics update anew. I fear it's expensive to do lots of terrain rendering each physics update, that's why I'm asking.

By rendering terrain, I mean making the entire level-spanning terrain bitmap and air/solidness mask out of the individual pieces, done once at level start.

-- Simon

[ccexplore]

I can't speak to how Lemmix implements rendering, since I don't believe I ever communicated any details of how graphics rendering works in DOS to Eric (since from a level solutions standpoint it is arguably irrelevant); I pretty much left that part completely up to him.  The DOS game's code IIRC, the flags are just passed to the blitter function and there is special blitting code to handle those cases.  The order in which terrain and objects are rendered are unchanged by the flags; the blitter just basically does extra work during blitting to create the equivalent effect.

I haven't actually completely disassemble all the relevant DOS game code around graphics rendering so this is partly conjecture on my part, but with how DOS handles the flags, there should be no need for it to ever go through the full list of terrain again during each frame update.  It is sufficient to just keep one single bitmap for the state of all terrain in level including updates due to skills, blit out the portion that's currently visible, and then blit out the next animation frame of each object and lemming over that (likely with the obvious optimization to not render anything that's completely outside the current view).

The way DOS handles this does seem to imply it should not be possible to see the same object being in front of some terrain but not other, so I suspect Lemmix engine probably does something very different.

Worth keeping in mind also that the frame rate in DOS (and probably in Lemmix as well) is only around 17 frames per second, plus it runs at lower resolution than lix does.

[namida]

1. This is a glitch that's slipped through the cracks. Although I believe there is feedback (although not specific to which lemming was highlit) in that it plays a sound upon highlighting. IMO it's a minor enough glitch that there's no need to release an extra update to fix it. (If you really want to see which lemming you've highlit, eg in a crowded situation, advancing or reversing one frame will make it display, no need to fully unpause.)

2. Ceasing gameplay when the last lemming leaves is consistent with other engines - including Lix, I believe. The difference here is that NeoLemmix doesn't have a "restart level with replay" function when level ends; however this is definitely something that can be added for V2.00n.
In regards to the IRC discussion, Akseli is completely correct about all cases involving NeoLemmix, as well as involving a Lemmix player (including traditional CustLemmix used for playtesting traditional Lemmix levels from the NeoLemmix editor). The traditional Lemmix editor (ie: EricLang's version unmodified) does not provide a results screen full stop, but rather "freezes" once the last lemming leaves (in quotes because it's not a freeze in the sense of crashing; just as in it stops doing anything until you exit playtest mode); a replay can still be saved at this point IIRC but the Lemmix Editor has a different hotkey than the various (Neo)Lemmix players do. I can't say for sure though, as I never really used the traditional Lemmix editor (personally I preferred LemEdit back then, and used Lemmix players for playtesting).

3. This is nothing to do with EricLang's code and is a NeoLemmix feature. Since Lemmix did not support alpha blending (and the same holds true currently for NeoLemmix, although the latter does support alpha channel data in its files; it just doesn't make use of that data currently), EricLang's code repurposed the alpha channel of the image for other uses, such as marking a pixel as solid (to differentiate between "blackground, non-solid black" and "solid black like eg. in the Crystal set", according to source code comments). Virtually all functions that need to check if there's terrain at a given pixel - including that of determining the "draw on terrain" function - check this rather than checking the color of the pixel. NeoLemmix simply takes this a bit further; with "is this pixel solid for the purpose of Draw On Terrain?" and "is this pixel solid for the purpose of lemmings interacting with it?" are two different things; although the former never happens without the latter. One-way walls (as in the trigger areas of them) are also not applied to pixels that are not "solid" for the purpose of Draw On Terrain. When desgining a level, the level designer can choose which terrain pieces do or don't set the "solid for Draw On Terrain" flag for their pixels. The end result is - one way walls do not have to have smooth edges when intersecting with other terrain (rather than with non-solid area), unlike in DOS L1 / traditional Lemmix. (On a side note, this may have to be handled differently in V2.00n, as I intend to support alpha blending properly.)

Example of this effect in action, from LPIV Twisted 7 (click to show/hide)

4. I will keep this in mind.

[ccexplore]

Thanks for the explanation.  In terms of what Simon was talking about (re-quoted below), your explanation would appear to confirm it is a non-issue, for both Lemmix and NeoLemmix.

I fear it's expensive to do lots of terrain rendering each physics update, that's why I'm asking.

By rendering terrain, I mean making the entire level-spanning terrain bitmap and air/solidness mask out of the individual pieces, done once at level start.

[namida]

Indeed, the terrain bitmap is not re-rendered every frame. The way it's currently handled is that the terrain bitmap is stored in one image ("World" is the variable name used in the code), and the on-screen bitmap in another (named "fTargetBitmap"), each frame, fTargetBitmap is updated by drawing over objects / lemmings / etc by copying from World (effectively erasing them, but with the contents of World rather than blank space), then the new frames are drawn onto it. Special routines are used to handle cases such as No Overwrite, etc.

This has been changed very little, if at all, from how EricLang's code handled it, aside from the aforementioned features relating to Draw On Terrain (which only change which pixels are or aren't drawn from a given interactive object).

[Simon]

1., 4. Right, these aren't critical, but something to keep in mind.

2. Is probably best solved by making more obvious what hotkeys are possible at what time. Automatic level ending is normal. Data should not be lost at end of level. If the data is still there to be saved, all good.

3. So, the land is rendered once at the beginning, and the OWWs are rendered every physics update. Whenever the OWWs are rendered, they examine the land, which carries special information, and draw only some of their pixels. Makes sense.

-- Simon

[namida]

2 is best solved by - and most likely will be solved by - a more obvious "Save Replay" button on the postview screen.

3. So, the land is rendered once at the beginning, and the OWWs are rendered every physics update. Whenever the OWWs are rendered, they examine the land, which carries special information, and draw only some of their pixels. Makes sense.

That's a good way to sum it up.