Mac OS X CoreAudio reference setup code

The versions on the release page (0.13 and 0.14) are now signed. The coming week I'm going to work on the HID code and get something nice up.
Jeff, if I add a test for the length of the IOHIDValueRef in your OSXHIDAction callback, the error with my PS4 controller goes away.

if( IOHIDValueGetLength(value) > 2 )
return;

Took some time to localize it but seems that it is a known problem of at least the PS3 controller and obviously the same goes for the PS4. Interesting that it doesn't happen if connected wirelessly.
Filip,

Thanks for tracking down the problem with the PS3/4 controller. I just borrowed a PS3 controller from a friend so I could test with it, but I hadn't tried it yet. That's a strange error condition - I appreciate the sleuthing!

Jeff
Filip,

I did try the GameController framework on 10.10. It didn't recognize any of my controllers.

The WWDC talk on the GameController framework only mentioned supporting MFi (Made For iPod/iPhone/iPad) spec'd controllers, so I'm guessing that requirement may also hold for controllers on OS X, whether you're using them directly connected or via forwarding from a connected iOS device. MFi has specific hardware requirements for controllers, so I doubt that non-MFi controllers (like the ones that everybody uses) would work.
Jeff, a semi-related question since you seem to really know cocoa well:
I'm mixing your code with my own and one thing I changed was a simple structure instead of a dictionary for the hid elements...
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#define MAX_NUM_HID_ELEMENTS 2048
struct HIDElement {
    long type;
    long page;
    long usage;
    long min;
    long max;
};
struct HIDElements {
    uint32_t       numElements;   
    uint32_t       keys[MAX_NUM_HID_ELEMENTS];
    HIDElement     elements[MAX_NUM_HID_ELEMENTS]; 
};

void HIDElementAdd(HIDElements * elements, uint32_t key, HIDElement e)
{
    Assert(elements->numElements < MAX_NUM_HID_ELEMENTS);
    uint32_t index = elements->numElements;
    elements->elements[index] = e;
    elements->keys[index] = key;
    elements->numElements++;

}
HIDElement* HIDElementGet(HIDElements * elements, uint32_t key)
{
    uint32_t numElements = elements->numElements;
    for(int i=0;i<numElements;i++){
        if(key == elements->keys[i]) {
            return &elements->elements[i]; 
        }
    }
    return 0;
}

HIDElements                 g_hidElements;

This works fine.
BUT: The weird thing is that if I move this data inside the "HandmadeView" it dies randomly on element insertion(HIDElementAdd)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#define MAX_HID_BUTTONS 32
// View
@interface HandmadeView : NSOpenGLView {
@public
    CVDisplayLinkRef            _displayLink;
    real64                      _machTimebaseConversionFactor;
    //HIDElements                 _hidElements; <- fails horribly!! ??!?!

    game_sound_output_buffer    _soundBuffer;
    game_offscreen_buffer       _renderBuffer;
    game_memory                 _gameMemory;

    // input from callback
    int                         _hidX;
    int                         _hidY;
    uint8                       _hidButtons[MAX_HID_BUTTONS];


    GLuint _vao; 
    GLuint _vbo;
    GLuint _tex;
    GLuint _program;
    BOOL                        _setupComplete;
    
}


Any clues?
Found error. Just sent a pointer to a pointer instead of a pointer in a callback...
Stare into the void, and the void stares back...
Cool. Glad you got it sorted out.


wan
Stare into the void, and the void stares back...


I've been there many times...
I've updated my little test app to add a modified version of Jeff's HID code. I'm also integrating it into my main project in a more production-worthy fashion. For those interested:

https://github.com/zenmumbler/catest/blob/master/catest/main.mm

I apply the MS-suggested deadzone to the value and normalise the values. All the code in here is mostly for quick testing, but it does work. Use the left stick up/down to change the frequency of the tone.

Jeff, I was wondering, why is there a check for the report size of an element? I'll actually look up what a report is for an element, but why is it bad if it's bigger than 64 bytes?

My goal is essentially to rebuild what Feral has built up, a database of controller mappings to common controls. I.e. knowing that, for the X360 controller, elements with usage 48 and 49 correspond to the left stick, is very useful. I've always hated the horrible ultra-generic control mapping dialogs for HID controllers. Button #3, Axis Rx, it means nothing.

@wan, what driver are you using for your wired PS4 controller?
Nice!
Btw, have Casey said if it is ok to use his code in a public repo at this time? I would like to push my repo but it uses his day 22 "handmade.cpp/h" code so Im not sure. Have you asked? Has he made a statement?
@zenmumber
no driver needed for ps4 contorller. But: USB is reported as a sony controller, wireless as nameless
@wan, re using the code: from the main page:

How will the source code be licensed?

Two years after the final version of the game is released, 100% of the source code will be released into the public domain. Prior to that, all rights are reserved, so please contact me for permission before you use it in your own projects. This is a precaution to prevent people from directly cloning the game until after it has been out for a reasonable time, since this project is an expensive endeavor and I hope to offset some of the cost through sales of the game proper.

So I would ask Casey via email if it's OK as the code is not licensed, it's © Casey Muratori
I update my stuff at: https://github.com/framkant/osx_handmade_hybrid
continuously. I asked Casey via twitter if it was ok to include the handmade.h/cpp files of day 22 so that the code more or less can mirror the win32 code. He said "yes" to this particular request.
I use some code from Jeff which I got the impression is OK. I also assume that your code, @zenmumber, is public domain?

I just implemented dynamic code loading/hotloading, but have omitted audio for the time being.

My goal is to create an open "good practices" OS X platform layer that can be used for many different projects. Or at least something that can be useful as a starting point. I have grown tired of using libs like GLFW and SDL since I lose control of the code. (like if I want to support some new feature in OS X 10.10 then I have to wait until it's available through the libs)
/Filip (I should not have registered as "wan" that is a handle I never use so it makes communication slightly weird. my twitter is @filipwanstrom)
I have learned a ton from everyones ideas. I have used a few, I hope that is OK. I especially loved filipwanstrom's creation of the app bundle code.

I'm way behind Casey's code. I have Video working, and partial audio. My goal has been to stay as close to Casey as I can. So for now I'm using no OpenGL and I'm trying to be as procedural as possible with no class definitions.

My Repo doesn't include the game code, but I will keep the README updated with which version to use. Currently it uses day 20.

https://github.com/tarouszars/handmadehero_mac

Edited by Mike Oldham on