MININIM updates

[Norbert]

Use ALT+F7 to record a replay file for the current level, or the next one in case you are in a cutscene.

Maybe something to look into:
Alt+F7 is the Xfce (and thus Xubuntu) shortcut to move windows.
This means users of this DE can only record after modifying the keyboard shortcut.

[oitofelix]

Maybe something to look into:
Alt+F7 is the Xfce (and thus Xubuntu) shortcut to move windows.
This means users of this DE can only record after modifying the keyboard shortcut.

Thanks for reporting.

I use Xfce, but haven't noticed that because the first thing I did was to replace Alt by Super for every defined window manger key binding. By principle, window managers shouldn't be in the way of applications. In GNU systems there are many different window managers available for use, each one with its own default key bindings. People using GNU systems, are in general used to setting up things (in particular, it's quite common to configure your own key bindings to do "things"), and irregardless of that, it's quite easy to change default key bindings. Therefore, in general, I think it's not a good policy to constrain key bindings used by applications primarily on such basis. If the conflict was in the Windows port, however, it probably would make sense to change it, because there key bindings are standard, hard-coded or difficult to change, and people are not commonly acquainted to that idea.

[Norbert]

You're probably right.
Although I certainly hope that one day we'll move away from expecting people using GNU systems to tinker with things before they work.
It is why people don't use GNU systems.

[oitofelix]

Although I certainly hope that one day we'll move away from expecting people using GNU systems to tinker with things before they work.
It is why people don't use GNU systems.

There is quite some truth to that.

[Norbert]

I noticed on GNU/Linux that there is no default filename on the saving window. Whether this is the standard behavior across platforms, I don't know. Maybe it's useful to add a default in the format "<level number>.mrp" or something similar. I was thinking about this in the context of popot.org, among other things, which blocks - not just on the client side - everything other than *.mrp and *.p1r.

[oitofelix]

I noticed on GNU/Linux that there is no default filename on the saving window. Whether this is the standard behavior across platforms, I don't know. Maybe it's useful to add a default in the format "<level number>.mrp" or something similar. I was thinking about this in the context of popot.org, among other things, which blocks - not just on the client side - everything other than *.mrp and *.p1r.

An Allegro bug prevents MININIM from doing so on GNU/Linux. Another one prevented MININIM from showing stock file overwrite confirmation dialog boxes. For this latter I had an ad-hoc solution in place, for the first one that was not possible. At any rate, I've fixed both and submitted a pull request.

I hope Allegro developers find improvements brought to the library through MININIM useful. Either way, I'll base future releases of MININIM on my own fork of Allegro.

PS: After saving the first file, MININIM already uses it as the default for the next save. That's handy, and partially what you want.

[Norbert]

At any rate, I've fixed both and submitted a pull request.

Nice work.

[oitofelix]

This post is about David's MININIM playtest of the standard legacy level set.

As for performance, it eats 11-15% of CPU in windowed mode, and 25-30% in fullscreen mode.

What multi-room resolution were you using? 2x2? Albeit very optmized, rendering is the most demanding task in MININIM, and in most games I suppose. Therefore, having 4 rooms rendered on screen is almost like having 4 instances of MININIM in single room mode (well that's an overstatement, but just to give you an idea). In my machine, MININIM windowed (640x400), single-room, consumes about 4% of one i3's core.

In my virtual Windows machine, under the same conditions, MININIM consumes 5%-15% of one virtual CPU core. Anyway, I have the feeling that in Windows things are slower for some reason. That's not MININIM's fault though. That's Allegro department. I have only Windows running in virtual machines and that's not reliable to do a serious assessment about performance.

I can't avoid harm from a landing loose floor by crouching. I suppose this is intended.

Indeed, this is intended.

The prince can climb up much faster after grabbing.

That's good. Right?

It can be a bit surprising when the view changes to scroll a guard into view.

To remedy this situation, at least partially, specially for high multi-room resolutions, I implemented the room selector marks (those rectangles red and green surrounding rooms after automatic scrolling).

When a guard has only 1 HP, that HP should blink. Like it already does for the prince.

Done. Thanks for reporting!

When the skeleton falls, it screams like the prince!

I'm glad you like it.

I see (hear) that multiple sound effects can play at the same time. For example, gate closing + exit opening. Or slow-fall music + other sounds.

Yep, Allegro allows me to do that. By the way, why that's not the case for SDLPoP?

Guards will follow the prince if they can reach him by falling later. For example, the orange guard on level 4, if the prince goes to the nearby potion. Or the yellow guard on level 10. That one was quite annoying, as the gate (where he came from) closed while I was fighting him.

In MININIM, AI is in general smarter than in the original game. In my experience that's more challenging and funnier to play.

It's not so easy to defeat a cornered guard.

That's intended.

This no-auto-sword-drawing is good when I have to sneak behind a guard who's not looking.

I'm glad you like it. The kid draws the sword automatically if in fight range, though. In that case he takes care of keeping it at the end of the fight as well. I think that's the perfect balance for the "to auto or not to auto" draw sword dillema that caused some discussions in earlier versions of MININIM. That's proof that the answer to some questions can only be achieved given enough time and experience.

I get to see the mirror appearing immediately (with music) when the exit fully opens.

That's because it uses a multi-room generalization of the original concept, that's the mirror appears as soon as its room is visible in multi-room visualization. This is true for other special events as well, like the mouse in level 8.

I tried to stab the shadow on level 5, but I can't...

That's because the shadow is created immune to sword hits in that level. After all, you are not supposed to be able to kill him there, because he appears later on. However, your surprise is an indicator to me that this isn't the behavior for the original game. If that's the case I may want to implement the legacy behavior, because that's about legacy special events.

By the way, you can drink the potion before the shadow if you use MININIM's jump turn movement to avoid pressing the door's opening floor.

It was interesting to fight against two guards at the same time on level 5...

I'm glad you like it. This opens interesting new possibilities for MININIM native level sets that support multiple guards in one single room.

I see you put spikes behind the un-openable gate on level 5.

Not directly. The thing is that in MININIM (unlike the original game) there is no room linked to nowhere. Thus normal rooms are delimited by room 0, a room linked to itself from every direction. This makes a level in MININIM finite without boundaries, closed behind itself, curved onto a higher (internally inacessible) dimension.

As room 0 is a room in which every construction is a wall, it would look weird to let nothing above room 0 from other room's perspective. Therefore MININIM ensures this doesn't happen by fixing levels on-the-fly (putting spikes there).

Guards seem to be tougher...

That's because the fight system is quite different from the original game. Said that, for legacy levels, guards' skills are the nearest they can be to the legacy ones.

And they stab me when I'm trying to run away!

It's worth noting that the kid can't keep his sword and avoid fight if he is in fight range. This forces the player to stab the guard to push him away and activate his refraction time, so the kid can get space and time to keep his sword and run away.

The fat guard can scream, too!

In MININIM, everybody screams, except for the princess and the mouse (yet).

At the end of level 6, it's a bit scary/confusing to see all those spikes in the pit...

I've described above why that's so. I may want to consider implementing the legacy rendering behavior for MININIM's legacy semantics. Could you describe the rules SDLPoP use to draw the four boundaries of rooms linked to nowhere?

Some attributes of MININIM's rendering sub-engine may make this task a little bit challenging because of exceptional conditions, like the partial view of rooms below each visible room, present even in single room mode (where in the original game there is just a black band). Right now, thinking a little bit about it, it seems, rendering like the original game will be disruptive of true physical representation, specially regarding multi-room view. I'll have to consider it more comprehensively to be sure, though.

The Manual seems somewhat outdated. It does not mention multi-room modes, for example.

That's an understatement. Actually, it's very outdated.

Its [MININIM's] user’s manual (in PDF format) is bundled in the hope that it might be useful, but keep in mind that it lags far behind the current development stage of MININIM and thus doesn’t describe several features thereof accurately or at all. The author plans to update MININIM’s documentation in a definitive manner when MININIM reaches reasonable feature-set stability. In case you’d like to help in speeding up this process by maintaining its documentation, you’re very welcome! Please, contact the MININIM community at its forum.

I wish I had people helping me with that.

Sometimes the display does not follow the prince after I used Shift+H/J/U/N.

That's expected, because you moved the current room selection (the one with a temporary red rectangle around it) away from the kid. Therefore, if the kid changes rooms the camera should not automatically follow him, because the engine presumes you are interested in another room. The camera only starts to follow him again when he meets the currently selected room (or the converse). This is useful if you want to view something else while a replay is executing, for instance. The key HOME changes the currently selected room to the kid's one and centralizes the multi-room visualization, while SHIFT+HOME just centralizes the multi-room visualization for the currently selected room.

Okay, it seems that regular guards scream, too. (Level 7 purple guard)

I told you!

The first guard of level 8 seems to be quite easy. I just pressed left and shift and I defeated him... He's too inactive, perhaps?

That's because of how MININIM handles fight mechanics. That guard has however the same nominal skills of his legacy counterpart in the original game. For instance, his essential characteristic of never attacking is preserved. Of course, if that was a native MININIM level set, that guard's skill would probably be higher to make the fight more challenging.

It's worth noting that in MININIM's native level format you can fine tune each skill attribute for each individual guard.

Hey, this works for all guards?! (Except Jaffar, because he immediately strikes back.)

I don't think so. If you aren't careful enough they will stab you back. Of course, the likelihood of that happening depends on the particular guard's skills.

Chomper timings seem to be different. For example, the twin chompers after the rightmost guard chomped together.

They certainly are. That didn't prove to be a problem for compatibility with legacy mods yet, though. How does SDLPoP handles chomper timings? Sequentially? In MININIM they are randomly (modulo position) timed.

When I climb up from a guard's view, he stays active until I do something else. Example: The orange guard on level 8.

Actually he stays active (or vigilant, in MININIM's jargon) for just a few seconds after you get out of his sight, whatever you do.

It was funny to see the mouse appear in the other room, out of nowhere...

Fortunately, in MININIM, we aren't subject to the law of conservation of energy.

The flip potion has yellow bubbles.

Yeah, to distinguish it from the float one. The standard item specification considers graphical representation of items implementation-dependent. As a related note I plan to make MININIM compliant with that specification. This will probably allow MININIM to use every PoP 1 item conceived to date (and virtually infinitely many more).

At the flip potion, I could break the two loose floors at the same time, the prince fell down, and it seems he didn't lose any HP?

The only way I know how to make him avoid suffering any harm on that part is to vertically jump, facing the right at the very edge of the base floor, in order to release both loose floors at once, and then immediately perform a falling turn and hanging on the walled floor while both loose floors are falling (alternatively climbing at the same time).

I think the prince fell into the wall near the second flip potion. After you climb down where the loose floor was, crouch twice, and do a standing jump.

That's the same problem (regarding diagonal collision) I talked to Norbert about in respect to Prince of Wateria mod. Fortunately, this had been fixed before I got to your report. I'm constantly fixing such physics-related remaining bugs.

Shift does not work with numpad 4/6 if Num Lock is on!

Works fine for me, under GNU/Linux and (virtual) Windows.

What!? A guard can survive a two-row drop!? He loses only 1 HP. Example: Last guard on level 9. Or the purple guard on level 10.

If the kid can, why guards shouldn't?

But loose floors hurt them too!

As I said, fair competition, same rules for all.

Ctrl+G shows only *.sav files, but Ctrl+L shows all files. Also, Ctrl+G does not automatically add the .sav extension.

For the next release:

• Save files (actually configuration files in general) will have the extension "mcf"
• All load dialogs will only show valid files
• All save dialogs will hint the correct extension

For reference, see here.

On level 13, the exit opens immediately when Jaffar dies. No need to change rooms.

Hopefully that won't cause any incompatibility with legacy mods.

Level 14 is oddly blue...

That's because it's night when the kid reaches the top of princess' tower. Do you have documentation on the palace drawing algorithm for that level used by version 1.3 of the original game? I may consider implementing it instead.

And it's odd to see the empty room before meeting the princess...

I agree. I still don't understand why Jordan Mechner didn't consider MININIM's multi-room feature while designing that level.__ I'd try to ask him, but he probably won't answer my emails.

Is there no Hall of Fame? Or it just didn't appear because I interrupted the ending music?

No, there isn't. I plan to implement it eventually.


Thank you for testing MININIM thoroughly and taking the time to provide useful feedback. That's very much appreciated.

[Norbert]

"In MININIM, everybody screams."
--oitofelix

Hehe, that's one for the books.
(Yeah, "except for the princess and the mouse (yet)", but with just the first part it's funnier. )

[oitofelix]

"In MININIM, everybody screams."
--oitofelix

Hehe, that's one for the books.

[oitofelix]

I'm glad to announce the release of MININIM 201701122309.

• Allegro upgrade
  
  • MININIM releases now use my own fork of Allegro 5.2.3. That's a significant upgrade from the previously used 5.0.10. My fork may have improvements brought to the library through MININIM. Like these. If you are building from source consider using it for best results.
  • I plan no rupture from upstream Allegro. MININIM future releases should continue to build properly using vanilla 5.0.10 or my own fork of the latest development version, the only difference being the set of available features.
  • Windows releases of MININIM now come with a default "allegro5.cfg" file which the user may use to fine tune Allegro.
  • Unfortunately recent versions of Allegro have a bug where joystick initialization fails on Windows. That has been reported by me here. The workaround is to use debug builds of Allegro (with debug symbols stripped off, of course). Users should notice no difference (besides some additional Allegro debug/logging optional facilities, useful for bug reports of low level failures).
  • Useful features made available in recent versions of Allegro are planned to be used in next MININIM releases.

News of this release:

• Haptics fully integrated into game mechanics.
  
  • The player can feel kid's muscular effort and body movement, falls, collisions, harm, potion effects, sword hits and bumps, its surroundings, pressing, shaking and breaking floors, choppers closing, spikes coming out, and more.
  • The option --gamepad-rumble-gain scales down every effect proportionally in case the default is too intense for the available gamepad (or the player's taste). A value of 0 disables haptic effects altogether.
  • Option --joystick-info reports all haptic effects supported by the connected joystick. However, all effects used by MININIM are implemented in software using just the simplest constant force feedback for maximum portability and perfect timing with in-game events. The currently implemented software effects are: gain, sine, triangle and queue of effects.
  • CTRL+J: enables joystick (implicitly calibrating it) at first call, and subsequently calibrates it, rumbling in case it's haptic-capable. Keyboard input continues to work as usual. This is the default mode in case a joystick has been detected.
  • CTRL+K: disables joystick and haptics.
  • Allegro support for haptics is experimental. Allegro developers told me MININIM is the first game to use its API. That's MININIM on the cutting edge . I'm providing feedback to them on improving Allegro's haptics API.
  • Haptics require Allegro 5.2.0 or superior, but MININIM still can build fine against 5.0.10. In this case haptics support is unavailable and a proper message remarking this fact is printed next to the documentation of --gamepad-rumble-gain option in --help output.
  • Because of an Allegro bug, haptics is not properly supported on Windows. I've reported this to Allegro developers here, and I'll be following this closely, providing help if possible. In the unlikely case of it magically working for you on Windows, please let me know.
  • I tried to make haptics in MININIM natural and enjoyable. Feedback from users, critics or suggestions are very welcome. After all, I had access only to one (cheap) device. Please, let me know if haptics doesn't turn out to be what I/you expected using your device.
  • I had an idea for haptics implementation back when I introduced joystick support in MININIM. However at that time the stable version of Allegro didn't have any API for that (not even an experimental one). Recently this idea came back to me thanks to Falcury. Fortunately this time Allegro was mature enough (kind of).
• Option --random-seed sets the initial seed for the random number generator. This is potentially useful for debugging purposes. Thanks to Norbert for suggesting it.
• Regarding MININIM saving and loading of files:
  
  • Save files (actually configuration files in general) have the extension "mcf".
  • All load dialogs show only valid files.
  • All save dialogs hint the correct file extension.
• ALT+ENTER is an alias to F, = is an alias to + and _ is an alias to -.
• In MININIM, everybody screams!
• General improvements to the physics and specially the fight system.
  
  • David had a point when he said:
    

    * The first guard of level 8 seems to be quite easy. I just pressed left and shift and I defeated him... He's too inactive, perhaps?
    * Hey, this works for all guards?! (Except Jaffar, because he immediately strikes back.)

    Of course, as I replied, the problem with those guards was their derivation of skills from the legacy profiles. Fine tuning guard skills allowed one to make guards that couldn't be defeated by mechanical tricks. I've, however, revised the fight system and implemented an scheme (based on the concept of "anger") to hopefully make any guard, no matter how unskilled he might be, immune to repetitive tactics, like that one David described. Fights are quite more enjoyable now.
  • Standard legacy level set replays have been remade. Naturally, changes in the engine may affect the outcome of replays that rely on previous behavior. Use --time-frequency=0 and --rendering=NONE to find out if that's the case for any replay chain you may have recorded. I suggest you record again the faulty replays and use --validate-replay-chain to validate the entire chain again (without having to record again unaffected replays).
• As usual, many bugs have been fixed.

Looking forward to your feedback.

Have fun!

[Norbert]

Allegro support for haptics is experimental. Allegro developers told me MININIM is the first game to use its API.

Surely they've had other people use it for games?
From what I can find, ALLEGRO_HAPTIC and similar entries say "Since: 5.1.8", which is 3 years ago (2014-01-12).
Or maybe Allegro is less popular than I think.

In MININIM, everybody screams!

Fun easter egg, that --scream.

[oitofelix]

Allegro support for haptics is experimental. Allegro developers told me MININIM is the first game to use its API.

Surely they've had other people use it for games?
From what I can find, ALLEGRO_HAPTIC and similar entries say "Since: 5.1.8", which is 3 years ago (2014-01-12).
Or maybe Allegro is less popular than I think.

I don't know. Allegro's haptic API author, Beoran, said here:

Also, you're the first person to actually use the haptic API, so I would like to ask if it is useful or not, and what could be improved.

If MININIM isn't the first game to "actually" (whatever that means) use it, it's at least the first one he knows about. (assuming he has a consistent state of mind and is telling the truth)

In MININIM, everybody screams!

Fun easter egg, that --scream.

I'm glad you like it. Of course, that was inspired by yourself.

[David]

How does SDLPoP handles chomper timings?

Initialization: https://github.com/NagyD/SDLPoP/blob/ma ... 007.c#L894
Animation: https://github.com/NagyD/SDLPoP/blob/ma ... 007.c#L277

I see (hear) that multiple sound effects can play at the same time. [...]

Yep, Allegro allows me to do that. By the way, why that's not the case for SDLPoP?

I think it's only because of "compatibility".

I tried to stab the shadow on level 5, but I can't...

[...] However, your surprise is an indicator to me that this isn't the behavior for the original game. If that's the case I may want to implement the legacy behavior, because that's about legacy special events.

The legacy behavior is that the prince can't draw his sword there.

Shift does not work with numpad 4/6 if Num Lock is on!

Works fine for me, under GNU/Linux and (virtual) Windows.

More precisely: In that case the kid will run instead of stepping.
The old versions of SDLPoP that used SDL 1.x had the same problem.
Reported here: viewtopic.php?p=15195#p15195

By the way, you can drink the potion before the shadow if you use MININIM's jump turn movement to avoid pressing the door's opening floor.

Now I tried this. It took a few tries but I could do that.
I have to jump from near the left edge of the left opener button. Then hold shift+left.
Dunno, but this turn-grabbing looks a bit unrealistic...

By the way, MINIIM's editor does not place the selection "rectangle" correctly if the window is stretched.
In SDLPoP's editor, I have fixed a similar bug here: https://github.com/NagyD/SDLPoP/commit/ ... 6ec6d2a740

While at it, I see MININIM moves the mouse cursor if I change the multi-room width and/or height in editor mode.

When in the editor's Kid menu, the prince is drawn at the starting position semi-transparently.
But, why is a sword displayed on the floor?
Nevermind, I found it: https://github.com/oitofelix/mininim/bl ... kid.c#L230

[oitofelix]

More precisely: In that case the kid will run instead of stepping.

Indeed, I could reproduce it (only on Windows, though). That's an Allegro bug. I reported it.

Dunno, but this turn-grabbing looks a bit unrealistic...

Video-games these days...

By the way, MINIIM's editor does not place the selection "rectangle" correctly if the window is stretched.

That happened only on Windows. This bug has been fixed in my local VCS.

While at it, I see MININIM moves the mouse cursor if I change the multi-room width and/or height in editor mode.

That's because MININIM preserves the current selection even if multi-room resolution has changed.


Thanks for reporting those issues.