Emerald Mine Club - no such thing as wrap-around movement?

[monsterman]

Because when I played an EMC levelset with some wrap-around places, I am unable to enter them when I don't have any other way around.

BTW - 2 things: How in the world did you make things move at the start of a level and how did you make these levels?:shock:

[Daniel H.]

Which levelset are you referring to?

[RAP]

I think Holger is trying to fix this problem right now. I've witnessed the lack of warp-around movement. We'll wait soon enough...

[Holger]

The current implementation of the native EM/EMC game engine does not support wrap-around. A future implementation will support this feature.

There are currently no plans to fix this problem any time soon.

[dave]

The current implementation of the native EM/EMC game engine does not support wrap-around. A future implementation will support this feature.

There are currently no plans to fix this problem any time soon.

this is implemented in my real emerald mine engine for a long time now:
http://www.emeraldmines.net/?emeraldx11

=edit= example - see ruppelmine 2 / level 80 - for working wrap around

[dave]

I think Holger is trying to fix this problem right now. I've witnessed the lack of warp-around movement. We'll wait soon enough...

you might wait a while. it has been available for over 3 years now but still no sign of it in rnd. how long does it take?

[RTADash]

how long does it take?

I think Holger is busy with his son and other preoccupations right now.

As I see it, he could have easily just left all the emerald mine levels partially broken under the RnD engine and said "Tough luck", but he personally chose to go to the trouble of adding a second engine into the game, to make all of those external levels function ~99% as intended. I'd be grateful for what he's managed to do up to this point.

[dave]

As I see it, he could have easily just left all the emerald mine levels partially broken under the RnD engine

heh "partially"

and said "Tough luck",

like he is saying about upgrading the engine?

but he personally chose to go to the trouble of adding a second engine into the game,

going to the trouble of doing something you already said you would do? and what of the mysterious boulderdash and supaplex engines?

to make all of those external levels function ~99% as intended. I'd be grateful for what he's managed to do up to this point.

you mean cut&paste my software? not much in that. where would this point be if i hadnt written it in the first place? credit where it's due.

ps. it would be interesting to know how many emerald mine caves are actually possible with the rnd engine, to find out just how "partially" broken it is.

[RTADash]

like he is saying about upgrading the engine?

A 2 (3?) year old child is hard work for anyone if they're doing a good job. (And I just know that Holger is.)

going to the trouble of doing something you already said you would do? and what of the mysterious boulderdash and supaplex engines?

They'd be nice too, but I imagine that every throwback engine takes not only a long time to get to a point where it's usable, but then to also fine-tune it over the course of many updates.
I personally wouldn't mind if the game development went on a 4 year hiatus if that's what it took for him to ensure the best for his son.

you mean cut&paste my software? not much in that. where would this point be if i hadnt written it in the first place? credit where it's due.

I'm not denying that you wrote an engine, but did you rewrite the EM engine entirely, or just extend the engine by Klaus Heinz and Volker Wertich? (not trying to be offensive here, I'm just wish to learn more about who did what) Is it in the same or a similar programming language to RnD?

ps. it would be interesting to know how many emerald mine caves are actually possible with the rnd engine, to find out just how "partially" broken it is.

Do you mean the RnD engine or the current EM engine? They are two different engines, with different timing and rules.

Edit: Looking over this again, I have to apologize for my somewhat aggressive behaviour, and for putting words in Holger's mouth. I rest my case for now; I think it would be best if we wait to see what he has to say without either of us making one more assumption about him or his work in the meantime.

[Holger]

Thank you for your post, RTADash! You are totally right, especially regarding my two year old boy keeping me from developing R'n'D. :-) (Yes, he's really already two years old! :-o )

But to stay on-topic (a little bit at least), here are also some notes and history on the current and upcoming engines in R'n'D!

About David Tritscher's EM/EMC compatible game engine:

I'm happy that I had the opportunity to integrate a game engine that is highly compatible with the original EM engine by Klaus Heinz and Volker Wertich and the EMC engine by No One and Ruppelware. According to David, this engine is a rewrite that was neither based on code of the EM nor the EMC engine, but independently rewritten from scratch. Nevertheless, it's highly (though not totally, therefore the "99%") compatible with the classic engines!

As David's EMC game engine is wrtten in C just like R'n'D, it was relatively easy to get it running in R'n'D (by using "cut & paste", if you want). This "get it running" means that the new code was started somewhere from within R'n'D and then painted it's output into the R'n'D window. This was the point where _integrating_ the new engine into R'n'D just started (somewhat similar to a heart transplantation, where the real work also starts _after_ the "cut & paste" of the heart ;-) ).

