Quoterelease: 720.6 real-clock-min/sec (617.2 game-clock-min/sec)

So that is 12 hours of replay-gameplay without graphics?
Not bad!
I am curious if you pre-allocate a large memoryspace before starting the game to fit in the history for each second.
By the way: are you aware of these new fixed-buffers in C# and this parameter-attribute [ConstExpected] (or [ContantExpected])?
Anway: curious to see the code:)

Question: how do i activate FF and going back etc.? Is there some doc with keybindings?

With "is it worth it" I was refering to the technical implementation of saving states in between, while "just replaying from the beginning" could be more than fast enough. That is what I am curious about. Saving states in between is a time-consuming thing.

The rewinding mechanism is interesting. The question is: is it worth it?
Looping through all frames, adjusting the terrain can be very fast.
With 128 lemmings running around + building + jobs (without graphics) I get around 24 hours of gameplay in one second.
With 1 lemming that I measured around 75 days of gameplay in one second.
Is rewinding to any moment not instant? Did you measure it? Curious

I ported this decompression algorithm in 4 languages: delphi, c#, rust and zig. But I never dived into it, what it really does
I know it makes a lot of sense to check this checksum as well to be sure of a correct result.

Interesting project. Is there sourcecode somewhere?
So you save compressed bitmap states each 17 frames? I was thinking: do you skip that if nothing changed in the terrain and only save the lemming/trap states in that case?

I am still amazed that they managed to do all this with so limited memory. Nowadays we use 30 or 100 MB to run Lemmings

@WilLem: I am not yet sure about everything. There are quite some insane details to handle...
A level-boundary-forcefield is a very viable idea as well.


Regarding turn-around stuff: In Lemmix there was this call everywhere to CheckIfWeAreAtTheCeilingAndIfSoThenTurnAround
Which lead to strange situations sometimes. And yes: I think the builders turn at leveltop.

Steel in the dos-levels are virtual blocks, in 99.8% of the cases put behind the typical steel blocks.
I plan to make the tiles themselves to be 'made of steel'. Thus we have a pixel precise collision check.
More or less the same I plan to do with one-way-walls: pixelprecise instead of a virtual square.

Reveiling steel would be nice... but that is quite some insane task which requires double layers of terrain. I think it is too dramatic

QuoteHaha, I like your thinking, but... wouldn't this waste skills unnecessarily?

Yes!

The elevator bug (as I call it) is when a jumper gets stuck inside a one pixel gap and goes up the terrain. On my Lemmix github I think somewhere a bit hidden is that ccexplores testlevel dedicated to this.

Furthermore: I discovered that - directly after lemmings change action, for example from walker to miner - always the first animation of the new action is missed.
I think I want to change that.

In general the idea is to stay very close to the orginal mechanics but more precise.

Quote from: Mindless on November 03, 2024, 08:23:17 PM

Quote from: EricLang on November 01, 2024, 11:01:21 AMC# (no control over memory, too slow: discarded)

C# is definitely viable for game development.  The only heap allocation that Golems (programmed in C#) does in the main game loop is the creation of save states for rewinding; everything else is pre-allocated or is allocated on the stack.  And .NET is definitely not too slow -- it can outperform C in some cases.  There can be challenges, for sure, but don't write it off.

True. C# is quite cool and can be very fast. But I really dislike lowlevel stuff and the garbage collection. Of course it is very good if you do not have any heap allocation!

Very true. there is no rendering involved. It will be completely separated, it always disturbed me.
I know visuals are deeply embedded inside the existing Lemmix. And NeoLemmix as well I think. Loap I do not know what that is.
It was quite some work to skip frames fast exluding all visuals.
Zig is faster than C.

A little update:
After trying a better remake of Lemmix with
-the programming language C# (no control over memory, too slow: discarded)
-then in the programming language Rust (I gave up after 6 months, the language is too complicated and too restrictive)

I discovered the (not even finished) language "Zig" which is very promising.
I started with the lemming-mechanics which work now and I have a bet with a friend:
He thinks A.I. can solve lemminglevels and I think not. The easy levels yes, difficult levels no.

