Why at the end of the constructor? I try to do this:


CanvasExtension myCanvas = new CanvasExtension();

myCanvas.setFullScreenMode(true)


With this I do the "setFullScreenMode" out of the Constructor Class. I read that if you call the method inside the constructor, baybe it fails.

This is the method I used for the projects I made in the past and it never gave me problems. It even works on older Nokia phone models like 6600, 6260, 6630, 6670, 6680, the newer but buggy N70, and on series 40 phones like the 6233.

If there was a bug, I've yet to encounter it. Maybe the bug exists on certain phone models? Or the way the canvas class was initialized? I'm unsure. But if you experience the problem I would appreciate it if you gave me a heads up.

Thanks.

I installed latest java sdk+netbeams. And applications made in it work 5-8x slower that the java 1.4 and j2me wtk 2.1 on my s65. Why is that? and the generated applet works in 2 colours - gray and black? (on newer phones it is ok, but still the speed is reduced) And why Netbeams work so slowly? This should be fast and easy as you build some little and non-complicated applications, but I guess its just fashonable now to make any windows applications big, slow and memory consuming (like windows itself). I hate that attitude. Im staying at the old one. I have few newer phones but i need the compatilbility and speed. The old java run smoothly on the newer phonest at very high fps. BTW the method of getting keys by getKeyStates (in both sdks) does not work on s65 and s66 correctly. (for example if you keep holding RIGHT it retuns randomly 1 and 0 on (getKeyStates & RIGHT_PRESSED) Instead i use 2 methods simulateously - getKeyStates and keyPressed/keyReleased. And it works fine on all devices that way.
Ty for the tutorials. I still find many parts useful tho i cant just copy and paste them :)

Uhm, I hope this helps you some:

I installed latest java sdk+netbeams. And applications made in it work 5-8x slower that the java 1.4 and j2me wtk 2.1 on my s65. Why is that?

I don't think that is possible as the Mobility Pack that comes with NetBeans IS the "j2me WTK" itself. The compiler is the same one, the emulator is the same one.

I have also used the standalone and mobility pack versions of WTK 2.2, 2.5, 2.5.1 and lastly 2.5.2 to compile the same MIDlets. They all produce the same output (to my perception).

and the generated applet works in 2 colours - gray and black?

Try checking your device/platform configuration setting for the project.

And why Netbeams work so slowly?

I don't know what kind of machine you have but NetBeans does take a long time to load especially if you have so many plug-ins installed that you don't need to use and your computer doesn't have much memory left. I suggest installing only the plug-ins that you need so it doesn't eat all your machine's memory.

Also check the minimum hardware requirements of NetBeans. I first used NetBeans on a P3 Celeron 776Mhz test machine with 512MB of ram, lol, and it worked fine. The pc I'm using now is a P4 Celeron 2.4 Ghz Single Core with 512 Ram. NetBeans works fine but I can't play NFS PROStreet!!! (EA, that is so low...)

I have few newer phones but i need the compatilbility and speed. The old java run smoothly on the newer phonest at very high fps.

The compatibility of a MIDlet depends on the MIDP configuration and CLDC platform you choose before you compile you're MIDlet, and most importantly your code (specially when it comes to speed).

Like I said the Mobility pack is the same WTK so...sorry, but it just doesn't make sense that the same WTK produces different MIDlets. So I'm stupefied beyond Hogwarts...I'm afraid I can't help you on that one.

BTW, you aren't limited to using the mobility pack for your platform. You can also use the standalone Sun Java WTK from within the NetBeans IDE.

