Jump to content
  • Advertisement
Sign in to follow this  
Mafian

Cell phone threads

This topic is 4835 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 just started coding for cell phones, and naturally ive been pouring through sample applications to get the swing of things. There have been a couple of key differences that I have noticed between the apps I have seen and my traditional programming style. For example, imagine an application that shows a bunch of black balls floating around the screen, bouncing off the screen edges. On a PC, I would make a Ball class, give it a "run" method for processing movement and bouncing, and give it a "draw" method for drawing it to screen. I would then make an array of these objects, and during the game loop, I would execute each ball's "run" method and each balls "draw" method before swapping screen buffers. It seems like on cell phones, though, developers tend to start a thread for each ball (or other finite state machine). The thread processes movement and then makes a request for a repaint clipped to its region. So if you have 20 balls, you have 20 seperate threads, each one updating a balls position and then requesting a redraw. My question is this: due to the inherent capabilities of cell phone hardware and software, is the 40-thread method better suited for higher performance? Would it be possible to go with the traditional single thread application where all objects are updated and then drawn before making a single repaint call? I find one thread and one redraw to be much easier to contemplate, and I may be wrong, but I also assume it would run more efficiently that way.

Share this post


Link to post
Share on other sites
Advertisement
Oh man, that sounds horrible. I'm not sure where you found that code, but I think it would definitely be in your best interest to keep everything single-threaded. As far as I know, there's no inherent benefit to going multi-threaded, but there are lots of reasons why not to.

In fact, it would be best if you kept a nice healthy distrust of any thread-related behavior on J2ME. I've had thread-related bugs where the only possible explaination I could come up with is that the phone was just flat-out ignoring the "synchronized" line. I was never able to conclusively prove that certain phones really do have buggy synchronization support, but I'm pretty sure of it.

Share this post


Link to post
Share on other sites
Yeah, thats what I thought. Although there hasnt been any single threaded examples in the SDK, I'll give my traditional method a shot. I didnt want to have to change anyway ;)

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!