64 Bit Cocoa (Mac) Ogre doesn't respond?

[ArtOfWarfare]

I know this question has been asked before, but I still can't figure out why this isn't working.

I have the basic first tutorial set up. I'm using BaseApplication.cpp/.h exactly as they are online.

Other than that, I have TutorialApplication.cpp/.h... these are as they are at the end of the first tutorial, with just these lines added to main:

Code: Select all

        // Added as suggested for manually configuring an Xcode 4 project
        Ogre::String workingDir = Ogre::macBundlePath()+"/Contents/Resources";
        chdir(workingDir.c_str());
        std::cout << "working directory: "+workingDir+"\n";

I can't find out how I'm supposed to make it respond to user input.

I'm using Cocoa for the API and 64 bit. Ogre version 1.8.0.

What I get is this: The window appears with the Ogre head (after some screen tearing - how can I make it so the initial screen tearing stuff doesn't happen?) My cursor vanishes. To unselect the window, I have to command tab out of it. If I look at the window while it's in the background, I can see the FPS is updating. When I mouse over the window, I get a spinning rainbow ball for a cursor. In the dock and the force quit window, I see "Application Not Responding".

So... suggestions?

Also, a somewhat related question: I'd like to utilize gestures on computers with multitouch trackpads. Will OIS support that or do I need to find a different way of supporting those?

[masterfalcon]

It sounds like you're using a traditional while render loop. This doesn't work with Cocoa because the system needs to spend a little bit of time here and there with the resources and the while loops locks it out. Look at the sample browsers code, you'll see that we've set up a NSTimer to call renderOneFrame which then avoids this problem. Someday I'll get display link working too, but it's taken a backseat for now.

[corristo]

Hi, I think I found kind of solution without mess with timers:
https://github.com/corristo/openmw/blob ... sx_loop.mm

Will look if I can use display link without hacking ogre

[corristo]

Looks like I'm having problems with this approach =\
After resolution change in-game window correctly resized, but part of screen begins flickering & input strangely works.
As far as I can see messages still correctly pumped.
here is screenshot: http://d.pr/i/tMEa+

Any thoughts on what it can be?

[jokoon]

What is the reason for this NSTimer requirement ? I have this issue in both 1.8 and 1.7.4

Is it an issue created by XCode 4 then ?

I just looked at this piece of code, I don't know a lot about objc https://github.com/corristo/openmw/blob ... sx_loop.mm

Is this the simplest way of fixing it ?

[masterfalcon]

Xcode 4 is an IDE, it does not affect API usage. Are you asking why a displaylink is not used? Or why a while loop is not used?

[jokoon]

I meant to ask if this issue was the result of how new xcode version use clang, or if this issue was always there, I'm not sure if I had this issue in previous versions of Ogre.

I'm just trying to understand why the while loop / startRendering() doesn't work properly, and looking for a simple and dirty fix in my code to make it work. I'm starting to want to learn objc

I didn't even know what a displaylink is until I read this https://developer.apple.com/library/mac ... cepts.html

PS: I'm using a simple framelistener and OIS, nothing fancy

[masterfalcon]

The use of NSTimer is due to the nature of Cocoa, not Xcode, clang or Ogre. This has been discussed elsewhere within the forums and you can find much more info on Apple's site but here's the gist.

With Cocoa you don't poll for events, they are delivered to you when they occur via overridden event handlers. This includes all window update functions. If you use a while loop these events cannot be delivered and nothing will render.

[jokoon]

I have an application which runs on visual c++, I just want to keep using my code adding as little objc as I can since I don't know the language a lot. Do I really need to add as much code as what I do find in the samplebrowser or appdelegate ?

[masterfalcon]

Yeah, hate to break it to you but Cocoa is an Objective-C API and you will need different code than on windows.

[jokoon]

Is there a plan to make Ogre take care of it in further Ogre versions ? I guess it would not be immediate, or would it ?

[masterfalcon]

Are you talking about moving it into the core? Unlikely at this point. It doesn't fall into the same event handling pattern as the other architectures so it doesn't fit well with the rest of the code. In addition to it being a different language, don't want to clutter the code too much, etc.

[jokoon]

So using a framelistener is not recommended.

I'd be curious to see what is the simplest implementation to use ogre with cocoa developers have come up with until now.

EDIT:

Wait there. I just compiled in 32 bit and everything works perfectly, is it such a bad thing ?

[masterfalcon]

Framelisteners are just fine. There's no reason that you can't use them.

The reason that that worked is that 32 bit builds can use the Carbon event message pump.

[jokoon]

Since it's deprecated, one day it won't work then ?

When will that day come ?

[masterfalcon]

I can't say when Apple will remove Carbon but it's still supported in Ogre. But from 1.9 forward it will also be deprecated.

[jokoon]

Well it either gives me enough time to come understand the objc code so I can use it, or either to wait patiently for someone to release something which can be interfaced with C++.

[masterfalcon]

Another option is to interlace it yourself. Just block it out with #ifdef __OBJC__ and add -x objective-c++ to your compiler flags.

[jokoon]

Another option is to interlace it yourself. Just block it out with #ifdef __OBJC__ and add -x objective-c++ to your compiler flags.

I'm not sure to understand. Does it mean I _MUST_ use cocoa and have objective c in my project to have a 64 bit application or not ?

Framelisteners are just fine. There's no reason that you can't use them.
The reason that that worked is that 32 bit builds can use the Carbon event message pump.

I take back what I said about "works perfectly", it doesn't, somehow my keyboard inputs get stuck.

What is the simplest to use, SampleBrowser_OSX.h or the AppDelegate.h from the xcode template ? I don't know a lot of objective C++

[masterfalcon]

Yes that's correct. Carbon does not support 64 bit so you must use Cocoa.

[jokoon]

Does buffered inputs work in OIS as intended ?

[masterfalcon]

As far as I know it does.

[jokoon]

I'm still lost as to where I should put my init code and where I should put my startrendering code, instead of using OgreFrameWork. I guess I could start to put comments to figure this out...

[jokoon]

Where should I put the code which is called at each frame ? in

Code: Select all

- (void)renderOneFrame:(id)sender

?

I put a call to code that init everything in my code in setupDemoscene(), doesn't seem to be called anywhere.

I also wonder why there is a call to sleep... it is to wait for the app to be displayed on screen before it fires the nstimer thing ?

It'd be nice to put comments just to state where to put what.

[mobileben]

It may be easier to forgo using the templates and build your own. While I understand why the demo code is built with a certain structure, I think it is a little clumsy around OSX/iOS. Aside from using cmake to build the Xcode project file for Ogre, I just rolled my own as well as broke apart the demos to launch the app more akin to OSX/iOS programming. Bear in mind, the demo code is still an excellent source to use as a reference on how things work. That's more or less what I used as a reference to build my own launching code.

Out of curiosity, I looked at the templates you referenced. The sleep you are seeing appears to be used to relinquish the thread so it doesn't become an potentially endless room which doesn't yield.

I haven't used Ogre enough to know how it fairs if you try and render if things aren't fully setup. To be cautious, I would just init before starting any rendering. And then experiment. But it looks like the code is already setup to do it that way.

FWIW, setupDemoScene should be called from DemoApp::startDemo() Which would get called from the app delegate's go method. That gets called from the applicationDidFinishLaunching method.

Although it sort of looks like runDemo won't get compiled in for 64bit apple targets?