hello,

In general, the problem is unlikely to be solved totally (JAVA is too slow).

I would leave frameRate untouched.
It is depending from your system, but it's likely around 60 times per sec.

I think your idea with PGraphics and then image makes it slower. Don't.

What puzzles me:
In Ship you have

1.    private void _update_accel() {

 and then

1.        set_xaccel(xaccel + xaccel_inc);

so you increase the acceleration each time draw runs (60 times per second).
You don't want that I guess.

This is enough (you already have this):

1.        set_xspeed(xspeed + get_xaccel());

(why not have xspeed+=xaccel; instead? All this set_ and get_ seems overcomplicated within the class Ship).

I think it would be enough to change xaccel in keyPressed; the method _update_accel()  seems overcomplicated without much gain...

Greetings, Chrisir   

Hi,

on my laptop your code runs with only about 20 fps. Even less when "shooting".
For fluent animations you have to increase the framrate (should be at least somewhere around 30).

When you want to use an offscreen-buffer, have a look at GLGraphics-library, that could really improve performance by a lot.

@Chrisir
The reason I have all those accessor methods is because I plan on expanding this code quite a bit and it helps to keep everything uniform and orderly. I'm trying to keep as much as possible out of the main loops and inside the classes themselves.

I'm updating acceleration in its own method because I may want to change the nature of how acceleration changes in other classes. Yeah, I know it's pretty redundant as the code stands now.

I thought that drawing to offscreen graphics and then rendering only once was actually faster than trying to make lots of little draws to the screen on the fly?

@iron13
Thanks, I'll check out using that library instead and see if that can't smooth things out.

" accessor methods [...] it's pretty redundant as the code stands now"
Yes, clean Java is quite verbose... But indeed, it can be a time saver when the code becomes larges and goes under refactoring.
I haven't looked at the code yet, but in general we use accessors to access the data from outside, but more rarely inside the class itself (ie. a method of a class rarely calls an accessor of the same class) as classes are supposed to remain small (sometime it is not possible) and easy to refactor without changes propagating outside (that's the point of accessors, precisely).

" I thought that drawing to offscreen graphics and then rendering only once was actually faster than trying to make lots of little draws to the screen on the fly?"
Not really. Well, it depends how it is used...
In draw(), all drawings actually go to a good old PGraphics, and the whole buffer is displayed only when draw() ends. So the performance is the same. Or can be worse if you don't benefit of the OpenGL acceleration!
On the other hand, if you have a built image that don't change on each frame, it is worth making it in a separate PGraphics, as you just have to draw it with image() when you need it.

Let me repeat

1.        set_xaccel(xaccel + xaccel_inc);

here you increase the acceleration each time draw runs (60 times per second).
You don't want that I guess.

Ah, I see what you are saying Chrisir.

The [xy]accel_inc variables are set to 0 unless a keypress has been detected, so it only increments the acceleration in the draw loop if a key is held down up to a maximum acceleration.

So when an arrow is held down it will increase acceleration (not speed directly). When no arrow is pushed the acceleration experiences a constant negative decay until the speed hits zero (actually, I just noticed a bug in this behavior but that is how it is intended to function).

I think this implementation of the physics lends itself to a floaty "spaceship" kind of feel.

Thanks for looking at my code!

PhiLho, thanks for clearing that up for me. I had no idea that Processing was already doing offscreen graphics under the hood!

Related question - now that I've told Processing to use OpenGL to render my graphics does it still create offscreen graphics automatically or will I now have to explicitly do this?

I had this, and it drove me nuts.

Thanks for the reply David!

Using OpenGL graphics definitely alleviated most of the jumpy-ness but there is no telling when it will return as I continue to add things to my draw loop.

Multithreading seems like a great idea. I'd love to check out that post but I think you mislinked.

I really like the idea of keeping track of a deltaTime and drawing accordingly. It would also make my physics calculations more coherent. Looking into it...

re-linked, good luck!

Calx | http://calx.co.uk