Archived

This topic is now archived and is closed to further replies.

Motorola T720 solutions

This topic is 5095 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

The T720 is a strange beast, and some of you may have read my post about not being able to rely on even very simply code (ie: j = 0). After much work I''ve narrowed down the problem (a bit). The T720''s memory seems to get temporarily corrupted. By temporary I mean that memory can get turned to mush and then magically fix itself at some future time. To verify this try allocating a really large buffer (like an image, buf store it as an array of ints), display the buffer somehow, and then interrupt your app using the volume key on the side of the phone. When you return to your app you might be surprised at what is being displayed. For some types of bufferes this is not such a big deal (I can''t belive I said that) but for any flags that or state variables your using this can be catastrophic. Here are the steps I''ve taken to minimize the effect of the T720''s bad attitude. 1. Avoid static varaibles. Thats right: static int j seems to be less reliable than int j. 2. Anywhere you need to set a global variable, make sure your code is structured so that you can reset it again before it''s actually used. ie: static int myState; void mainloop() { myState = 6000; . . . stateHandler(); } void stateHandler() { if ( myState != 0 || myState != 1) myState = 0; } So what we''ve done is just made sure any ''default'' state changes are affected when we need them, thus avoiding the T720''s poor short-term memory. As ugly as this phone appears to the developer, it is attractive to the consumer. If you''re writing you apps for a variety of platforms I would suggest targeting this phone as well. Cheers, Will

Share this post


Link to post
Share on other sites
Sounds like your data is just being moved around or thrown away.

Many DirectX developers used to get caught out by a similar issue where texture data would get thrown away if someone ALT+TABbed out of the game. Windows would fill the graphics card up with its own data to draw the desktop and windows, destroying the game''s data. When the game was brought back up, it would draw crap to the screen. Newbies called this a "bug"; in fact, it''s a necessary fact of life.

If the T720 does something similar, there will be an event you can check that lets your app know that it''s been interrupted. When you get this, you suspend operations and wait until the app is given the screen back. When that happens, you''ll need to reload the data. It''s strange that it affects variables too though. It could just be that your phone is fucked.

--
Sean Timarco Baggaley

Share this post


Link to post
Share on other sites
Hey, we develop on the T720 with none of the problems you describe. I think the problem is that you are using globals & statics. I''m not positive, but I believe that you are not supposed to use globals or statics at all in BREW. At any rate, we don''t use them, and we don''t get the problems you describe.

And hey, if you want to talk about phones that are ugly for the dev but attractive for the consumer, have you seen the Nokia 3589?

Share this post


Link to post
Share on other sites
pinacolada: I''m using J2ME, not BREW. If I were using C I wouldn''t use classes. lol. As it stands I have to do a lot of trickery to get a decent frame rate out of the slower phones-- this includes lots of static variables and as few classes as possible. Curious-- why did you choose BREW? I was under the impression that it wasn''t widely used.

stimarco: There is an event which I catch that lets me know the app is being interrupted. My main loop runs in a thread, which I pause when I get this notification. Maybe I''m not pausing it properly.. I''ll have to check in to it.

It is a very odd thing, and I think you''re right about the memory being shuffled around-- this would explain the data magically comming back to life.

There are some other issues as well-- we don''t have the luxury of access a screen buffer, so everything I do is a request to the Java runtime-- screen updates are unpredictable. That is to say, some areas get updated, others don''t. It has something to do with cliping regions (setClip) but that''s as much as I know.

Will


Share this post


Link to post
Share on other sites
Do you get that strange behaviour on the emulator? Sometimes the emulators behave weird, especially the beta ones.

Having said that, I''ve only ported one of my games to T720, because it just doesn''t sell in my country, we do not need to bother. It was seamless, I just modified the Series 40 version so it did not use any Nokia APIs. It worked well.

My worst J2ME coding experiences are w/ T610. It has a terrible implementation. It''s s l o w.


And.. About Direct3D writing on textures and stuff.. That''s called "device lost" and it''s roughly equivalent of the situation in OpenGL applications.

-- Murat

Share this post


Link to post
Share on other sites
quote:
Original post by RPGeezus
pinacolada: I''m using J2ME, not BREW. If I were using C I wouldn''t use classes. lol. As it stands I have to do a lot of trickery to get a decent frame rate out of the slower phones-- this includes lots of static variables and as few classes as possible. Curious-- why did you choose BREW? I was under the impression that it wasn''t widely used.



Oh, whoops!

I didn''t choose BREW myself, it''s what the company uses (in addition to J2ME). As far as BREW being unpopular, I dunno- I went into a Verizon store the other day, and it seemed like all the phones they sell are BREW phones. And the Verizon GetItNow service is really good, as far as selling games goes.

Share this post


Link to post
Share on other sites