Somewhere you should have a method that executes at regular intervals (eg 30 per second) to update the position according to the velocity. (A javax.swing.Timer is the best way to do that.) That's where you need to have your
velocity_Y -= gravity;
y += velocity_Y; //set y
JamesCherrill
... trying to help
8,521 posts since Apr 2008
Reputation Points: 2,583
Solved Threads: 1,456
Skill Endorsements: 30
the problem with using javax.swing is that compared the the awt its slower because your referring to java specific locations.
If your looking at basic mechanics then using a constant downward acceleration of 9.81 (as we have on earth) will work. So whenever you jump you need an initial velocity upward which then uses an equation in order to apply the downward acceleration due to gravity.
I'd recommend starting with a website like this and then see if you still require help
Hope this was useful
ObSys
Junior Poster in Training
77 posts since Nov 2011
Reputation Points: 24
Solved Threads: 7
Skill Endorsements: 0
the problem with using javax.swing is that compared the the awt its slower...
Not true.
AWT was the first attempt at a GUI layer for Java, it's design was bad, so they tried again and fixed most of the problems with Swing which was fully released in 1998. Since then all the development and tuning has been done on Swing, and AWT has only been enhanced to the extent that parts of it underpin Swing. No normal application should ever use AWT rather than Swing.
... because your referring to java specific locations
This makes no sense at all
JamesCherrill
... trying to help
8,521 posts since Apr 2008
Reputation Points: 2,583
Solved Threads: 1,456
Skill Endorsements: 30
What i mean is that AWT uses native components in order to draw whereas Swing uses the Graphics2D API so surely awt would be faster as its using the native components of windows?
ObSys
Junior Poster in Training
77 posts since Nov 2011
Reputation Points: 24
Solved Threads: 7
Skill Endorsements: 0
OK, that makes more sense.
This article is an excellent and authoratative read on the differences between AWT and Swing painting.
In brief, here are some of the things it has to say...
For the most part, the Swing painting mechanism resembles and relies on the AWT's. But it also introduces some differences in the mechanism, as well as new APIs that make it easier for applications to customize how painting works.
...
Swing starts with AWT's basic painting model and extends it further in order to maximize performance and improve extensibility
...
One of the most notable features of Swing is that it builds support for double-buffering right into the toolkit.
...
Swing introduces a couple of additional properties on JComponent in order to improve the efficiency of the internal paint algorithms
...
The purpose of Swing's RepaintManager class is to maximize the efficiency of repaint processing on a Swing containment hierarchy... It implements the repaint mechanism by intercepting all repaint requests on Swing components (so they are no longer processed by the AWT) and maintaining its own state on what needs to be updated
When Swing was introduced (over a decade ago!) you may have been right about native methods vs Java "lightweight" methods, but subsequent preferential development of Swing over AWT means that Swing will be the better, and faster, choice for all normal GUI applications.
If you really want to build the fastest possible GUI by using Windows native APIs. then SWT would probably be the best choice of all, although Linux users may not be happy :)
JamesCherrill
... trying to help
8,521 posts since Apr 2008
Reputation Points: 2,583
Solved Threads: 1,456
Skill Endorsements: 30
Thanks. That's actually really useful because i've been led to believe that it's preferable to use the awt class. Going to change the way I program in the future :)
ObSys
Junior Poster in Training
77 posts since Nov 2011
Reputation Points: 24
Solved Threads: 7
Skill Endorsements: 0