5 posts
Following along on Mac OS
Edited by jish on
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. :)
16 posts
Based in Japan. Building a fully featured music production system with a twist.
Following along on Mac OS
Edited by Kapsy on
Hi jish,

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 :)

Jake Johnson
7 posts
Following along on Mac OS
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:

 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 

5 posts
Following along on Mac OS
Thank you for the tips, it looks like I have some more research to do.

The good news is there appears to be a path forward. :)
Jake Johnson
7 posts
Following along on Mac OS
@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.
5 posts
Following along on Mac OS
"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.
Mārtiņš Možeiko
2242 posts / 1 project
Following along on Mac OS
Edited by Mārtiņš Možeiko on
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.
5 posts
Following along on Mac OS
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. :)
Mārtiņš Možeiko
2242 posts / 1 project
Following along on Mac OS
If you want to do unity build, then your main file you use for compilation must include all other c/cpp/m/mm files.

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.
5 posts
Following along on Mac OS
Thanks again for the information! I'm still learning :)

My understanding was that it is bad practice to #include a .cpp file in C++. So, I guess, I'll stick with your suggestion to compile with multiple files listed, and use the static / internal keywords properly.
Mārtiņš Možeiko
2242 posts / 1 project
Following along on Mac OS
Edited by Mārtiņš Možeiko on
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.
Oliver Marsh
177 posts / 1 project
A budding game developer and programmer
Following along on Mac OS
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?

Oliver

98 posts
Following along on Mac OS
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?