Re: Requesting tips, comm
To: comp.lang.java.gui
"Knute Johnson" <nospam@rabbitbrush.frazmtn.com> wrote in message
news:OrGMh.112450$BK1.4200@newsfe13.lga...
Oliver Wong wrote:
"Knute Johnson" <nospam@rabbitbrush.frazmtn.com> wrote in message
news:44AMh.104676$BK1.87802@newsfe13.lga...
For active rendering I would take your rendering out of the EDT
altogether. The problem that you are going to run into is that
eventually too much will be happening on the EDT and you won't be able
to do any user input processing or that it will delay your rendering.
This key piece of information is pretty central to my
(mis?)understanding. I thought it's written that whenever you touch
Swing components, you should do so from within the EDT. If that's the
case, shouldn't you perform painting of JFrames and other widgets
within the EDT?
Unless you are trying to do high performance active rendering. Then you
do your rendering in another thread. The normal Swing component drawing
is disabled and you won't interfere with it at all.
Okay, thanks.
[...]
I don't have any real experience with XP timing but I would be very
curious to know if it is possible to make a JNI method that could sleep
very accurately. I would like to find something that could be accurate
to 250 microseconds +- to try in my timing loop. The accuracy of
Timer.schedule() is no where near that close. If you ran the test code
I posted you can see the jitter caused by the timing errors.
The library I use returns number of millisecond since the epoch, so
you can't get sub-millisecond precision with it. Probably there are
libraries out there that *do* provide sub-millisecond precision (and
hopefully a corresponding accuracy), but I don't know of any.
For example, I might have a scripting language which says "It
should take the character 2 seconds to walk from point A to point B",
and the engine will smoothly animate a sprite moving from point A to
point B at the highest frame rate that the computer can handle.
I think what you will find with that method is that your frame rate is
constantly changing as thread timing and system load changes. But I
will be interested in your results.
Yes, that's the case. The experience is "optimized" for the high end
machines. With a fixed-delay animation, you have some frame rate cap (e.g.
30fps), which all high end machines will be able to consistently produce,
and there's a certain cut-off point after which slower machines will start
to play the animation "too slowly", but will render every single frame. So
for example, things like syncing the animation to music or sound track may
become problematic.
With my variable delay system, you have a frame rate bottom (e.g.
24fps). If a machine is unable to consistently meet that 24fps rate, then
every frame of the "minimal" 10 fps animation will play, but at a slower
than intended speed (and thus have syncing issues once again). However,
any machine which can easily produce the 10fps animation with cycles to
spare will instead display an animation with the highest fps it can
muster, correctly timed (e.g. perhaps at 60fps).
[...]
I haven't used full screen exclusive mode much because most of what I
have been working on uses multiple monitors and still requires user
input. That won't work with FSEM. I don't know if it is possible to
remove the decoration on a window once it has been created or not.
I just tested it, and you cannot remove the decoration once you've
added it. I haven't used FSEM much either, because it's easier to debug
your game if you can still access the Eclipse workbench. Looks like I'll
have to rethink that part of the engine.
[...]
mainWindow.addWindowListener(new WindowAdapter() {
@Override
public void windowClosing(WindowEvent e) {
timeToQuit = true;
You are already in the EDT here, invokeLater is not needed.
EventQueue.invokeLater(new Runnable() {
@Override
public void run() {
synchronized (mainWindow) {
mainWindow.dispose();
mainWindow = null;
}
}
});
}
});
Thanks, I forgot about that.
[...]
Try it and see how it works. Post something that has some action!
Okay, here's a version which animates a blue ball sort of like the
code you posted:
<SSCCE>
import java.awt.Color;
import java.awt.Dimension;
import java.awt.EventQueue;
import java.awt.Graphics2D;
import java.awt.Insets;
import java.awt.event.KeyAdapter;
import java.awt.event.KeyEvent;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import java.awt.image.BufferStrategy;
import java.lang.reflect.InvocationTargetException;
import javax.swing.JFrame;
public class Test {
private static final int DEFAULT_RENDERING_WIDTH = 640;
private static final int DEFAULT_RENDERING_HEIGHT = 480;
private static JFrame mainWindow;
/**
* Returns true if the game is in the process of shutting down and
quitting.
* If it's in the middle of a game-loop iteration, it'll finish that
* iteration (potentially drawing 1 more frame of animation, and then
quit.
*/
private static boolean timeToQuit = false;
/**
* True if the player pressed the "action" key since the last iteration
* through the game loop, false otherwise. In a real game, I'd probably
have
* many of these booleans (e.g. an "up" key, a "down" key, etc., and move
it
* into a seperate class for organization purposes.
*/
private static boolean pressedActionKey = false;
static double x;
static double y;
static double deltaX = 3;
static double deltaY = 3;
public static void main(String[] args) throws InterruptedException,
InvocationTargetException {
/*
* This first invokeAndWait initializes all the GUI components, and
* registers the appropriate listeners to hook into the main game
* engine.
*/
EventQueue.invokeAndWait(new Runnable() {
@Override
public void run() {
mainWindow = new JFrame("My game");
mainWindow.setDefaultCloseOperation(JFrame.HIDE_ON_CLOSE);
mainWindow.setIgnoreRepaint(true);
mainWindow.addWindowListener(new WindowAdapter() {
@Override
public void windowClosing(WindowEvent e) {
timeToQuit = true;
synchronized (mainWindow) {
mainWindow.dispose();
mainWindow = null;
}
}
});
mainWindow.addKeyListener(new KeyAdapter() {
@Override
public void keyPressed(KeyEvent e) {
if (e.getKeyCode() == KeyEvent.VK_SPACE) {
pressedActionKey = true;
}
}
});
mainWindow.setPreferredSize(new Dimension(
DEFAULT_RENDERING_WIDTH, DEFAULT_RENDERING_HEIGHT));
mainWindow.pack();
mainWindow.setVisible(true);
mainWindow.createBufferStrategy(2);
}
});
/*
* This while loop is the main game loop. It basically iterates through
* 3 stages forever: getting the player input, reacting to it, and
* drawing the results on screen.
*/
long lastIteration = System.currentTimeMillis();
while (!timeToQuit) {
getPlayerInput();
{
long now = System.currentTimeMillis();
long elapsed = now - lastIteration;
if (elapsed > 1000 / 24) {
/* Don't do frame skipping when you drop below 24fps. */
elapsed = 1000 / 24;
}
processGameLogic(elapsed);
lastIteration = now;
}
synchronized (mainWindow) {
if (mainWindow != null) {
BufferStrategy strategy = mainWindow.getBufferStrategy();
Graphics2D g = (Graphics2D) strategy.getDrawGraphics();
Insets insets = mainWindow.getInsets();
g.translate(insets.left - 1, insets.top - 1);
g
.translate((double) (mainWindow.getWidth()
- insets.right - insets.left)
/ (double) DEFAULT_RENDERING_WIDTH,
(double) (mainWindow.getHeight()
- insets.bottom - insets.top)
/ (double) DEFAULT_RENDERING_HEIGHT);
updateScreen(g);
g.dispose();
strategy.show();
}
}
Thread.sleep(1);
}
}
public static void processGameLogic(long timeElapsed) {
x += deltaX * timeElapsed / 10.0;
y += deltaY * timeElapsed / 10.0;
if (x > DEFAULT_RENDERING_WIDTH - 30) {
deltaX = -Math.abs(deltaX);
}
if (x < 0) {
deltaX = Math.abs(deltaX);
}
if (y > DEFAULT_RENDERING_HEIGHT - 30) {
deltaY = -Math.abs(deltaY);
}
if (y < 0) {
deltaY = Math.abs(deltaY);
}
}
public static void getPlayerInput() {
/*
* Doesn't touch any Swing components.
*/
if (pressedActionKey) {
/* make mario jump */
System.out.println("Mario jumps.");
pressedActionKey = false;
}
}
public static void updateScreen(Graphics2D g) {
g.setColor(Color.BLACK);
g.fillRect(0, 0, 640, 480);
g.setColor(Color.BLUE);
g.fillOval((int) x, (int) y, 30, 30);
}
}
</SSCCE>
Unfortunately, to keep it as a simple SSCCE, I'm not able to include
the JNI library I'm using, so the timer resolution is pretty bad, which
means the animation isn't as smooth as it could be. I also realized I had
made a bug in the way I implemented insets and Graphics2D translation,
which is fixed in this latest iteration, though the blue ball mysteriously
seems to over-estimate the position of the bottom border, which I can't
really explain...
If you are interested in writing some C timing code for me, let me know.
I'm not. I'm not a C programmer. The library I use I downloaded off of
the internet:
http://www.javaworld.com/javaqa/2003-01/01-qa-0110-timing_p.html
- Oliver
---
* Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24