UIs in OpenGL ES

Sage
Posts: 1,066
Joined: 2004.07
Post: #1
Thanks to Frank and AnotherJake, I got my game running very nicely with OpenGL ES. Problem now is that I'm without UIKit and therefore on my own to create the menus and stuff for my game. It's not the hardest to create my own little button class and stuff, but as for actually laying it out, it's become quite a bit of trial and error. Then I change my texture atlas and have to change all my constants so that the buttons all draw right.

Is there a better way to handle UI stuff in OpenGL? What tricks do you guys have? I'm starting to think about using a NIB for the layout, reading it in, and using the tags of items to determine which of my items to place where. Then I can have a nice designer and use OpenGL to render it all. Anyone else give that a try?
Quote this message in a reply
Member
Posts: 245
Joined: 2005.11
Post: #2
I've done a similar thing (on the Mac) using XML to describe my layout. I never got as far as making a designer app, but reading in the XML and creating widgets is fairly simple.
The only thing I'd say is make sure you work out how you are going to join everything up and do everything you need at the outset, as going back to add in extra data sources and things can be a bit of a pain if the original architecture doesn't already work the right way.
Quote this message in a reply
Member
Posts: 269
Joined: 2005.04
Post: #3
I just have all my UI elements in a texture atlas and hard code all the button positions and actions. It's a horrible system that's a pain in the ass to update, but it's easy and fast to code originally. Incredibly easy to code "draw quad here, and if mouse/finger is inside this box do this." The problem being that if you've got 5 or 6 or 20 menu screens with 5 or 6 or 20 buttons each, you'll want to pull your hair out placing everything and measuring pixels at 8x in Photoshop or whatever.

