UIKit vs OpenGL for 2d hex strategy game

So, I've been working on a 2d, hex-map, turn-based strategy game and I've got all the detailed nitty-gritty figured out (like line-of-sight and path finding on a hex grid, loading sprite sheets, different movement costs for various terrain, etc.), but I've done everything for Mac rather than iPhone, so everything works by drawing NSImages onto a big custom view.

I've decided I'd rather have it be an iPhone game than a Mac game and so now I need to change everything to either UIImages in a UIView, or use Open GL. I see pros and cons either way.

There's not much animation going on - some sprites have an animation cycle (like a hex with an HQ on it might have a rotating radar dish), and when a unit moves, the movement is animated - the unit slides from hex to hex (maybe with a walk-cycle or tank-tread animation).

But, each redraw of the view still needs to draw each hex and unit that is currently in view (about 60 hexes, up to maybe 20 units).

I'd definitely go with OpenGL. It takes quite a bit of effort to get all the initial stuff set up (a 2D view, texture loading and handling, drawing, touch screen stuff, etc.), but I'm sure there are plenty of people who wouldn't mind sharing their prewritten iPhone templates to get you up and running fairly quickly. I wouldn't mind sharing my template.

I was thinking the 2 main "pros" for using UIKit would be native text handling (without having to create bitmaps for every character, etc.) and, yeah, just generally easier to work with since I'd have all the pre-existing UIImage functions.

I'm not against learning Open GL - I think I already have a half-way decent handle on it from watching/reading tutorials and playing around with it a little bit.

I was already kinda leaning towards the Open GL route, I just wanted to see if anyone else had any ideas/input since this would be my first iPhone game (first iPhone app of any kind except for tutorials and just messing around.)

Oh, I didn't realize you were doing a lot of text drawing. That, combined with the fact that your game is undoubtedly turn-based, means you could probably get away with using UIKit. Maybe you should just port the game first using UIKit, then if you decide it's too slow or whatever you can work on transferring it to OpenGL?

Jake, how does this compare for text that is dynamic. Is it better to render this texture and draw it each time or use a bitmap font and just render it. Lets say the text could change once every 2 seconds.

kendric Wrote:Jake, how does this compare for text that is dynamic. Is it better to render this texture and draw it each time or use a bitmap font and just render it. Lets say the text could change once every 2 seconds.

That depends on how much text (and perhaps how big) you're having to re-render. If it's just a little 64 x 256 strip of text, re-rendering it every second won't have much noticeable effect on performance. More text than that, or more often, and you'll just have to try it out to see. The Texture2D class is easy to use, so test it out!

OTOH, using bitmap fonts with a lot of characters can create a serious performance problem too. There is no free lunch with dynamic text. For text that doesn't change often though, you can't beat using Quartz in one texture (unless you need effects, of course).

My worst text usage is on dialogs but since they are dialogs with nothing else going on, framerate is moot The only text I have when action going is text that floats up after you kill an enemy that gives its name. So probably 160x16. If i see a lot of cpu usage in shark for text I may try that out.

It's quite thorough, and you may need to watch the preceding tutorials if you're new to the whole OpenGL thing.

It uses a pre-made "sprite sheet" of each character (so you can have fancy and colorful fonts) and renders each character of your text onto an individual set of triangle polygons (as opposed to creating a single texture for the entire message). I could see that being slower, but I'm unsure if there are pros to doing it that way as well.

There's nothing wrong with using bitmap fonts. The deal is that there is no one-size-fits-all approach to drawing text in OpenGL.

Bitmap font pros:
- fancy pre-rendered letters with everything you can do to them in Photoshop
- change the text frame by frame if you want since it won't affect frame rate much at all

Bitmap font cons:
- lots of characters means lots of geometry uploads and lots of calls to OpenGL, so the amount of text will greatly affect performance at some point
- will be monospace. However, kerning can be "hacked" in to some degree but is difficult to account for all cases

