adge
Hmmmm and yours is working? This is how I do it:
Yeah, mine is working well. It has been for the past year or so that I've been using it. Admittedly it's pretty light on features, but I will add those as I need them (i.e. window resizing, etc.).
adge
Yeah however it's not working. I'm currently going through Casey's OpenGL section. I hope it helps to learn and understand it a little bit and hopefully implement an own more simplified version of this shenanigans. But if you see what I'm doing wrong then please tell me.
I'm not an OpenGL guy at all, so I'm afraid I can't see by looking at your code what is wrong. What I would do in this case is just start very simple though -- just get something drawing on the screen. Take away all the viewport stuff, matrices, etc. Maybe look at some OpenGL tutorials or sample code to just get something on the screen, then you
can build up from there, and that will make it simpler to find out what your problem is. Unless someone else can spot it in the forums. :)
adge
I just don't want the drawing where apple thinks I should do it. So I don't like using views they so much force a design pattern on you. Is there a C Mac OS X API? I heard there was something like Carbon but its deprecated now and its 32 bit. I can't find any documentations. Does it still work?
Fair enough, but fighting it doesn't do any good either (unless it's for a good reason). It's the way Cocoa is structured, for better or worse. And you can certainly minimize your dependency on the view by having it only handle the final bitmap blit, while the rest of your logic is outside of it.
There are a lot of APIs for OS X that are C-based. Not so much for things like NSWindow, or NSView, but CoreGraphics is all C-based, as is Audio Units and Core Foundation. So in other words, most of the high level UI stuff is Objective-C, while many underlying frameworks are C. Carbon is still supported in old apps for legacy purposes, but there are no Carbon APIs in the new OS X SDKs. The only way you could use Carbon (I believe) would be to get your hands on the 10.6 SDK or earlier (I can't remember exactly when they removed the Carbon APIs from the OS X SDKs, but I think 10.6 was the last one). And the only way to get that is to download an old version of Xcode that has that SDK in it. But I would stay away from Carbon. There's no reason at all to use it.
adge
One more thing: How fast will the Handmade Hero Engine/Game be when it's done? Like compared to stuff like Game Maker, Unity usw. Regarding 2D.
As fast as it needs to be for this game. It's hard to compare against commercial game engines that are meant to be more general purpose, but we've seen that we will hit 60 fps using hardware rendering for this game, so it will be fast enough to support that.
I am trying to write a simple game loop for MacOS. The event polling solution I found on libraries like GLFW, SDL, and MacOS game ports for DOOM, Quake, Handmade Hero is to use the nextEventMatchingMask API. I am interested in the latency of event polling:
The experiment I run (source code) consist of opening a Cocoa MacOS window and "randomly" generating mouse and keyboard events. The typical latency numbers I get for the first 1000 events in such experiment looks like this:
Note that the top 25% latencies are more that half a millisecond. Even when there is no event available (zeros on the chart) we can get a latency of more than a millisecond (see zero floating around near the 600th event). To make things worse, this is the typical case I observe when my Macbook has not much going on: just a Terminal and the test program. It gets worse when more applications are running.
I wonder if there is a more efficient way to get the next (mouse/keyboard) event if available in a MacOS application. Is there a trick I am missing that makes nextEventMatchingMask calls more efficient?
I might be off on my expectation, but I was thinking in much smaller latencies, something similar to the PeekMessage API from Windows that Casey profiled here.
I also posted this question on stackoverflow, but thought it would also be interesting to have it in this thread.
1 2 3 4 5 6 7 | t0 = mach_absolute_time(); NSEvent *event = [NSApp nextEventMatchingMask:NSEventMaskAny untilDate:nil inMode:NSDefaultRunLoopMode dequeue:YES]; t1 = mach_absolute_time(); latency=t1-t0 |
The experiment I run (source code) consist of opening a Cocoa MacOS window and "randomly" generating mouse and keyboard events. The typical latency numbers I get for the first 1000 events in such experiment looks like this:
1 2 3 4 5 6 7 | # latency percentiles in milliseconds : 0% 5% 10% 15% 20% 25% 30% 35% : 0.033830 0.047655 0.060302 0.071263 0.073450 0.075871 0.079204 0.083330 : 40% 45% 50% 55% 60% 65% 70% 75% : 0.093038 0.107813 0.134466 0.143095 0.180434 0.334789 0.448111 0.500118 : 80% 85% 90% 95% 100% : 0.524535 0.583159 0.648065 0.719931 36.567810 |
Note that the top 25% latencies are more that half a millisecond. Even when there is no event available (zeros on the chart) we can get a latency of more than a millisecond (see zero floating around near the 600th event). To make things worse, this is the typical case I observe when my Macbook has not much going on: just a Terminal and the test program. It gets worse when more applications are running.
I wonder if there is a more efficient way to get the next (mouse/keyboard) event if available in a MacOS application. Is there a trick I am missing that makes nextEventMatchingMask calls more efficient?
I might be off on my expectation, but I was thinking in much smaller latencies, something similar to the PeekMessage API from Windows that Casey profiled here.
I also posted this question on stackoverflow, but thought it would also be interesting to have it in this thread.