Why are you starting new threads in every iteration of the game loop?And why do you have a separate thread just to call setDirection() instead of just doing that in the game loop?And you could probably use a sleep() at the end of the game loop to give the system thread some time to handle events.

Mind you, I remember running into a couple of phones that didn't like the 7zip-compressed jars and agressive obfuscation. A pair of Samsungs and an LG, but I can't recall the specific models. If you use these methods and your game misteriously doesn't work on a few phones, try without the added compression.

My guess:On the emulator most of the frames are so quick that the ball moves 0 pixels. Since you are not accumulating these small changes, all these frames actually do nothing to the ball, and only on the ocasional frame where the delta is big enough the ball actually moves.On the phone, the time delta is big enough so that the ball actually moves on every frame, hence you get a lot faster movement.

A solution would be to make the ball's speed and position variables floating point as well, and only clamp them to an integer when you draw them on screen. This way, even on the frames where the movement is less than one, the actual position of the ball will be affected - you just won't see the difference on screen. But on the next frame, when you add another fraction, there will be a difference. This will probably make the phone and the emulator behave more consistently.

EDIT:Here's an example of what I mean:Frame 1 - ball is at 1.0. Movement is 0.25.Frame 2 - ball is at 1.25. Movement is 0.3.Frame 3 - ball is at 1.55. Movement is 0.35.Frame 4 - ball is at 1.90. Movement is 0.2.Frame 5 - ball is at 2.1 - Only now you actually see the "effect" of all the previous frames.The way you are currently doing things, the movement would have been 0 in all these frames, so the ball would've stayed at 1.0.

You could also round instead of clamp to an integer and then the movement would be seen on Frame 3.

The two options to get a full screens Canvas are:1) Use a GameCanvas and the setFullScreenMode() method. (MIDP 2.0 only)2) Use a proprietary class like Nokia's FullCanvas if there is one available for the platform.

On some phones you can never get complete fullscreen though, like Motorola's that always display the battery and signal indicators on the top of the screen.

you dont have to sleep but the loop just runs as fast as possible? I was thinking maybe I should make the game run independent of the rendering like you can do in j2se games and lwjgl.If possible. So that will make the game objects move xx pixles pr second instead of move xx pixles pr tick. (comments appreciated)

It's possible. You should still sleep a few milliseconds on every tick because many phones have cooperative multitasking, so no sleep at all can cause problems. But you can use System.currentTimeMillis() to do time based movement.

I have decided to make a midp2 only game, but what your saying is that if the game is made with suns wtk then it will run on all phones supporting midp2? So the special developing kits for each phone is just if you want special features or a little bit extra performance?

Unless you're making a Hello World app, it probably won't. But using the proprietary SDKs doesn't mean it will work on the actual phones either. Unfortunately the only way to know for sure that it works on a phone is to test it on the device itself. The specialized SDKs are good when you want to use proprietary APIs, or check that the app looks good on the target phones, because they will have emulators with the right screen size, key configuration (apart from the ITU-9 keys, all other keycodes don't have standard values), supported media types, etc. If you are lucky you might get emulators that emulate the bugs and not-properly-defined-by-the-specs behaviour of the phones but you can't count on that.

I thought I had to use each vendors developer kit to compile the game for their phones even though they support midp2.. ? (because of small differences in the phones) But this is my first game so i dont know alot..thats why i was thinking about making it work in suns wtk first.

If you aren't using any proprietary APIs then it doesn't matter if you compile with the WTK or with the proprietary SDK. The bytecode generated is the same (or at least it should be).

I'd recommend getting the Sony Ericsson version of the Wireless Toolkit for that phone. It's almost the same as the regular Wireless Toolkit, except with skins for the SE phones, and on-device debugging!

Netbeans along with it's mobility pack integrates fine with the Sony Toolkit.

If you install the Nokia SDK integrated into the WTK (ie, in wtklib/devices) then all you have to do in NetBeans is change the platform.bootclasspath and platform.device of the project.properties file (in nbproject).

Using the GAME_x_PRESSED constants to capture 1,3, 7, and 9 is a bad idea. Because there is no rule that says those keys will be bound to the GAME_x keys. It's not possible to capture these keys with getKeyStates(), but making your own implementation is very simple.

It comes from the fact that numbers are stored in binary in a finite sequence of bytes. If you could only remember numbers in decimal notation with a predetermined amount of digits, you would see the same problem when you try to do things with amounts like 1/3:

- are all series 60 devices supposed to have the same 176 x 208 screen resolution? if so how come the siemens sx1 boasts a 176 x 220?

Nokia Series 60 phones are 176x208. Other manufacturers have made Series 60 phones, and Series 600 "compatible" phones that don't follow the specs to the line. I don't know about the SX1, but for example on the K700 if you use MIDP 2.0's GameCanvas you get 176x220 pixels, and if you use Nokia's FullCanvas you get 176x208 pixels.

Quote

- i know there is an sdk for series 60. does this mean that i can just use this and base all my apps on midp 1.0? does it support things like image transparency? If so wouldnt this make nokia ui api, etc pointless? or am i asking the wrong question.

Yes you can base your apps on MIDP 1.0. But it's functionality is limited so that's why there are proprietary APIs.Transparency support? Depends on what you mean. You can load an image with transparency and it will display fine, but if you try to create a mutable image it will have an opaque background. The Nokia API has a method to create transparent mutable images but it is broken on Series 60. In fact, the Java implementation on Series 60 phones is quite crappy. There are tons of bugs and behaviour that doesn't conform to the spec, and many people are unpleasantly surprised to find out that all that wonderful functionality the phones have is usually unaccessible to Java.

Quote

- seriously, what is the point of midp 2 if i need to make my applications compatible with midp 1 and can just use nokia ui api or SMTK?? I have realised that ill have to probably end up writing my own sprite / layer mechanisms (i mean who needs a 4 byte integer for a tile value on a mobile device?!?! ). Is this what everyone else does?

The point is that in a few years MIDP 1.0 with all those horrible proprietary APIs will be a thing of the past. Hopefully by then you will be able to assume almost every phone will be at least MIDP 2.0/MMAPI 1.0 compatible (by then you will be asking "what's the point of MIDP 3?" ). For now, in a commercial release there is usually no other option but to support all the different flavours out there (this means a lot more than just Series 60).

Quote

As you can probably tell I am very confused... yes there are a lot of resources on the web, but seriously who designed forum nokia, i mean from a usability point of view and finding information its totally crap. Theres so many documents that just overwhelm the beginner/average developer.I really need to start learning properly, writing games that are compatible with series 60 phones, so hopefully I can do a good uni project next year. I choose to limit my platform, makes it easier - but the amount of useless information is just giving me a headache.

Those are rich man's troubles. You have too much documentation. Defenitely better than not enough. You don't have to read every single article. You can safely ignore the success stories and most of the usabillity articles (those will become more relevant later) and just look into a few of the technical articles. Download the SDK read a couple of the "Getting started making games" articles and get cracking.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org