Problems with native EM engine?

Found a bug in R'n'D? Report it here!

Moderators: Flumminator, Zomis

Post Reply
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Problems with native EM engine?

Post by Holger »

In thread viewtopic.php?t=1810 , dave wrote:

> the rocks'n'diamonds version of my emerald mine engine has problems
> with playability (especially with a joystick) because it seems my old
> program (circa 2001) was butchered and my input stuff removed. i guess
> Holger didn't realise how important it was to keep the same input type
> method.

You're right that I mainly took the game engine, but used the input device code (joystick and keyboard input) and output device code (graphics and other artwork and display code) from R'n'D (although the EM engine still can use two different artwork engines, but this is still limited in the current release version).

About your main point here: Yes, I have changed the input device code from your approach to R'n'D's input device code, and indeed this is a little change away from original Emerald Mine behaviour. Interestingly, I did that change to improve playability, especially with a joystick! Some explanation: The original Emerald Mine joystick code only allows for horizontal *or* vertical movement when both directions are involved (that is, if the joystick is pressed diagonally). In R'n'D (and in the EM engine in R'n'D), the R'n'D behavior is used, which is a pseudo-diagonal movement (subsequent steps in vertical and horizontal direction).

I agree that this makes some EM levels a little bit easier to play, as the required level of physical or "artistic" control of the joystick is quite a bit reduced. (For example, try to escape from an enemy in a maze -- this is a bit easier with the R'n'D joystick code than with the EM joystick code, as you can't get "stuck" at wall corners when not 100% making sure that only horizontal or vertical directions are pressed at the joystick at all times.)

In my opinion, this is an advantage, although things are a little bit easier to play than with the original game.

I would like to hear if this is what you thought about regarding playability, or if there are other things that I oversaw or that I maybe messed up.

> also the graphics are screwed up in r'n'd when playing EMC caves from the
> huge archive.

Yep, right. This problem will be fixed with the next version of R'n'D and the next version of the huge EM collection. Sorry for not having it released yet! :-o

> my program is open source but i dont know when or if the latest engine will
> end up in rocks'n'diamonds.

As the incorporation of the older EM engine into R'n'D took quite a while, I cannot say when I will be able to update the engine to your new version. (Especially as there are some changes I made to accomplish compatibility with existing EMC disks, while your version of the game engine aims for a more "clean" version that does not contain each and every quick to assure total compatibility with EMC disks that may have misused engine bugs as "game features", like the walkable acid pool thingie in some sets.)
dave
Posts: 77
Joined: Mon Aug 13, 2007 2:06 am
Contact:

Re: Problems with native EM engine?

Post by dave »

Holger wrote:About your main point here: Yes, I have changed the input device code from your approach to R'n'D's input device code, and indeed this is a little change away from original Emerald Mine behaviour. Interestingly, I did that change to improve playability, especially with a joystick! Some explanation: The original Emerald Mine joystick code only allows for horizontal *or* vertical movement when both directions are involved (that is, if the joystick is pressed diagonally). In R'n'D (and in the EM engine in R'n'D), the R'n'D behavior is used, which is a pseudo-diagonal movement (subsequent steps in vertical and horizontal direction).
the diagonal thing was nice & i put it in my code :)

the problem i meant was that in kingsoft emerald mine, the joystick was read every frame, even though the player only got moved only every 8th frame. when the joystick is read every frame, there is two sets of state involved. one state is the current joystick position, and the other state is a kind of 'sticky' position, where it tracks the most recent direction from the joystick. so if you make a quick movement from the joystick, the first state may end up empty (because you moved the joystick back to the centre by the time the 8th frame came around), but the 'sticky' state remembers that a sharp movement was made.

when it comes time to move the player, these states are examined to move the player. which state to use depends on whether the player stood still 'last' time. if the player was standing still, the sticky state is used (so if he was still and you made a quick joystick move, it is picked up and used). if the player was _not_ still last time, the first state is used. this means that if you let go of the joystick between player movements, even though the sticky would still register a movement (because the joystick was held down to walk), you would stop because the state at the exact momement of movement was empty.

unfortunately its quite difficult to explain, but it is one of the major contributors to playability in emerald mine. i think the code is still in my old engine. look for joy->state and joy->sticky in the part that moves the player. the code to read the joystick is quite a lot simpler. when you read the joystick (every frame), always put the direction to move in joy->state. if the direction was _not_ joystick centered, put the direction to move in joy->sticky aswell. after calling the code to move the player, zero out joy->state and joy->sticky ready for reading next frame.

