Pretty sure this is a backroute.
I also suspect that there's more backroute potential using the fling bombers, so it might be better to replace them with normal bombers.

Fix for All Aboard the Pain Train.

Quote from: Ramon on December 20, 2022, 09:10:59 AM
Glad you asked Madeleine's World is a private romhack for Super Mario World which I created, and with it I sequenced the complete soundtrack myself using the SNES music engine. It's a mix of original compositions, songs from bands I've played with and other internationally known pop songs or video game tracks. If you're interested in any of the tracks, I could link you the originals or even the soundtrack itself.

I was wondering the same, that song stood out to me but I couldn't find any information. Thought maybe it was a Celeste mod or something. Would be happy to have the soundtrack as well

The are replays for some Lemmix levels. Now where to find those levels is another question...

This is a fun idea. Wish I had time to implement a level.

Long time ago we already discussed how to create levels that take a long time to solve (penultimate paragraph in this post: https://www.lemmingsforums.net/index.php?topic=1314.msg34071#msg34071)
This could directly be applied here: just have X lemmings on X platforms of different lengths (see post - some prime P times a fixed amount of pixels L) that need a certain time to synchronize, and require them to bash at the end of the platform to get out. If they are synchronized, they all cluster on the same spot, and can pass a squisher trap with only one lemming dying. Otherwise, some of them will be at least L apart, and if the trap is fast enough it is guaranteed to at least take 2.

But I feel like you could even make a level here that requires no skills and just solves itself, 200x200 might be enough to waste 8 minutes just slowly walking down a zigzag path.

Interesting how inconsistent the designs of the two flipping buttons are. Not only do they use different terrain pieces to illustrate, but one also has both the original and the flipped sprite, while the other doesn't.

Regarding the larger terrain button, do I remember correctly that the zoom button is mostly for discoverability? Does anybody actually click it? Seems to be one that could be done away with, at the risk though that some users may not discover the existence of zooming. Another option to buy screen estate could be grouping hatches and exits into the same dialog (which then poses the question on how to display/sort them; not all hatches/exits are obviously hatches/exits.)

I'm with Flopsy and Simon on this one: I personally won't use it (neither button nor hotkey, the latter as there's too many other important functionalities to be mapped), at the same time I agree that it technically belongs there from the UX perspective, even if it costs screen estate. Then again, I think it's a minor issue, so I hope Simon doesn't prioritize it over some other more exiciting stuff

QuoteIronically within the level text files there is the tile modifier 'f', which means: Tile is mirrored vertically. The flip horizontal button is implemented in the text files via combination of 'f' and 'r' ('r'=rotate 90 degrees clockwise), e.g. 'frr' for flipping horizontally a non-rotated tile.

I think this is historical, because the original Lemmings game allows you to flip vertically, but not horizontally. Lix supported this initially, and rotation was then added on top, if I'm not mistaken.

It's too early for me to tell for sure. I might be able to make both or none of the dates, I suspect Saturday is more likely to work than Sunday, as I might be travelling on Sunday, but again, can't say for sure.
So I suggest you pick based on everyone else's preferences, and (as usual) I'll join if I can make it. Would love to try to the new handicap with more players.

QuoteI've been thinking this over for a while and the only obvious downside I can see is that it will mark a lot of pairs of faces as having one that must come first, even when it actually doesn't matter. However, this would only result in a performance penalty, rather than a failure - it might be acceptable, would have to test (and possibly optimize) before I could say for sure.

Actually, if you mark dependencies where there are none, you add additional edges to your graph, and making it more likely to get cycles.

I think the many cyclic dependencies you see are exactly a result of this. There may be instances where you legitimately get cyclic dependencies, but these should be rare in practice (e.g. the lemming intersecting with the diagonal block).

I don't really have time to think through your outlined algorithm in detail, but you should have as few extraneous dependencies as possible.
Newell's algorithm (linked in my previous post, and the linked stack overflow post also has a link to the Wikipedia article) claims to take care of this, maybe worth having a look at.

QuoteThinking of another possible approach (somewhat based on Simon's idea using planes) - let's suppose I can come up with a list of prerequisites (eg. face A must be rendered before face B, face B and C must both be rendered before face D) - what is generally the most efficient way to translate these requirements into an ordered list? Keeping in mind that two faces may be neutral with regards to each other, but a third face might need to be drawn inbetween them (eg: A and B have no order preference to each other, but A must be drawn before C while B must be drawn after C).

QuoteThe next keyword to websearch from there is: Topological sort, or directly on wikipedia. (Starts to sounds like geoo or another computer scientist could have pointed us there much quicker. )

Yep, that's exactly what I suggested a couple of posts ago x_x

Quote from: geoo on September 03, 2022, 07:10:56 PMAnyway, if you do want to do face sorting properly, it seems to me if you're doing pairwise comparisons for intersection like Simon is suggesting, you can then piece it together into a linear order by building a graph (the nodes are the faces, the edges are when a face is partially obscured by another face), and then doing a topological sort. (Note that in practice you might encounter cycles in this graph, e.g. if you have 3 triangles where each one obscures but also is obscured by another one.)

But back to Z-buffering and the Z-fighting issues that you had when using that approach: Why don't you make the blocks a tiny bit smaller (not enough to be visible, but enough to avoid z-fighting due to rounding errors) than a full grid unit?

Interesting, my intuition is that score divisor is going to be the single most applicable kind of handicap (unless you're playing all-or-nothing maps), while I feel that the blanket skill divisor is going to be un-fun and rather useless. The rationale is that you want to limit/cut the strong skills for the stronger player, while keeping the utility skills unaffected. The blanket skill divisor does the opposite: Your utility skills get cut in half (so the strong player runs out and gets frustrated), while the skills allowing to wreak havoc with in small amounts (e.g. digger, blocker) will remain available to some extent. So I don't think skill divisor is going to be all too useful unless you can set it for each skill individually.

Also curious to see you're trying to implement fractional scores. I would have thought in practice it'd be fair to just round up to the next integer (and call it a tie if the scores match). The "divisor" is a somewhat arbitrary number anyway, and changing it in small ways will affect your score by more than an integer, so it doesn't seem like precision is really needed (but happy to be proven wrong with some case scenario).

I'll try to make it to the fireside chat tomorrow night, curious to discuss, not sure I'll be able to make it though.

They need some polish before they can be released:

- Title
- Decision on how far to shift the exit from the start (unless you want to include all possible versions)
- Release rate that doesn't perfectly cluster the bunch
- Some mechanism to prevent plugging up other players' climber chutes
- Overtime

Quote from: namida on August 28, 2022, 10:36:39 PM
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.)

I want to have a look at this problem, but I think I need some clarification to understand the issues with using a Z buffer (which then also affect face sorting):

• How is block faces in the same position an issue? I can see that happening when there are two adjacent blocks, but then their touching faces are obscured by other faces of these blocks and therefore not visible, so this seems to be a non-issue (also, in that case you see the front of one of them and the back of the other, so if you're doing back-face culling, you'd only draw one of them anyway. Note: If you compute the normal vector of a face so that it points out of the front side rather than back, you can determine whether you see the front or back face of the triangle by computing the scalar product of the normal vector with the vector where the camera is pointing, and skip drawing the back faces. Are you doing back-face culling, and if not, maybe it improves your results already?).
  
• I assume, as Simon is suggesting, lemmings are simply a quadrangle with a texture (that has some transparency)? If you have Z-fighting between a lemming and a terrain surface, couldn't you just always prioritize the lemming whenever the difference between the distances is very small (i.e. possibly caused by a rounding error)?
• Are there other instances of Z-fighting to consider?
• If you do have instances of Z-fighting because of faces being in the same location, then it seems to me that moving from Z-buffer to face ordering just moves the issue from pixel-level to face-level, i.e. on one frame you might see texture A, and in the next texture B.

Anyway, if you do want to do face sorting properly, it seems to me if you're doing pairwise comparisons for intersection like Simon is suggesting, you can then piece it together into a linear order by building a graph (the nodes are the faces, the edges are when a face is partially obscured by another face), and then doing a topological sort. (Note that in practice you might encounter cycles in this graph, e.g. if you have 3 triangles where each one obscures but also is obscured by another one.)

As for the comparisons (of say a convex polygon P and Q), I think the following should work assuming no cycles and intersecting faces:

• Compute the projections of P and Q into the viewing plane. Then check if these 2D polygons intersect. (I had this for pairs of triangles as a programming exercise once, it's a pain. It's not hard, but just a lot of cases. You could probably find this for pairs of triangles somewhere on the internet, and reduce the quadrangles to triangles. Or just check the bounding rectangles and hope for the best...) If they don't intersect, you're done: Don't add an edge to the graph, you can draw them in either order.
• If they do intersect in 2D: take an arbitrary intersection point (in the interior), compute the original points in P and Q that they are projections of, check which one is closer to the camera, and add an edge accordingly.

If you do have intersecting polygons, then either of them could end up on top with this strategy. (And of course, you will still have issues with cycles as well.)

I was looking up how people resolve this, and found Newell's algorithm, outlined in the last comment here: https://stackoverflow.com/questions/58367851/how-to-sort-these-lines-with-painters-algorithm

Basically, it does the sorting in a smarter way to resolve cycles along the way, and replaces my second point with the following (technically it adds more checks, but these are just for optimization):

• Are all points of P on the same side of the Q-plane, or are all points of Q on the same side of the P-plane? If either is true, you can determine which one is closer to the camera: e.g. if the points of P are on the same side of the Q-plane, and the camera is on the same side as well, then P is closer to the camera than Q, and you have to draw it later. (Otherwise it's the other way around.)
• If neither of the above holds, split the polygons.

Interestingly, even after all the conditional checks in Newell's algorithm where it decides to split the polygons, we still cannot conclude that P and Q intersect in 3D (I found a counterexample, see attached GeoGebra file).
Hopefully this should be rare, so instead of implementing splitting, maybe you can hope it doesn't happen

Saturday there's the chance I can make it, Sunday definitely not.