TiledLayer - implementation question / suggestion

[ameano]

Hi All

I was just wondering would it not have been better if Sun used a byte for each of the cells in tiled layer or even better short? I mean a short only consumes 2 bytes as opposed to the 4 bytes of an int.

Assuming you have 4 layers of 64 * 64 bytes, thats 16k worth of heap memory being used... Does TiledLayer use any form of compression?

I personally don't think there is any need for int values as noone is going to be able to fit 4 billion tiles in their game anyway...

Is is just me or does anyone else agree with this?
Perhaps we could write our own ByteTiledLayer or ShortTiledLayer implemenation...

Regards
Ameano

[Abuse]

From a performance perspective, the Sun implementation of javax.microedition.lcdui.game package is abysmal anyway.

I've seen very few games that have used it.

[ameano]

Ok, well I've been thinking about the advantages and shortfalls of the Game package... I'm new to games programming and j2me but not programming. so what your saying is that its better i write my own tile/ scene management routines?

Sprite / GameObject is one I will definitely I look into, but the inclusion of frame sequences is quite useful and makes things really easy... I suppose setClip can be used, but I have heard it causes problems...

Games published by our own members! Check 'em out!

[davidaprice]

From a performance perspective, the Sun implementation of javax.microedition.lcdui.game package is abysmal anyway.

Surely what's relevant is the performance of each phone manufacturer's implementation of the game API? Are they all equally abysmal? I've used TiledLayer myself and always been satisfied with its performance, but I'm not a commercial game developer. It seems like it ought to be possible to make a fast native implementation, and save lots of off-screen image memory at the same time (compared to the MIDP 1.0 solution of creating an offscreen background image from the tiles).

I've seen very few games that have used it.

How can you tell if they use it? I've not seen the source code of the popular J2ME games. Is it maybe just that so far, commercial games must be compatible with MIDP 1.0 to reach the widest market, so they can't use the game API at all?

Not arguing, just very curious about this...

[ameano]

or even better do you know of any better packages? Or do you code your own?

Thanks

[ameano]

also in response to davidaprice, is the performance you have gained based on an emulator only or tested on actual devices?

and how many layers do you typically have, how big and how many sprites does your game deal with?

Regards
Ameano

[davidaprice]

It's actually really easy to code your own Sprite & TiledLayer package using just the MIDP 1.0 APIs. For Sprites, have all the animation frames in one long horizontal PNG image, and draw the required frame by clipping to the size of the sprite and drawing the image offset left by the required number of frame widths. For TiledLayer, use the same trick for the PNG file of tile images, and create a big offscreen image of the background by creating a blank image and drawing the required tiles on it using the same clipping trick.

MIDP 2.0 Sprites don't really give you much. The TiledLayer potentially avoids the need for the big offscreen image, depending on how the manufacturer implements the API. You also can have transparency in the TiledLayer, which isn't possible in MIDP 2.0 since the blank offscreen image starts opaque white. If you have multiple TiledLayers scrolling at different speeds (nearer ones faster), you can get a pseudo-3D effect.

[shmoove]

Surely what's relevant is the performance of each phone manufacturer's implementation of the game API? Are they all equally abysmal?

The problem here seems to be that Sun's reference implementation is very innefficient (it draws all the tiles, even if they are not onscreen), and many manufacturers have apparently just used that implementation as their basis and didn't bother to optimize it for performance. I personally haven't used the Game API much (we are from the use as much MIDP 1.0 to reach a wider market philosiphy), but I've heard a lot of people complain about it's performance on a wide variety of phones. Hopefully the newer phones that come out will fix this issue. The Sprite object is OK, but the LayerManager classes tend to be poorly impelmented.

shmoove

[caraiz]

I had done some tests in differents mobiles, and normally TiledLayer is sooo slow, only at Motorolas seems run ok.
The problem is that in almost all mobiles fill the screen with small images is slow, and i suppose that TiledLayer is doing this.
So its better implement a backbuffer where draw the visible tiles and redraw the tiles which change when u do scroll, so u can get almost the same speed than draw a image with same size that screen.
This is, u can pass easily from 12-15 fps to 40-50 fps...

[ameano]

so its just to stick to midp 2 now?
what about gamecanvas that has a lot of useful stuff, such as querying key states??

Games published by our own members! Check 'em out!

[ameano]

ok even i didnt understand my last statement...

so isit best to stick to midp 1 for now, considering most people dont even have midp 2 phones... i have a nokia 6600 which ive had for more than 1 year, runs midp 2 but not a lot of phones do...

what about gamecanvas that has a lot of useful stuff, such as querying key states?? no?

[Abuse]

From the perspective of portability, there is very little functionality in midp2 that cannot be replicated in midp1 quite easily.

The thing you should steer well clear of, is using Graphics.drawRGB, and Image.createRGBImage.

Extensively using these can make porting to midp1 phones *alot* of work.

getKeyStates realy isn't very useful either, its functionality is easily replicable through keyPressed/keyReleased and some state flags. Also, there are a few midp2 phones that simply do not honour the contract of that method (and simply return 0).

Stick all your sound & vibration code in a seperate class, as  sound playing is the most unportable feature exposed in J2ME.