oh, and the fire button is always put in joy->state and joy->sticky, whether there was movement or not. the direction and fire is slightly separated. i dont know how much this affects things because i've never tried to change it :)

when i tried to play the EMC caves with r'n'd, it felt like the joystick was being read once, right on the 8th frame, just before the player moved. this is quite horrible to used, i ended up not stepping sometimes, and others i would step twice. the keyboard was a little better but emerald mine needs a joystick :)
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

> the diagonal thing was nice & i put it in my code :)

Good to know! :-)

> so if you make a quick movement from the joystick, the first state may
> end up empty (because you moved the joystick back to the centre by the
> time the 8th frame came around), but the 'sticky' state remembers that a
> sharp movement was made.

Now I understand -- very good!!

In fact I have to admit that I most probably not completely understood what exactly this "sticky" direction state did, and apparently thought I could remove it. :-o

But this is VERY useful for joystick responsiveness if the player can move only every 8th frame (as is the case with the native EM engine)!

> unfortunately its quite difficult to explain, but it is one of the major
> contributors to playability in emerald mine.

I will definitely re-implement it again! This will surely improve playability of all those EM/EMC levels a lot -- thanks for explaining this in detail!

> when i tried to play the EMC caves with r'n'd, it felt like the joystick was
> being read once, right on the 8th frame, just before the player moved.

Although the joystick is read every frame, the EM engine indeed only uses the device state of the frame where the player can move (so it's just the same as if the joystick was read only every 8th frame)! :-/

> this is quite horrible to used, i ended up not stepping sometimes, and
> others i would step twice. the keyboard was a little better but emerald
> mine needs a joystick :)

This "sticky" trick can just as well be used for the keyboard, too (although it's probably a bit harder to press and release a cursor key in the non-moving seven frames than it is to move the joystick the same way).

So this trick would improve playability of the EM engine regardless of the input device that was used.

I'll try to fix this for the upcoming next version!
dave
Posts: 77
Joined: Mon Aug 13, 2007 2:06 am
Contact:

Post by dave »

i had a closer look at the code you have copied and changed from my old emc code into rocks'n'diamonds and i am a bit disappointed. the changes you made appear to be incomplete.
you removed a sound effect when going in the exit with the comment in the code saying the exit sound is played twice. the trouble is you removed the wrong one. the sample should be played when the player walks into the exit, not when the player is on the exit and therefore killed. its a slight bug but it's still a bug (i can create a cave where the player goes in the exit and it is considered won, but the sound is not played).
the fake acid object you added is very incomplete. fake acid is exactly blank space. but your changes don't treat it as blank space except for a falling stone. in the entire logic code, every time something checks for a blank space, fake acid should be accepted too. in kingsoft's engine, fake acid is internally replaced with the blank space code. the way i coded acid is already very incompatible with all emc engines, and fake acid added nothing but bugs.
only yesterday i found a bug in my code (including my code in r'n'd). a 0 time for a wheel means infinite for caves up to version 5. when loading an emc cave in r'n'd, if the version is not v6, a wheel time of 0 should be changed to 9999. this bug broke some caves :(
if you ever put in my latest emc code, dont change anything in logic(). even if it looks like better compatibility dont change it. there are too many subtle things going on and it will probably break. even i hesitate to change things in it. if you want exact compatibility, hassle the BD4 guy for his code, or run UAE.
dave
Posts: 77
Joined: Mon Aug 13, 2007 2:06 am
Contact:

Re: Problems with native EM engine?

Post by dave »

Holger wrote:You're right that I mainly took the game engine, but used the input device code (joystick and keyboard input) and output device code (graphics and other artwork and display code) from R'n'D (although the EM engine still can use two different artwork engines, but this is still limited in the current release version).
i found that this patch helps on the linux sdl version. the rest of the code in this function appears to work fine with or without the patch, but there might be something subtle going on and this helps? dunno, but it worked for me:)

--- src/events.c~ 2008-07-15 07:34:01.000000000 +1000
+++ src/events.c 2008-12-10 12:37:53.755703000 +1100
@@ -122,5 +122,5 @@
while (1)
{
- if (PendingEvent()) /* got event */
+ while (PendingEvent()) /* got event */
{
Event event;
@@ -150,5 +150,4 @@
}
}
- else
{
/* when playing, display a special mouse pointer inside the playfield */
Post Reply