Messages

1

Window / Re: Mac external trackball not detected / IOHIDElementGetDevice Crash

« on: May 06, 2013, 01:23:56 am »

Also note that mouse events work fine with the trackball and other external mice, it seems like its only the IOH api that isn't working..

A quick examination of SDL and glfw both seem to indicate that neither use IOH for mouse or keyboard handling, unless I missed something.

2

Window / Re: Mac external trackball not detected / IOHIDElementGetDevice Crash

« on: May 06, 2013, 12:58:09 am »

So this seems to be a bigger issue. Multi-mouse support in general seems to not be working.
If i connect a regular usb mouse into my macbook pro, no clicks are detected, only clicks from the touchpad register.

I'm unfortunately unclear why this is.. Ive added a ton of debug stuff to the IOH code and it sees the usb optical mouse, detects the buttons, adds it to the m_Buttons array, but when checking in IsMouseButtonDown the IOH value always comes back as 0.

3

Window / Re: Mac external trackball not detected / IOHIDElementGetDevice Crash

« on: May 05, 2013, 10:34:37 pm »

Understood, I'll see what I can figure out with it. I was surprised that most of the IOH objects seemed to have no information exposed in the debugger. Didn't look very friendly to say the least.

4

Window / Mac external trackball not detected / IOHIDElementGetDevice Crash

« on: May 05, 2013, 08:08:09 pm »

So I've been using some of the old RC 2.0 code for probably a good year or two without problems, however it seems I've ran into an issue now. I'm now using a Logitech m570 wireless trackball, and games instantly crash when checking for a mouse press. This is likewise present in our previous commercial releases. The crash seems to happen at IOHIDElementGetDevice.

Now I downloaded the latest SFML and I no longer seem to get a crash, but the trackball does not work at all. Debugging the code a bit it seems like SFML detects 3 mice with the following button counts 940,7,39. This seems strange to me, as I would have expected at most 2 mice to be detected, but I'm not familiar with this API any.

Some left, right and other buttons do get detected and added to the m_Buttons array, but in the end the trackball buttons seem to do nothing.

I also checked out some games like FTL that use SDL and the trackball seems to work fine there, so it seems like its not a global issue. The trackball also works fine under SFML and Windows.

5

Window / Re: Tactics for handling Input Injection and Real Time Polling

« on: January 31, 2013, 04:58:11 am »

Well the basic problem is, say I have a window displayed over my game view.

I click the window to do something with the mouse, the window gets the event and is happy, but suddenly the game also detects a mouse push (Since its using real time polling) and is trying to do things as well.

Normally I would explicitly handle this via game logic, but with using a GUI library that can be complex and tedious.

Really I suppose there are a lot of ways to handle this, I could just set a flag to not poll real time inputs if a input event is consumed this frame, or what not. Just wondering if anyone had nice clean solutions to this particular issue.

6

Window / Tactics for handling Input Injection and Real Time Polling

« on: January 31, 2013, 04:40:10 am »

I'm starting to work with some GUI libs that need to consume the input events in order to work correctly, but then game code is using the real time system.

Just wondering if anyone has some well known approaches to handling this?

Ditching real time is obviously one solution, but might not always be ideal.

7

General / Re: Mac Menubar

« on: January 28, 2013, 07:30:22 pm »

By the way, have you tested Quit, does it close application properly ? I mean finishing the application loop ?

Well in my game, the main loop is just a while loop until a running flag gets set to false, either via a SFML close event, or some other cause. I simply have the Quit menu set my running flag to false, so on the next update the main game loop ends, and it goes off into a normal shutdown flow.

Previously I had tried having the quit option just call Terminate, but this sadly doesn't seem to inject a CLOSE event via SFML.

8

General / Re: Mac Menubar

« on: January 26, 2013, 08:49:05 pm »

Nah no worries. There is rarely ever a good reason to leave something in a sort of undefined behavior state, especially when its a simple correction and doesn't hurt anything. Better safe than sorry down the road when Apple tweaks something, as they have a habit of doing.

9

General / Re: Mac Menubar

« on: January 26, 2013, 06:23:48 pm »

Making assumption that none of the parent classes has anything to initialize is not reliable. Even if the documentation says NSObject doesn't initialize anything, you're not guaranteed it'll remain so. Moreover, your work should be reusable and adaptable, which includes the possibility of changing the parent class without rewriting your class (or at least not dealing with that kind of issue).

Yeah I agree completely. My ramble was mostly based on trying to discover why the current code seems to work fine, regardless of init or not. I'll edit the pasted code above to include the init.

My disclaimer on the code being complete rubbish still stands though. I write just enough Obj C to accomplish something, and then bury it in a dark place where I hopefully never have to see it again. As a consequence my familiarity with Obj C is very minimal. I probably write like 100-200 lines of it a year, and I try to avoid that.

