Ive read alot of posts and articles concerning this, and much has been answered, but they've also raised more questions: -when animating, is it better (in terms of speed/mem tradeoffs) to use a single image object, and change the clipping region to draw different frames. Or is it better to split it into many image objects? -Ive heard its faster to use static & final methods (is there such thing as a final method?) rather than public, is this true? (and whats a final method?) -Finally, i also heard that the creation of new objects is quite slow. Would this just be the case for allocating of memory: CustomObject myObject = new CustomObject(); Or simply calling of the 'new' command (ie replacing an old memory space): myObject = new CustomObject(); Apparently use of object pool is a good way to avoid this, im wondering if i should make new objects by using the 'new' command and put it in old memory space, or i should make a function in the object which resets and initialises the object to its new value. thanks in advance

* static:
Static means the method is only *created* once even if multiple objects are created.
The con-side is that you cannot access data from inside the class.

f.e. if you have a CSoccerPlayer class and use the static method update() to update them you cannot reference the players x/y fields from inside the method since the fields are non-static (logically because then every player would have the same positions)

But you could pass in the object as an argument.

* creation of new objects:
Yes it is quite slow.
Create the objects and if you no longer need them, put them in a reserve vector for later reuse.

Heck even using objects is ill-advised.
Avoid them as much as possible. Use arrays.

Your device-memory is very limited on most devices and it is reccomended you save were possible to leave room for device-*problems*.

Quote:Original post by DaemonSpawn
Ive read alot of posts and articles concerning this, and much has been answered, but they've also raised more questions:

-when animating, is it better (in terms of speed/mem tradeoffs) to use a single image object, and change the clipping region to draw different frames. Or is it better to split it into many image objects?

This depends on your platform. The best guess I have is to just try it and measure the speed.

Quote:
-Ive heard its faster to use static & final methods (is there such thing as a final method?) rather than public, is this true? (and whats a final method?)

A static method has no implicit this pointer. This means you dont need to push that value onto the stack when calling the function. Even if you can get some speed this way, I don't think it is very much. Again, measure the speed.
A final method is one that cannot be overridden or hidden by subclasses:
Java Language Specification
And I don't think it makes any difference in speed if a method is private, protected, public or package private.

Quote:

-Finally, i also heard that the creation of new objects is quite slow. Would this just be the case for allocating of memory:
CustomObject myObject = new CustomObject();
Or simply calling of the 'new' command (ie replacing an old memory space):
myObject = new CustomObject();

Apparently use of object pool is a good way to avoid this, im wondering if i should make new objects by using the 'new' command and put it in old memory space, or i should make a function in the object which resets and initialises the object to its new value.

thanks in advance

Whenever new is called, a new object is allocated on the heap. Putting objects into 'the old memory space' via

myObject = new CustomObject();

is not necessarily possible.
Using a pool is a good idea. You can do this by providing an init() function for your objects, and not using constructors anymore. Then create objects with new on demand when your pool is empty. When an object is not used anymore, just tag it somehow so that the pool manager may call init() on it again.

For a comparison of image drawing techniques I found this thread on nokias forum, makes for an interesting read:
http://discussion.forum.nokia.com/forum/showthread.php?s=3ddf755309131c7e3ee662402648902e&threadid=33852&highlight=%2Aspeed%2A

thanks for the answers guys, that really cleared up most of the contradicting optimisations ive heard, now i just have to test the speed of the animation techniques on my device and all is good :D. Thanks for the post link too fatjaba, another source of j2me techniques to help me.

I do not have on-device profiling on my MIDP device (SE T610). The SE emulator is so dissimilar to the device there is no point in using it. It is basically the Sun WTK with some minor mods.

However, I do believe that a lot of the time my game spends waiting for the hardware or library routines to do graphics things.

As far as animation strips vs separate images is concerned - try to find a happy medium. It is not sensible to use one huge image for everything (especially on T610 which has very little graphics ram), but neither is it sensible for you to split everything into individual Image objects.