A lot of big and small things had to be done for a seamless integration, like changing the graphics engine to be able to use the R'n'D artwork customization scheme (use the new engine with custom R'n'D artwork, but also vice versa by letting the R'n'D engine use artwork defined for the EMC sets the other way round); adding internal level format conversion code (to be able to play R'n'D levels with only EM/EMC game elements with the native EM/EMC engine, and to be able to play native EM/EMC levels with the R'n'D game engine); adding game snapshot code to quickly save and load the game state within the game; writing converters to import not only the over 50.000 levels of the EMC collection, but also the level set specific graphics, sounds, title screens and Amiga boot shell messages to provide a nostalgic EMC experience as complete as possible.

(These over 50.000 levels of the EMC level collection that were converted with a bunch of scripts from Amiga disk images containing various different game data formats for the new EMC engine in R'n'D in a structured archive can now also be converted to and used by David's EMC game ("Emerald Mine for X11") by a special converter -- it's good to see that the original program that made the EMC engine in R'n'D possible now also profits from my work on the huge and complete EMC level archive for which the EMC engine was added to R'n'D in the first place! :-) )

About "broken engines": Although the native EMC engine still does not play _all_ of the over 50.000 EMC levels, it's still highly compatible with the original EM/EMC game engines on the Amiga and far away from being "broken". Regarding the R'n'D game engine not being able to play many of the classic EM/EMC levels, it is important to know that it wasn't intended to be a highly compatible EM/EMC game clone in the first place, but to be a tile based game in the tradition of BoulderDash, Emerald Mine, Supaplex and Sokoban, with game elements from these games and others (like DX-Boulderdash, for example). The intention was to be able to create and play levels with similar appearance and game-play (like in Sapphire Yours or Sub Terra), not to directly play unmodified original levels from those classic games (like in Diamond Caves, which is not only a perfect Emerald Mine clone, but a superset of it with many new elements (but not compatible with the Emerald Mine Club engine)). As more and more people also asked for compatibility with existing classic levels, the idea of adding separate, highly compatible, native game engines was born (as it is quite impractical to write a single game engine that aims to be 100% compatible with _all_ classic game engines). The EM/EMC engine was the first of these native game engines, the native Supaplex engine will follow with the next major release of R'n'D (planned to be released this year).

About the "mysterious boulderdash and supaplex engines":

While the native BoulderDash game engine is still on hold (because I cannot do them all at the same time :-) ), the native Supaplex engine is close to being completed. It was a bit more complex than the EMC engine, and took several years to do the conversion of the engine code alone (not working all of the time on it, of course :-) ). Contrary to the EMC engine, which was written in C just like R'n'D, the Supaplex engine code is based on Frank Schindler's Supaplex clone "Megaplex", which was written in Visual Basic, and was based on Assembler code created by disassembling the original game executable (the same disassembly that was used to generate Herman Perk's "SpeedFix" version of Supaplex, that made it possible to play it on modern PC hardware). To transform this large amount of Visual Basic code to C without getting crazy over manual code conversion, I wrote a Perl script that automatically translated the Visual Basic code to C until it was (more or less) compilable. Then I had the foundation on which I could start to integrate it into R'n'D as the second native game engine (with all the integration details and fine-tuning work described above and correctly assumed by RTADash). This second native game engine is indeed 100% compatible with the original game engine, because the relevant game engine logic is 100% identical to the original engine! It is already able to automatically solve all Supaplex demo files (similar to R'n'D tape files) that are also solved by the original Supaplex and Megaplex games. Work on it is nearing completion and will hopefully be available to the public soon (where "soon" does not mean "next week", but "next version", whenever this may be (but expected to be within this year :-) )).

Phew! This was quite a good lot of writing work! (Only possible because my little son is already sleeping. :-) No coding anymore this night, as he will wake up again soon, and then I do have to be well-rested... ;-) )

[dave]

