PoP1 tricks against MININIM --- accessing the physics engine's robustness

[oitofelix]

Hello PoP1 fans!

I'd like to invite people to test systematically each one of the PoP1 tricks against MININIM, so we can have a picture of how stable its physical engine actually is and what's left to be improved.

I expect many of the tricks to simply not work against MININIM, but people might end up finding new flaws. I want to fix as many errors as possible for the next release. So I'll be very grateful for any bug reports. You can report your results --- negative or positive --- here in this thread.

For those of you that don't have time to do this (or even if you do ), and want to help somehow these issues to get fixed, or want to see new features added, or just want to demonstrate your appreciation for my work, please donate! Any value is highly appreciated, but if you are generous enough, your act of kindness will be acknowledged in MININIM documentation for the upcoming release and beyond, and on my personal website too.

Thank you!

[Norbert]

The most skilled players on this forum - I'm not one of them - would need an easy way to modify the original levels shipped with your program. The reason is that most tricks cannot be performed anywhere in the original game. Even if they could, it would be easier for playtesters to modify and jump into a level that has the required tile layout in the very first room. MININIM's files in data/legacy-levels/ are close to the PLV format (pp. 26-28). The main tool that exports/imports PLV files is PR. Level editor apoplexy relies on PR for this. Level editor RoomShaker also has PLV import/export features. Another route would be to implement support for the XML format. There are currently two tools that can use this XML format, apoplexy (export/import) and polipo's PoP.NET (import). Yet another solution would be to add support for reading the LEVELS.DAT file, perhaps using SDLPoP code (it uses the same license, GPL3+).

[oitofelix]

Yet another solution would be to add support for reading the LEVELS.DAT file, perhaps using SDLPoP code (it uses the same license, GPL3+).

I've implemented LEVELS.DAT support in commit c9bfaf9. To use it, just put the LEVELS.DAT file inside data/dat-levels/ and run MININIM with the --level-module=DAT option. Be aware, though, that this will probably only work with little-endian machines. As soon as I'm aware of any MININIM user using a big-endian one, I'll revisit the dat.c module and implement an endianness independent solution.

I didn't use or look at SDLPoP's implementation. Is it big-endian friendly? I'd bet it's not because the original PoP had no such target.

MININIM's files in data/legacy-levels/ are close to the PLV format (pp. 26-28).

Why do you say they are just "close"? They are the very original data.

Another route would be to implement support for the XML format.

What are the benefits of supporting this XML format? Are there demand for this?

Ps: If any Windows user is willing to work on the task proposed in this thread and needs the DAT support, please ask and I'll make a build of MININIM for Windows from the VCS available, so you don't have to wait for the next release to start testing the engine.

[Norbert]

I've implemented LEVELS.DAT support [...]

That was fast.

MININIM's files in data/legacy-levels/ are close to the PLV format (pp. 26-28).

Why do you say they are just "close"? They are the very original data.

See pages 26-28 of the aforelinked PDF file.
PLV files are an extension of the original data.
In PLV files, the original data starts at offset 18, and the file ends with user data.

What are the benefits of supporting this XML format? Are there demand for this?

I included XML primarily to give a more complete overview of available options. For some people it is an easier option than working with the hexadecimals of binary files.

Ps: If any Windows user is willing to work on the task proposed in this thread [...]

The most skilled PoP1 for DOS players, such as yaqxsw, SuavePrince, Khushal64n6 and Moscow Tracer, all use Windows.

By the way, something like "run MININIM with the --level-module=DAT option" is easy for us, but see, for example, this. You or I may want to create a document that explains how to use apoplexy with MININIM. Or someone could create a BAT file (or GUI-based thing) that launches and moves around (level/DAT) files where and when needed.

[Norbert]

By the way, something like "run MININIM with the --level-module=DAT option" is easy for us, but see, for example, this. You or I may want to create a document that explains how to use apoplexy with MININIM. Or someone could create a BAT file (or GUI-based thing) that launches and moves around (level/DAT) files where and when needed.

