I've replaced glutWarpPointer with CGWarpMouseCursorPosition(pos) and that works just fine. (With a couple of weirdo bugs that I'm just trying to iron out now)

Thanks for the tip about the integer limits, i hadn't considered that.

Quote:Can you describe what you're attempting to actually do? The code you've shown is very odd looking; it may very well be that there is a different and more robust approach -- one which will fit better within the functionality GLUT offers.

I'm attempting to get input from the mouse buttons and at the same time do a mouse look thing. I'm using incremented integers because I figure, why use an INT and a BOOL, when you can do the same thing with just an INT?

Quote:have you stuck a printf at the top level of the HandleMousePress function to see what GLUT is giving you?

I don't actually know how to use printf. I suppose that's something I should learn. And the INTs are signed.

Quote:I don't know if this is at all relevant, but every time you call glutWarpPointer(), mouseMovement (or whatever the name is) function is called

Yep I considered that and tried commenting out some lines and changing functions around but it had no effect.

...

Well that solves my problem Thanks everyone for all your help (especially AnotherJake), I really really appreciate it!

QuestingCordiial Wrote:I don't actually know how to use printf. I suppose that's something I should learn.

printf("hello I am at this line\n");
or
printf("HandleMousePress called with button:%d buttonstate:%d\n", button, state);

You can have as many escape sequences as you like. %d will print an integer, %f a float and there are a bunch of other ones. Then you stick a comma separated list of the variables at the end to match the escape sequences.

And if you use Cocoa, NSLog is more flexible than printf, though it appears to be pure C you are writing.

BTW, I've gotten into the habit of also including a fflush(stdout) after every printf when debugging, just to make certain it gets sent. Don't know any technical details behind whether or not that's worth the trouble though...

I think that is to do with newlines at the end, ie. it doesn't get flushed until a newline character. I could be wrong though. My examples above have been edited with the \n at the end, as this is how they should have been.

reubert Wrote:I think that is to do with newlines at the end, ie. it doesn't get flushed until a newline character. I could be wrong though. My examples above have been edited with the \n at the end, as this is how they should have been.

If you are using xcode, you should set it to always display the console when you do a build and run. That way you can see the results as the program is running. You can find this setting in Preferences > Debugging, select "On Start: Show Console".

Blacktiger Wrote:If you are using xcode, you should set it to always display the console when you do a build and run. That way you can see the results as the program is running. You can find this setting in Preferences > Debugging, select "On Start: Show Console".

I simply cannot imagine programming without immediate visual access to console output from printf's (and logs from Cocoa) -- I thought everyone needed that. It's been integral to my style of programming for nearly twenty years. To me, during development, not having the console visible during execution would be analogous to the proverbial "having one hand tied behind my back"!

Hairball183 Wrote:I have a 15-inch monitor and as such must conserve space, which means I sometimes am forced not to be able to see everything I'd like to at once. ...

Well obviously you don't always get to see it, depending on the situation (e.g. full screen on a single display setup, or a maximized window), but I prefer to have at least the bottom line of the console peaking out somewhere if at all possible, unless I know for a fact that I won't be seeing any output or don't happen to care about output at the time. Screen space doesn't really have anything to do with it -- I used to do this on the 9-inch 512 x 342 pixel display in my Mac Classic back in the day too.

At one point, I seem to recall that the developer tools I was using did not conveniently display console output so I bought a third-party utility to help. I think that utility was called D-Con; which I thought was a pretty clever name for "Debug-Console" and at the same time alluding to a popular rodent poison. It was pretty neat because it had a small console window always floating at the tool palette level, so it showed up even over the program being debugged.

printf'ing is a very powerful method for debugging! For instance, if you have a bug in your program somewhere, but you just can't see it out of thousands of your lines of code, simply start sectioning off large parts with printf's. Then you'll narrow things down by "bracketing" that subsection with more printf's, and repeating the process until you get down to a more narrow area and start setting debugger breakpoints, or continue subdividing the sections of code to get even further down to a few lines or even just one. The general idea goes something like this: