More Progress

I've been quiet, but I've been SLOWLY making progress.  The downtime before and after phase 2 of the Starcraft 2 beta really helped me get a little done.

Recent accomplishments include:

• I got the first overworld area and the rocky overworld area completely working (the outdoor parts)
• I've successfully broken up resource loading into the separate areas, so it waits to load graphics resources for the various dungeons until they are needed.
• HUD stuff including enemy portraits is in place.
• The subscreen is mostly finished.  I've finished the inventory screen, finished the map screen (and thanks to the nice resolution of the iDevices, the subscreen map is just a tiny image of the actual screenshots for each area, which looks slick, in my opinion), added the enemy database, and still need to do the "options" screen.
• The base code for saving and loading is in place, but I haven't yet put any UI in for it.  I'm leaning towards auto-saving each time you change rooms, so if you have to quickly turn the game off, you don't lose any progress.

This is really all to easy at this point -- not interesting and challenging enough to really suck me in, which is I guess why it's going slow (plus this being the 3rd platform for the game, it's not as new to me anymore) There haven't really been any technical hurdles in awhile.  Saving and loading, which I thought might be somewhat tricky, were as simple as writing to a file.  The scrolling for the enemy database took a little bit of thought to implement, but nothing noteworthy.

So, I guess, just enjoy some new screenshots:

Subscreen

Well, now that the Starcraft 2 beta is closed (at least for a few weeks) it's time to get some more done.  I haven't done much since the last post.  Mostly it's been reworking UI bits.  I'm not a huge fan of the lack of buttons on the iphone/touch, but I guess everyone has to deal with that.   I've been working on getting some on-screen UI for health/control buttons/etc.

Tonight I finally also got the main inventory subscreen somewhat laid out, mostly similar to the gba version, but slightly different, since the font resolution is much higher.  I'll also need to add options to toggle to the map or enemy database, but that can come later.

The other thing I need to work on is the control scheme.  It will use a simple on-screen control pad, but in playing other iphone games to get ideas, I've noticed that some of them with control pads work well, and some of them are completely miserable to use.  A lot of it will be fine-tuning the hot spots, dimensions of the control areas, etc.  My friend Rob also made a suggestion that I think will really help -- if you hit the attack button, and there's nothing in front of your character, but there is something that could be hit if you had turned before attacking, it will auto-turn your character.  The part of me that likes crazy difficult games wants to fight against the idea, but I do think it would really help make up for the fact that it's REALLY hard to accurately control a character with a touch-screen control pad.  So good suggestion, Rob.  That's something I'll need to add in, maybe once I get the subscreens and menus working.

Progress

Well, progress is going a little slower than anticipated, mainly due to the fact that I finally got into the Starcraft 2 beta, so my spare time is being split between Anguna and Starcraft.  But that aside, things are going fairly well.

The framerate issue from before is trivial to fix, so that's been addressed.

Performance was more interesting.  If I render the entire background every frame like I planned on doing, things USUALLY worked fine, but would occasionally get sluggish if the device was doing stuff in the background (checking mail, getting push notifications, doing whatever else that crazy thing does).  So I decided as a workaround to prerender each background to an offscreen surface, then just blit that to the main display every frame.  Which worked fine, except that there was some sort of odd behavior in the graphics system where it wouldn't actually destroy/release memory from offscreen surfaces when I was done with them (or at least do so in a timely fashion), so after about 10 room transitions, I'd run out of memory and crash.  Of course, since it was only on the device, it took quite a while to figure out exactly what was happening.  Turns out Apple has a nifty tool called the Iphone Configuration Utility which, believe it or not, actually runs on windows!  It lets you view the device console logs in real time, which was amazingly helpful in tracking down the issue.  Fixing it was then just a matter of reusing the same offscreen surface for every room, drawing over the last one, instead of destroying and recreating them with each room transition.

I'm also running into long load times -- I'm not sure how I managed to see only 5 seconds before, but it's often taking 7-10 seconds to load the resources for the game, and that is with them being marginally broken up.  That's a bit higher than I'd like.  I think that I might be able to reduce the perceived load time by doing part of it while showing a splash screen, doing some more at the game start, etc, but I'd still like to get that a lot lower.

Overall, though, things are running well.  The first dungeon is completely working (although a lot of the UI to make it really play right is missing, such as life bar, subscreen, button for activating secondary item, etc), and the first little chunk of the overworld is mostly functional.  (the graphics for the bridge to the desert area are messed up right now).

I really need to start messing with the UI now.  Which should be a lot easier than it was on the GBA or DS, but still a good amount of work, as it's going to be completely different than the GBA UI, meaning a lot of it will have to be completely rewritten from scratch.  So that's my next task....(well, after I play some more Starcraft 2).....

Running on Hardware