As David's EMC game engine is wrtten in C just like R'n'D, it was relatively easy to get it running in R'n'D (by using "cut & paste", if you want). This "get it running" means that the new code was started somewhere from within R'n'D and then painted it's output into the R'n'D window. This was the point where _integrating_ the new engine into R'n'D just started (somewhat similar to a heart transplantation, where the real work also starts _after_ the "cut & paste" of the heart ;-) ).

A lot of big and small things had to be done for a seamless integration, like changing the graphics engine to be able to use the R'n'D artwork customization scheme (use the new engine with custom R'n'D artwork, but also vice versa by letting the R'n'D engine use artwork defined for the EMC sets the other way round); adding internal level format conversion code (to be able to play R'n'D levels with only EM/EMC game elements with the native EM/EMC engine, and to be able to play native EM/EMC levels with the R'n'D game engine); adding game snapshot code to quickly save and load the game state within the game; writing converters to import not only the over 50.000 levels of the EMC collection, but also the level set specific graphics, sounds, title screens and Amiga boot shell messages to provide a nostalgic EMC experience as complete as possible.

this doesnt accurately represent the real amount of work in writing Emerald Mine for X11.

sound, graphics, joystick etc. makes up about 15% of the total code, which would need to be written for any new port anyway. (rnd in many ways is like a new target; it has its own way of using graphics, sounds, input devices etc which is different to windows or unix etc). an important note is that this only needs to be written once per platform (including for rnd) and fogotten about. the code to copy little bitmaps around or draw lines doesnt need to change once its written.

but the point is the game logic is identical across all ports. when the game logic changes it should have no impact on any system specific code (eg graphics) so it is easy to cut&paste it in and voila! new features. there is very little extra work involved. your artwork customization schemes and snapshots and converters should not even need a single line changed (assuming it is coded well in the first place).

no, the real effort is in the game logic.

its not a coincidence that the logic is consistent even in extremely rare cases. there are things in it so subtle you only learn it after a _long_ time of developing. i have been debugging it for 15 years which is evident by the amount of actual bugs reported in these forums (as far as i can tell its less than 1 and at the very least, counted on one hand).

this is why i want to be credited properly. it is 10x harder to debug than write, and it is 10x harder to write than merge it in to another program.

this is also why i insist it must not be changed. if you find a bug, ill fix it and we both benefit. i have no patience to fix other peoples broken changes, after 10 years of very careful writing and testing (and playing :-).

(like in Diamond Caves, which is not only a perfect Emerald Mine clone, but a superset of it with many new elements (but not compatible with the Emerald Mine Club engine)).

i played diamond caves when it first came out, (when i still had my amiga :-) and it is not a perfect clone. iirc you could collect emeralds and diamonds as they fell, which is a fatal flaw in any emulation of emerald mine. also i found explosions in dc to be wrong. perhaps its fixed in new versions?

bd4 is probably the most accurate emerald mine clone ive seen. afaik it is along the same lines as Emerald Mine for X11 (built from disassembling the original kingsoft code) but he focused on compatibility (except no NOI/RIS additions), and succeeded.

While the native BoulderDash game engine is still on hold (because I cannot do them all at the same time :-) ), the native Supaplex engine is close to being completed. It was a bit more complex than the EMC engine, and took several years to do the conversion of the engine code alone (not working all of the time on it, of course :-) ).
Contrary to the EMC engine, which was written in C just like R'n'D, the Supaplex engine code is based on Frank Schindler's Supaplex clone "Megaplex", which was written in Visual Basic, and was based on Assembler code created by disassembling the original game executable (the same disassembly that was used to generate Herman Perk's "SpeedFix" version of Supaplex, that made it possible to play it on modern PC hardware). To transform this large amount of Visual Basic code to C without getting crazy over manual code conversion, I wrote a Perl script that automatically translated the Visual Basic code to C until it was (more or less) compilable. Then I had the foundation on which I could start to integrate it into R'n'D as the second native game engine (with all the integration details and fine-tuning work described above and correctly assumed by RTADash). This second native game engine is indeed 100% compatible with the original game engine, because the relevant game engine logic is 100% identical to the original engine!

see how hard it is? and it sounds like most of the work was already done for you. someone else has dissassembled it, and written it in visual basic, and debugged it, and made sure it's (as you say) 100% compatible. (i am skeptical of this. you have very different programming langauges and runtime environments. if the original code relys on such things you will have a hard time emulating it. for example in emerald mine to be 100% compatible would require the amiga ROM because it is used for random numbers. another problem is code that examines uninitialized memory (see level 80, in both ruppelmine 4 & 5).

