Hey (getting started with J2ME)

[kallin]

Hey Hooble !

You said to come by your site and say hi, so here I am! I really appreciate the advice you've given me regarding j2me development.

If you know of any really good sites for tutorials, tools, etc, I'd really appreciate it! I guess my biggest concern right now is figuring out how to effectively test against the different types of phones (emulation?), what is an acceptable file size, all that good stuff.

[Adam Schmelzle]

The best way to make sure your game runs on as many phones as possible is to target Midp1.0/CLDC1.0 , and don't use any optional packages(JSR's).

The next thing to worry about is .jar size. You are fairly safe with anything under 75KB, but it you want to add the advertising code, that will tack on about 25KB or so, so I guess you need to aim for 50KB. The only devices that won't let you install games over 75KB are the low end ones anyway, so you may not have to worry about that. Next in line is 140KB, which isn't hard to keep under.

Runtime memory differs greatly from device to device, but you can count on 400KB minimum for low end devices and 700KB+ for the rest.

Make sure your application can display at any resolution, so either make a different build for each of the common screen sizes, or have it dynamically adjust. My games all dynamically adjust, since it's annoying having to create different builds. The most common resolutions are....

128x96, 176x208(**most devices**), 240x320

Of course there are thousands of different devices, and many with resolutions that fall in between those. Some phones are picky and will throw an Exception if you try to load/create an image with width or height dimensions larger than the physical screen resolution.

The best site I know of for checking device specs is jbenchmark.com .

Here's the essentials for starting with J2ME development...

• Sun Wireless Toolkit (WTK) : java.sun.com/products/sjwtoolkit/download.html
  
• Eclipse : eclipse.org, or your favorite IDE
  
• EclipseME plugin : eclipseme.org
  
• Proguard Obfuscator: proguard.sourceforge.net/
  

The Sun toolkit includes an emulator with several different skins for testing on varying screen sizes. If you want to test behavior for specific devices, most manufacturers have freely available emulators or device plugins for the WTK.

To get the applications/games on to a device, you'll need to have a device that supports one of: a)copying to a memory card,b) copy across a data cable, or c) use a web server to download using the device's online web browser. I personally just point a dyndns.org dynamic DNS account at my dev machine and run a small web server to serve a web page for installing to my devices.

The main benefit of the Proguard obfuscater is that it will dramatically reduce your .jar file size, and can be integrated into the IDE using the EclipseME plugin.

I don't really know of any specific sites for tutorials, all I remember doing is the usual Sun tutorials and google searching when I was starting out. I can probably answer any questions anyone has about making this stuff work, as I figured it all out on my own and have likely stumbled on every possible speedbump already.

[kallin]

Cool thanks for all the tips I look forward to the road ahead..

I'm used to using intellij IDEA which has a j2me plugin built in, and I've managed to get hello world up and running on an emulator in very little time. I'm sure I can integrate the obfuscater somehow...

When you're releasing a game to be published, what's your qa process like? My biggest concern right now is releasing something, and then hearing back that it doesn't work on 80% of the phones, or is choppy on a bunch, etc. etc... There are way too many phones out there to test for... Does gamejump QA your stuff for you?

I also noticed on gamejump that you choose the game you want after you select your phone. This leads me to believe that somewhere along the line there's a filtering process going on, identifying which phones a given game will work on.

Finally, I'm setup with the 'Sun Java(TM) Wireless Toolkit 2.5.2 for CLDC'. Is that the jdk you recommend?

Thanks!
Kal.

[Adam Schmelzle]

Yeah, the latest WTK is what you want...

Releasing: My QA process is simply playing the game and testing all features on the phones that I have available. I currently have 8 phones, which covers from the low end to the high end, and most of the popular manufacturers.

To make sure your performance it up to par, you need to test on the slowest phone you expect to run on. Most of the pay as you go, and free phones are quite crappy. If you can make the game playable on a phone that scores around 1000 in the Jbenchmark 1.0 test, then you are golden, 'cause nobody plays games on phones that are that slow. My first phone was a Solo-mobile Sanyo SCP-2300. It was perfect because it had free mobile internet, and only cost $100. I made the initial version of my first game '3D Attack Chopper' using ONLY that phone for testing. It turned out to be compatible with just about every device on the planet.