Perhaps using one image for each badguy in a platform game (for all animation frames) might be ok - if it wasn't too big.

Anyway, I'm strongly opposed to totally wrecking your OO structure for the sake of some tiny perceived performance gain, particularly if that gain is going to be so small it makes no difference.

Things that you create a great deal of and destroy often - like particles and bullets - should probably be stored in arrays and reused.

Anything else that might have methods on etc - like badguys and switches, for example in a platformer, should have its own object and use non-static methods. The overhead really is NOT THAT great. And using polymorphism does save code in the long run.

I guess on the newer devices, the CPUs are a lot better, JVMs more optimised, so these rules are even less important.

If you are calling new() every frame inside your main loop you should probably consider pooling objects. But if you just call new() occasionally, that's fine.

---

FINAL: writing "final", in principle makes things faster, but in practice is unlikely to. Why? Because the JIT can tell if a method is not overriden at compile-time and make the method effectively "final" anyway. All writing "final" does, it make it slightly easier for it to figure out that it is not overridden.

Of course if running through the interpreter, "final" could in principle make things a bit faster.

STATIC: Making stuff static removes a tiny bit of overhead - the VM no longer needs to pass a reference to "this" through to the method. But if you're passing a parmeter anyway, surely that is no different. The same argument as above applies for method overriding and the JIT.

So my thinking is, if the JIT is half-way decent, it should be just as fast to use non-static, non-final methods.

Mark

I found that the biggest problem with MIDP applications is JAR size and heap space usage. Speed tends to come second to this.

Quote:markr wrote
Anything else that might have methods on etc - like badguys and switches, for example in a platformer, should have its own object and use non-static methods. The overhead really is NOT THAT great. And using polymorphism does save code in the long run.

Classes have an overhead of several hundred bytes (more for large classes) which can be a significant proportion of the JAR file. JAR file limits can be as low as 30K, with 60K being average. The upshot of this is that you don't want to create unnecessary classes. I personally only use three classes for my MIDP applications: MIDlet, Canvas and TimerTask; and if I have some spare space then I also have a Loader class which then allows me to do animated loading screens.

Also, the free Java compiler doesn't do much code optimisation, which means you need to be careful about writing the code.

Skizz

It seems both animation methods have their dis/advantages.
As im making a tile engine, i guess ill use filmstrip for the spites, all of which are in each map, and separate images/small filmstrips for the tilesets, of which a few random ones must be loaded for each map.

Quote:Original post by Skizz
Classes have an overhead of several hundred bytes (more for large classes) which can be a significant proportion of the JAR file.

At the moment all ive had time to do is make the the UI components, like inputbox, combobox etc. But these are all separate classes. Would this be ok? Later i was also going to make classes like 'tile', and 'sprite', which only contain maybe 10 variables, but is this a bad idea?

depending on the complexity of your game it may or may not be a bad idea. If you are just attempting a simple game then it wont pose many problems to you, but if you are going to write a cutting edge game which requires all possible optimisations to be used then it is bad. As has already been mentioned, adding in extra classes takes up jar and memory space and when you consider only a few bytes can stop a game running it would be wise to ditch a lot of the Object-Orient stuff you have been taught in school! :)

Quote:Classes have an overhead of several hundred bytes (more for large classes) which can be a significant proportion of the JAR file.

Yes but obviously using classes does make code easier to maintain. The biggest drawback of classes is that each class goes into a separate file in the .zip which adds to the zip index AND also compresses less well than a single larger class.

Quote:
Also, the free Java compiler doesn't do much code optimisation, which means you need to be careful about writing the code.

Java to classfile compilers typically do almost no optimisation. Optimisation is really done by the JIT in Java. I was referring to that in my previous post.

Of course if you use an obfuscator it does some optimisations (like removing unused stuff).

Mark