Analog Overflow in Centipede games

Weehawk · Post by **Weehawk** » Sun Feb 20, 2005 10:18 pm

Okay, these games, like all tracball games in MAME, have always been subject to analog overflow. This is a phenomenon which occurs when you try to move the mouse too fast and exceed some sort of limit as to what the program can handle for input. The result is usually that the behavior of the onscreen controlled item will not match the motion indicated by the mouse. In Centipede, the shooter may stutter and drag, or may swing off to one side crazily for a moment.

Some ROMsets seem to be more sensitive to this than others, and various MAME version over the years have likewise not been consistent, some being more sensitive than others.

With MAME versions 70 through 83, I was able to play these games fairly well simply by keeping my movements steady and fluid, nothing too jerky. This is a weakness in the emulation, as I would NOT be able to make the same type movements that I would when playing the real machine, but I could play a decent game at least. It's not just me, other players, including the Centipede and Millipede world-record holder Don Hayes report the same conclusion.

Recently a problem was fixed with "pokey" the sound chip for early eighties Atari games. These games can now be recorded and played back with sound on, before it would not work. Unfortunately something has also gone really weird with the analog overflow issue.

I find that on centtime, and centiped, the only ROMs I've tried so far, that at the very start of the game, the shooter is completely uncontrollable, but that it goes away after a couple of minutes and the game behaves much as it did in older versions.

The recording attached demonstrates what happens every time. You can see that my shooter slams over to the left side of the screen immediately. That's not intentional. You can see that I try to move to the right, but keep getting slammed right back into the left side. I can shoot and control my brief right movements well enough to survive for a little while. Then suddenly, a little under 5000 points, the problem disappears and I can play normally, or as close to normally as I ever could in MAME.

Why the heck would this happen for a few minutes, and then change? Somebody ought to be able to figure something out based on this. Perhaps this will provide a clue as to why the analog overflow thing exists in the first place and maybe something can be done about it.

Watch the recording, made with WolfMAME .91 and see what you think.

The TJT · Post by **The TJT** » Sun Feb 20, 2005 11:57 pm

Good news, not happening here..maybe it's your setup, errr hehe...

...Tried centiped with wolf92. First everything was slow...I changed analog controls x-sensitivity and y from 30% to 150% then the ship moved better.

Since I can't do s*** at centipede, tried marble:
At analog sensitivity of 206% at my setup, game was very close to arcade...could roll trackball as fast as wanted, no overflow thingy, no matter how fast I was rolling...Was able to finish the game after 2-3 years away from it...Not bad

At sensitivity 225% or such, overflow appeared.
---------

My windows mouse driver enables me to kill completely acceleration when using mouse. So only thing I change when changing analog sensitivity in mame is mouse (cursor) speed, not acceleration.
Maybe this is the difference between setups.

I have folders ctrlr and CFG at my wolf92 directory. Do you have cfg?
I don't have nvram.

Sounds though like you'd have analog joystick connected in your system that might cause probs?
Using analog joystick and recording often requires little wiggling before mame recognises joystick properly.

QRS also reported similar, but opposite behaviour at shangon...controls freaking out after couple minutes.

Chad · Post by **Chad** » Mon Feb 21, 2005 2:00 am

around 83 that's when the doubled the inp frame size, so what you may be experiencing is a harddrive bandwidth problem and since the more you move the mouse the more data you have to spit to the drive (because of extra analog frame bits being variable length). Still (120+x)*60=~10k per second seems like any drive should handle it, less it's a buffering problem in mame itself. just some info, can't be sure it's the trouble.

Post by **mahlemiut** » Mon Feb 21, 2005 2:30 am

Chad wrote:around 83 that's when the doubled the inp frame size, so what you may be experiencing is a harddrive bandwidth problem and since the more you move the mouse the more data you have to spit to the drive (because of extra analog frame bits being variable length). Still (120+x)*60=~10k per second seems like any drive should handle it, less it's a buffering problem in mame itself. just some info, can't be sure it's the trouble.

That was 0.84u4. Don't forget the bug that caused oversize inp files too, from 0.84u4 to 0.87, and 0.90u2 to 0.91u2.

dbh · Post by **dbh** » Mon Feb 21, 2005 6:41 pm

I just recorded a game of Millipede using Wolf 0.92. I didn't have any major issues with trackball control and I was able to playback with sound enabled, but there were some other major problems with the emulation.

On two or three instances, the millipede froze at the top of the screen, usually right at the transition between a swarm wave and the next wave. During this time, everything else appeared to behave correctly. The other major problem was with swarm waves. On later levels, there is usually a constant barrage of creatures, but on many occasions there would only be a handful of things coming down when there should have been a lot more. I also noticed a couple times where 5 or 6 bees would come out in exactly the same column which is highly unusual. I'd guess these problems are associated with the recent pokey chip fix.