10

General / Re: Mac Menubar

« on: January 26, 2013, 04:55:00 pm »

Hmm... I think

Code: [Select]

menuNotify = [MenuNotification alloc];should be

Code: [Select]

menuNotify = [[MenuNotification alloc] init];

Reading Apple's documentation I think your right. Though I have no idea what difference it *should* make, given there really shouldn't be much in the way of instance variables I would think, and I'd certainly hope since its a custom class derived just from NSObject that init isn't going to swap me out with something else.

Admittedly though looking at the created object in the debugger does show a whole lot of extra junk there, which I wouldn't personally expect.  However, the same junk seems to get the same values from what I can see regardless of "init" or not.

Ah some more apple documentation "The init method defined in the NSObject class does no initialization; it simply returns self." Since I have no init methods defined myself, it seems like it matters squat in the end. Though programming practice certainly says to do it.

11

General / Re: Mac Menubar

« on: January 25, 2013, 10:46:36 pm »

#ifdef PLATFORM_MAC
NSDictionary *  aboutOptions = [NSDictionary
                        dictionaryWithObjectsAndKeys:@"Credits", @"Credits.rtf",
                        nil];

@interface MenuNotification : NSObject <NSApplicationDelegate>
- (void) terminateRequest: (id)sender;
- (void) performAbout: (id)sender;
@end

@implementation MenuNotification

- (void) performAbout: (id)sender
{
    [ NSApp orderFrontStandardAboutPanelWithOptions: aboutOptions ];
}

- (void) terminateRequest: (id)sender
{
    //set our main loop to end
    DirectReality->running = false;
}
@end

MenuNotification * menuNotify;
#endif
 

#ifdef PLATFORM_MAC
    menuNotify = [[MenuNotification alloc]init];
    [NSApp setDelegate: menuNotify];
   
    id menubar = [[NSMenu new] autorelease];
    id appMenuItem = [[NSMenuItem new] autorelease];
    [menubar addItem:appMenuItem];
    [NSApp setMainMenu:menubar];
   
    id appMenu = [[NSMenu new] autorelease];
    id appName = [[NSProcessInfo processInfo] processName];
   
    NSString *title;
   
    title = [@"About " stringByAppendingString:appName];
    [appMenu addItemWithTitle:title action:@selector(performAbout:) keyEquivalent:@""];
   
    [appMenu addItem:[NSMenuItem separatorItem]];
   
    id quitTitle = [@"Quit " stringByAppendingString:appName];
    id quitMenuItem = [[[NSMenuItem alloc] initWithTitle:quitTitle
                                                  action:@selector(terminateRequest:) keyEquivalent:@"q"] autorelease];
    [appMenu addItem:quitMenuItem];
    [appMenuItem setSubmenu:appMenu];
#endif
 

Anyways no promises on how great that code is. I really don't touch Obj C unless its just to write something once and then wrap it away so I don't have to see it again, but it seems to work just fine.

12

General / Re: Mac Menubar

« on: January 25, 2013, 08:51:53 pm »

Alright this was actually trivial to accomplish it seems.

I just created a little objective c interface to handle my callbacks, set NSApp's delegate to my own callback which SFML doesn't appear to touch, then created a menu and added it via [NSApp setMainMenu:];

I then populated the menu with the standard menu item entries like about, show all, hide, and quit.

I was able to do all of this inside of my own initialization routines and didn't need to mess with nib files or cocoa runloops or anything, in about 40 lines total i'd guess.

Finally wrap the code in a #ifdef for mac platform.

13

General / Re: Mac Menubar

« on: January 25, 2013, 06:54:52 pm »

Thanks guys, I hadn't even realized there was a cocoa example.  I'll also take a look at the whole  [NSApplication sharedApplication] i've actually never used interface builder, despite doing Obj C and so forth. (Admittedly I try to limit Obj C to the bare minimum.)

14

General / Re: Mac Menubar

« on: January 24, 2013, 09:12:26 pm »

unfortunately I haven't had the time to work on this issue yet. So no progress so far.

Oh well no worries, just wanted to check, before diving off into the deep.

Do you know if I should expect any major issues if I try an use SFML from within a existing cocoa setup? I pretty much just use SMFL for doing the OpenGL context creation and input gathering.

I suppose the biggest headache might just be the event stuff.

15

General / Re: Mac Menubar

« on: January 24, 2013, 07:45:08 pm »

I don't really know what you want to do, but in any case you can still develop a Cocoa application where you set the menu bar as you want, and then create SFML windows within the Cocoa application.

Well 8 months down the road and this issue has come up to bite me. Our one game on the Mac App Store, has now been denied an update due to lacking a menu bar, and specifically the ability to click on the App name in the menu bar and select quit.

Has there been any progress on this general issue? If not I guess I'll be trying to embed my game into an existing cocoa window.