When you upload an application/game to greystripe.com, their system checks requirements like the Midp version, and the optional JSR's that are required to run. If it spots something that will stop the application from running/starting, then it won't allow you to map that game build to that specific phone. Back before the fall of 2007, greystripe had a MUCH better system for determining compatibility, where you chose the limiting factors like Midp version, screen size, manufacturer, and JSR's, and the system would auto-map the compatibility. Apparently most publishers/developers didn't use this system correctly, so now they make you select the compatibly phones from a list of over 1000, with NO info available. I hate the new system, and have expressed my views to them. They are apparently working on a way to allow some publishers access to the old way of doing things again....

So I've probably confused you here. This is the exact process to submit a game:

1) Chose 'new application'
2) Fill in description, name etc.
3) Supply the images that the website uses to display the game: thumb, feature, screenshots etc.
4) Upload your .jad/.jar files
5) Chose which devices are compatible with each build you uploaded. This is the annoying part, where you look through a huge list of devices and pick/chose.
6) The devices that you selected are auto-verified for the technical requirements(Midp version, JSR's, .jar size)
7) The devices that passed the auto-check will be 'test wrapped' with some temporary ad code, so you can see how it will work.
8) you chose to release the game when you're satisfied with what you've got in the system.
9) The guys are greystripe look everything over, and if the images/descriptions are all there, and the game seems to run, they release it on the gamejump.com website, and it's catalog partner sites. This can take a couple weeks depending on the load of new games, and the time of the month. They release new games 2 times a month I think.

At this point, your game shows up in the 'new' category, as well as the other categories that you chose when filling out the game info. The game will automatically work it's way up/down the ranks in the webpage based on some combination of how often the game is played, and how much it's downloaded. This is the best part, as you don't need to promote your game at all, since it'll move on up as long as it's a good game. My games are consistantly on the first, second and third pages in their respective categories, and some of them have been out over a year.

Gamejump doesn't really do much QA on your games. I think they run it on a few devices that you chose as compatible, just to make sure it'll run, but they won't send bug reports or reject your game if they don't like it. There are guidlines of course, like everything must be PG-13, and a few minor obvious things.

I've never had any formal training, but my process seems to work. My games are consistantly some of (if not the most)the most compatible in greystripe's catalog. I read a lot about compatibility being a problem for J2ME developers, but as long as you stay away from most of the manufacturer specific libraries you will be fine. I usually make 4 different builds of my games:

1) Midp1.0 generic : runs on all devices
2) Midp2.0 generic: runs on all Midp2.0 devices. This is needed for games that have sound and/or network Socket support.
3) Nokia Midp1.0 : I make a separate build for Nokia phones, because they organize the 'softkeys' differently than most other devices. They still work with generic code, but if you use their libraries, you can draw your own softkeys.
4) Nokia Midp2.0 : Same reasons as #2 + #3 combined.

With these 4 builds, I can cover just about any phone on the planet. Any problems I have with compatibility are usually from a phone being too slow, or not having enough heap space. That'll simply depend on the specific game design though.

I hope this helps, keep the questions coming!

[kallin]

I've been ordering whatever books I can find on J2ME to gain some perspective on the whole scene.

The book I'm really getting into is 'j2me game programming', by martin wells. It's a little dated, from 2004, but as you said not much has changed on the j2me front.

I wonder though, what are the numbers like for % phones in use with MIDP 1.0 vs 2.0?

You say you make a separate build for 1.0 vs. 2.0 phones. Do you have any idea how often the different builds are downloaded? It seems to me that 1.0 is extremely limited, and would be difficult to port something down from 2.0. There aren't even transparent images on 1.0!

I'm debating whether or not it's worth it to build 1.0 compatible games. What do you think?

[Adam Schmelzle]

www.mobref.com/statistics/world/gJavaMIDPVer

Midp2.0 is a much bigger audience. Deciding on a Midp version really depends on your target audience, technical requirements, and how important it is that you reach 'everyone'.

For example, since there are not many Midp1.0 devices, most games are not actually Midp1.0 compatible. This means that making a Midp1.0 game gets you access to all those people with Midp1.0 devices and no games to play. Some of my games aren't Midp1.0 compatible though, since you can't do much with sound/networking in Midp1.0.

The only important differences between Midp1.0 are the lack of sockets and sound support in Midp1.0. This isn't as big a deal as you may think. In mobile games, the sound is not all that important and often gets turned off. Also, unless you are doing a real-time multiplayer game, Socket support isn't very important either. The Midp2.0 libraries have a few extra classes in the standard library, but you'll find that they aren't super useful anyway.

All that said, there's absolutely no problem with making a Midp2.0 only game. What aspects do you expect to have trouble with in Midp1.0?