Here is one possible solution. The current/latest version of apoplexy, version 3.0, launches GNU/Linux and Windows executables for playtesting if it detects in the prince/ directory respectively a "prince" file that is a Linux ELF binary, or a "prince.exe" file that is a Windows MZ+PE\0\0 binary. (This is because of SDLPoP support.) As a result, this is possible: replace all files in prince/ with MININIM's files, rename mininim(.exe) to prince(.exe) or add a symbolic link (didn't test the latter), then add LEVELS.DAT. Next, MININIM will say "Too many arguments" because apoplexy calls it as, for example, "<executable> megahit 1" for level 1. This means that MININIM would have to be modified to allow these arguments. Also, instead of "--level-module=DAT" it would need to work with the LEVELS.DAT file automatically if it is present (access()). After these changes, it should be very easy for users to get started.

[oitofelix]

See pages 26-28 of the aforelinked PDF file.
PLV files are an extension of the original data.
In PLV files, the original data starts at offset 18, and the file ends with user data.

I've implemented PLV extended level files support in commit 41d1e65. To use it, just drop the level files named sequentially from "01.plv" to "14.plv" ("00.plv" and "15.plv" are currently ignored) inside data/plv-levels and run MININIM with the option '--level-module=PLV'.

Sorry for my misunderstanding on this matter. Hereafter I call the level files loaded by '--level-module=legacy' as "raw level files".

That was fast.

I included XML primarily to give a more complete overview of available options. For some people it is an easier option than working with the hexadecimals of binary files.

Isn't safe to assume people are using well suited tools like your level editor apoplexy, rather than editing files by hand?

...Or someone could create a BAT file (or GUI-based thing) that launches and moves around (level/DAT) files where and when needed.

That won't be necessary. See below.

Here is one possible solution...

Good thinking! Based on your suggestion I've decided to make MININIM compatible with the legacy command line parsing and level loading behavior, as it doesn't conflict with MININIM's native interface. However, I'd like to ask you to modify apoplexy to look additionally for the MININIM's executable (for both platforms) so people don't have to rename it.

You or I may want to create a document that explains how to use apoplexy with MININIM.

Perhaps you could amend the apoplexy's SDLPoP instructions to describe how to do the same for MININIM?

The most skilled PoP1 for DOS players, such as yaqxsw, SuavePrince, Khushal64n6 and Moscow Tracer, all use Windows.

I'll make a build available to them as soon as I get MININIM working with apoplexy.

[Norbert]

Isn't safe to assume people are using well suited tools like your level editor apoplexy, rather than editing files by hand?

Definitely. The XML specification is meant to be used by authors of remakes/ports who prefer not to read and process any binary files, for instance if it's easier for them to read and understand the XML level files that apoplexy can export.

[...] make MININIM compatible with the legacy command line parsing and level loading behavior, as it doesn't conflict with MININIM's native interface.

Sounds good. When you've implemented this I will completely rewrite that PDF document. I will include information about MININIM, and I will also change instructions from copying specific files of SDLPoP/MININIM into the prince/ directory to copying all SDLPoP/MININIM files into the directory and then applying modifications if necessary. As for modifying apoplexy, this is more complicated/interesting. (See the entry for v3.0 in its docs/ChangeLog.txt file. I'll probably address this soon in a thread on the apoplexy board. [Edit: Done; here.])

[oitofelix]

Commit 1a1abcd sums up all the modifications I've promised. I tested it with apoplexy 3.0 RC2 under GNU/Linux and the apoplexy/MININIM integration works like a charm. I tried to test it under Windows, but the 32-bit build you made available requires a CPU a little bit more modern than mine (AMD Duron 700MHz).

