Differences in mechanics: Qt vs JavaME on mobile
-
JavaME has evolved into a quite mature and de facto platform for mobile games and I used to to practise game making myself on it as well. Qt however is fascinating because it is more native and offers much more choices and possibilities for imagination. In addition Qt is being developed and enhanced more and more, while JavaME won't bring much new things to game coders anymore. I don't want to start a discussion which one is better in what area, but I'd like this thread to list any differences between JavaME techniques and Qt ways of doing that comes to your mind regarding mobile games development. It would help many existing JavaME coders to migrate to Qt.
-
First thing that comes into mind is that JavaME very often uses a separate thread for controlling (calling for) animations and game state changes, key press checks and actual drawing. A common way is to have in a 'public void run()' function a while() loop that checks for these things and then waits for the remaining time of the selected ticking speed. Qt however, uses an event driven approach and doesn't require a separate thread (but of course you can implement threads). Key and mouse events as well as system and user defined timer/action events call for defined specific functions where you can then change the state of the program. Repainting the screen can be requested, but many of the convenience functions do it for you automatically when needed. So the first thing to learn is that there is no one place controlling everything. When you get used to it, it actually makes sense. Depending on what type of game you're doing and whether you use QGraphicsView framework or purely QWidget based approach, the actual event functions vary a bit. In addition to these events, there is the 'signals and slots' mechanism to notify whatever element of some event that occurred.
Just to give the first taste...
-
Java ME does have game specific classes for creating 2d games. I think QGraphicsView may be much more useful for games than QWidget. Qt does have the advantage of native performance and low level access if needed. The programming techniques will be similar regardless of the language you use. The techniques for 3d games may be different for Java ME and Qt since the mobile 3d graphics api for Java ME is a higher level api than opengl es. But Java ME is much more portable than Qt when considering mobile devices. So unless Meego devices becomes popular, Java ME might the platform of choice for games. Just my thoughts ...
-
JavaME is quite portable nowadays but it didn't use to be so always. Various vendors implemented many critical functionalities with varying success and priority causing one thing to work in one device and another not so well. That is always the problem with interpreted code across different vendors and different interests. The inbuilt "widgets" in JavaME didn't either be quite the same across devices, but basic canvas usage is really nice still. Now JavaME is very mature, but the new specification (MIDP 3.0) is not bringing anything significant to game developers anymore.
Qt on the other hand is a portable language by design and it is rooting itself into current and future mobile devices. In my mind, having the roots in desktop area gives leverage to its feature set and puts strict requirements to the quality of mobile ports from day one.
JavaME will probably remain as the main gaming platform for some more time and at least as long as the masses are still using older and cheaper devices.
-
It seems that the future of Java ME is on low end devices. High end devices like iPhone, Android and Meego don't have Java ME. 2 - 3 yrs from now, I feel Java ME will be much less relevant. Every manufacturer nowadays seems more interested in promoting their own platform and ecosystem. Even on Symbian, I feel Java ME won't be further developed, It will remain as it is now.