Jump to content
  • Advertisement
Sign in to follow this  
Ilankt

Guide lines to cell phone programminig?

This topic is 4826 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm a C++ Programmer that want to program games for cell phones. I have no idea where to start, I have no experience in programming to cell phones... BTW, I'm aiming for the Motorola cell phones (I have Motorola E398). Any tip/aiming/link will be great. Thanks.

Share this post


Link to post
Share on other sites
Advertisement
Remember that each cell phone is different. Just because it works fine on one cell phone does not guarntee it will work on another. There are alot of phone specific problems such as Sprint that have their own APIs for their phones. Make sure you have a strong programming background in Java (preferably J2ME) because that is what most cell phones support. If you want to use C\C++ through BREW you can create games for the computer using dlls, however you will not be able to port them onto the phone because BREW compilers cost alot of money.

~guyaton

Share this post


Link to post
Share on other sites
Test on the real device.
Phone emulators are mostly more like simulators simply 'reimplementing' MIDP on the PC. The results often are quite different from what you get on the actual device.
Example: I once implemented a nice rendering optimization on a SonyEriccsson K700 emu just to find out after two days of work that it actually cost me performance on the real device.

Share this post


Link to post
Share on other sites
First, already stated above, emulator != hardware.

Second, EMULATOR != HARDWARE. Just to make that really clear. ;)

Third, every cell phone is a different cell phone. They can be VERY different, or LITTLE different, but they are ALWAYS different. Don't assume that since some 2 models have the same screen resolution, memory, firmware, installed libraries, etc that your code will run on both the same way. Always test on all devices - don't assume anything.

Fourth, the major development problem in mobile phones i've seen is almost always lack of memory. Even if your emulator says you have plenty of memory left but the thing crashes on the phone, just make your program print the available memory on the phone on each frame. It's probably reaching zero somewhere.

Fifth, always garbage collect, calling System.gc(). Emulators usually do that by themselves, but the phones won't do that, leading to the problem stated above.

Sixth, sometimes your app crashes but it's not your fault. Almost every single phone I have worked with has a firmware bug somewhere. Sometimes they crash because a PNG has some specific number of colors, like 7 or 15 (yeah, I know); sometimes it's because you render a string too long (this was my latest problem - some phones crash if you render a string with more than 200 characters, even if you're clipping it); and some other stupid things.

Finally, google a lot. If you're having a specific problem with anything there is a big chance someone already had the same problem. I've discovered lots of problems and learned workarounds just by googling and reading some forums. You can also find out what functions you should avoid calling because they are too slow and some other tips here and there.


Hope this helps and welcome aboard (if you didn't quit already [lol]).

Share this post


Link to post
Share on other sites
hehe Blew is right on the money.
Like to add a little:

* Testing: while testing make sure you do anything possible to screw with the device.
F.i.
6600 has a memory leak when it should dispose forms, leading to the device crashing.
7650 stores images in native heap, which you have no control of and nulling it will NOT free up memory.
S65 is one of the few devices that uses pauseapp and startapp, as hide and show notifies are handled very ... interrestingly.

* garbage collect:
yes, do it often!
Though some devices might need 'rest period' during it.

*app crashes:
Yup. My favorite is .setGain on the 7650. It would be ok if it did not do anything but the sucker crashes on ya.

On problem we had, and only came up once, was a 'monty thread exception' on a 6600. Something with threading. Unfortunetly we were not able to remove the problem.

* preverifier:
this sucker can also get you. Often is is just the wrong file in the jar somewhere but I also had it that it did not like 'int i = 0;'.

* info:
Like Blew said there is enough out there. KVM-INTEREST at JAVA.SUN.COM mailing list also has a lot of good info.

Share this post


Link to post
Share on other sites
Heh, maybe this thread should go sticky, or someone should make a faq with the issues described here.

I know it would have helped me a lot. :)

Share this post


Link to post
Share on other sites
from a profesional experience, online games are bad. VERY bad. some phones will crash if certain .class files are t0o large, however when trying to do some multiplayer stuff with class sizes too large, they will just tell u that it cannot connect to the internet. no reasons, no excuses. nothing. Some phones have weird loading times if certain files get too large (resource files, class files etc) so beware of that. at my company we keep an internal server with all the problems with all the different types of phones. as you find them make sure you document them.


~guyaton

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!