So the title pretty much says it already, I use the OpenGl ES template in Xcode to create a game. I use triangles for my code.
So what I want is basically the same like here, just for iOS instead of Android.
Can anyone help me please?
While initializing the GLKView, call this to enable 4x MSAA, with view being your GLKView instance:
[view setDrawableMultisample: GLKViewDrawableMultisample4X];
Related
The app uses OpenGL ES2 and the GLKit framework, and the render/update loop provided by GLKitViewController. It used to run at a steady 60 fps on my iPad2 with iOS7.1, but once I updated the iPad2 to iOS8.1, the exact same code now fluctuates between 56-59 FPS. (CPU utlitization, however, remains at 40-60% as before ).
Profiling reveals that the OpenGL drawing commands are using a much larger proportion of CPU time than they used to. The biggest change seems to be that calls to "GLKBaseEffect prepareToDraw" are taking much longer than they used to.
(The app uses a single GLKBaseEffect which is reconfigured at various points during the render loop, neccessitating a call to prepareToDraw each time. I realise it may be possible to optimize by having multiple instances of GLKBaseEffect, and that is something I was considering for later, however, the performance, as it was, was solid on iOS7.1)
I'm now examining the OpenGL ES Analyzer trace in Instruments to determine the OpenGL calls generated by "GLKBaseEffect prepareToDraw", to see if anything seems unusual, and will update the post accordingly once I've managed to figure anything out.
I'd be very grateful for any guidance on how to progress at this point - why might calls to GLKBaseEffect prepareToDraw take longer on iOS8.1?
The cause of the problem was identified by Jim Hillhouse and confirmed by Frogblast on the Apple Dev Forums thread "OpenGL Performance Drops > 50% in iOS 8 GM": setting the text property of a UITextField (or UILabel, in my case) in a view which is a subview of GLKView is causing the GLKView superview to layout, which is then causing framebuffers to be deallocated and reallocated. This wasn't happening in iOS 7.
Jim Hillhouse's workaround was to place the subview inside a UIViewController, and embed that in GLKView. I've done the same, using a Container View to hold the view controller, and can confirm that it works.
Is there a way to force SCNView to render a new frame on demand if there is no animation inside the scene? If the scene is static SCNView renders exactly once and then only after something changes.
Usually this makes sense, but I am working together with the Vuforia augmented reality framework which requires me to render a new frame every time it processed a new video frame from the camera. I worked around this issue by creating my own UIView with a CAEAGLLayer which renders the SceneKit content using an SCNRenderer. This works great, but I am curious if there is a way to do this with SCNView so I can avoid directly touching OpenGL ES.
Update
As of iOS 11.0 and macOS 10.13 the rendersContinuously property on SCNView is the preferred way to force the view to continuously render frames.
Previous answer
you can set its playing property to YES
You can increment the sceneTime like so:
sceneView.sceneTime += 1
It will then render a single frame.
As a UIView, you can use the same mechanism to request an update as you would any other UIView: [_sceneView setNeedsDisplay]; However, as pointed out, this shouldn't be used as the primary way to drive updates as it would not be synced with the display.
I'm currently discovering Cocos2D in combination with SpriteBuilder and I'm making stuff bounce around.
It's quite fun :)
What I'm trying to figure out is the following :
- On SpriteBuilder, I create a CCSprite, and I enable physics for this one.
- I can invoke it in XCode, and do whatever I want with it. Plus, the sprite is reacting accordingly to the physics settings applied to it. Great.
Now, what I would like to do is to disable the physics from this sprite in the code. I don't find a method in the Cocos2D API that would do the trick.
Can you help me out ?
Thank you for your time and help ;)
I write the correct answer then:
sprite.physicsBody.sensor = TRUE;
My iOS application stops rendering in case if the GLKView drawableMultisample is GLKViewDrawableMultisample4X. Everything works fine with the GLKViewDrawableMultisampleNone but if I set it to GLKViewDrawableMultisample4X, so I get only blank pink screen.
I've checked it on the iOS Simulator / iOS 7.0.3
Is anybody know how to resolve this issue ? Is it may be related to the iOS simulator and may work good on the real device?
I was having exactly this issue. It's not clear if the cause is the same but, in my case I was triggering my render from a displayLink trigger - without any regard for the semantics of setNeedsDisplay, or how GLKit sets up the render buffer around the execution of the drawInRect method.
I was of the mindset that since I was using displayLink, I could run all my rendering directly off of that trigger - and since it all worked before I tried to set up anti-aliasing, i figured it couldn't be far wrong!
The problem only manifested when I set GLKViewDrawableMultisample4X, much like the OP's problem.
The solution...
Ensure the view is created with enableSetNeedsDisplay = NO
Have displayLink trigger a function that contains nothing more than the following:
- (void)render:(CADisplayLink*)displayLink {
// This function should *not* perform any rendering
// We only want to inform GLKit that we're ready to render
GLKView * view = [self.window.subviews objectAtIndex:0];
// Tell GLKit that we're ready to draw
[view display];
// GLKit will ensure the buffers are setup before
// calling drawInRect
}
Move all rendering into drawInRect. GLKit will ensure the buffers are setup before drawInRect is called.
Now i 've got a project with ARC, which use over 6m memory on pushing chat ViweController(UItableview with custom cells). I have no idea about why it happening. The most interesting that i cant identify for what reason it needs too much memory. So this is my Instruments screenshot:
In more detail view it looks like:
I think libRip.A.dylib needs too much memory. Have you got any ideas about it?
And please explain me what is and strange libRip.A.dylib library?
According to this that libRIP call is responsible for drawing a UIViewController with a background image.
EDIT:
Apparently this problem happens when you're setting a view's backgroundColor using [UIColor colorWithPatternImage:].
A way around it is to use a UIImageView as background instead. As described here.