I can't answer your question, but if I had to guess: SDLPoP's migration to SDL 2 possibly fixed it.
A similar bug was marked as "RESOLVED ENDOFLIFE"; resolved by moving away from SDL 1.2.

Unrelated, but related to MININIM, the following. In the near future, I will probably modify popot.org to point visitors towards SDLPoP instead of PoP1 for DOS. I don't see a reason for people interested in playing PoP1 for DOS to not use SDLPoP. For instance, I might start the main Get the Games page with a statement that explains why picking SDLPoP over PoP1 for DOS makes sense. At some point, adding SDLPoP, at least as an option, to the mods' packages might also make sense.

The main reason to suggest SDLPoP over PoP1 for DOS is that it delivers the same experience but adds features. In my opinion, this would justify my choice to urge visitors to go try SDLPoP instead of PoP1 for DOS. I could generalize such a statement to include MININIM. What should I tell visitors about MININIM, is what I'm currently thinking about. I don't want to write that it is "another implementation", because from a visitor's perspective that's not informative enough; too vague.

It's difficult for me to 'sell' MININIM in this context. The main reason I even feel like mentioning it on the website - in this context; not in general - is that I don't want you to feel left out. Most of the website visitors are probably looking for PoP1 for DOS, not something that modifies battle and movement behavior. I could mention specific features, such as the multi-room option, but that's not general enough. Something subjective, like "MININIM is an improvement over PoP1 for DOS", also won't work.

The mods' packages, if I'd want to add SDLPoP in them as an option, how should MININIM fit in the picture? Should these packages only include the modified files, and should the mods overview page then explain how to add these files to a user-selected implementation? (PoP1 for DOS with DOSBox, SDLPoP, or MININIM.) With Total Pack automating that process? Of course, most of these mods were never meant to be used with MININIM.

Norbert wrote:The main reason to suggest SDLPoP over PoP1 for DOS is that it delivers the same experience but adds features. In my opinion, this would justify my choice to urge visitors to go try SDLPoP instead of PoP1 for DOS.

Another reason which would justify that in my opinion is that (unlike PoP1 for DOS) SDLPoP is free software.

Norbert wrote:I could generalize such a statement to include MININIM. What should I tell visitors about MININIM, is what I'm currently thinking about. I don't want to write that it is "another implementation", because from a visitor's perspective that's not informative enough; too vague. It's difficult for me to 'sell' MININIM in this context. [...] I could mention specific features, such as the multi-room option, but that's not general enough. Something subjective, like "MININIM is an improvement over PoP1 for DOS", also won't work.

I tend to see this from an artistic point of view. From my perspective, if the original game were a piece of music composed by Jordan Mechner, MININIM would be my interpretation of it --- the way I, oitofelix, think Prince of Persia should be ideally experienced (constrained to the extent of my skills in objectifying such intent); how I myself feel it when I think abstractly about its concept.

Technically, however, I don't know how to best describe it rather than a "free software implementation of PoP 1 (based on PoP 1 for DOS) written from scratch by myself having the goal of surpassing the original in every technical aspect".

Norbert wrote:The main reason I even feel like mentioning it on the website - in this context; not in general - is that I don't want you to feel left out.

I'm grateful for that.

Norbert wrote:Most of the website visitors are probably looking for PoP1 for DOS, not something that modifies battle and movement behavior.

Of course, most people don't know MININIM yet. Probably the thought that things may be different and potentially better might never have occurred to them. I know people who like me, think MININIM is a better implementation of Prince of Persia than the PoP1 for DOS or SDLPoP. From time to time I receive their thankful mails from all around the globe.

Norbert wrote:The mods' packages, if I'd want to add SDLPoP in them as an option, how should MININIM fit in the picture? Should these packages only include the modified files, and should the mods overview page then explain how to add these files to a user-selected implementation? (PoP1 for DOS with DOSBox, SDLPoP, or MININIM.) With Total Pack automating that process? Of course, most of these mods were never meant to be used with MININIM.

I would offer MININIM as an alternative for playing those mods from a different (MININIM's, that's oitofelix's) perspective. Furthermore soon MININIM will have a very user-friendly interface surrounding all of its features, including its advanced level editor which will support saving to the legacy format. People may want to explore/modify those levels using such a tool for a variety of reasons.

Regarding legacy mods, for MININIM you should only include the LEVELS.DAT file, because (for MININIM's standards) graphics are orthogonal to level design. Graphics and sound set mods are not yet supported by MININIM, but that's planned. From MININIM's perspective support to these features doesn't equate to people distributing portions of the data directory. Those sets should be explicitly and conveniently supported by the engine as individual non-conflitant packages. What I have in mind is that MININIM will allow for people to have multiple graphics/sound sets installed in parallel and then they'll be able to easily switch among them on the fly, whatever level sets they are using, for any possible combination.

Although there isn't any yet, I'm sure mods (that is a non-exclusive combination of level, graphics and sound sets) for MININIM will emerge as soon as it gathers critical mass. Then their authors may hint on a specific combination of level/graphics/sounds --- they may as well point to some of the components from other published mods --- but ultimately that choice is left rightfully to the user.

Maybe you could also distribute GNU/Linux binary packages?
I ran into...
src/ui.c:23:8: error: unknown type name ‘ALLEGRO_MENU’
static ALLEGRO_MENU *append_menu[APPEND_MENU_MAX_DEPTH];
...and various other errors, probably because I don't have a custom Allegro.

Norbert wrote:Maybe you could also distribute GNU/Linux binary packages?

I will. From next release onwards, I'll officially support and distribute binary builds for the 3 platforms MININIM has been ported to: GNU/Linux, Windows and Mac OS X. The scripts to generate such builds are already in place: gnu-linux-release, windows-release and macosx-release.

That's probably because you are using the Allegro 5.0 series. The menu interface is a feature officially supported by Allegro in the 5.2 stable series. That said, there are a couple of pull requests (from MININIM's fork of Allegro) regarding API enhancement and bug fixes that have not been integrated into upstream.

MININIM's GitHub page has been updated to give full instructions on building MININIM's fork of Allegro (for apt-based distributions), which is now the officially supported method for those who want to build from source.

oitofelix wrote:MININIM now implements the fellow shadow feature. This allows the player to invoke and control multiple instances of the kid simultaneously. See here for a more detailed description and gameplays.

This does seems to be the most practical way to implement multiplayer in game, but seems some kind of cheat...

That's because save files are a particular case of configuration files.

YURA wrote:Where the .MCF files are saved----? they are absent after preservation?!

Files are saved in the folder you choose using the dialog box. Initially the user settings folder is selected, afterwards the last used folder is remembered. You can find out what the user settings folder is for your system running "mininim --print-paths" (without quotes) in the command prompt. However, MCF files are not currently meant to be saved, just loaded. Supposedly they are hand-written files containing user settings.

YURA wrote:Hi!, It seems, you wanted to finish that files of loading of levels were saved?!

Why do you say that?

YURA wrote:Or there will be other format of files?

MININIM is going through a transition right now. Those INI files (for configuration and native level format) won't be used anymore by the next release. Lua scripts --- way more powerful and expressive --- will be used instead.

Yes! Although for the past 6 months or so I've been very busy with university and development had been put on hold, I'm now finally free to work full time on MININIM again (for at least 2 weeks), and I'm planning to make a new release within this time period. From now on I'm committing myself to maintain a schedule where MININIM gets a fair amount of my weekly attention span, regardless of my academic occupations, so its development does not come to a halt. MININIM has been and will continue to be a high priority project to me for the foreseeable future.