So now I am building a simulator to be used with A.I. and we need insane speed for that. That is where this Zig-language comes in.

My original plan was anyway to slightly change the mechanics and I was wondering what people think about it.
Here is a short list:

-If a lemming exits the world (bottom, top, right, left) he will always die.
-(not sure yet) when reaching the top of the level they do *not* turn around.
-Steel is pixel-based instead of block-based.
-Steel is really really indestructable  (even if it is hidden behind other terrain).
-Bashers, miners and diggers will immediately stop when encountering a (masked) collision with steel, even if it is one pixel.
-Bashers, miners and diggers *always* accept their job even if they will fail because of steel. I think this reflects their brainpower better

There is one exception to the rule: the miner does not stop if there is steel at the first (high) stroke. I discovered that is irritating.

-The 'jumper elevator bug' is kept intact. That one is to cool to remove.

edit: Ah I forgot one thing. the sprites and mechanics will be 100% symmetrical (for example the difference for LeftToRight or RightToLeft builders will be gone).

To be continued...

Hello there,

I was browsing a bit through the neolemmix code and would like to know if my assumptions are right...

The highresolution mechanics is basically lowresolution.
For this purpose a "Physics" bitmap is created, which - I presume - is a downscaled version of the highres actual terrainbitmap which is rendered to screen.
When changing the terrain (building, digging, exploding etc.) *both* bitmaps (lowres physics and acual highres terrain) are updated.
Is this about correct?
And how about the FootX and FootY position of lemmings and triggerarea's?

Thanks in advance!

EDIT by WillLem: If you're looking for SuperLemmix Source Code and instructions for compiling, see this post.

---

Superlemmix is a fork of NeoLemmix isnt it? Is the source online as well? There are some interesting things I would like to study. (hi res mechanics for example).
Interesting would be a background (tiled or stretched) image I think. I even was thinking about snow, rain etc.

I noticed, when refactoring my Lemmix, that during "hyperspeed" (no graphics should be done until the target frame) there was *still* some drawing done, which slowed down performance. This was noticable when rewinding one frame in pause mode (which basically replays the whole game until one frame before the current frame).

"Fast forward" should be able to do at least 50 FPS on modern computers. Graphics32 is quite fast, but faster is possible when handcrafting everything yourself
This is not Incredibly difficult: throw away Graphics32, use a home grown pixelbuffer and directly blit to screen using the windows StretchDiBits function. This function does not need a handle.
The only real drawback here is that you have no font-rendering available.

Then also I noticed that the update speed is probably not optimal in Lemmix, and maybe also in NeoLemmix. I presume the Application.OnIdle event is still used, which is not the fastest possible. Ideally you want to call Game.Update() as often as possible.

In my new project I use a faster method and also always render to screen, which gives framerates between 150 and 1000. And my computer is not the newest one.
Knowing that Delphi is a little bit faster than C# this should be possible in NeoLemmix too.
But also there could be some other bottleneck. I saw there was quite some stuff added to the mechanics.

Yes I was experimenting with it, and it works a lot better. The bashers, miners and diggers detect if there was a steel pixel encountered during the removing of terrain. If one of the pixels is steel they stop. That works perfectly.
The only difficult part is the "drawmode" of the steel block (normal, eraser, not-on-terrain, only-on-terrain). I still have to find out what should happen in all these cases.



Tricky 4. Steel behind normal terrain. How to handle that one... In the original the steel is over the whole area (i think) regardless if the steel is visible.

I was wondering if I should convert steel area's. I think most of the steel is on these "steel" tiles. Sometimes not too precise. I could make the tiles themselves indestructable, which would be more "realistic" as far as you can speak of realism in Lemmings.

Yeah thanks it's interesting. I added some nice things already. A "high resolution" minimap which shows everything live. and "swipe" skill assignment.
Also the framerate is quite high for an old fashioned programmer like me. No hardware accelerated stuff but an FPS of 200 on a fullscreen big monitor (3840x 2160). Playing in windowed mode is also possible. On smaller screens / smaller windows an FPS between 400 and 1000. Playing only mechanics is fast as well. It can handle 3 playing hours in one second

The Tribes however will give me headaches