For those interested in Mac OS X development, I created a CoreAudio based sample program that shows how to setup an output AudioQueue with buffers and using a callback to supply it with audio data (a square wave in this case.)
This mirrors the DirectSound setup and playback code of the win32 version of HH. This code is stand-alone, but I'm looking at creating a full Mac OS X shell for HH as well.
This sample uses some C++11 features such as auto type deduction and std::thread to have the app wait for a few seconds so you can hear something but otherwise is very straightforward.
Full, commented code with command line build args here:
https://gist.github.com/zenmumbler/b5bbabef1df3efe1a5df
Have fun.
This mirrors the DirectSound setup and playback code of the win32 version of HH. This code is stand-alone, but I'm looking at creating a full Mac OS X shell for HH as well.
This sample uses some C++11 features such as auto type deduction and std::thread to have the app wait for a few seconds so you can hear something but otherwise is very straightforward.
Full, commented code with command line build args here:
https://gist.github.com/zenmumbler/b5bbabef1df3efe1a5df
Have fun.
Awesome! I took the liberty to convert to pure c99 for people like myself that don't use c++ much.
(not much of an effort since your code was excellently easy to follow)
https://gist.github.com/framkant/6daed7f6145af958f0bc
(from another european mac guy)
(not much of an effort since your code was excellently easy to follow)
https://gist.github.com/framkant/6daed7f6145af958f0bc
(from another european mac guy)
Hey, thanks for converting it. I've added a comment on my version linking to yours.
I'll post my pure Mac shell code later today. Should have everything except controller code.
There's technically the ControllerKit for easy input but, like XInput,
It only works with a very limited set of controllers, so I fear that it's going to be direct HID code, which may take some time.
One more thing for the OS X version is the menu bar. GLFW creates it in code but that is, to use Casey's words, rather janky. I may just add a minimal xib file.
I'll post my pure Mac shell code later today. Should have everything except controller code.
There's technically the ControllerKit for easy input but, like XInput,
It only works with a very limited set of controllers, so I fear that it's going to be direct HID code, which may take some time.
One more thing for the OS X version is the menu bar. GLFW creates it in code but that is, to use Casey's words, rather janky. I may just add a minimal xib file.
Thanks! I've been trying to figure out how to do a os x platform layer. This helps a lot.
Somewhat related: have either of you considered showing how to open an window and receiving input as well?
Somewhat related: have either of you considered showing how to open an window and receiving input as well?
Yes, I'm working right now on a the Mac platform file. It covers the window, keyboard input, audio output, the offscreen graphics buffer and display. It will not have controller support yet. I'll post here once I get it to a working state.
Thanks for doing this conversion! I'm looking forward to seeing the native Mac layer...
- Casey
- Casey
So, what would be the preferred way to go for cocoa?
I assume two main paths: (but I'm no expert on mac dev by any stretch!)
1) embrace cocoa with all it's quirks, make a nib/xib/storyboard etc
2) Try to circumvent it all and do it programmatically
I usually either make a complete mac app using xcode (that is 1 here) or I use GLFW for cross platform. I like GLFW a lot btw and haven't found a reason not to use it yet.
I assume two main paths: (but I'm no expert on mac dev by any stretch!)
1) embrace cocoa with all it's quirks, make a nib/xib/storyboard etc
2) Try to circumvent it all and do it programmatically
I usually either make a complete mac app using xcode (that is 1 here) or I use GLFW for cross platform. I like GLFW a lot btw and haven't found a reason not to use it yet.
If you want to go at it programmatically:
Carbon is old 32bit API that was developed to aid porting in mac os 9 days. C interface but deprecated long time ago. Not recommended by Apple.
The modern way is to use Cocoa for UI (window and input) which is only available through Objective C or Swift. Pretty easy to and starting an XCode project will setup most. If you are ok with objective-c but don't want to do xcode, google "nibless cocoa" and you can find some resources for how to open window.
If you want to avoid xcode and you want to stay in C/C++ you can find some resources googling "cocoa opengl c++". You'll find resources like Objective-C Runtime Reference which is the API for interfacing with objective c without programming in objective c.
I've mostly done research so far, and don't have any working code. If you come any further, please share.
Carbon is old 32bit API that was developed to aid porting in mac os 9 days. C interface but deprecated long time ago. Not recommended by Apple.
The modern way is to use Cocoa for UI (window and input) which is only available through Objective C or Swift. Pretty easy to and starting an XCode project will setup most. If you are ok with objective-c but don't want to do xcode, google "nibless cocoa" and you can find some resources for how to open window.
If you want to avoid xcode and you want to stay in C/C++ you can find some resources googling "cocoa opengl c++". You'll find resources like Objective-C Runtime Reference which is the API for interfacing with objective c without programming in objective c.
I've mostly done research so far, and don't have any working code. If you come any further, please share.
Doing research here too. I have created hacks before that get it done but the Cocoa API seems to change and what was valid last time I did something is deprecated now. Best case would be If some undercover apple-dude came here and just gave us the minimal/optimal way to do it :)
Phillip Ridout (http://github.prideout.net) made a minimal layer a few years back called PEZ that might be worth looking into.
I would assume looking into the SDL and GLFW sources could show some acceptable hacks as well...
Phillip Ridout (http://github.prideout.net) made a minimal layer a few years back called PEZ that might be worth looking into.
I would assume looking into the SDL and GLFW sources could show some acceptable hacks as well...
I have a Mac OS X shell working that only uses the native OS libraries. I used CoreAudio, HID input, CVDisplayLink and OpenGL for the drawing shell. I also have a simpler version that uses Quartz instead of OpenGL, but the OpenGL performs a little better and that's probably the end-game anyways. But it doesn't matter much, as we're just blitting to the screen either way right now.
As far as which way to go (embrace Xcode/Cocoa vs. circumvent), I did two sample projects showing you how to do it either way. Well, sort of. Without a 64-bit Carbon API, it's hard to completely circumvent some Cocoa code. And even if you go that route, you'll probably be fighting the libraries more that you want to. For as little shell code as we need, it's not a big deal to write a little Cocoa code that creates the wormholes we need to write the actual game code.
It's more straightforward to just create a default OS X project in Xcode with a simple nib file, but, in the spirit of doing things "from scratch" [1], I also created a single osx_handmade.cpp file implementation that doesn't need Xcode or any nibs. Just clang and a [strike]Makefile[/strike] bash shell (actually, I still use Makefiles).
I'll post both of my example projects as soon as I sync them up with Casey's code from Friday.
Jeff
[1] "If you want to create an apple pie from scratch, you must first invent the universe." - Carl Sagan
As far as which way to go (embrace Xcode/Cocoa vs. circumvent), I did two sample projects showing you how to do it either way. Well, sort of. Without a 64-bit Carbon API, it's hard to completely circumvent some Cocoa code. And even if you go that route, you'll probably be fighting the libraries more that you want to. For as little shell code as we need, it's not a big deal to write a little Cocoa code that creates the wormholes we need to write the actual game code.
It's more straightforward to just create a default OS X project in Xcode with a simple nib file, but, in the spirit of doing things "from scratch" [1], I also created a single osx_handmade.cpp file implementation that doesn't need Xcode or any nibs. Just clang and a [strike]Makefile[/strike] bash shell (actually, I still use Makefiles).
I'll post both of my example projects as soon as I sync them up with Casey's code from Friday.
Jeff
[1] "If you want to create an apple pie from scratch, you must first invent the universe." - Carl Sagan
Ah, you sound like you know quite a bit more about Cocoa APIs than I do. Looking forward to your code but will still develop my own version too as I'm using the HH project to learn after all.
I'm still working in my code inside the current HH sources, but I did post an Obj-C example program that can almost bootstrap itself (except for the menubar, is there a way to just embed the xib xml data in a .h file and call some function to load the objects directly?)
Anyway, here is the program so far. I'll update this one too. This one is stand-alone so it's easier to see what's going on without having to read over all the HH stuff:
https://gist.github.com/zenmumbler/7cac9ba10fc70ff04480
I'm still working in my code inside the current HH sources, but I did post an Obj-C example program that can almost bootstrap itself (except for the menubar, is there a way to just embed the xib xml data in a .h file and call some function to load the objects directly?)
Anyway, here is the program so far. I'll update this one too. This one is stand-alone so it's easier to see what's going on without having to read over all the HH stuff:
https://gist.github.com/zenmumbler/7cac9ba10fc70ff04480
Edited by zenmumbler
on
Could you please put this in a repository? I have a controller that I can test it with, and I've been meaning to get to grips with IOKit HID.
I created a quick repo with the Xcode project etc at:
https://github.com/zenmumbler/handmade-alt-proto
This is the non-HH-style code but the minimal Cocoa program.
Let me know if it works for you.
https://github.com/zenmumbler/handmade-alt-proto
This is the non-HH-style code but the minimal Cocoa program.
Let me know if it works for you.
Thanks! I'll see what I can do.
@zenmumbler,
You can load a nib file directly, but for simple menus, you might as well just create them yourself programmatically.
Here's a little menu code excerpt that should get you going:
https://gist.github.com/itfrombit/2075934dabf9a378b628
I'll post my whole repo in Github later this evening.
You can load a nib file directly, but for simple menus, you might as well just create them yourself programmatically.
Here's a little menu code excerpt that should get you going:
https://gist.github.com/itfrombit/2075934dabf9a378b628
I'll post my whole repo in Github later this evening.