Added support for directional controls. Joystick is still emulated with arrows plus two extra keys, but it has allowed me to test the directional code. All that remains now is to change the emulated joystick routine to read the real Coco3 joystick.
After having been sent some sample code with explanation from James, and reading up on a few blogs, most notably John Linville's The Making of Fahrfall: Reading The Joystick, it's clear that I only need to sample each of the two axes twice in order to obtain a digital reading - something best done internally in my Knight Lore code.
I haven't really looked into joystick support for the Coco3 in MESS, so I have no idea if I can even test it under emulation, but I do have a pair of the standard single-button Tandy joysticks. In the interests of productivity, the best option is probably Drivewire or, failing that, CocoSDC (which I've yet to use). Either of those options is certainly better than erasing and programming EEPROMs...
UPDATE: Was hoping I'd get time to implement reading the joysticks tonight, but after reading a great article on coco3.com that details everything I need to know, it's become apparent that it's a little more involved than I first thought. I'm sure at least some of the PIA configuration need only be done once for Knight Lore, since I have total control over the machine, but it will take some analysis to determine exactly which bits. For another night...
FORGOT TO MENTION: I have it reading the joystick buttons now at least.
It's been years since I timed it, but the ROM joystick routine is nowhere near as slow as the routine to read (say) an old PC joystick and you only need to call it once per game loop, not per frame.
ReplyDeleteYeah PC joysticks were horrid!
ReplyDeleteIn Knight Lore, one game loop is one frame. The need to switch in ROM to read the joysticks is an issue in itself, since I need to be mindful where my joystick code is executing from. It's really an overhead I don't want to deal with. And since the game frame rate is affected by the input routine, I need to save as many cycles as possible, and optimise the number of samples I do.
Under different circumstances it wouldn't be an issue, and I'd gladly off-load the work to the ROM to save myself some coding, but I'm pushing the Coco to its limits as it is.