(cross-posted from Handling Framerates on J2MEForums)

I’ve recently had the opportunity to play a high-budget game of quite some fame on two phones: a Moto V550, about 800k heap, and an SE W810i, more than 2Mb heap.

The game is based on building placement. So you have a beautifully rendered isometric map screen and a cursor. Click the cursor on a spot, and the whole screen changes to a piece-selection menu that shows one building at a time as you press left and right. After you choose the building, you click the button again and it goes back to the map screen, this time with the building placed.

Bear in mind this is all 176×2** isometric, map screen and selection screen alike.

Ok. Here’s the catch — in the SE W810i everything fits on memory. So you see the map screen, you choose the piece, and you go back to the menu (almost) instantly. It gets a bit clunky because of the “maximized” selection menu with a black background — no overlay — but it works.

The peril lies in the way it’s done on the Moto V550. The pieces for the map screen barely fit the memory — which is understandable, I’ve done isometric for that Moto and it’s a lot of trouble — which means that everytime you want to select a new building the game:

1) Unloads everything;
2) Loads a single building;
3) Unloads the single building and loads the next one as you press the arrows;
4) Reloads the whole map screen (with its tiles) when you select the building.

Can you spot the problem? Every load is a createImage(). In a Moto. Yeah, right, THAT’S going to work well.

So here we have it — an absolutely unplayable game (trust me, I tried, I really wanted to play it, I love the genre) that is being sold as “Moto Vxxx compatible”. Hah. And meanwhile, since the implementation is the same, the SE version suffers with a clunky interface.

GAH. I *hate* fragmentation issues.