Not directly answering your question; but it sounds like your code could be optimised...  though it may depend on the interaction between the objects.

If in your array of objects it doesn't matter whether object A does something to object B or vice-versa each frame, just so long as one of them acts on the other, then you can significantly reduce the number of operations.  In your current setup it seems that object A will do its thing with object B and then when it comes to object B's turn it does its thing to object A - thereby duplicating the process.

This kind of optimisation is used a lot in collision detection - it may be worth doing a search on that to see some example code

Thanks for taking the time to answer, but actually (and unfortunately) I do need to compare A<>B and B<>A. It is a programme for some kind of gravitational simulation. So each of the objects needs to react with all of the others (excluding itself, of course) and alter its position accordingly in every step of the loop.

It is by definition a heavy piece of code, and any "optimization" would alter the term "simulation".

So apart from changing the code is there any way to use lighter graphics? Anyone knows anything about P2D?

In any form of animation there are 2 parts - calculating the new state/position and drawing the current state. To speed up the simulation you have to either optimise the state calculation or find a better way to do the drawing.

Quote:

does this mean you are doing the state calculations in the draw() method?

There are approachs to the problem

• calculate the state of an object
• redraw the current state
• repeat for each object

and

• calculate the state of an object
• repeat for each object
• draw the current state

The problem with the first approach it all has to be done in the draw() method and if as in your case the state calculations are large then it is not surprising you get flikering.

A possible solution is to use the second approach which can be done in Processing with
Code:

void setup(){
   // blah blah blah

   registerPre(this);
}

void pre(){
   // do all the state calculations here
}

void draw(){
   // draw the objects here
}
 

With regard to JAVA2D vs P2D.
In the source code comments for PGraphics2D and PGraphicsJava2D it states P2D is better than JAVA2D if you are working at the pixel level but is less accurate than JAVA2D for drawing shapes. Looking at the code for drawing a rectangle in these two classes P2D is doing a lot more work than JAVA2D

In this case perhaps it you should stick with JAVA2D .

Actually I made the suggestion because I had used OpenGL on a 2D project and found I was able to render it at larger dimensions and with better performance than using the 2D rendering methods; but if you asked me why I don't think I'd be able to give a conclusive answer.

My assumption is that as long as the draw commands sent to OpenGL are understood by the graphics hardware then it will handle the rendering, thereby freeing up the processor to concentrate on the calculations...  though any optimisation of these will obviously help.

Wow, many things going on here...
I've been away for a few days.
Anyway, the conclusion is that Processing is kind of weak to keep
up with such a piece of code which is bound to fail at a certain
number of instances, whether it is 20 or 200.
By the way the same algorithm runs smoothly on c++ using the
allegro library up until 200 or more instances.
But.. java is easier and doesn't break my nerves to declare a class
the right way. So...
Also the for 20 objects i have 20 object.draw(); in the draw loop.
I will try using the
void pre(){...}
function for the calculations and see if that works.
Or maybe openGl? Still experimenting...
Thanks for the support, guys.
I will also try to post the whole code from an external link
sometime soon. It's a fun, meaningless game of attraction and
repulsion between "particles".

On a different subject...
Is there a way to print text on the screen without including fonts
in the application folder or having to browse for a font file?

Hey, I'm just curious but, if it's a game why do you care so much about strict simulation? Gravity has really short arms, so you can pre-compute the gravitational effect of an object up to a certain radius where the effect is negligible, then in every time step add it to a vector field and step all of the objects along their local vectors. If you do it like this, you only have to loop through all of your objects twice, once to create the field and once to update the object positions. Kinda like fluid simulation actually..

In any case, I have found that OpenGL can really speed up drawing, at the expense of making your game very unfriendly to browsers.