I´m trying to make simple game using OpenGLES.
I have two EAGLViews(menu and game view).
Each view has its own viewController. Initializing of the views is done by initWithNIBName method of the viewController.
And when I want to show the view, I simply use addSubview method of the main window.
The game view is initialized only once at the launch time. Menu view is initialized only if it´s needed. Problem is, that when I go from game view to menu and then back, and then I redraw the game view, something goes wrong. (I'm setting EAGLContext in drawView method before drawing, so the context may be right).
Don´t you know where is the problem?
Or if the whole switching is managed wrong, gimme and advice please.
Thanks for replies.
I guess you are having a trouble with texture not showing correctly?
I don't know the real thing behind OpenGL, but this is my hypothesis:
Each time you came back to the EAGLView, The EAGLContext of EAGLView is changed. (if you have been copying and pasting from the OpenGLES template) The textures can only be loaded after the context is in its correct state, or else you cannot load any texture. Now, by leaving the EAGLView, and coming back, you are instantiating a new EAGLContext from initWithCoder:(NSCoder*)coder :
context = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES1];
if (!context || ![EAGLContext setCurrentContext:context]) {
[self release];
return nil;
}
So how can we preserve this context? I make it global. Simple as that. And when EAGLView is to be instantiated once again, have it check that whether the "global" EAGLContext is nil or not. If it's nil, just instantiate it, else do nothing. And never ever release or dealloc this global EAGLContext unless you want to quit your program.
This works for me, but again, my hypothesis above may not be correct. If anybody knows the real thing, please lecture me. I am also humbly in need of guidance. I want to truly know why this occurs and why do we have to do this as well.
And by the way, does this answer your question, Jenicek?
Related
I have a few problems in my game and I think I found the source. First of all, I use a CMMotionManager in my game to capture gyro motion, and if the user plays the game twice without closing the app completely first, the gyro can glitch and stop listening to the user, probably because there are two gameScene's, so there are two CMMotionManagers. I also have music playing in the menu that I have to explicitly call stop on when I transition to the gameScene, and it should just be deallocating that scene.
I don't want to deal with multiple view controllers, so my idea is:
Pass the old scene as an argument into the new scene
Once the new scene has loaded, set the old scene to nil
Should this solve my problems?
Calling SKView presentScene: or presentScene:transition: will properly get rid of old SKScene.
However, if there is a strong reference to the old scene, that scene will not be deallocated. My experience of this problem was from Trial and Error.
Please check this code post. It demos when the scene has a weak reference or a strong reference.
https://gist.github.com/naterhat/5399eec40eaa23edbfbc
Without seeing your code, my suggestion to solve the problem is by removing any connection to the scene other than SKView. Log when scene suppose to be deallocated by switching to a new scene. If works, then slowly connect new code. If not deallocated, something is still referencing the old scene.
You can check in Instruments to see if a scene is deallocated. Instead, I find it best to do this by adding logs in the init and dealloc methods of the scene.
- (void)dealloc
{
NSLog(#"%# Scene DEALLOCATED", self.name);
}
- (instancetype)initWithSize:(CGSize)size
{
if(self = [super initWithSize:size]){
self.name = #"TEST";
NSLog(#"%# Scene CREATED", self.name);
}
}
Hope this helps.
I have a EAGLView that I wish to convert into a UIImage. I can do this with the solution posted here:
How to get UIImage from EAGLView?
However, I can only accomplish this if a small amount of time has gone by between the creation of the EAGLView and the UIImage.
This code, which creates a EAGLView, and then a UIImageView right afterwards, does not work:
EAGLView *EAGLphoto = [[EAGLView alloc] initWithImage:photo.workAreaImage];
[theWorkArea.photoArea1 addSubview:EAGLphoto];
//I put a glfinish() here but it didn't help
UIImageView *photoView = [[UIImageView alloc] initWithImage:[self glToUIImage]];
//glToUIImage is taken from the link above
[theWorkArea.photoArea2 addSubview:photoView];
I'm assuming the UIImageView tries to get created before the EAGLView is finished being created. I tried to put a glfinish() in between but it did nothing. When I run the code, the EAGLView shows up fine but the UIImageView shows up as black.
However, this modified version of the above code works:
EAGLView *EAGLphoto = [[EAGLView alloc] initWithImage:photo.workAreaImage];
[theWorkArea.photoArea1 addSubview:EAGLphoto];
[self performSelector:#selector(getUIImage) withObject:nil afterDelay:0.1];
- (void)getUIImage {
UIImageView *photoView = [[UIImageView alloc] initWithImage:[self glToUIImage]];
//glToUIImage is taken from the link above
[theWorkArea.photoArea2 addSubview:photoView];
}
Am I using glfinish() incorrectly? Is there a better method than my hack?
Usually when you make visible changes to UIKit objects instead of updating instantly they merely flag themselves to make those changes in the future, then do the whole set of changes as a batch next time you relinquish the main thread (by returning to the runloop). That's not a misfeature or a failure in the implementation, it's actually usually what you implicitly expect, being the reason you can write code like:
view.frame = someNewFrame;
view.someOtherProperty = someOtherValue;
And not worry that every so often the view will visibly adopt the new frame before adopting the other changes. As a rule, you want the things you do to views to appear to be atomic.
Occasionally you run into a situation, as you have here, where the fact that changes you've already requested haven't come into effect yet is exposed. frame and someOtherProperty would return their new values in the above example so that you don't care whether the changes took effect immediately or not, but based on your observation about performSelector:withObject:afterDelay: it seems likely that you've stumbled upon a situation where the change doesn't pretend to be immediate.
EAGLView is difficult to diagnose because it's not really a UIKit feature. The CAEAGLLayer that it's built upon is, but EAGLView is just the name Apple have adopted for a custom UIView subclass built on CAEAGLLayer in various example projects. They've not been consistent about the interface or implementation of EAGLView across their examples, but at a guess I'd say that probably it's creating the OpenGL frame buffer object (that is, the thing that OpenGL uses to store numbers related to pixels, allowing glReadPixels to work) only when asked to lay itself out, and it doesn't lay itself out until UIKit asks it to do so. Which isn't until you've dropped out to the runloop.
That diagnosis can be confirmed by checking the code of the EAGLView that you have. If there are a bunch of calls to things like glGenFramebuffers that are triggered as a result of layoutSubviews, drawRect or some other method that isn't called directly by the relevant init then that proves it.
Assuming that diagnosis to be correct, you could adapt EAGLView but I think probably the best solution is just to stick to performSelector:withObject:afterDelay:0. This isn't a race condition, so that solution isn't in the slightest bit flakey or unreliable, it's just a slightly roundabout way of saying "let UIKit catch up with all of those instructions, given that I know that'll let EAGLView get into a meaningful state, then continue with my stuff".
Ok hopefully this is an easy question:
I have a main viewcontroller that is loaded by the app delegate at application startup.
This viewcontroller has some code in 'viewDidLoad' to create some non view type based objects (some sound/data objects). Aside from that it also loads a UIView.
The sound/data objects take a while to create, but the app is quite functional without them for a start - so I want to load these objects after the UIView has loaded, but can't seem to figure out how.
I have tried moving the appropriate code to viewDidAppear, but this is still called before the UIView actually appears on screen. Is there a function that is called after the viewcontroller actually starts displaying UIViews, or any other way to achieve what I want?
Any help would be much appreciated - thanks!
In case anyone else has a similar problem, I found a way to solve it: use NSThread to load things in the background without pausing everything else.
There's a good simple example here: http://www.iphoneexamples.com/.
I need some help. This seems to be a common problem I am having when am adding and changing views in my coding. And I would love to learn what I am doing wrong.
Currently I am adding and removing views using the following calls from my view controller:
[startView removeFromSuperview];
[self addSubview:secondView];
and then doing the opposite again to go back.
[secondView removeFromSuperview];
[self addSubview:startView];
I am fine up to this point.
But the problem I have is that when I then decide to go back to 'startView" and call the first code that I have above for the second time.
My View loads but very little works.
None of my methods are called, there is no animation and the view is shown but it is "dead" or "asleep". And I have no idea why!
I am basically adding a view, removing it, then adding it again and everything breaks.
Can anyone give me a hand as to what might be happening? is it that ViewDidLoad doesn't fire the second time it's loaded? or something like that?
I would much appreciate it.
I may have figured it out So don't worry!
I had a flag hidden in my code somewhere that was stopping my methods from firing.
Sorry!
Hey all, I'm completely stumped with this iPhone problem.
This is my first time building a view programmatically, without a nib. I can get the view displaying things just fine, but the darn ViewController isn't responding to touches the way it used to in programs where I used a nib. I should add that in the past, I started with the View-Based Application template, and this time I used the Window-Based Application template.
My thinking is that the View-Based template does something magical to let the iPhone know where to send the touch events, but I can't figure out what that would be even after several hours of bumbling around Google. Or I could be looking in an entirely wrong place and my troubles are related to something else entirely. Any thoughts?
There's nothing magical in the view-based template. The most likely reasons for failure to respond to touches are:
You've messed with touchesBegan:withEvent:, userInteractionEnabled, exclusiveTouch or something else, thinking you need to mess with these (generally you don't; the defaults are generally correct)
You created a second UIWindow
You put something over the view (even if it's transparent)
Simplify your code down to just creating a view programatically that responds to a touch and nothing else. It should be just a few lines of code. If you can't get that working, post the code and we'll look at what's going on.
Problem solved. touchesEnded != touchedEnded.
That'll teach me to program without my glasses on.
Another possible scenario for failure in response to touches is when your VC frame is not predefined and its boundaries are actually exceeding the window placeholder. It happens a lot when you just forget to define the frame property for the VC.
Once you define it correctly - User interaction returns to normal.
Good luck !