Joypad functions not working on OS X without...

Archives Forums/BlitzMax Bug Reports/Joypad functions not working on OS X without...

Oddball(Posted 2010) [#1]
...calling JoyCount() first.

Non of the Joypad functions work at all on Mac OS X without first calling JoyCount(). I have tested this on OS X 10.6.3 with an x360 controller and using BlitzMax v1.39.

Test code:
SuperStrict

Graphics 400,300

'JoyCount()
'Uncomment the above line and everything works as normal
'Tested on Mac OS X 10.6.3 with Xbox360 controller and using BlitzMax v1.39

Repeat
	
	Cls
	If JoyDown(0) Then DrawText "Joypad detected",5,5
	Flip
	
Until KeyHit(KEY_ESCAPE) Or AppTerminate()



jkrankie(Posted 2010) [#2]
Have you installed the mac xbox360 driver? OS X doesn't pick it up by default, likewise with many other console peripherals.

http://tattiebogle.net/index.php/ProjectRoot/Xbox360Controller/OsxDriver

Cheers
Charlie


Oddball(Posted 2010) [#3]
Yep, that's the driver I'm using. I'm guessing that you're not experiencing the same thing then?


jkrankie(Posted 2010) [#4]
Ah, i didn't read your problem properly. FWIW, i've always found that you need to call Joycount() first, it certainly always has been on OS X as far back a i can remember. Do you not need it on windows?

Cheers
Charlie


Oddball(Posted 2010) [#5]
I've never had to call JoyCount() on Windows in the past, but I can't test this on Windows at the moment. I'm pretty sure though that the intended behaviour is to be able to use the other joypad functions without calling JoyCount() first.


jkrankie(Posted 2010) [#6]
Well i guess that does makes sense, but presumably when it comes to a game that uses joysticks you'd want to know how many are connected to the system anyway?

Cheers
Charlie


Oddball(Posted 2010) [#7]
I don't usually iterate controllers unless I'm doing local multiplayer. I just use the controller at port 0 for solo player games, that's how I discovered this quirk.


Brucey(Posted 2010) [#8]
It's not surprising really :
int JoyCount()
{
	if (!macjoycount) InitMacJoy();
	return macjoycount;
}

The same applies for the Linux code... JoyCount() happens to initialise the drivers. You don't need this on Windows because it doesn't require initialisation.


Oddball(Posted 2010) [#9]
I spotted that too Brucey. I've altered the freejoy.macosx.c function ReadJoy to include the line:
	if (!macjoycount) InitMacJoy();
I'm not entirely sure whether that is an appropriate solution. here's the altered function in full.

freejoy.macosx.c - line 340
int ReadJoy(int port,int *buttons,float *axis)
{
	if (!macjoycount) InitMacJoy();
	if (port>=0 && port<macjoycount) readmacjoy(joylist[port],buttons,axis);
	return 0;
}
Does anyone know if this is a sensible solution?


marksibly(Posted 2010) [#10]
Hi,

Adding a JoyCount() call somewhere at the top of the .bmx file seems to work OK.

Any objections...?


Oddball(Posted 2010) [#11]
No objections really, apart from it not being mentioned anywhere so will likely trip others up too. Is there an issue with checking if the joy functions have been initialised each time ReadJoy is called? It seems to work fine for me, although I haven't tested it a lot, and would make the functions consistent across all OSs. Anyway, just curious as it's not a hardship to add JoyCount at the top of my code.


skidracer(Posted 2010) [#12]
Maybe the joy?dir commands should be removed also, they look kind of undocumented and broken.


Brucey(Posted 2010) [#13]
Anyway, just curious as it's not a hardship to add JoyCount at the top of my code.

I think he meant by adding it to the top of the "module" code (which will be run at module initialisation time).
Which precludes you from having to change your own code.


plash(Posted 2010) [#14]
I think he meant by adding it to the top of the "module" code (which will be run at module initialisation time).
Either adding the JoyCount call, or making a proper function to initialize it (and even then, still calling it).


Oddball(Posted 2010) [#15]
Brucey wrote:
I think he meant by adding it to the top of the "module" code (which will be run at module initialisation time).
Which precludes you from having to change your own code.
D'oh! Rereading it again I can see that is exactly what Mark meant. I keep forgetting that module code is executed when imported. Ignore my comments then, as that is a much more sensible solution. Thanks.