Player skidding is still a big big problem

[Nannerpus]

Hello everyone, it's been a long time since I played, it is good to be back.

Unfortunately, it seems that a problem I reported long ago has not been dispatched. I reported that my player frequently "skids" during the development phase of my turn. In other words, he continues to move in a previously commanded direction even though I have either stopped pressing movement keys or I have attempted to change the player's direction of motion.

Additionally, it is almost impossible for me to command proper plot selection during the first few seconds of each land grant phase. Typically I notice that my button press to choose a plot will go totally unacknowledged until at least three seconds have elapsed during the land grant. Only occasionally can I shorten this delay by holding the button before the cursor begins to move. And I almost never get stuck with a later-selected plot as one might expect if this were a simple lag issue. It just seems like I'm temporarily "locked out" until a certain time has elapsed, and then things function as they should when I try to select a plot.

The skidding problem occurs with varying frequency; sometimes it will hardly happen in a game, while other times it will be a major difficulty throughout an entire game. The button latency issue occurs during every turn of game in which I attempt to pick from one of the first three to four plots available during the land grant.

The skidding problem also occurs during auction phases. Then, the player will overbuy (oversell) even though I have commanded him to either stop buying (selling) or I have commanded him to reverse his course. Similarly, there is occasionally a delay of 2-3 seconds before the player will begin to move as commanded during sale price negotiations, causing the player to stand still when he's been commanded to move up or down.

Please have a look at my recent game logs, as each of them has demonstrated this problem, occasionally severely (i.e., every turn or nearly every turn has a skid event):

http://www.planetmule.com/hi-score-game/game?game_id=41218
http://www.planetmule.com/hi-score-game/game?game_id=41205
http://www.planetmule.com/hi-score-game/game?game_id=41071
http://www.planetmule.com/hi-score-game/game?game_id=41065
http://www.planetmule.com/hi-score-game/game?game_id=41055
http://www.planetmule.com/hi-score-game/game?game_id=40999
http://www.planetmule.com/hi-score-game/game?game_id=40993
http://www.planetmule.com/hi-score-game/game?game_id=40986
http://www.planetmule.com/hi-score-game/game?game_id=40982

I don't think this is a network lag issue, in most of the games above I have had a very decent ping, usually under 500 ms.

To refresh everyone's memory, I first started experiencing this problem last year (Sep-Oct 2010) after switching to a new computer. It is a Mac Mini, 2.4 GHx Intel Core 2 Duo with 8GB RAM. It runs Mac OS X 10.6.6 and has always run 10.6.x since I first began using it. The current Java is Apple's Java SE 6, both 64- and 32-bit available, with 64-bit taking precedence. The Java is based on version 1.6.0_24-b07-334. My previous computer was an older Mac Mini, a 2.0 GHz Intel Core 2 Duo with 2GB RAM, running Mac OS X 10.5.8 with Apple's Java SE 5, which I believe was based on a different Java version, but I cannot remember the Java version number.

BTW in almost all of the games linked above, the machine was not running any other applications, perhaps a single browser window at the most. I made sure to unmount all my external hard drives and power them off. I also disabled wireless networking and deactivated my screen saver.

One other noteworthy performance degradation I've noticed while using my current Mini: switching from "chat screen" to "full screen" map viewing mode incurs a horrendous 5-10 seconds delay, during which any music or activity sounds continue looping as though time has frozen.

I first observed this problem while using P.M. version 1.3.3 and also observed it under 1.3.4 before I took my long break.

I'm not knowledgeable about Java but if there's anything I can do to help solve this devilish problem please let me know. I'm astonished I managed to win even one game with this occurring so frequently, but usually it winds up costing me a significant loss of development time for at least a few turns each game.

Thanks & sorry for the long post,

Nannerpus

[Peter]

Hello,

Thanks for the detailed report.

I'm confident that this is a keyboard input issue on Mac. It may be possible to adjust how Planet Mule reads input on Mac to counter this issue. We've noted to look into it for future updates at least.

I've read that other Mac users have installed some keyboard application which makes the input work better. You could try searching the forum to find the name of that program.

If you manage to solve this issue, then please tell us what you did.

Regards,
Peter

[Nannerpus]

Peter,

Is there anything I can do to help the Turborilla team as far as collecting data from my computer while P.M. is running a game? Maybe there's a trace or profile operation I could perform, I'm not sophisticated enough to imagine one up but if you can direct me I'm glad to give it a try.

I do know that the bugs I've described don't show up in practice games, so there's something about the interaction of my system with other players across the network that's taking place, I just don't know where to start looking.

At your service,

Nannerpus

[Peter]

If there's a keyboard input issue it ought to show up also when you play locally. Could you verify that no "skidding" occur while you play locally against AI opponents? Could you also check if you have a substantially lower FPS while playing online compared to local (The FPS number is shown in the status bar at the bottom)?

