So I am using Xcode 3.2.1 and am trying to make an iPhone OpenGL ES1 project. The default template for an opengl project is ok, but I have been trying to split the code up so not everything is done per frame on the drawView() call.
I have a seperate setupRC method that sets the lighting, turns on depth test, turns on culling and sets the clear color. This is called on the init of the EAGLView and this works just fine.
I have took the glViewport() and glFrustrum() calls and put them at the end of the resizeFromLayer() method in the ES1Renderer.m file. This gets hit when the app starts and when the app gets resized as it should.
Now the problem is the frustrum's far seems to be messed up, as in all my objects get cut / clipped off. I tried adjusting the camera position and angle and it still all objects are cut / clipped. I increased the far from 1000.0f to 30000.0f and still get the same result. What is crazy is that if i call both the glViewport() and glFrustrum() calls in the drawView() every frame everything looks right. Nothing is clipped and looks like i want it. From everything I've been reading the frustrum and viewport calls only need to be called when the window / gets made and resizes, but If I don't call it every frame in my project it doesn't work. Any ideas?
Thanks In Advance
I wonder if you might be doing some extra translating somewhere before you start drawing? Maybe you could make sure you do a loadIdentity() before you start drawing everything just to make sure you're starting from where you think you are.
In trying to get this frustum/viewport situation worked out in XCode's OpenGL iphone template myself, one resource that was helpful in getting to the bottom of it was:
http://iphonedevelopment.blogspot.com/2009/05/opengl-es-from-ground-up-table-of.html
Related
First, My goal is render sprite objects as below.
So, I set Edit>Project Settings>Graphics>Transparency Sort Mode as "Custom Axis" and Transparency Sort Axis as (0,1,0).
But it only works in the Scene View. When I run play mode, the Transparency Sort Axis I set automatically return to the default value - I mean, Custom Axis + (0.49,-1,0.49). Then the objects' states in the play mode are as below.
I've been suffering from this problem over than a week... because as far as I remember, when I was much more unskilled Unity beginer and tried some tutorials, the setting I set in this way worked in the play mode without any issues.
I think maybe the reason is in the asset I imported because when I made a new project without any asset and tried exactly same procedures, it worked.(transparency sort axis didn't changed automatically during play mode). But I'm still not sure about this problem's reason yet and don't know how to fix it.
Could you please help me solve this problem?
When I draw any shape (Whether it's textured or not) it will flicker when I go to fullscreen and make the title bar show when I move the mouse to the top. It will turn lighter and then back for like a split second. I don't know if this happens with solid colors, but when I color the vertices and draw a gradient or apply textures, this happens. It's annoying, even though it's subtle. How can I fix it?
How to reproduce: Create a shape in Metal, either color the vertices differently to create a gradient, or apply a texture to it, and make the window fullscreen. Move the cursor to the top of the window. When the title bar shows up, the shape/texture will flash briefly. How can I fix that?
I am using macOS 1.15 Catalina.
This can be demonstrated even with the Xcode's example Metal game. Just go to fullscreen, show the title bar, and it will be unsmooth when you show and unshow the titlebar.
UPDATE: I have realized, that if I put the drawing code in viewDidLoad() instead of draw() this behavior will cease. How do I make it so that it's not buggy without having to only render ONE frame?
ANOTHER UPDATE: It does occur for solid colors.
This is a very difficult question, because I don't know what to try. This bug is also very hard to fix, because it only sometimes happens.
Example of the bug (Video)
Another example of the bug that displays the "white flicker" (Video)
Also this question was only half answered, because it turns out that I managed to fix the problem of the titlebar blocking the framerate, but there is still a problem with the white flash.
After watching your video, I understand what your problem is. In your case UI (Tittle Bar) is blocking the main thread, it's normal behavior because MTKView rendering occurs on the main application threads. You need to create a custom metal view and implement a render loop on a background thread.
Your best bet is to report this as a bug to Apple. I tried to research and there seems to be no results about this bug.
I assume you want a fix, but all I got is a workaround:
It doesn't seem to occur while the drawing code only runs once, in viewDidLoad. Maybe you could keep it there, and manually call the MetalView's draw method 60 times a second. I figured out how to get what I said to work. Leave the drawing code in draw, but make sure to set the preferred framerate to 0. Then manually redraw it 60 times a second. Because the draw method auto redrawing is buggy in this sense.
Ok I'm not sure how much details I can really give, but I'm having a crazy weird problem. I'm using the GLPaint code in my app from Apple, and the PaintingView.m code is the same exact code from Apple-nothing else. Yesterday, everything was working fine and the brush image for the paint was a circular particle that came with the GLPaint, and it was working fine.
Now, out of nowhere, the particle is just a square, and a square particle means that the GLPaint app can't find my particle-meaning if I just put any file name into here: brushImage = [UIImage imageNamed:#"Particle.png"].CGImage; I'll get a square particle.
So this is something wrong. However, I just have no idea why. I tried replacing the Particle.png image over again and placing it in different places in my Xcode project but that didn't work. I know it's a long shot, but does anyone have ANY possible ideas as to why this could happen?
If you have replaced Particle.png with an image that is not square, and the sides are not a power of two, then it will not work. For instance, the particle image can be 32x32, or 64x64, but not 110x110.
As for debugging, I would suggest putting a breakpoint at the line after brushImage = [UIImage imageNamed...], and check the value of brushImage. If you are not comfortable using the debugger, just throw NSLog(#"%p", brushImage) right under that line. If the image is nil, or 0x0, then you know that the image file cannot be found or decoded. If it is not, then the problem is in the code, not the setup.
Well I figured out the problem and I'll post the solution just in case anyone ever has an issue like this. Turns out I had a duplicate painting view in IB that for some reason maybe confused the painting view class. All I had to do was delete one of the views, then everything worked fine again.
Is there a way to draw on the iPhone screen (on a UIView in a UIWindow) outside of that view's drawRect() method? If so, how do I obtain the graphics context?
The graphics guide mentions class NSGraphicsContext, but the relevant chapter seems like a blind copy/paste from Mac OS X docs, and there's no such class in iPhone SDK.
EDIT: I'm trying to modify the contents of the view in a touch event handler - highlight the touched visual element. In Windows, I'd use GetDC()/ReleaseDC() rather than the full cycle of InvalidateRect()/WM_PAINT. Trying to do the same here. Arranging the active (touchable) elements as subviews is a huge performance penalty, since there are ~hundred of them.
No. Drawing is drawRect:'s (or a CALayer's) job. Even if you could draw elsewhere, it would be a code smell (as it is on the Mac). Any other code should simply update your model state, then set yourself as needing display.
When you need display, moving the display code elsewhere isn't going to make it go any faster. When you don't need display (and so haven't been set as needing display), the display code won't run if it's in drawRect:.
I'm trying to modify the contents of the view in a touch event handler - highlight the touched visual element. In Windows, I'd use [Windows code]. … Arranging the active (touchable) elements as subviews is a huge performance penalty, since there are ~hundred of them.
It sounds like Core Animation might be more appropriate for this.
I dont think ull be able to draw outside drawRect...but to get the current graphic context all you do is CGContextRef c = UIGraphicsGetCurrentContext(); hope that helps.
I am trying to implement simple paint functionality in my iPhone app. I tried updating a bitmap with a bitmap brush, and I also tried this tutorial.
Both methods have the same problem, even though the code is almost totally different. It happens only on the device - the simulator works fine.
When I touch the screen and move my finger, the screen does not get updated. When I pause or lift my finger, then the screen gets updated. This is not a very good user experience!
I tried calling drawRect from touchesMoved directly, but found that the drawing context (which I retrieve using UIGraphicsGetCurrentContext) is invalid for many of the calls, so painting the screen myself for every touchesMoved doesn't work.
Any ideas?
Thanks for any help, this has been quite frustrating!
Henning
It sounds to me like you're not giving the main run loop a chance to update the display. Your drawing code may be taking longer to execute than the time between touch events, so the display is never updated. When you lift your finger, it does the updating because it's no longer burdened with your drawing.
You might consider optimizing your drawing to speed it up (drawing only within the dirty region of the screen, for example), using something like NSOperationQueue to queue up the heavy calculations of your drawing to run on a background thread, or selectively dropping touch drawing events to keep your response smooth.
One additional possibility is placing your heavy drawing code in a separate method and calling it via performSelector:withObject:afterDelay, with a 10 millisecond (or smaller) delay. This might give the main run loop a chance to update the display with its current state. I haven't tested this, but if I remember correctly I've seen this work.
You can't directly call drawRect:. To refresh your screen on demand, try calling [self setNeedsDisplay] from your touchesMoved method, which will setup the proper contexts for a call to drawRect:.