Okay, it’s that time of the cycle to take on the lifting that is known as “Universal”. I’m talking, of course, about taking Joe Monkey from iPad-only form factor to both iPad and iPhone.
A little background here
I developed Joe to be “high-def” from the drop. That was one of my main interests, to have an iPad game that looked great and felt comfortable in your lap. While the iPad does not (yet) have a “retina” display, it’s stil high def compared to the 320 pixel resolutions of the earlier phones.
I was acutely aware of eventually having to reformat for different resolutions, and this understanding was one of the major reasons I decided on an entirely vector-based illustration model. That will help here.
My original designs
Well, I thought I was being smart by writing first for the iPad then down-grading to the iPhone (4). I figured that the resolutions were close enough that there would be minimal changes when I took on the phone platforms. I assumed the pain would be in taking on the non-Retinal types of displays. But a Retinal display was close in resolution that I figured it would be simple minor adjustments. Not true.
The point system in iOS for the phones is based on the first reference design (the first iPhone). Thus there are still 480 points across the screen if on the iPhone (even on an iPhone 4+). That is compared to the 1024 points (and pixels) across the iPad. So, even though the Retinal display has 960 pixels across, Cocos2d and iOS deal with the screen in points. And those points dimensions are 480×300. Thus if something was put on the iPad screen at 500×100, then running it on the phones (any), that same object would be off the screen.
Because of this design (iPad first, then iPhone work) I am forced to go through the code and find all the places I reference positions and distances. In those spots I will be fitting a bit of plumbing that will make the “positions” relative to their resolution. It should be more an exercise in mundanity than engineering. But that’s just what I understand at this point. We will have to see if that’s how this actually turns out.
Okay, my first snafu. I found the answer but it did take a bit of time, and I thought I’d outline it here. Basically, there are a few places I’m talking directly to OpenGL about positions and sizes. It’s very important to remember that OpenGL is in true pixels. Everything else is a layer of abstraction over that. So iOS and Cocos2d with their handling of “retinal” coordinates, etc… Those are in points so you don’t have to muck with the math all the time. but when you talk to OpenGL you’re back to core pixels. That’s not all that surprising, but abstractions have a nasty habit of making one forget.
Update #2 (TMX-hd)
TMX files are the underlying files that manage the maps of Joe Monkey. They are somewhat standard files that offer “tile maps” to game engines.
Since I first wrote JM for the iPad the TMX maps are all simple 128×128 tile maps. I also do a large amount of management of these tiles and maps in my own engine. I don’t rely on the tile map as it is presented dues to the fact that I have to move things and destroy things quite a bit. That said, I have discovered that I will have to edit all of my tile maps (duplicate them) to include both standard and high-def versions.
At this point it appears what I will have to do is duplicate all of my current maps and change their tile sizes and margins.
A, er, side-effect of this change is that I will have to dive into my engine and find all the places I was being lazy by using that “128” as a constant. The development of JM as been at that scale since the beginning, so I am sure I came to assume that it would be 128 forever.
Bad Programmer. Bad.