I still recommend trying to find that Mac keyboard application I know other users have installed.

[Nannerpus]

In all of my tests playing training games against three A.I. robots, there is never any skid/dead button problem.

Occasionally if I am hosting a tournament game with three live players I will experience the skid/dead button problems. I can't recall any notable difference in frequency of occurrence compared to games I play in but do not host. It seems pretty random but tends to occur more often under high network loads (i.e., during the "day" here in the U.S.A. when playing against U.S.-located opponents). And for some reason it seems like lots of chat activity can exacerbate the condition, particularly at the start my development phase. At those times my worker just stands in place, frozen & unresponsive to my movement commands while the timer bar creeps down at its normal rate.

I have not observed FPS changes because I usually play in fullscreen mode, but I'll take a look next time I'm playing.

Thanks,

Nanner

[Nannerpus]

I just played a full tournament game in chat-screen mode. (Where the **** is that Wampus?) I was hosting. Log here: http://www.planetmule.com/hi-score-game/game?game_id=41377 (How's that for a close finish, BTW?)

Throughout the game I kept an eye on the FPS counter, it was at 60 with occasional drops to the 55-59 range.

I experienced three major skid/freeze events. During two of them the FPS never dropped below 58. I was not checking the FPS counter the third time.

More info: My computer is driving an Apple 27" HD LED display. I forgot to brag about this earlier  The screen resolution is set at 2560 x 1440 x 32bits. I will try another game at a lower resolution & see what happens.

The computer indicates that the graphics processor is an NVIDIA GeForce 320M on the PCI bus. It has 256MB VRAM and I don't know if any of it is shared with the CPU or if that full amount is solely in use by the GPU.

Thanks,

Nannerpus

[Peter]

It's just a thought, but maybe the skidding occurs when you receive chat messages? Did you notice if the skidding would occur more frequently in fullscreen mode compared to windowed/chat-screen mode? Anyway, I don't think it's related to the FPS. I assume you get the "Click here to focus the game" while you're typing in the chat.

[Chuckie Chuck]

Peter - I can't actually answer for him, but my understanding is, it does to better in full screen, but it still happens some.  The issue occurs during development phase while HE is developing, it's like the keyboard sticks, and he just keeps going instead of stopping or changing direction when he intends.  Has resulted in lost mules, and inability to get back to the store before the timer runs out.  I've witnessed the skidding when I've played with him.  I think the keyboard driver is likely a key component here, may be related to keyboard buffer and repeat rate configuration.  I don't have a MAC so I can't play with this idea and figure out if I can duplicate and/or solve the issue.  (I am getting an older G4 with OSx 10.5.8 from a friend soon, and it doesn't match the machine in question, but if I'm right, I might be able to force it to skid and come up with a fix.  Assuming it will handle running Mule, lol.)

[Nannerpus]

Update: I've played a couple of games with a reduced screen resolution setting (1600 x 900) in my "Display Preferences." This has largely eliminated the two key symptoms indicative of the skid/dead button issue. I have not observed any skids or freezes when controlling the worker during the development and auction phases of the turn. I also have not experienced the 2-3 seconds "blocking" of the button during the land grant phase.

Another symptom, that of a consistent 1-3 seconds lag in the posting of my chat messages, has been reduced to a smaller lag of less than 1 second. In addition, the "glitch" associated with switching between fullscreen and chat-screen modes is also reduced from over 5 seconds to about 2 seconds.

These observations have not been impacted by altering the keyboard repeat rates or repeat-onset delay settings, which were targets for my earlier attempts to remedy the problem (approx. Sep. - Oct. 2010). They are also insensitive to the viewing mode choice: the improvement observed is identical in fullscreen and chat-screen modes.

All of this points to the likely inability of my computer's graphics processor to drive a large number of pixels while maintaining the quality of responsivity to user input that M.U.L.E. requires. For my fellow arithmetic enthusiasts, the reduced resolution setting uses only 39% of the virtual pixels compared to the maximized native display resolution setting. It appears the NVIDIA GeForce 320M is the little engine that can't, if it's trying to lug over 3.5 megapixels uphill at 60 FPS.

I don't have any suggestions for further investigation but I welcome expert advice and if asked I will assist the game developers in any way I can.

Thanks,

Nannerpus

[Chuckie Chuck]

1.  Play with graphics card rendering settings (since the game uses GL, that may have an effect)

2.  Keep checking with Apple to see if they have a driver update for bug fixes with the GeForce (or even check with GeForce?  This is an integrated card right?)

[Peter]

Update: I've played a couple of games with a reduced screen resolution setting (1600 x 900) in my "Display Preferences." This has largely eliminated the two key symptoms indicative of the skid/dead button issue...

Thanks. That was useful info. I've noted that we should test what impact larger resolutions have on Mac computers and check if slow rendering can affect the input.