Amount of PNG's generated

Hey, just got my Dev today and i've been playing around with the mobile exporter, its great!

Anyway, i'm having some problem with framerates when the game scrolls. I opened up the .jar in winrar and noticed there were A LOT of png files in the directory...which i'm assuming relate to the current graphics in the game.

I have some screenshots below.
http://www.rhysd.com/mobile/screen3.png

As you can see, there are really only 16 or so separate tiles that make up the level (the others are repeated - see image below)

http://www.rhysd.com/mobile/screen1.png

Is it at all possible to code the exporter so it looks for objects with the same "object name" in the frame editor and only export one image for them, instead of all separately? I'm not sure how it's doing it at the moment and whether the 99 png files in the jar are all being used as i'm no tech wizz. Below is a screen of the 99 pngs in the jar.

http://www.rhysd.com/mobile/screen2.png

You can test the game here

http://www.rhysd.com/mobile/milber.rar

Controls:

left and right - 4 , 5
jump - 9
use item - 2
quit - *
restart level if dead - *

and here is the source for Francois or Yves

http://www.rhysd.com/mobile/milberMFA.rar

I can confirm that more people are having problems with scrolling in Java Mobile Applications. The scrolling is simply to slow to function.
So far the reports I've been getting are from devices under 200x200 screen size. It would be nice to hear from someone on 240x320 (Nseries or so.) Do anyone else have laggy scrolling apps?

Can this be optimized somehow? As you can see in RhysD's example it happens in even the smallest of games.

I can confirm that scrolling is laggy with 240x320 displays as well!
Sometimes when you scroll parts of active objects gets stuck in the background, as if it was not redrawn properly...

Scrolling looks great in mi Rock Z6... it runs at 50fps constantly, useing a 640x480 frame and a single active bouncing inside the frame with a quick backdrop in the back...

Scrolling on a mobile phone, with such a low processor, I think you should forget about it.
About the number of images. Of course, duplicated images are not duplicated in the Jar. If two objects use the same images, they are only saved once. In your app, all the images are different, and there are 99 of them. That's all.

Thanks for the conformation Francois :) So I take it holding ctrl and dragging a tile duplicates it... >_>

I still can't see how there can be 99 images in my current mfa...any help would be appreciated

edit: are pngs separate for each frame of animation?

Yes

ok, thanks for the info...and sorry for so many questions! :D

I can confirm that simple scrolling on my N93, N95 and N82 is working smoothly. Obviously the more objects in play the less so, but a simple double height screen scrolled to give the effect of a static image bouncing down from the top (using a few backdrops only) as I've put in my game is working beautifully on my phones :)

Scrolling isn't the fastest for me, but it's certainly well playable - I'm running a 240x320 app on a Nokia 6500

What about to use some algorithms like comparation of equal images, flip them instead of repeat an oposite direction, and other image tricks to optimize and reduce the amount of png generated..?

Quote:

---

Scrolling isn't the fastest for me, but it's certainly well playable - I'm running a 240x320 app on a Nokia 6500

---

My games runs at 250/300 fps :) useing 500 frame rate and machine-independent speed in my 240x320 Motorola Rockr Z6 - at 532Mhz -

It is much faster to keep two images than to flip them on the run. Image rotation is very poor on mobiles.

Hi Francois,

actually, Locaz00 is on the right track. I've been an artist in the mobile industry for years and one of the most important techniques used by ALL of the good mobile developers is to only include the art for one direction and to have the software generate the necessary alternate directions. This is for Brew or Java... even the weakest of phones. The trick is that the images are not flipped durring gameplay (actuallt also 90 digree rotations are also supported), the flipping and rotating is processed at load time for a game or level. This keeps the filesize nice and small at the cost of increased load time.

This is a feature critical for MMF2 users to come close to professional games as far as amount of art conent in a game on any given phone.

I had actually requested a long time ago this feature: when the user creates a new active and loads in the art, there should be checkboxes for the following:

1) create Hflipped animations at load time
2) create Hflipped animations at runtime (on the fly.. for fast devices)
3) Create rotated directions at load time
4) Create rotated directions at runtime (for fast devices)

That's exactly what i meant! Thanks Holymonkey ^^...
Most games have a Load time for loading a screen, it could be a great idea to be able to pre-load all necesary files executing actions like HolyMonkey said in a post-loading screen :)

There are a lot of features that can be applied to Java Mobile based games, for sure...

These features would be useful for reducing "bloat" for any platform. And theres no reason to not have a runtime flip or rotate feature for faster phones and pc's as well. If a "loading feature" is not feasible, then simply having this process begin (at start of frame) would be fine... allowing for the creation of a progress bar related to that process would be ideal.