The file is too big to attach so I've posted it here:

http://www.centipede.us/marp/dbh-milliped-682101.zip

zlk · Post by **zlk** » Tue Feb 22, 2005 8:51 am

Nice millipede replay dbh.

NotMan · Post by **NotMan** » Tue Feb 22, 2005 12:57 pm

Nice replay on Millipede! Does the arcade version ever have those millipede froze like that.

Remember last time we had to re-record Centipede/Millipede without sound on due the analog recording desync. I didn't know if it still works on Wolf .92 with the sound on.

Oh Btw, Congrats for breaking the Millipede world record. Would love to see you crack over a million on Millipede on MAME.

Try it with no sound if the analog recording doesn't give out those Millipede's bugs!

NotMan

dbh · Post by **dbh** » Wed Feb 23, 2005 12:18 am

zlk wrote:Nice millipede replay dbh.

NotMan wrote:Nice replay on Millipede

Thanks

Does the arcade version ever have those millipede froze like that.

Nope, I've never seen the real arcade machine behave that way. I also haven't experienced anything like that in older versions of MAME so I can only guess that it is caused by one of the recent "fixes".

Oh Btw, Congrats for breaking the Millipede world record. Would love to see you crack over a million on Millipede on MAME.

Thanks again! I would also like to crack 1M, but it will be tough using a mouse. Now if I ever get around to getting a controller with a real trackball and not have to worry about the analog overflow then I'm sure I could do it.

Post by **mahlemiut** » Wed Feb 23, 2005 3:06 am

[quote="dbh"]Nope, I've never seen the real arcade machine behave that way. I also haven't experienced anything like that in older versions of MAME so I can only guess that it is caused by one of the recent "fixes".

All I've changed is making it produce the same random numbers each time - more than if it was played without sound, where I'd presume it receive some static value (always the same, I'd presume, otherwise playback wouldn't work without sound either). Does this happen in regular MAME 0.92? If so, don't look at me. And do note that Centipede, Millipede and other Atari games will not playback with sound enabled in MAME 0.92.

dbh · Post by **dbh** » Fri Feb 25, 2005 10:19 pm

Does this happen in regular MAME 0.92?

I played a short game to about 250K in regular MAME 0.92 (with sound on) and did not observe the same behavior. When I have a little more time I will try recording a longer game without sound to make sure that the strange behavior does not occur.

Weehawk · Post by **Weehawk** » Sat Feb 26, 2005 2:54 am

Also, I note that in MAME .91 you always start with the same mushroom pattern in centiped and centtime. (Not milliped though).

That's not the way it's supposed to be. This doesn't happen in MAME .83

The pokey fix is apparently doing something it shouldn't be doing to the random number generation.

Post by **mahlemiut** » Sat Feb 26, 2005 3:41 am

Weehawk wrote:Also, I note that in MAME .91 you always start with the same mushroom pattern in centiped and centtime. (Not milliped though).

That's not the way it's supposed to be. This doesn't happen in MAME .83

The pokey fix is apparently doing something it shouldn't be doing to the random number generation.

Actually, that makes perfect sense, as it only goes through a list of numbers, only going to the next one in the list when requested. This is to keep it consistent, whereas before, it went through the list with a pointer that tends to differ each time its run.

Weehawk · Post by **Weehawk** » Sat Feb 26, 2005 3:50 am

mahlemiut wrote:
Weehawk wrote:Also, I note that in MAME .91 you always start with the same mushroom pattern in centiped and centtime. (Not milliped though).

That's not the way it's supposed to be. This doesn't happen in MAME .83

The pokey fix is apparently doing something it shouldn't be doing to the random number generation.
Actually, that makes perfect sense, as it only goes through a list of numbers, only going to the next one in the list when requested. This is to keep it consistent, whereas before, it went through the list with a pointer that tends to differ each time its run.

Well, whether it makes sense or not, it's not the way the real machine works.

Post by **mahlemiut** » Sat Feb 26, 2005 6:26 am

You'd rather it not playback with sound? That can be arranged...

Weehawk · Post by **Weehawk** » Sat Feb 26, 2005 12:48 pm

mahlemiut wrote:You'd rather it not playback with sound? That can be arranged...

Having to choose between the two evils, I would say in the case of Centipede that I personally would prefer to keep the sound and lose the randomness, as I don't feel it affects gameplay that much or makes competition unfair.

On the other hand, the problems that Don observes the pokey fix to be causing in Millipede sound more serious.

What I was really hoping was that, armed with the information given, some sort of light bulb would go on over your head and you would realize what went wrong with the "fix" and fix it.

In any case, we're just concerned about the games being emulated correctly and your work along these lines is appreciated tremendously. Don't think otherwise for a second.

Perhaps educating us a little bit would shed some light on the issue. Why would one chip (pokey) be used to produce sound and random numbers? That sounds like an odd combination.