[Holger]

A quick question to clarify before answering your whole post:

[bd4]
> afaik it is along the same lines as Emerald Mine for X11
> (built from disassembling the original kingsoft code)

So "Emerald Mine for X11" is also based on a disassembly of the original Kingsoft engine code? I assumed this, but wasn't sure.

[dave]

So "Emerald Mine for X11" is also based on a disassembly of the original Kingsoft engine code? I assumed this, but wasn't sure.

going back a long time...

i disassembled original kingsoft emerald mine, and re-wrote it from scratch in assembly for the amiga.
then i found the emerald mine club enhancements (in their demo) and i disassembled that and then added those elements (this was not a re-write, each new element was implemented from scratch), still in assembly for the amiga.
then i got an ibm pc and put linux on it, and ported the assembly that i had written to c.
then a few years later i decided to rewrite the c code and remove some restrictions and add more flexible data structures etc.

so to answer your question, no it is not based on disassembly, it is written and re-written three times, in c, entirely from scratch.

=edit= let me clarify this: i have never used even a single line of code from any emerald mine game, on the amiga or otherwise. every time i wrote new code (of which most doesnt exist anymore) it was always from scratch. each new version improved on the last, and after 3 complete rewrites, it has become stable and mature.

Regarding the R'n'D game engine not being able to play many of the classic EM/EMC levels, it is important to know that it wasn't intended to be a highly compatible EM/EMC game clone in the first place ...

yet you, and others, continue to say its 'partially' compatible with emerald mine.
exactly how much is that?

try 99.8% incompatible (100 em levels shipped with rnd divided by 50 000 total).

ps. has anyone verified the 'classic original games/emerald mine' that comes with
rocksndiamonds are all solvable?

[RTADash]

has anyone verified the 'classic original games/emerald mine' that comes with rocksndiamonds are all solvable?

All of the levels that can be played with just a single player [0-81] are solvable. Haven't tried the ones that require multiplayer mode; 82-end. (Only one of me at the computer ) However with the new implementation of player-focus-switching into the RnD engine, I'd say that they'd all likely be solvable now, too.

yet you, and others, continue to say its 'partially' compatible with emerald mine. exactly how much is that?

Could range from .00000000001% to 99.9999999% and still truthfully be considered partial . Coming up with an exact figure is hard, with 50,000 levels to playtest. (probably 40,000 if you remove the duplicates though)

[somewhat off-topic] On a side note, I feel the need to mention that 99/100 of the original Boulder Dash levels and 110/111 of the original Supaplex levels are also solvable under the RnD engine. Not too shabby, given the RnD engine isn't nearly identical to any of these, behavior-wise. It's when compatibility of later levels and engine versions is desired, that things get complicated. I personally am very interested to see how the BD engine will turn out, with that classic being my forte of the three. [/somewhat offtopic]

[dave]

has anyone verified the 'classic original games/emerald mine' that comes with rocksndiamonds are all solvable?

All of the levels that can be played with just a single player [0-81] are solvable.

did you personally solve them all? how long did it take?

However with the new implementation of player-focus-switching into the RnD engine, I'd say that they'd all likely be solvable now, too.

how do you know that?

yet you, and others, continue to say its 'partially' compatible with emerald mine. exactly how much is that?

Could range from .00000000001% to 99.9999999% and still truthfully be considered partial

Regarding the R'n'D game engine not being able to play many of the classic EM/EMC levels ...

what is the range for 'many' ?

[somewhat off-topic] On a side note, I feel the need to mention that 99/100 of the original Boulder Dash levels and 110/111 of the original Supaplex levels are also solvable under the RnD engine. Not too shabby, given the RnD engine isn't nearly identical to any of these, behavior-wise. :)

so not even 100% for 3 level sets (original emerald mine, original boulderdash, and original supaplex) out of ~600 sets? hmm thats still only 0.5%
what is the range for a 'coincidence'?

ps. it would be interesting to know how many emerald mine caves are actually possible with the rnd engine, to find out just how "partially" broken it is.

Do you mean the RnD engine or the current EM engine?

i have gone ahead and hilited the relevant parts of my original message.