If you've got time to create a system using XML or NIB or whatever then I highly recommend it, if only to keep your sanity. The downside being you've spent days or weeks on something the user will never notice. One of these days I'll design that perfect OGL UI system. One of these days...
Quote this message in a reply
Member
Posts: 283
Joined: 2006.05
Post: #4
Before you try all of this, I assume you've tried using UIKit over the top of OpenGL? Because while there can be a performance hit, I've found it to work really well in some situations (no idea what the deciding factors are though). And if that's at all possible, it's definitely worth doing because you have to work very hard to exactly replicate the subtleties of UIKit controls (things like the larger hit box once you've pressed down on a button). And if it's slightly off, it starts to feel unfamiliar and wrong.
Quote this message in a reply
Sage
Posts: 1,066
Joined: 2004.07
Post: #5
Well I gave UIKit a good try. I even went so far as to design my own way of going from UIViewController to UIViewController without the UINavigationController to try and cut down on the overhead. Performance while I'm using UIKit is acceptable enough, but once I get into my actual game (where there is nothing but my UIWindow, a EAGLView, and a controller class for the gameplay) the game refuses to run at full speed. I'm not entirely sure the cause, but it's not looking good for UIKit.

I'm going to try another couple of ideas, but it looks like it's just coming down to having to make the UI with OpenGL.
Quote this message in a reply
Sage
Posts: 1,066
Joined: 2004.07
Post: #6
After some more experimenting, I've found a solution that works for my needs. I'll describe it briefly here, but I'm hoping to stress test tomorrow and, if it holds, do a more full write up so others can use it.

What I basically do is set up my app to support the system described by Frank/AnotherJake in this thread as well as a normal UINavigationController. I have an enumeration called GameMode which simply has GameModeUIKit and GameModeOpenGL as the values. The default is GameModeUIKit.

Then I use Interface Builder to create the UI and program in some custom UIViewControllers just like normal. My app then starts up using this UI just like any other navigation based app. In my app delegate, I programmatically create a full screen EAGLView and keep track of it for later use.

When I'm ready to go from UIKit to OpenGL, I simply switch the game mode which calls the setter which looks like this:

Code:
- (void)setGameMode:(GameMode)newMode
{
    if (gameMode == newMode)
        return;
    
    gameMode = newMode;
    
    if (gameMode == GameModeUIKit)
    {
        gameRelease();
        
        [glView stopAnimation];
        [glView removeFromSuperview];        
        [window addSubview:navigationController.view];
    }
    else
    {
        [navigationController.view removeFromSuperview];
        [window addSubview:glView];
        gameInit();
        
        glView.animationInterval = kGameFrameIntervalNormal;
        [glView startAnimation];
    }
}

That will fully remove the navigation controller from the window and add just the EAGLView, as well as initializing the game data and starting the animation. From then on, I use the C interface to handle the actual game play portion. Whenever I'm done, I switch back to the GameModeUIKit and it'll restore my navigation controller.

It might not be a perfect system, and it does leave me responsible for all the in-game UI elements, but it certainly alleviates a lot of strain for me when working on a game that will feature 200+ mazes each with their own leaderboards. No way I want to make an OpenGL UI to replace all of the UITableView. Smile

As I said at the top, I'm going to keep testing it tomorrow to make sure it really scales to handle the full extent of what I need. If everything goes well, I'll be writing up a nice, long blog post on it so others can steal the system for their own use.
Quote this message in a reply
Nibbie
Posts: 1
Joined: 2009.02
Post: #7
Nick Wrote:...Then I change my texture atlas...

Platform: iPhone 2.2.1 {ObjC}

I'm a real gaming neophyte, being given the task to generate a 'Texture Atlas'. I don't want to re-event the proverbial 'wheel' here, particularly since I'm just beginning to know enough to be dangerous.

Is there a common library or code to for generating a 'Texture Atlas'?

... or is everyone using custom code?

Regards,

Ric.
Quote this message in a reply
Nibbie
Posts: 1
Joined: 2009.03
Post: #8
Awesome, you can even animate the transition. This is exactly what I was looking for. Thanks!

Nick Wrote:After some more experimenting, I've found a solution that works for my needs. I'll describe it briefly here, but I'm hoping to stress test tomorrow and, if it holds, do a more full write up so others can use it.

What I basically do is set up my app to support the system described by Frank/AnotherJake in this thread as well as a normal UINavigationController. I have an enumeration called GameMode which simply has GameModeUIKit and GameModeOpenGL as the values. The default is GameModeUIKit.

Then I use Interface Builder to create the UI and program in some custom UIViewControllers just like normal. My app then starts up using this UI just like any other navigation based app. In my app delegate, I programmatically create a full screen EAGLView and keep track of it for later use.

When I'm ready to go from UIKit to OpenGL, I simply switch the game mode which calls the setter which looks like this:

Code:
- (void)setGameMode:(GameMode)newMode
{
    if (gameMode == newMode)
        return;
    
    gameMode = newMode;
    
    if (gameMode == GameModeUIKit)
    {
        gameRelease();
        
        [glView stopAnimation];
        [glView removeFromSuperview];        
        [window addSubview:navigationController.view];
    }
    else
    {
        [navigationController.view removeFromSuperview];
        [window addSubview:glView];
        gameInit();
        
        glView.animationInterval = kGameFrameIntervalNormal;
        [glView startAnimation];
    }
}

That will fully remove the navigation controller from the window and add just the EAGLView, as well as initializing the game data and starting the animation. From then on, I use the C interface to handle the actual game play portion. Whenever I'm done, I switch back to the GameModeUIKit and it'll restore my navigation controller.

It might not be a perfect system, and it does leave me responsible for all the in-game UI elements, but it certainly alleviates a lot of strain for me when working on a game that will feature 200+ mazes each with their own leaderboards. No way I want to make an OpenGL UI to replace all of the UITableView. Smile

As I said at the top, I'm going to keep testing it tomorrow to make sure it really scales to handle the full extent of what I need. If everything goes well, I'll be writing up a nice, long blog post on it so others can steal the system for their own use.
Quote this message in a reply
Post Reply