Anyways, I made a MinGW build of MININIM 0.9.2.1*. Hopefully, skilled (and non-skilled ) PoP players can use this to help me out with the particular mission of this thread. GNU/Linux users can easily build from the VCS (if that's not the case, let me know).

* The fourth digit indicates it's not an official release.

When you've implemented this I will completely rewrite that PDF document. I will include information about MININIM, and I will also change instructions from copying specific files of SDLPoP/MININIM into the prince/ directory to copying all SDLPoP/MININIM files into the directory and then applying modifications if necessary.

Thank you. I'm looking forward to this.

As for modifying apoplexy, this is more complicated/interesting.

What about maintenance releases once in a while?

The XML specification is meant to be used by authors of remakes/ports who prefer not to read and process any binary files, for instance if it's easier for them to read and understand the XML level files that apoplexy can export.

I see. So, for now, there is no compelling reason to implement a XML level module for MININIM.

[Norbert]

I made a MinGW build of MININIM 0.9.2.1*.

I've added this post to the thread about PoP1 tricks.
Hopefully I have accurately summarized what the idea is and how players can take up the 'challenge'.
It's a thread they are perhaps more likely to (fully) read.

* The fourth digit indicates it's not an official release.

Okay, I think I'll wait for an official release before replacing the PDF file that goes into using native PoP1 implementations with apoplexy.

What about maintenance releases [of apoplexy] once in a while?

I'm afraid I could not give a satisfactory explanation as to why - so I will not attempt to explain my reasoning and the reasons; sorry - but I've decided (quite a while back) that I personally won't make any more changes to apoplexy past its most recent version 3.0, not even for small bug fixes. I'm aware that this is somewhat strange. Either way, all my/our PoP work is voluntary, so it's nice to have the luxury of taking on and dropping projects without obligations. I've already seen customized builds of apoplexy in the wild, which can exist because of the free and open-source nature of the application. The program has some odd aspects (e.g. one big 30,000+ lines C file, its ShowImage() function, my extensive use of arrays; all that could be changed, of course), but my code is usually fairly readable.

[oitofelix]

I've added this post to the thread about PoP1 tricks.
Hopefully I have accurately summarized what the idea is and how players can take up the 'challenge'.
It's a thread they are perhaps more likely to (fully) read.

Thank you!

Okay, I think I'll wait for an official release before replacing the PDF file that goes into using native PoP1 implementations with apoplexy.

I can do an official release if that raises the likelihood of people playing MININIM. I don't have a rigid schedule for this. For me the crucial matter is what's best for the community. I'm open to suggestions and requests.

I'm afraid I could not give a satisfactory explanation as to why .... I'm aware that this is somewhat strange.

I'm quite a bit curious! I respect your right for silence, though.

The program has some odd aspects (e.g. one big 30,000+ lines C file...)

Wow, that's a lot! It's approximately 75% of MININIM's code and 166% of SDLPoP's code, in size.

[David]

I didn't use or look at SDLPoP's implementation. Is it big-endian friendly? I'd bet it's not [...]

It's not.
I added this some time ago: (At the same time when I added 64-bit support.)

Code: Select all

#if SDL_BYTEORDER != SDL_LIL_ENDIAN
#error This program is not (yet) prepared for big endian CPUs, please contact the author.
#endif

[...] because the original PoP had no such target.

It's more about whether SDL is available for big-endian systems.
http://wiki.libsdl.org/Installation
Support for PowerPC Mac, Amiga, Atari was dropped in SDL 2.0.
Are there any supported big-endian systems remaining?

By the way, the official ports of the original game for Mac, Amiga, Atari ST *are* big-endian.

[oitofelix]

It's more about whether SDL is available for big-endian systems...By the way, the official ports of the original game for Mac, Amiga, Atari ST *are* big-endian.

Just to clarify, when I say "original game", as far as MININIM is concerned, I'm considering only its model. It's modeled after the IBM-PC port of POP (and only that).

I've also made the implicit assumption (for a simple bet) that SDLPoP is based exclusively on reverse engineering of that port's executable. I don't know if that's the case, though.

[David]

Just to clarify, when I say "original game", as far as MININIM is concerned, I'm considering only its model. It's modeled after the IBM-PC port of POP (and only that).

Then it's correct, the DOS version has no big-endian variant.

I've also made the implicit assumption (for a simple bet) that SDLPoP is based exclusively on reverse engineering of that port's executable. I don't know if that's the case, though.

You're right.
(However, I copied some names from the Apple II source.)