Centipede Speed Up request

[Zeosstud]

Hello,
Anyone interested in trying to update Centipede so the trackball sensitivity could be higher, it goes to 200% currently but several of use seem to agree even more would be helpful..

Thoughts?

Zeosstud

[jimmystones]

Hello,
Anyone interested in trying to update Centipede so the trackball sensitivity could be higher, it goes to 200% currently but several of use seem to agree even more would be helpful..

Thoughts?

Zeosstud

The core is getting a bit flaky and might not enjoy adding another option to the mix, but I'll give it go!

[Lex]

I think 300% would be close to the original Centipede arcade game otherwise it is working very well. Would be great if this would be implemented.

regards,
Lex

[jimmystones]

I've just pushed a new version with a 400% speed option, should be available for update within an hour or so...

(the reason it's 400% is mainly because x2 or /2 is much easier for the FPGA and causes less stress on the core!)

[Hetzen]

Thanks jimmystones. I've just played a few games with the GRS trackball the sensitivity is certainly increased and plays better, but I'm now wandering what 800% would do. It took 3 rolls to get across the screen on 200% it now takes 2.5 rolls on 400%. Moving the ball slowly, you can certainly feel the ball travel a bit to move one pixel on screen, at 400% there is less play, but it's still there.

Is it even possible to go to 800%?

I'm happy to test a non release if that would help.

[Hetzen]

I think 300% would be close to the original Centipede arcade game otherwise it is working very well.

I'd be interested in what you think with this update. I can't honestly remember if there was much play at low speed rolling.

[Lex]

Hello Jimmy!

Thanks so much for giving this a go - you are awesome. I am redesigning my control panel from my self-build arcade machine at the moment and making it perfect. I can´t wait to test this when I am finished. No matter what you do there are two main factors connected - DETAIL and detail takes time (which we believe we don´t have). Nice greetings

[LamerDeluxe]

The trackball doesn't look very fast in this video: https://youtu.be/ZrSfoG0wY8c

[Hetzen]

The trackball doesn't look very fast in this video: https://youtu.be/ZrSfoG0wY8c

Good shout finding that. I think at around 3:53 you can see the distance the bug moves with one gesture, it seems further than 400% currently reaches.

[LamerDeluxe]

The trackball doesn't look very fast in this video: https://youtu.be/ZrSfoG0wY8c

Good shout finding that. I think at around 3:53 you can see the distance the bug moves with one gesture, it seems further than 400% currently reaches.

I think you mean from 2:53, there you can indeed see the screen in combination with his hand moving. 1:02 and 4:38 are also good, but a bit further away.

[Hetzen]

The trackball doesn't look very fast in this video: https://youtu.be/ZrSfoG0wY8c

Good shout finding that. I think at around 3:53 you can see the distance the bug moves with one gesture, it seems further than 400% currently reaches.

I think you mean from 2:53, there you can indeed see the screen in combination with his hand moving. 1:02 and 4:38 are also good, but a bit further away.

I pointed out 3:53 to show how it moves with a gesture, ie it's maximum speed with one hand pass. The travel is not quite like the video shows at 3:57. It seems the core at the moment tops out at a clamped speed.

I've attached a video with 400% sensitivity. The front end shows minimum movement on the track ball. It seems it's counting @4 slot pulses from the direction flywheel for one pixel. Then it shows full movement and the top speed the bug can travel atm.

It's all very playable as is and a definite improvement on 200%, so was just wondering if 800% was possible. I could be wrong. Interested in what others think.

[LamerDeluxe]

Good shout finding that. I think at around 3:53 you can see the distance the bug moves with one gesture, it seems further than 400% currently reaches.

I think you mean from 2:53, there you can indeed see the screen in combination with his hand moving. 1:02 and 4:38 are also good, but a bit further away.

I pointed out 3:53 to show how it moves with a gesture, ie it's maximum speed with one hand pass. The travel is not quite like the video shows at 3:57. It seems the core at the moment tops out at a clamped speed.

I've attached a video with 400% sensitivity. The front end shows minimum movement on the track ball. It seems it's counting @4 slot pulses from the direction flywheel for one pixel. Then it shows full movement and the top speed the bug can travel atm.

It's all very playable as is and a definite improvement on 200%, so was just wondering if 800% was possible. I could be wrong. Interested in what others think.

Ah, I see. In your video it looks like it moves a really short distance with slow trackball movement. Seems like acceleration is being used. I wonder how well that matches the real machine.

[Hetzen]

Seems like acceleration is being used. I wonder how well that matches the real machine.

I think you might be right. I wonder if the original was completely linear in its reading of the pulses, where as mouse controllers have acceleration curves. That might explain the 3 spins to 2.5 spins needed to cross the screen with a 2x increase in sensitivity.

I've just read through this Github thread https://github.com/MiSTer-devel/Arcade- ... /issues/23 and now fully appreciate the work that has gone into getting this to work at all. So thanks Jimmystones for getting it to this state.

[Hetzen]

I've just compared this to the Atari 50th version running on the PC, man that version is laggy with a mouse or trackball compared to this.

[LamerDeluxe]

Seems like acceleration is being used. I wonder how well that matches the real machine.

I think you might be right. I wonder if the original was completely linear in its reading of the pulses, where as mouse controllers have acceleration curves. That might explain the 3 spins to 2.5 spins needed to cross the screen with a 2x increase in sensitivity.

I've just read through this Github thread https://github.com/MiSTer-devel/Arcade- ... /issues/23 and now fully appreciate the work that has gone into getting this to work at all. So thanks Jimmystones for getting it to this state.

Exactly, I was wondering the same thing.

Just read that thread and wow, what a nightmare, wasn't expecting that.

[jimmystones]

So based on my understanding of the way the original hardware works, it definitely is trying to be linear - but the game only reads the encoder values so many times a second, and that read is in no way synchronised with the rotation, so the results can be a bit weird on occasion.

There is definitely a maximum theoretical speed you can move, as the game could only read up to a rotation speed per frame before it's counters roll over (and if that happens you can get glitchy negative acceleration, which is very unpleasant!)

The difficulty is compounded a bit on MiSTer because we have a mouse/trackball reporting back from the Linux side at one frequency (which is not 100% consistent to be honest!), feeding an emulated trackball encoder being read by the game running on the CPU at a completely different frequency.
As such the trackball emulation I have made is definitely a bit hacky and doesn't 100% replicate the original hardware, and may well inherit some acceleration from the USB device or Linux I suppose (though I don't think I intentionally added any). Regardless I think it's a lot better than what we had before

