Try this:



I think that because the subviews are being removed from the array, Cocoa is getting mixed up (this doesn't happen to me - 10.2.3). Hopefully the code above should fix it.

ok - I will try that and get back to you. However the error makes sense because if you look at the docs for NSArray:

Quote:makeObjectsPerformSelector:

- (void)makeObjectsPerformSelector:(SEL)aSelector
Sends the aSelector message to each object in the array, starting with the first object and continuing through the array to the last object. The aSelector method must not take any arguments. It shouldn't have the side effect of modifying the receiving array. This method raises an NSInvalidArgumentException if aSelector is NULL.

it says "It shouldn't have the side effect of modifying the receiving array." Im not sure you can iterate through the array while deleting items the other way you suggest either.

Ill get back to you.

I have 10.2.3 on a b/w G4 400 btw. I dont know why I crash and you dont.

cheers,
Codemattic

This works:


Device Spec Builder looks good! I can definately see users creating their own specifications files for devices that dont already have them.

cheers,
Codemattic

Quote:Originally posted by codemattic
Device Spec Builder looks good! I can definately see users creating their own specifications files for devices that dont already have them.

and to prove it I emailed you an .amelioDesc file for Thrustmaster's Firestorm Dual Analog gamepad. It would look cooler with alpha added to the "User Config View" image - but I havent gotten to that yet.

Im glad to see that work on Amelio continues. I was worried that the lack of community response might dissuade you. Smart to take a couple of open source Mac OS X games and add Amelio support to show end users what the benefit is (and programmers how easy it is to add)

I have suggestions (some of which you probably have already thought of)

I have a dual analog pad. The hid config rom is configured badly and as such in OS X only the left analog stick is recognized by games. Amelio doesnt recognize the right stick either. So I edited the Amelio Framework so that if it doesnt recognize an HID-element to return AmElementKind_Axis as a default instead of AmElementKind_Unknown - and now Amelio recognizes the other stick!

Of course that is a kludge. However possible solutions are:

Let the user in the config dialog choose what type each element is from a pop-up menu. Your choice would be default, button, axis, etc... Default would be whatever the hid says it is - but if the hid device was configured wrong by the manufacturer - the user could change it.

Also - if Amelio doesnt recognize the element type - it could look at the range of the element. If the range is from 0..1 its probably a button - if the range is greater than that its probably an axis.

As it is now Amelio automatically checks the web for new drivers. Does it do this every time? I would much rather the user have control over this. In the config dialog there could be a button "download new drivers".

Holding down option to get the standard interface is a little awkward. Especially since you cant use it to option-click on a device that is already selected - which would be bad in the off-chance that someone only has one device - they could never option-click on it.

cheers,
Codemattic

Quote:Originally posted by codemattic
Im glad to see that work on Amelio continues. I was worried that the lack of community response might dissuade you. Smart to take a couple of open source Mac OS X games and add Amelio support to show end users what the benefit is (and programmers how easy it is to add)

I have suggestions (some of which you probably have already thought of)

I have a dual analog pad. The hid config rom is configured badly and as such in OS X only the left analog stick is recognized by games. Amelio doesnt recognize the right stick either. So I edited the Amelio Framework so that if it doesnt recognize an HID-element to return AmElementKind_Axis as a default instead of AmElementKind_Unknown - and now Amelio recognizes the other stick!

Of course that is a kludge. However possible solutions are:

Let the user in the config dialog choose what type each element is from a pop-up menu. Your choice would be default, button, axis, etc... Default would be whatever the hid says it is - but if the hid device was configured wrong by the manufacturer - the user could change it.

Also - if Amelio doesnt recognize the element type - it could look at the range of the element. If the range is from 0..1 its probably a button - if the range is greater than that its probably an axis.

As it is now Amelio automatically checks the web for new drivers. Does it do this every time? I would much rather the user have control over this. In the config dialog there could be a button "download new drivers".

Holding down option to get the standard interface is a little awkward. Especially since you cant use it to option-click on a device that is already selected - which would be bad in the off-chance that someone only has one device - they could never option-click on it.

cheers,
Codemattic

Thanks for the feedback. Yes - I have been a little dissuaded by the lack of response, but as it is my dissertation I am determined to finish it.

I also have a dual analog pad that I just bought, and have made the changes necessary to support it. Little things like this are impossible to find without either testing the device myself or having someone like you report them (so thanks!).

When Amelio does not find a device driver on the internet, then yes - it will keep looking every time a game starts up until a driver is found. One way around this would be for the user to create one with the Device Description Builder tool, and if they do that then they may as well send it to me to put in the central repository.

I'll fix the option-click thing too.

I'd like to ask anyone else reading this (with OS 10.2 and above) to download and test this with any USB gamepads/joysticks/steering wheels you have. There is a lot of talk about what should be done amoungst developers on the mac-games-dev mailing list, but they are all too busy to do anything about it. Until Apple has time to implement a proper API for these devices, why not help me and get a few of your favourite open-source games up and running with gamepad support.

I've just started looking at Amelio. So far it looks pretty good. I'll have to play with it some more to see just how useful it will be. I've written my own little wrapper for the HID Utilities, but yours looks quite a bit more robust.

I'll be glad to see more independent games using HID manager.

And you would have got a very positive response from me, if I had either the December dev tools or a gamepad. Don't be disheartened...

Do you think it will be difficult to add force feedback?

Quote:Originally posted by codemattic
Do you think it will be difficult to add force feedback?

I haven't looked into this much. If the FF API is anywhere near as bad as the HID API then it probably will take a lot of effort. I'll probably tackle FF after v1.0 is released.

I was adding some input stuff to the FAQ this morning, and so you've got yourself a FAQ page: http://macgamewiki.crissman.net/index.php?AmelioGIL .

I figured I'd let you explain your library, rather than trying to do so myself. Just go to the page and click edit...

Quote:Originally posted by OneSadCookie
I was adding some input stuff to the FAQ this morning, and so you've got yourself a FAQ page: http://macgamewiki.crissman.net/index.php?AmelioGIL .

I figured I'd let you explain your library, rather than trying to do so myself. Just go to the page and click edit...

It's looking for a username/password, but I can't find anywhere to register.

You don't have to register, you don't need a password. You do need SomeKindOfWikiWord to use as a name -- I'd respectfully suggest CalumRobinson