Rendered Quartz to texture pros:
- beautifully rendered and typeset text like you'd see normally in the OS
- render as much text as you want, and performance is pretty much only limited by fill rate, which is usually negligible for text

Rendered Quartz to texture cons:
- re-rendering the text costs a little time, so re-rendering lots of it very often can greatly affect performance. Small amounts are usually fine though.
- can't easily apply effects like you'd get from Photoshop.

So as you can see, which one to use depends on the situation. I use both quite frequently. Some games will only use bitmap fonts, some games will only use rendered Quartz text, and some will use both.

AnotherJake Wrote:Bitmap font cons:
- lots of characters means lots of geometry uploads and lots of calls to OpenGL, so the amount of text will greatly affect performance at some point
- will be monospace. However, kerning can be "hacked" in to some degree but is difficult to account for all cases

.

No, if done right it will be faster than Quartz rendering...

As far as kerning .. no problem whatsoever, you just have to know what you are doing ( which is the main downside of using freetype based rendering - you have to become familiar with low level font rendering/kerning stuff)

warmi Wrote:No, if done right it will be faster than Quartz rendering...

I don't think you understood me. If you are drawing 500 characters of bitmapped font, you'll have 500 quads vs. 1 for the equivalent Quartz rendered texture. There is simply no possible way you can tell me that drawing 500 quads is faster than drawing 1 (assuming same size of text). The difference being that the Quartz rendered texture is only rendered once, at the expense of how long it takes Quartz to render into that texture vs. the bitmapped font is already rendered and you're just putting up a texture for each character. If you don't change your Quartz texture very often, it will smoke the equivalent bitmapped font string.

warmi Wrote:As far as kerning .. no problem whatsoever, you just have to know what you are doing ( which is the main downside of using freetype based rendering - you have to become familiar with low level font rendering/kerning stuff)

As you just said to your own argument, it is not "no problem whatsoever". You have to know what kerning is, how to use it, and then include that information along with your bitmapped fonts. While it's not really hard to do, it is error-prone because kerning happens differently in different situations, so you do in fact have to know what you're doing.

Excellent! This thread addresses the exact issue I am having. I have a bitmap font system and my clients aren't satisfied with its output. I'm using their font sheet and as far as the bitmap font's system goes, it works perfectly. The system has all sorts of spacing features for between letters, words, lines, and paragraphs. It even wraps the text to specified bounds and you can insert icons in between letters.

What they don't like is the tracking and how some letters have more space between them than others. Obviously, the system needs some kind of kerning.

The question I have for you guys is, how do the professional game developers go about solving this type of problem? My guess is they'd put kerning in. I could probably do that but I need to know about kerning pairs. I did some research and it is to my understanding that there are over 4000 different pairs and that the kerning can also depend on where in the sentence that the letter occurs as well as what type of character it is.

So, is there a database out there somewhere that gives data on which letters are kerned and how much? Something that would be enough data to extract the two letters and the x offset to apply between them is what I'd need.

Like:
Letter 1: A
Letter 2: V
X offset: -2

Letter 1: O
Letter 2: D
X offset: +1

... etc.

I think all I need is a database with information regarding those kern pairs. Any suggestions where I could look for such a database?

Kerning information is different per-font, so you'll have to either specify it yourself if it's a totally custom fontset, or you'll have to extract the information from the font (i.e. the source truetype font the bitmap fontset was created from). I put together a system years ago, using kerning information I extracted from the font while using FreeType, but wasn't totally pleased with the results (heck, I can't even remember exactly what I did, it was so long ago now). I came to the conclusion that if I needed stuff rendered with kerning, I was better off just using FreeType or Quartz, because I didn't imagine a scenario where it would really matter that much with a bitmapped font, since I typically only use those for things like scores and goofy things like that which don't really require it (although I still use a cheesy spacing algorithm for scores using separators).