BTW the method of getting keys by getKeyStates (in both sdks) does not work on s65 and s66 correctly. (for example if you keep holding RIGHT it retuns randomly 1 and 0 on (getKeyStates & RIGHT_PRESSED) Instead i use 2 methods simulateously - getKeyStates and keyPressed/keyReleased. And it works fine on all devices that way.

Using the getKeyStates() method directly in the "IF" statement is not a good way to check for key presses since the getKeyStates() method also flushes or clears the key states. So if you call it twice in a row or in quick succession, chances are the second call would detect no keys pressed. The best way to go about it is to assign the value returned by the getKeyStates() method in a temporary int variable and use that variable in your conditional statements.

I also use the key callback events for non-standard keys like soft keys but sparingly. It's always best to make your game so that it doesn't require the user to push so many buttons on a small device. Avoid having the player push more than one button simultaneously.

One of the best mobile games I've seen so far requires only 1 button to play the game: Link to Game Info.

Frankly, I really have no experience programming for s65 and s66 (I assume both phones are Siemens?) so I have no idea what compatibility problems they have with the standard j2me. Your best bet when developing MIDlets for a particular model is to use the SDK/WTK the manufacturer provided if thay have one.

Finally, the really big issues with the portability of Game MIDlets are with fullscreen mode, key codes (pound, sharp, and soft keys) and audio support. Among minor ones are screen resolution and font sizes. Other than these quirks, standard code will work just fine.

BTW, What do you use for editing code?

I hope these insights would prove useful to you.

Good Luck!!!

I use notepad. :D Sorry but im old school ;). If you recommended some LIGHT (fast and small) editor I would be very gratefull. Sometimes when i have problems I run netbeams and paste it there to check the "{}". Here is the game i made. Its still in the alpha stage. It's the conversion of an old Atari XE game (made in 1989). I used few parts of your tutorial for learning some stuff. here is the url:
http://ftp.pigwa.net/stuff/other/robbojava/Robbo_0_48a.jar
Engine is nearly finnished (there may be some hidden errors). The menu is in part-polish (poziom=level) and may be displayed baldy on phones with smaller res. (many reasons for keeping alpha stage) Now I'm working on making image fonts, but here I have some experience from other platforms (mophun) and Ill try doing it my way. When i run into some problems I'll check your tutorial of course. :) TY for great tutorials. They are easy to understand and that is the most important thing about tutorials. (and unfortunately not common) BTW I started to learn java 9 days ago :)

Very nice!!! It's looking good.

I see you have included graphics for 3 different resolutions. I'm applying the same technique on a game I'm working on which coincidentally is also a remake of an Atari game (2600).

Ever thought of making the sprites scroll between tiles instead of jump from tile to tile? What is the FPS on your target phone?

Thanx :)

Yes, but im trying to make exact conversion and that way it was on the original. The fps is kinda relative. The max fps is 20 (i think there is no need for bigger value, it works great) and the min is 6fps. When the phone is too slow to handle 6fps it still reports 6fps and just slows down game a little (when fps is smaller than 6 the game becomes unplayable). The only true possible values are 20, 10, 6 and <6. The results i got is 20fps on SE K750i, 20fps on some new low-end nokia, <6fps on Siemens S65 (but works only 15% slower than it should, fully playable) and 6-10fps on Siemens EL71 (i don't have a bloody idea why does it work so slowly on that phone.. It should be fine, the phone is quite new. The version has still some room for optimization. (now it wastes much of the cpu time) . There is no target phone as I try to make this version universal for almost all MIDP 2.0 devices (dynamic frameskip, that measures speed in few last seconds). I added the "buffer fire" option for some phones (motorolas, siemens EL71), as people have trouble hitting 2 buttons simulateously on them. (after selecting this option you can press fire and then the direction) It's just too bad that noone wants to help me with making new levels. Damn players - they just take, not giving anything in return :). BTW there is no jobs for people like me where i come from. Im applying for jub as a salesman.. Damn Poland.

by the way whats the name of the game form Atari 2600 you are working on?

Hi klocek,

Email me via amberlewren at gmail dot com so I can send the details and I think I can help with your game too (if you let me lol). It's very interesting as I've never played the game before. It's not available on the Atari 2600, is it?

On most newer phones with fast processors, the layer based classes works just fine. But if the processor is not fast enough (ex. N70), the layer classes will only make the game slower. So if you don't need pixel-perfect collision detection it would be better to draw the sprites and the map manually.

I tested tiles and pasted graphics. (i started with pasting graphics and the speed was REAL pain in the ass, tiledlayer made it much faster - playable on almost all phones) With pasting graphics the only phone able to do it right was SE K750i. (this phone is invincible) I haven't tried the sprites mode, but how could i do that? 1 loaded sprite is just individuall graphics which sometimes i dont need to use and sometimes i need to use several times. How to use 1 sprite many times without constantly loading it? (i cant load all possible graphics * 16 times screen_height) I dont know how to do it with sprites. here is game description. It was on the Atari XE/XL platform, not the console.

http://www.atarimania.com/detail_soft.php?menu=XL&SYSTEM=8&JEUX_ID=&VERSION_ID=4396&Page=1&ADV=0&OK=OK&SOFT_LIB=robbo&SFAMILLE_ID=0&TRI=SOFT_LIB&SENS=ASC

http://www.youtube.com./watch?v=LwJXgpsVAIQ
http://www.youtube.com./watch?v=2vh1xNgV1LY

Ok, I'll make a demo for you. Be sure to email me at amberlewren at gmail dot com so I can send you the link to the code.