I know @ifrombit has a good handle on an objc port of the handmade code.
Was wondering if there was any interest in a swift version of the platform layer on OSX?

I didn't see that anyone had made one yet and I figure if that's the way cocoa/ios is going that way it might be good to cover that base as well...

[strike]I'll throw it together tonight unless someone's already got one built.[/strike]

In it's infancy but this is where it'll reside https://github.com/joekarl/swift_handmade_hero

I'd actually love to see this

Well I should probably get started on this then lol.

Been making a little progress on this but running into a little thing.

Perhaps @ifrombit or @cmuratori can help.

I can't for the life of me figure out where the following types are defined and it's keeping things from compiling:
debug_platform_free_file_memory
debug_platform_read_entire_file
debug_platform_write_entire_file
debug_read_file_result

I'm probably missing something important here but has me stumped...

Make sure to define HANDMADE_INTERNAL=1

Sweet, thanks @ChrisG0x20, I figured I was doing something dumb....
Just needed to set that in the preprocessor stuff in xcode and good to go.

Thanks!!

Just giving an update.
The code is substantially more complete .
As of right now, supports the graphics rendering and dynamic library loading.
Will be updating for input and audio next.

Code is here https://github.com/joekarl/swift_handmade_hero and supports day 29 of the hh source.

As for how the process has been so far, Swift is an interesting language with decent support for diving into raw memory access. The memory allocation/manipulation hasn't been terrible. The only thing that's been a bit of a problem has been the fact that once cannot invoke a function pointer directly in Swift. So there's an objc shim that is used to invoke the platform independent layer and Swift calls that.

Overall fairly smooth considering I haven't programmed in swift before this o_0

Thanks for this! So I am thinking that since this is written in OpenGL, that it is hardware accelerated right?

On OS X, can you not write a software renderer unless you go through X11? (I remember crawling through some of the SDL source and it seemed that even in non-hardware acceleration mode it it was using OpenGL).

So the renderer is still in the CPU, the opengl bits are just to get the graphics buffer to the screen. The glTexSubImage2d call is just updating the texture memory with what we've rendered in our graphics buffer. I guess to answer your question, the drawing is not hardware accelerated, but the blitting to the screen is.

Another of way of doing this (without opengl) would be to copy the memory into an NSImage and then drawing that to the screen in the drawRect function. Or you could create a layer backed view and update the layer bits.

Here's an example of someone's platform layer that's using cgimage to do the drawing https://github.com/zenmumbler/han...aster/HandmadeHero/main.m#L48-L87

Really there's a bunch of ways to get the bits to the screen, what I'm doing with opengl just avoids most of the overhead of cocoa.

I'm hoping to implement the input code today and then audio tomorrow, so stay tuned :D

I've updated with keyboard input and support for day 30 code.
Still need controller support but it's a start o_0

Fixed a bug where low power graphics chip in the macbook air would cause initialization of OpenGL to fail. Hopefully that's helpful to people...

Another update:
Day 38 support with bmp loading included (thanks to itfrombit for finding a solution to the size_t issues with handmade_platform.h).