Edit Simon: I've split this off Fork: SuperLemmix.

---

I'd probably want to try and find a way to make it so it's the same speed regardless of what computer you run it on, and at this point I have no clue how this would even be approached. "if Superlemming=true, enable fast-forward" is relatively simple, whereas dealing with frame rates directly I can imagine will be much more difficult.

NeoLemmix sets a frame rate cap and runs as fast as it can subject to that cap. If the hardware can't manage the full fast forward speed, it'll just run as fast as it can. In extreme cases (slow hardware and/or large levels or with a lot of objects), it might not even manage the 17FPS of normal playback - again, in such a case it'll just run as fast as it can. Superlemming mode, back when it existed, just altered the frame rate caps.

Unless you can find a way to replicate the exact physics (or something you deem close enough and bug-free enough, if you're okay with breaking exact physics) with more efficient code, the only way you're getting around that is by frameskipping (ie: not actually rendering every frame if the hardware can't keep up).

When mass saving images, if styles are missing, the output images simply contain the placeholder graphics rather than any error and/or failure.

For teleporters/receivers we have a defined behavior: Either both objects must be flipped, or else neither is flipped. If they are flipped, the lemming comes out the receiver facing the opposite direction they entered the teleporter.

For portals, currently, flipping doesn't do anything (aside from adjusting the graphic / repositioning the trigger area in the same way it would do for any object). The question that arises is - what should happen?

I see three possibilities here:
1. Flipped portals have no special effect and behave the same as ordinary portals. Not keen on this one (unless flipping portals is prohibited altogether, rather than being allowed but having no physics effect), in particular due to it being inconsistent with what teleporters do.
2. Paired portals can be flipped individually. If either the sending or receiving portal is flipped, the lemming reverses direction when exiting the receiving portal. If both are flipped, this cancels out and the lemming's direction does not change.
3. Paired portals must either be both flipped, or neither flipped, much like teleporter/receiver pairs. If the pair is flipped, the lemming reverses direction when exiting the receiving portal. This is my preferred approach.

Thoughts?

I'm wondering if anyone more experienced with 3D graphics (or perhaps just geometry / maths in general is enough) can help with ideas on how to improve the rendering.

The main problem here is around determining the order to draw block faces and other 3D-space elements in. Due to how L3D levels can have multiple block faces in the same position, a Z buffer is not an option - this leads to an awful level of Z-fighting, and can also lead to lemmings' graphics disappearing inside blocks when they're close to a block face (especially deflectors). Instead, we need to determine what order to draw the block faces in. (Optionally, we can also work out which ones don't need to be drawn at all, due to being outside the viewing area. However, not doing this only results in a performance penalty, not glitches, so this is not critical.)

The current build, orders these elements purely by the distance from the camera to a "key point". The key point is usually, but not always, the middle of the element's position in 3D space. In the case of a tie, it's broken by a defined priority order based on the element type (so for example, if a block face and a lemming have exactly the same key point - or different points that are the same distance from the camera - the block face will be drawn first, then the lemming).

Source code in a side branch (wip/rendering-fix-20220828) implements a different algorithm, which looks at every vertex of each element, and finds the one that when transformed into screen coordinates is furthest from the camera (including the depth) then uses this as the "key point". The other difference is that instead of determining position based on the entire key point at once, it determines it based only on the depth at first, using the other two axes as a tiebreaker only (if it's still a tie after this, it uses the same priority order as the existing algorithm to break the tie). This algorithm seems to have slightly fewer glitches, but those it does have tend to be more noticable.

I'm wondering if anyone has any better ideas here? I've taken several shots at it throughout Loap's development, and these two algorithms (the former of which has been the one used in virtually all released builds; the latter is a recent development and hasn't been included in any build yet) are the only ones that even come close to getting it right - most other things I've tried have felt like they should work, but  produce awful results when I actually implement and try them out. To be clear - what I really need is thoughts on the algorithm itself; once I have the right idea, I shouldn't have any difficulty coding it.

Also, just to avoid miscommunications - note that in Loap, the X axis is left to right, the Y axis is front to back, and the Z axis is bottom to top. (ie: the coordinates (1, 2, 3) would be 1 space to the right, 2 spaces "into" the screen, and 3 spaces upwards from the origin).

EDIT: Also, with regards to freedom of movement of the camera - the camera in Loap can move in any 3D direction, has a full 360 degree freedom of movement for the yaw, a -45 degrees to +45 degrees range of movement for the pitch, and no ability at all to roll.

Haven't noticed similar outcomes in any other level. In particular, I checked several other levels with similar poles - "Stilt Walkers", "Final Maze" (official) and "Deep Dash", "Breaking The Routine" (my pack) - and all of them dispalyed fine.

Presumably this is an edge case in L3D's behavior that Loap is not replicating correctly. The only research I've done into the why is quickly checking if L3DEdit has the same issue - it does not. Also presumably, this is purely a graphical issue.

Two bugs, probably related:

1. Scrolling option will not appear when subfolders (rather than levels) push the list past the maximum on-screen capacity.
2. Loap may crash when the maximum capacity is exceeded in a folder that contains both levels and subfolders.

Based on seeing it in a LP video, it seems lemmings in this situation continue their forward trajectory but immediately start moving downwards in DOS L3D. Haven't tested in Loap yet.

Need to look into what happens in both L3D and Loap (and adjust the latter if necessary) when a basher is walking along a slope (not up / down it, but along the slope sideways) and bashes through a wall at the end of it. Not exactly a common setup, but worth checking. Currently I'm not sure what happens in either engine.