Though again, driving controllers aren't easy to come by.
If they're easy to read they'd be a nice addition, however.
They're pretty easy and cheap to find on Ebay and for-sale sites, plus a
lot of potential customers have probably already purchased them for Thrust
or are going to purchase them for the upcoming Indy 500+ hack. And it
would support the joystick anyway.
They are quite easy to read.
And for the Joystick, I think it'd be nice to make the button speed up the
paddle.
Again, at the risk of sounding like a broken record, what's the
estimate for how long it takes, in machine cycles or scanlines?
I can't remember, it's something like 12-14 cycles to read the paddles with
Thomas's most recent cycle consistent code?
The paddle cap charges over a long time with the paddle at highest
resistance, I'd estimate it takes at least a full frame. But it varies
from paddle to paddle. C64 paddles and Gemini paddles have more physical
movement per pixel. No games I've played use the full range of the
paddle. Standard for high-res paddle games is to read the paddles over
most of the visible kernel on every scanline.
Because moving it to, say, the Overscan (assuming you're not
needing that time for game logic) ISN'T a matter of fine resolution,
since you can spend all your dang time polling for the charge;
You can read it more frequently, but that'll make the paddle really
sensitive. Using overscan, you're only looking at roughly 1/5th of
standard paddle movement range. Jitter problems are common on games that
read it every line, so I'm not sure what's going to happen if you try to
read it 4-5 times per line.
I guess this weekend I can try whipping up some sample code.
I think that's the only way to determine if it will really work.
-paul
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