[kallin]

To be honest, I don't even plan on implementing any sound at this point. I'd bet most people turn it off anyways if they're in a public place (and if not, why are you playing games on your cell phone? ).
The only networking I plan on right now is maybe a high score board, which is possible with 1.0.

The biggest problem with 1.0 for me is the lower specs on minimum jar size, heap size, as well as graphics limitations like transparent images.

The only cell phone I have is a couple years old now and it has 2.0. With most people getting new phones with long contracts, I expect almost everyone to have 2.0 phones anyways...

[Adam Schmelzle]

Midp1.0 doesn't really impose any limitations on jar size or heap size, and 99% of Midp1.0 phones will load and display transparent images. It's true that most Midp1.0 phones have limited jar sizes, but that's not because they are following Midp1.0 specs, it's just 'cause they are low-end phones. Midp1.0 doesn't restrict the capabilities of the phone, it simply specifies what classes you have access to.

All you have to do to make a game Midp1.0 compatible is not use the library features of Midp2.0.

I say just make the game with the compiler set to 'Midp1.0' and until you need to use a Midp2.0 feature you don't even need to think about it. The only reason I have for making a game incompatible with Midp1.0 is because I can't generate transparent images at runtime with Midp1.0. Most games don't require you to create transparent images using code during runtime, so that hasn't been an issue for the most part.

[kallin]

Oh Awesome, I thought you couldn't even load/display transparent images in 1.0, which would have been a really problem.

I'll do as you suggest and stick to the 1.0 libraries for now. Thanks for the tip!

[Adam Schmelzle]

No problem, have fun!

[chrisl]

Hi Adam,