I just got into the developer program, so I can finally run things on hardware!

Unfortunately, I had the same experience as last time I did the switch from purely testing on simulators/emulators to testing on hardware.  Things were working great in the simulator, I loaded it on hardware, and it just crashed and died.  It took it about 5 seconds sitting at the loading screen, then crashed back to the menu (or whatever it's called on the iphone/touch).

A couple hours of debugging turned up the same issue as last time -- I was initializing some things incorrectly, which led to some bad pointers, which somehow, out of pure luck (would that be good luck or bad luck?  I'm not sure) worked just fine in a simulator, but caused seg faults/null pointers on the real thing.

Luckily, it wasn't as hard to track down as it COULD have been, so as of today, it's running on hardware!

A couple thoughts/surprises:
1.  My framerate is too high.  The framework I'm using locked things to 30fps on the simulator, so I assumed it would do the same on the hardware.  Nope.  So I need to manage that myself.

2.  It'll also be nice to really see how the performance works.  In the simulator I was running into performance issues blitting the tiles for large backgrounds.  I found a workaround, but it'll be nice to do some experiments to see what I can get away with and what I can't.

2.  I can actually now observe how much time it spends loading.  My biggest gripe with a lot of the iphone games is the long load times -- for small portable gaming, you should be able to get into the action very quickly.  I'm at about 5 seconds right now.  That doesn't include music or sound effects, but does include loading ALL the graphics up front.  I can probably lower it a bit by breaking up the art assets and loading them as I need them.  We'll see.

If I had a camera handy, I'd take some video or at least a photo of it on hardware, cause pictures are fun.  But I don't, so you'll just have to use your imagination.

Back at it

Well, I'm back at it.  Without an artist, that means one of 3 things:

1.  Make a video game with ugly graphics (either a plain ugly game, or some game where I can cheat and use the theme in some way to my advantage to get away with some sort of ugly)

2.  Have my next programming project be a non-game (that doesn't require an artist)

3. Port Anguna to something else!

So, here I go on step 3.

I recently found a cool product called the Airplay SDK, which is a whole toolkit for doing handheld game development in C++.  Using it, depending on licensing and whatnot, you can build games for all sorts of things:  iPhone, Android, Windows Mobile,  etc.  The important part to notice was that I could make iphone games without going out and buying a Mac! (I had an old mac mini at one point, but it was too pathetic to do development on...and the iphone develepor tools required an intel mac, which this wasn't). 

So I bought an iPod touch and started porting.  Unfortunately, a week or two into my efforts, Apple changed their terms of service, which, as far as I can tell, make it really unclear whether Airplay apps will be approved for the app store.  That was a bit discouraging, but I'm hoping they will be, so I'm moving forward with the effort anyway.

So, after a few evenings and lunches of work, here's what I've got (this is a screenshot in Airplay's simulator):

At Chris (the artist)'s advice, we decided to scale all the images double, which means it will look a bit more pixelated than most games, but it exactly matches the full screen resolution of the iphone, and if we push it as a "retro" feel, may go over ok.

The porting so far is coming along fairly easily -- it's amazing how much easier it is to get graphics on the screen with a more powerful device and thus more powerful sdk.  No more messing with vram and OAM attributes.  The biggest hurdles I ran into so far are based on the differences between C and C++.

C has designated initializers (which I used all over the place, thanks to a tip from Kashiwa), but C++ doesn't...so I had to go back and manually change a lot of code from using designated initializers to just initializing an array in order. 

I also ran into a difference in how referencing external constant structs works.  In C, I did a lot of:

const struct EnemyType enemy_bat_def = {....};

and in a different file:

extern const struct EnemyType enemy_bat_def;

and then referring to it in that file. 

Well, for some reason something is different in C++, and this doesn't work.  I'm guessing it has to do with the differences in C++ about how const is handled, or more likely, how structs are actually just classes without functions, but my knowledge of the gritty details of C++ is embarassingly lacking.  So I just changed how I did it. (now in the 2nd file, I'm referring to a pointer to the struct instead of the struct itself).

Other than that, it's been incredibly straightforward -- the bulk of the codebase just worked.  I'm still having to muck with how palettes are handled a little bit  (my animation definitions indicated which base image to use for an animation, so a set of palette-swapped enemies just all used the same animation definitions.  I can still do this, but the SDK handles palettes a bit differently, so it's a few changes).

I haven't yet applied for my iphone developer's license, so I've been running everything in a simulator so far, so the next step is going to be to get that and actually run this on the hardware, and see what breaks.  (or what the performance is like).

Then, it will be time to work on the UI -- the UI, menus, and controls will need a complete overhaul, so that will likely be the biggest portion of the work involved in this port.

So there you have it.  Let's see how quickly I can get this thing done.