[Zeosstud]

JimmyStones,
Thank You, that update truly made a difference. Do not know how you guys do it, but I certainly appreciate it.

Zeosstud

[LamerDeluxe]

and may well inherit some acceleration from the USB device or Linux I suppose (though I don't think I intentionally added any).

I was wondering if there could be mouse-acceleration options in Linux (like Windows has), that could interfere with the handling of mouse-like devices on MiSTer. So that seems to be a possibility then.

And could past polling make the roll-over problem worse?

[jimmystones]

Assuming you mean fast polling, then no I don't think that changes the frequency at which the MiSTer framework sends mouse updates to the core, it just increases the frequency with which the number that the framework sends is updated. So it shouldn't affect the actual speed, just more accurately reflect changes in speed. I think....

I hope that makes sense to someone!

[thorr]

I don't think LamerDeluxe meant fast polling (edit: I am wrong). I think in the first statement, he is saying that in Windows for example, you can sometimes adjust sliders for mouse acceleration, and perhaps there is a Linux equivalent and it has some default value. I don't know what the second statement is saying. Edit, now I get it. Past polling was a type-o for Fast polling. I would think that fast polling should not affect anything but input lag.

As a side note, is there a way to hook up a trackball with SNAC? I have a Happ trackball that could be hooked up this way and might theoretically work exactly correct, except I have high resolution encoder wheels (from groovygamegear). I haven't tried the new version of the core yet, so it might be just fine via USB. I am still building my arcade cabinet.

[netbeui]

I compared my Centipede arcade with the MiSTer Centipede core and to me it seems like the core sensitivity setting at 100% is closest to my machine. If it helps I can record a video tomorrow, just let me know

[thorr]

I compared my Centipede arcade with the MiSTer Centipede core and to me it seems like the core sensitivity setting at 100% is closest to my machine. If it helps I can record a video tomorrow, just let me know

What kind of trackball are you using with the MiSTer and how is it connected?

[jimmystones]

No SNAC as yet I'm afraid, no - I would like to give it a try and add it for Centipede and Missile Command some point but I'll need to get my hands on / access to various bits of kit as I'm not really set up for the electronics side.. Wouldn't even know how to wire it up!

[Hetzen]

Apparently the bug should move 2.5 mushrooms with the exposed arc of the ball. 200% does this with the GRS trackball. BUT, that depends on how fast you roll the ball. For example, you can move right quickly, then move back slowly (which brings you back short of where you started). So there is some acceleration going on, probably within the mouse driver.

If the exposed portion of the ball is 1/3rd of its circumference and the ball is 2.25 inches (5.625cm) in diameter, the balls surface will have moved roughly 5.89cm.

If the diameter of the spindle the ball rolls against is 0.8cm in og hardware, its circumference will be 2.513cm, meaning the spindle will have revolved 2.34 times after moving the ball 1/3rd of it's full rotation.

There are 24 teeth in Centepede's og hardware, meaning 56.26 teeth have produced pulses to move 2.5 mushrooms. And assuming the mushrooms are 8x8 pixels, the distance travelled on screen is 20 pixels.

So it looks like the arcade machine is interpreting pulses as linear with no acceleration, that means 1 pixel of movement requires @3 pulses from the og hardware trackball.

What then gets complicated is then reverse engineering this to off the shelf trackballs, ball to spindle to tooth ratio to try and get real parity.

Original track ball teardown can be seen here https://www.youtube.com/watch?v=St5C9dzdJZE

[netbeui]

I compared my Centipede arcade with the MiSTer Centipede core and to me it seems like the core sensitivity setting at 100% is closest to my machine. If it helps I can record a video tomorrow, just let me know

What kind of trackball are you using with the MiSTer and how is it connected?

I'm using a Kensington trackball mouse, this one: https://www.kensington.com/p/products/e ... trackball/. It's a standard USB mouse so it's connected to a regular USB port on my MiSTer.

The ball diameter on the Kensignton is very close to the ball diameter on my Centipede trackball. It feels lighter than the Centipede trackball so the weight is off but the diameter feels very close.

[thorr]

No SNAC as yet I'm afraid, no - I would like to give it a try and add it for Centipede and Missile Command some point but I'll need to get my hands on / access to various bits of kit as I'm not really set up for the electronics side.. Wouldn't even know how to wire it up!

Having a SNAC connection would be awesome, and for Crystal Castles too . This might help: http://forum.arcadecontrols.com/index.php?topic=68289.0
and here is a trackball: https://groovygamegear.com/webstore/ind ... cts_id=363

I don't expect anything at all, but thought I would share in case it helps. Thanks!

[Zeosstud]

@thorr Curious if you have gotten to play any yet with the USB connection and your high resolution encoder wheels. Would be interested in your feedback with that setup, Centipede and Missile Command would be the games I cared about most, but any feed back you might have with any of the games or cores would be interesting. I have Happ 3", U-Trak and Happ 2.25" trackballs I will be putting thru their paces soon, they all just have factor parts, not the enhanced stuff from GGG.

Zeosstud

[thorr]

@thorr Curious if you have gotten to play any yet with the USB connection and your high resolution encoder wheels. Would be interested in your feedback with that setup, Centipede and Missile Command would be the games I cared about most, but any feed back you might have with any of the games or cores would be interesting. I have Happ 3", U-Trak and Happ 2.25" trackballs I will be putting thru their paces soon, they all just have factor parts, not the enhanced stuff from GGG.

Zeosstud

I just tried it. For me, 200% seems the best for both of those games. 400% is too fast in Centipede. 300% would be maybe better than 200%, but I prefer 200% instead of 400%, and it is good enough. In Missile Command, 200% seems about right. I tried Crystal Castles, but I can't even launch it. It is missing a file for some reason.

[Hetzen]

Apparently there's a way to switch off acceleration within Linux. Thing is I'm not finding a directory called xorg.conf.d.

To completely disable mouse acceleration, create a file called "50-mouse-acceleration.conf" in xorg.conf.d. The path to xorg.conf.d can vary depending on the Linux distribution you use. For instance, in Ubuntu, Linux Mint, and derivatives, it's /usr/share/X11/xorg.conf.d/. On Arch Linux, it's /etc/X11/xorg.conf.d/.

To open an empty 50-mouse-acceleration.conf file in /usr/share/X11/xorg.conf.d/ with Nano (command line text editor; should be installed by default in most Linux distributions), use the following command:
sudo nano /usr/share/X11/xorg.conf.d/50-mouse-acceleration.conf
And in this file, paste the following:
Section "InputClass"
Identifier "My Mouse"
MatchIsPointer "yes"
Option "AccelerationProfile" "-1"
Option "AccelerationScheme" "none"
Option "AccelSpeed" "-1"
EndSection
Then save the file (to save the file in Nano, use Ctrl + o, then press Enter; to exit, use Ctrl + x). Note that the section just needs an identifier, but the actual name doesn't matter, so you don't have to replace "My Mouse" with anything.

Once you're done, restart the session (logout/login). That's it!

Using this, the Touchpad acceleration is left unchanged.

http://www.webupd8.org/2016/08/how-to-c ... mouse.html

[Flandango]

Mouse acceleration is usually handled by the window/desktop manager (Xorg, Gnome, etc...) , which Mister doesn't use.
I could be wrong since it's been ages that I dealt with it, but Linux, at the driver level doesn't do mouse acceleration.
DPI/sensitivity of course is a whole other thing.