Maybe you can clarify a potential compatibility issue: is it OK to use GIF images in a game, if I want to maximize compatibility with as many handsets as possible? (using MIDP 1.0 for a start, as you suggested)
GIF is used in many J2ME tutorials and books, so I thought it was OK. Moreover, the graphics I intend to use compress a lot better in GIF compared to PNG (small size and reduced palette).
BUT I just read that GIF was not officially part of MIDP specs until MIDP 3 (http://www.ddj.com/mobile/184406435;jsessionid=BEFZBKOMUTVQUQSNDLPSKHSCJUNN2JVN?_requestid=5133)
and thus may not work with many phones.
(see also this article: developers.sun.com/jsp_utils/PrintPage.jsp?url=http%3A%2F%2Fdevelopers.sun.com%2Fmobility%2Fmidp%2Farticles%2Fguiapis%2F)
Would you also advice against using the GIF format, staying with PNG instead?
Thanks!

[Adam Schmelzle]

I 100% advise against using .gif files in game. Midp3.0 doesn't really exist yet, so it actually surprises me a lot that ANY tutorial would use .gif files. As stated .png files are guaranteed to be supported, and this is one of the few guarantees that I can make with regards to compatibility. Also, on some of my own phones .gif files are not supported, and I only have 6 or 7. If .gif isn't supportd on some of my phones, I guarantee that it's not supported on a whole pile of others.

Many people throw their images together into a strip, to share the palette and save space/achieve better compression. Also look into using a tool called pngCrush, which will brute-force search for the best compression method to use on your png files, as well as optimize the palette. It can help significant;y.

[chrisl]

Thanks for the quick answer!
I was afraid you would answer just that... Well, that's how it is then. I just wonder why so many reknown references (such as the "Java ME Game Programming" book) don't mention this caveat, there already are enough less obvious traps for us newbies...
Today I tried PngCrush and OptiPNG: indeed they do save some memory (about 10 to 20% for my sample images, more efficient on small palette files, slight advantage in favor of OptiPNG), but the results still pale compared to the Gif size.
Anyway, I'll rather have a bigger foot print if it guarantees compatibility, so I'll follow your advice and try to group images.
Thanks again and good luck with your Tower Defense design: I'm impatient to see you give the mobile treatment to this addictive but rather interface-heavy game genre!

[Adam Schmelzle]

Thanks for the encouragement, and good luck with making your first mobile game. I just got back into the swing of things a couple days ago, and have made significant progress. I hope to have something to show soon...

[chrisl]

I was searching for device skins/plug-ins (for the WTK) from manufacturers, but all I found were big integrated tool suites (from Sony-Ericsson, Motorola, ...). Is it really worth to invest time in these dedicated tools, if all I want is to check compatibility?
I was naively hoping to just find simple plug-ins to complete the list in the Default Device Selection tool, but it doesn't look to be that simple, and I'm not sure I want to clutter my PC with lots of intricated tools. Are you using them? Any one in particular?

[chrisl]

ProGuard obfuscation:

I have a doubt regarding my usage or configuration of Proguard for Eclipse ME:
- At first it seems to work well as I obtain a jar file which looks correctly obfuscated and runs fine on my phone.
- But in the same "deployed" output directory, I obtain at the same time a second jar file ("MyGame_obf.jar"), which is slightly smaller (36k instead of 38k). I can't use it as there is no corresponding .jad file. What is this file? Is it a temporary one that I can safely ignore? Or is it actually the one I need, but then why isn't there a corresponding .jad file?

(Note: when I check both jar files in the notepad, they don't look obviously different, except for the size.)

P.S. Maybe this is not the best place to post this?

[Adam Schmelzle]

The _obf.jar file should be just a temp file, and can be ignored. I don't get the temp file staying around. Is the obfuscated .jar significantly smaller than a non obfuscated one? I've had issues when using the newer builds of Eclipse, specifically the versions after they started calling it 'Europa'. I currently use an older version of eclipse. Maybe I'll check out the newest build and see if my problems are resolved, but I was dissapointed the last few times I gave it a whirl. When I was using the 'Europa' versions of eclipse, I could only build the mobile project once, after which a file was in memory by the system and un-deletable, forcing me to re-start eclipse to build again.

For the most part the manufacturer specific SDK's are useless. If you plan to use some of the manufacturer specific libraries, than it can be good idea to test with them, but I find using a phone to be less hassle. I was hoping they would integrate as well, but just as with the actual devices, none of the manufacturers follow all the standards properly.

[chrisl]

Yes the obfuscated .jar is greatly compressed (38kb instead of 60), so I guess I shouldn't worry about the _obf.jar one.
Here are my options for ProGuard:
-dontusemixedcaseclassnames -dontnote -defaultpackage ''
My Eclipse version is 3.3.2 and it works well so far (but I've not digged very far into the options and features).

Thanks also for your feedback regarding the manufacturer SDK's, I'll do without them then.

[Adam Schmelzle]

np.

[chrisl]

Hi!
I've been a bit slow to realise what exactly was implied by your previous comment a while back: "I can't generate transparent images at runtime with Midp1.0."
I started coding a simple sprite bank system (all sprites put on a single png with transparency - for compact file size - then split into individual images after loading), but of course that failed because I'm losing the transparency information when using Graphics.drawImage (my original sprites actually become opaque images, with white color replacing transparency).
Isn't there any solution for this with MIDP1?
Could there be a solution linked to the "Image Transparency issue" topic found elsewhere on your site?
As a backup, I do have a working solution (for each and every sprite, I just draw the full sprites bank image against the background clipped to the desired sprite size with Graphics.setClip).
It works, but not only do I find it really inelegant, I'm also concerned about potential performance issues (clipping before each drawing).
It performs fine on my only test phone though (a Sony-Ericsson W200, a rather low-end handset by today's standard, but not very old: no idea how it compares to older phones which may still be used by some GameJump customers.)
What would you recommend?

[chrisl]

Another not-related question: you mentioned this earlier in this post:
"Some phones are picky and will throw an Exception if you try to load/create an image with width or height dimensions larger than the physical screen resolution."
I currently create my background by resizing a loaded image (I chose a medium-hi res: 176x220) to the actual physical screen resolution (say 128x128 on my test phone). It seemed to work nicely, but should I worry about compatibility issues?

[Adam Schmelzle]

Re: Transparency in Midp1: No way around it. You simply can't create images with transparency at runtime in Midp1.

Re: Performance of clipping the entire image: Yes, you probably will need to worry about the performance on lower end devices. The SE-w200 is actually quite a powerful device in Midp1 still. Check out jbenchmark.com for a comparison, as I find those benchmark fairly good for comparing relative performance in Midp1 (jbenchmark 1.0 score). Lots of new devices still suck at games.

Re image size being larger than screen: Unfortunately, you likely do need to worry about it. Pick a minimum screen size that you will support, and then use that as the max size for images. Of course many devices won't care much about the images being slightly larger than the screen, but plenty probably will still have a fit. Think of it like the max texture size in PC video cards, there's always a limit. Since there's a limit, the natural limit from a hardware standpoint will be the physical screen size, or marginally bigger.

Also, people don't upgrade their phones as often as you or I would, they'll keep that clunker until the battery dies.

[chrisl]

Don't you ever have good news for me?

The JBenchmark site indeed provides striking results: take 2 rather budget Nokia phones: one released recently, the Nokia 5000, gets an appalling score of 715 at JBenchmark1, while a slightly older one (available here for roughly the same price) scores 4806.
Worse, the recent Nokia 5000 has a state-of-the-art QVGA screen, which is worrying considering its low fill rate, compared to older phones which only had low-res screens to draw to.
(It's also disapointing to see Nokia neglecting the gaming aspect of this phone, considering the youth-oriented styling. Anyway... I need to buy one of these poor-performing Nokia for testing purposes. I guess it will be time for heavy optimization then!)

Re image size: I've adapted my graphics, but of course that goes against jar size optimization, since the original goal was to group sprites in bigger screens.

By the way, I got good results with another png tool: PNGOut. I'm currently using the very convenient trial version of the Photoshop plug-in, but there is also a free command line version, which is probably just as efficient.

[Adam Schmelzle]

Cool, next time I'm using a lot of graphics I'll check out PNGOut as well.

[chrisl]

I'm wondering if you previously encountered issues with auto double-buffering in MIDP1?
I was using a basic gameloop seen in countless MIDP samples and tutorials: it worked fine on the emulator and one of my phones, but flickered horibly on another.
Running out of ideas about this issue, I tried something apparently silly and... it worked.
So either I was lucky this time and this change might bomb on me later on (on another phone) OR maybe I don't understand the behaviour of the functions involved.

My game loop was just something like this:

- [update game state]
- repaint();
- serviceRepaints();

this called paint(Graphics) which did the various drawing on the graphic context passed by the system. This code produced flickering on one phone.

And the unexpected solution was to remove the call to serviceRepaints(), though I thought it *should* be necessary to force the painting.

How is it really supposed to work?
Shoud I expect trouble at some point if I don't use the serviceRepaints() method?
Maybe I'm being paranoid, but I don't like "working" code which I obtained by luck and don't understand...

[Adam Schmelzle]

Yes, you are supposed to call serviceRepaints. Without it, you are not going to get a call to paint() on a regular basis. Although WITH serviceRepaints you will get at LEAST one call to paint() for each game update.

It's pretty stupid really. You either get too many, or not enough screen refreshes. I get around this problem entirely by calling my own draw() function immediately after my update(). In my draw function I draw the current game state to an off-screen buffer.

In my paint() function all I ever do is draw my off-screen buffer to the device. One line of code, and since it's a single image operation there is no flicker. Also with this software based double buffering, I can redraw only the parts of the screen I know have changed(to my off screen buffer), since I can be 100% sure of the contents of my buffer.

I experienced the exact same problem that you described when I started working on Attack Chopper 1, and tested it on a few devices. I'll never even consider using hardware double-buffering on a Java device ever again. Software all the way!

[chrisl]

The funny thing is that I had disconnected hardware double buffering until now and it worked fine but slowly (I've been lazy and basically redraw everything all the time).
So I was in the design phase of a partial screen update, when I realised I had not rewired the hardware double buffering: after doing so, as described in my previous post, the result is a much more acceptable framerate on my slow test phone (a full-featured LG KE970 "Shine" with QVGA res... but appalling JBenchmark1 performance: 1332!).
Considering your own experience, I guess I have to get back to the previous step though, and get to work on optimization!

[Adam Schmelzle]

Yeah, things can really slow down if you need to redraw the entire screen every frame. I find that the large screen phones often suffer in jbenchmark1 performance, and that's 'cause the jbenchmark1 test depends a lot on fill-rate. However the fill rate of the larger screen phones doesn't seem to be proportionately higher, and ofter gives a worse score than you'd think.

Think of jbenchmark1 as the benchmark for poorly optimized draw code.

[chrisl]

MONOSPACE font?

Small question today: is it to be expected that, on some (most?) phones, the settings below always return the same font when using font.getFont?
font.FACE_SYSTEM
Font.FACE_MONOSPACE
Font.FACE_PROPORTIONAL

I'm trying to get a monospace font for easier page layout on some screens, but that only works with the emulator and none of my phones! Is there a trick somewhere?

[Adam Schmelzle]

Don't 'cha just LOVE J2ME? I don't believe there are any guarantees with respect to font support. I always just use the default font, and attempt to specify a smaller size. Then I iterate through all of my strings, and record the results for future use. My text drawing routine always returns the width of the text, so that it's easy to incorporate.