Hello,
I've been a professional developer for about 10 years now so I am not new to programming, but I am very new to game development.
Also, I only have a laptop running Mac OS.
My question is:
Is there a good way to follow along with this series on Mac OS?
* I found this repo on GitHub which aims to use all of the same C++ code, https://github.com/itfrombit/osx_handmade is that a good idea?
* Should I be trying to find Xcode tutorials and learning that first?
* Is there some other solution that I do not know about, that I should be pursuing instead?
Or is developing on Mac OS just a terrible idea? Here be dragons, turn around now?
Any opinions, feedback, or direction would be appreciated.
Well, onto the next video. :)
I've been a professional developer for about 10 years now so I am not new to programming, but I am very new to game development.
Also, I only have a laptop running Mac OS.
My question is:
Is there a good way to follow along with this series on Mac OS?
* I found this repo on GitHub which aims to use all of the same C++ code, https://github.com/itfrombit/osx_handmade is that a good idea?
* Should I be trying to find Xcode tutorials and learning that first?
* Is there some other solution that I do not know about, that I should be pursuing instead?
Or is developing on Mac OS just a terrible idea? Here be dragons, turn around now?
Any opinions, feedback, or direction would be appreciated.
Well, onto the next video. :)
Edited by jish
on
Hi jish,
I'm up to episode 62 using OSX, so I'll give you my 2c from where I am:
Once you get to episode 26, it's all engine and the platform layer largely becomes irrelevant (I'm pretty sure it's visited later on however).
itfrombit/osx_handmade is excellent - I also found it useful for pointing me in the right direction. I also tried to use the native C BSD libs wherever I could, over the Objective-C ones --- it's not going to hurt to use Objective-C, but I was no longer interested in learning it as a language so I tried to avoid it where possible. You can find my repo at https://github.com/kapsy/handmade_osx --- it's not as polished as itfrombit/osx_handmade, but it does some things differently which might help to give another perspective.
Even with those, I would thoroughly recommend still going through the series and trying to emulate (in OSX), what is happening on the stream from the start rather than copying and pasting. It will take longer than if you were following on Windows, but you'll almost certainly learn much more than following on Windows and taking in everything verbatim.
I only use Xcode as a debugger, which isn't great (but totally adequate), and Vim for actual code editing. Even if it is your main editor, Xcode can probably be picked up just through real world usage.
I would say that if you never again intend to create platform independent software that will run on OSX then it's probably not worth your time, as anything learned will just go to waste. However if you do, it's very much worth it. Initially I tried to develop HMH on Windows, first using a Virtual Machine which didn't go too well, Boot Camp (didn't work easily with 7), and then even considered buying a Windows box. In the end I decided to continue on OSX as I intended to create future projects for the platform, and it ended worth it for the knowledge gained.
Apart from the extra time spent, there really are no downsides :)
I'm up to episode 62 using OSX, so I'll give you my 2c from where I am:
My question is:
Is there a good way to follow along with this series on Mac OS?
Once you get to episode 26, it's all engine and the platform layer largely becomes irrelevant (I'm pretty sure it's visited later on however).
* I found this repo on GitHub which aims to use all of the same C++ code, https://github.com/itfrombit/osx_handmade is that a good idea?
itfrombit/osx_handmade is excellent - I also found it useful for pointing me in the right direction. I also tried to use the native C BSD libs wherever I could, over the Objective-C ones --- it's not going to hurt to use Objective-C, but I was no longer interested in learning it as a language so I tried to avoid it where possible. You can find my repo at https://github.com/kapsy/handmade_osx --- it's not as polished as itfrombit/osx_handmade, but it does some things differently which might help to give another perspective.
Even with those, I would thoroughly recommend still going through the series and trying to emulate (in OSX), what is happening on the stream from the start rather than copying and pasting. It will take longer than if you were following on Windows, but you'll almost certainly learn much more than following on Windows and taking in everything verbatim.
* Should I be trying to find Xcode tutorials and learning that first?
I only use Xcode as a debugger, which isn't great (but totally adequate), and Vim for actual code editing. Even if it is your main editor, Xcode can probably be picked up just through real world usage.
* Is there some other solution that I do not know about, that I should be pursuing instead?
Or is developing on Mac OS just a terrible idea? Here be dragons, turn around now?
I would say that if you never again intend to create platform independent software that will run on OSX then it's probably not worth your time, as anything learned will just go to waste. However if you do, it's very much worth it. Initially I tried to develop HMH on Windows, first using a Virtual Machine which didn't go too well, Boot Camp (didn't work easily with 7), and then even considered buying a Windows box. In the end I decided to continue on OSX as I intended to create future projects for the platform, and it ended worth it for the knowledge gained.
Apart from the extra time spent, there really are no downsides :)
Edited by Kapsy
on
It isn't too hard to follow along using OS X. I'm using SDL. I haven't looked at anyone else's code; so I'm not sure how they are doing it, but you can check out my build script here: https://github.com/ofalltrades/lo...el_asteroids/blob/master/build.sh
It isn't HMH, but the build process is the same. Dead simple. If you choose to do it this way, just put your SDL library in the same place as mine, and it will just work. All you really need from that script is:
It isn't HMH, but the build process is the same. Dead simple. If you choose to do it this way, just put your SDL library in the same place as mine, and it will just work. All you really need from that script is:
1 2 3 4 5 | #!/bin/bash
clang++ src/main.cpp -o build/Release/low-level_asteroids \
-I/Library/Frameworks/SDL2.framework/Headers \
-F/Library/Frameworks -framework SDL2
|
@jish: If you continue to have trouble, PM me and I will help you get setup piece by piece. Getting started is the hardest part and not always (never?) easy.
"Getting started is the hardest part and not always (never?) easy."
Yes, getting started does seem to be proving difficult. With the two GitHub repos in Objective C, I started down that path. I actually got a window opening and closing, so that was a nice little victory!
However, as soon as I attempt to add code in different files, everything falls apart. See my code here:
https://gist.github.com/jish/24734d381fb9a27525b9f91bdfa21c77
Am I making a simple mistake somewhere? It's been a while since I've done some of this stuff.
I just finished episode 11 and Casey recommends using SDL. I also see that you guys are recommending SDL, so I may have to do some research on that.
There are two mistakes.
First is that you are not including handmade.cpp in gcc commandline. Compiler cannot find "GameUpdateAndRender" function, because you are not compiling it.
Second one is about "internal". It is defined as "static" keyword. Simply speaking "static" keyword marks function as non-accessible from other translation units (.cpp/.m files). That is what compiler is warning you about - that you will most likely get linker error about this. If you'll fix first mistake, you'll still get error because of this "internal". Remove it from functions you want to directly call across translation units. Instead put it next to all "OSX..." functions you are creating.
First is that you are not including handmade.cpp in gcc commandline. Compiler cannot find "GameUpdateAndRender" function, because you are not compiling it.
Second one is about "internal". It is defined as "static" keyword. Simply speaking "static" keyword marks function as non-accessible from other translation units (.cpp/.m files). That is what compiler is warning you about - that you will most likely get linker error about this. If you'll fix first mistake, you'll still get error because of this "internal". Remove it from functions you want to directly call across translation units. Instead put it next to all "OSX..." functions you are creating.
Edited by Mārtiņš Možeiko
on
First is that you are not including handmade.cpp in gcc commandline.
Yea, I was attempting to compile without naming all of the files. I believe Casey referred to this as the "unity build". Only specifying one file to compile in a simple build script. Maybe I misunderstood this?
Simply speaking "static" keyword marks function as non-accessible from other translation units
Again, I must have misunderstood this.
In episode 11 it looks like Casey is marking the GameUpdateAndRender function with the internal keyword. :(
Anyway, thank you for the suggestions! I tried both of them and they resolved my issue. The code compiles when adding another command line argument for the file and removing the internal keyword. :)
If you want to do unity build, then your main file you use for compilation must include all other c/cpp/m/mm files.
So in unity build you need to put #include "handmade.cpp" inside your osx_handmade.mm file.
For Casey "internal" thing works because of unity build. If you want to do unity thing then you can leave "internal" there. And later he changes how GameUpdateAndRender gets called (for hot game code dll reloading) - he doesn't call it directly, but indirectly through function pointer.
So in unity build you need to put #include "handmade.cpp" inside your osx_handmade.mm file.
For Casey "internal" thing works because of unity build. If you want to do unity thing then you can leave "internal" there. And later he changes how GameUpdateAndRender gets called (for hot game code dll reloading) - he doesn't call it directly, but indirectly through function pointer.
It's a "bad" practice only if you are doing "normal" build - when you are compiling bunch of .c/cpp files individually.
If you do unity build - that's exactly how unity build works, by including all your .c/cpp/m/mm files in one "master" file. #include simply takes contents of other files and puts in your "master" file - and at the end you are compiling only one file.
If you do unity build - that's exactly how unity build works, by including all your .c/cpp/m/mm files in one "master" file. #include simply takes contents of other files and puts in your "master" file - and at the end you are compiling only one file.
Edited by Mārtiņš Možeiko
on
Hi,
I was investigating further into the mac build and was wondering how you avoid having to not to do C style structs i.e. using typedef?
Thanks for your help,
Oliver
I was investigating further into the mac build and was wondering how you avoid having to not to do C style structs i.e. using typedef?
Thanks for your help,
Oliver
OliverMarsh
Hi,
I was investigating further into the mac build and was wondering how you avoid having to not to do C style structs i.e. using typedef?
Thanks for your help,
Oliver
If you mean in the context of Objective-C, just change the extension of your Objective-C files to .mm instead of .m. This will compile them as Objective-C++, allowing you to integrate C++ directly into your Obj-C files just as with C.
thanks flyingsand, it worked, another cause was that i was passing the -x objective-c compiler flag.