Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2
1  Java Game APIs & Engines / Java 2D / Re: A couple of opengl + Linux related questions on: 2005-04-22 16:50:45
Ok, I think I found the AWT bug you were describing here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4356756

However, I don't think AWT being able to detect the physical displays is really the problem.  If my understanding is correct from reading Nvidia's documentation, there are 2 distinct ways to enable a multiple display desktop with X (as well as enabled 2D opengl).  The first way, which is a legacy or deprecated mode as far as NVidia is concerned is to run two instances of the NVidia driver which creates two distinct desktops controlled by the X11 server.  In this mode, NVidia can provide opengl acceleration to only one physical display while the second display will not have opengl acceleration.

The second method which I'm trying to take advantage of, and the one which does not seem to work properly with Java involves NVidia's twinview.  In this mode, NVidia is able to provide opengl acceleration to 2 physical display devices at the same time while still providing xinerama extensions.  They do this by providing one large, opengl accelerated desktop behind the scenes and then adding a twinview/xinerama layer in between that enables applications (including the window manager) to "see" two distinct displays and act accordingly while at the same time able to take advantage of opengl acceleration on those two displays.

It seems to me that when the Java 2D opengl pipeline initializes, it sees the NVidia twinview/xinerama layer and correctly detects two physical displays, but that it is not correctly determining that both physical devices can be opengl accelerated.  By enabling the "NoTwinViewXineramaInfo", the Nvidia twinview/xinerama layer no longer provides physical device information and only at this time does the Java 2D opengl pipeline code work correctly on both physical devices.

So, am I off my rocker in my understanding?  Or should this be something I should consider filing a bug report for?
2  Java Game APIs & Engines / Java 2D / Re: A couple of opengl + Linux related questions on: 2005-04-21 07:14:38
Thank You, Dmitri, for your help.  Taking into consideration what you described, I tried a few more things out.  Turns out, my assumption about which display device was the primary display (i.e. Display 0) in my Linux setup was incorrect.  I have a digital flat panel and an analog CRT connected and it turns out that the analog CRT is actually the primary display and upon dragging my opengl enabled window to that physical display I begin to see OGL calls in my trace output.  If the window is on the second display (i.e. Display 1) it appears that OpenGL acceleration desists and the X11 pipeline takes over.  So, when it says it didn't enable opengl on screen 1, I guess it really means it!

However, I still don't think everything is behaving properly.  From the NVidia Linux driver documentation Twinview should behave as such:
Quote
- The NVIDIA driver conceals all information about multiple display devices from the X server; as far as X is concerned, there is only one screen.
- Both display devices share one frame buffer.  Thus, all the
the functionality present on a single display (e.g.accelerated OpenGL) is available on TwinView


It seems to me the exact opposite is happening with Java, i.e. it is seeing two distinct displays when it should only be seeing one.

There is an option called "NoTwinViewXineramaInfo" that disables Twinview's xinerama information.
Quote
When in TwinView, the NVIDIA X driver normally provides a Xinerama extension that X clients (such as window managers) can use to to discover the current TwinView configuration.  Some window mangers can get confused by this information, so this option is provided to disable this behavior.


So when I enable the NoTwinViewXineramaInfo option, I effectively get only one very large, opengl accelerated screen called "screen 0" and my opengl window runs via the OpenGL pipeline on both physical displays.  Unfortunately, though, this effectively cripples the Linux window manager which now no longer honors the bounds of the physical displays.

As such, it seems to me that either Java is asking the Nvidia drivers the wrong question when querying the opengl capabilities of the physical device or the NVidia drivers are providing back the wrong answer.

As far as enabling opengl with the System.setProperty, you we're right.  I hadn't realized static 2D calls were being made elsewhere in advance of the static main method.  So I'll have to rethink how I allow the user to adjust that property.  I realize that OpenGL isn't enabled by default for a reason, but unlike Windows which has multiple fallback methods, it seems to me that there is no good, accelerated alternative to X, so I intend to provide the user with the ability to run in some sort of safe mode using the X11 pipeline if they notice display problems.
3  Java Game APIs & Engines / Java 2D / A couple of opengl + Linux related questions on: 2005-04-20 23:47:36
Hi,
I recently began experimenting with 1.5's opengl pipeline under linux and am confused about a couple of things.

First, (and this may be a bit of a noob question) does enabling the opengl pipeline differ between setting the property as a JVM parameter via
1  
-Dsun.java2d.opengl=True
vs setting the system property in main() with
1  
System.setProperty("sun.java2d.opengl", "True");

I was under the impression that setting doing the System.setProperty as soon as possible was the correct way to set java2d properties.  However, if I do it with System.setProperty, I don't get the warm and fuzzy "OpenGL pipeline enabled for default config on screen 0" output.
Does the System.setProperty just not output the verbose messages, or can the opengl pipeline only be set by passing it as a JVM parameter?

Second, as I mentioned, I get a "OpenGL pipeline enabled for default config on screen 0".  However, I also get a "Could  not enable OpenGL pipeline for default config on screen 1".  So I am wondering what this implies as far as my hardware goes.  I am using a dual monitor setup with an Nvidia card using Twinview.  Does this mean that opengl is disabled for one of the displays?  If I want hardware acceleration should I be checking that my window is remains completely within the bounds of screen 0?  My guess is that Nvidia's Twinview abstracts away the second monitor and treats screen 0 as one large, opengl accelerated dispaly, rendering screen 1 as reported by java irrelevant, but this is just a guess.  Does anyone know for certain?

Third, when watching the "sun.java2d.trace" output in Windows I know to look for "D3DBlitLoops" to know that it's accelerated, but I'm not sure what to look for in Linux.  I am seeing alot of
Quote
sun.awt.X11PMBlitLoops::Blit("Integer RGB Pixmap", SrcNoEa, "Integer RGB Pixmap")
which I'm guess are not hardware accelerated based on the fact that they have "X11" in there.  Is this a correct assumpution?  What should I be seeing as far as OpenGL accelerated messages go from the java2d.trace feature?

Anyway, just trying to get a grasp on a few basics to know which way I should go next.  Thanks for any insight.
4  Java Game APIs & Engines / Java 2D / Re: Java2D Dual Monitor Bug? on: 2004-10-13 17:48:39
Yeah, dual monitor support in Windows I've found to be very quirky whether its Java, my software DVD player, or playing Doom3 without first disabling the second monitor.

For what it's worth though, it's not too difficult to get things moving again when dragging your JFrame from one monitor to another.  In my code I have:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
public class GameParentFrame extends JFrame implements ComponentListener
{
      private ArrayList deviceSpace = new ArrayList();
      public void initView()
      {
            addComponentListener(this);
            initGraphicsEnvironment();
        }
      public void initGraphicsEnvironment()
      {
            GraphicsDevice[] deviceList = GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
            for (int x=0;x<deviceList.length;x++)
            {
                  GraphicsDevice gd = deviceList[x];
                  GraphicsConfiguration gc = gd.getDefaultConfiguration();
                  Rectangle bounds = gc.getBounds();
                  if (bounds != null)
                  {
                        deviceSpace.add(bounds);
                  }
            }
      }
     
      public Rectangle getDeviceLocation(GraphicsConfiguration gConfig)
      {
            System.out.println("Device origin= " + gConfig.getBounds().getX() + ", " + gConfig.getBounds().getY()); //$NON-NLS-1$ //$NON-NLS-2$
           return gConfig.getBounds();
      }
      public void componentMoved(ComponentEvent e)
      {
            //check for spatial location and reset the tickers if necessary to prevent them from "freezing" on a device context change
           Rectangle currentBounds = getBounds();
            for (int x=0;x<deviceSpace.size();x++)
            {
                  Rectangle deviceBounds = (Rectangle)deviceSpace.get(x);
                  if (deviceBounds.intersects(currentBounds))
                  {
                        if (deviceLocation != x)
                        {
                              deviceLocation = x;
                              view.notifyDeviceContextChanged();
                        }
                  }
            }
      }
}


and then in my view code where I extend Canvas and have a BufferStrategy setup I have:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
        public void deviceContextChanged()
      {
            trackComponent.resetDrawing();
      }
        public void resetDrawing()
      {
            recreateBufferStrategy();
      }
      public void recreateBufferStrategy()
      {
            if ((running == true) && (isVisible() == true))
            {
                  if ((getHeight() > 0) && (getWidth() > 0))
                  {
                        createBufferStrategy(3);
                        strategy = getBufferStrategy();
                  }
            }
      }


So as the frame is dragged from window to window, it will recreate the buffer strategy and get the animation rolling again.  It flickers a little while it's in the middle of the two monitors while its being dragged but seems to work OK.  Of course it would be better if it recreated the BufferStrategy only after the drag is complete, but I could never figure out how to get Java to notify me when the dragging of a JFrame is finished.
5  Game Development / Newbie & Debugging Questions / Re: Java Gamebook recommendation on: 2004-09-28 18:36:58
DrA, I really appreciate you posting your thoughts on a couple of these Java game books.  Sometimes, as you've shown, standing in my local Barnes and Noble store reading the table of contents doesn't give a very complete preview of a given book.  Or, as in the case of Brackeen's book, the local bookstore doesn't even carry it so I have no way of knowing its worth or sometimes its existence without some outside, trusted recommendation, like from this forum for example.  Thanks again.
6  Java Game APIs & Engines / Java 2D / Re: Getting user system properties on: 2004-09-16 21:05:49
As far as computer RAM goes, perhaps my understanding is flawed, but isn't the critical question how much RAM is allocated to the VM?  Because if the VM runs out of memory it doesn't really matter how much system RAM you have.  You'd have to restart the VM to increase it's system RAM allocation.  And said VM RAM values can be obtained by
1  
2  
3  
4  
Runtime runtime = Runtime.getRuntime();
runtime.freeMemory();
runtime.totalMemory();
runtime.maxMemory();


And as far as Java2D graphics go, what other information do you need exactly other than available accelerated memory?  I mean, I wouldn't think you would want or need to enumerate the graphics card's 3D capabilities just for Java2D.  And graphics memory can be obtained through the GraphicsDevice which will also tell you available resolutions, number of monitors, and other information pertinent to 2D.
1  
2  
GraphicsDevice gd = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
gd.getAvailableAcceleratedMemory()


And for CPU information there are the system properties:
sun.cpu.endian=little
sun.io.unicode.encoding=UnicodeLittle
sun.cpu.isalist=pentium i486 i386

Anyway, I know it's not alot of information but maybe some very basic information is all he really needs for now?
7  Game Development / Newbie & Debugging Questions / Re: Java2D or Seperate Library on: 2004-09-09 22:01:57
Assuming you want more advanced graphics than just Swing can provide, I would start with Java2D no matter what.  Once you've learned the Java2D basics of BufferedImage and animation loops, the knowledge should provide a good stepping stone and insight into more advanced APIs such as JOGL.  If you have a look at the tutorials at http://grexengine.com/sections/externalgames/ this is the approach they take, starting with Java2D and moving to JOGL which seemed to work really well for me personally.
8  Java Game APIs & Engines / Java 2D / Re: graphicsDevice.getConfigurations() maps to wha on: 2004-05-10 04:07:42
As to why the ColorModel of each configuration is identical, according to trembovetski from this thread:
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=2D;action=display;num=1067546922

"GraphicsConfiguration objects correspond to pixel formats.  
On windows the depth will always be the same as the desktop depth. On other platforms (i.e. Solaris sparc) there are video boards which can handle windows with different depths, so there you can have GraphicsConfigurations with different depths (GC objects correspond to X11 visuals on unix). "

I think thats related to what you were talking about.  If not, I was never here.  Grin
9  Game Development / Newbie & Debugging Questions / Re: Spawning jvm processes on: 2004-02-22 21:57:42
Quote
Note that shutdown hooks will only be run if the process is terminated nicely

D'oh! That's it.  For some reason, I had it in my head that terminating it from my IDE was like hitting Ctrl-C from cmd, but I can see why that wouldn't be the case and goes with what you said before about Windows not killing child processes.

Quote
Not if its not in your shell ENVIRONMENT variables


Makes sense.  I guess it's not really that big of a deal to set an explicit path for this, but since the type A side of me needs to be appeased, I found that
1  
private String [] envp = new String [] {"CLASSPATH=" + System.getProperty("java.class.path")};
seems to work pretty well for getting the path to wherever it was launched from.

As always, thanks for the help  Smiley
10  Game Development / Newbie & Debugging Questions / Re: Spawning jvm processes on: 2004-02-21 00:10:54
Thank You the information so far has been very helpful.  I have a couple of questions, however, that I haven't been able to sort out.  For instance, the java docs state for Runtime.exec():
Quote
If envp is null, the subprocess inherits the environment settings of the current process

However, I am unable to successfully launch the new process without explicitly settings the classpath in the environment argument.  Shouldn't it be able to figure it out from the current process as it states?

Second, I can't seem to register a shutdown task through addShutdownHook.  Is this not the correct function to use?

I wrote a small test program.  Is there something I'm doing wrong?
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
93  
94  
95  
96  
97  
98  
99  
100  
101  
102  
package com.launcher;

import java.awt.BorderLayout;
import java.awt.GridLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.io.IOException;
import java.util.ArrayList;
import java.util.Iterator;

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;


public class MainLauncher extends JFrame
{
      private JButton launchTest1;
      private JButton launchTest2;
      private JPanel buttonPanel;
     
      private ArrayList externalProcessList = new ArrayList();
     
      private String [] envp = new String [] {"CLASSPATH=c:\\projects\\LauncherTest\\bin"};
      public MainLauncher(String title)
      {
            super(title);
           
            setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
           
            initComponents();
           
            Runtime.getRuntime().addShutdownHook(new ShutdownThread());
      }
     
      public void initComponents()
      {
            buttonPanel = new JPanel();
            buttonPanel.setLayout(new GridLayout(1, 2, 2, 2));
           
            launchTest1 = new JButton("Test 1");
            launchTest1.addActionListener(new ActionListener()
            {
                  public void actionPerformed(ActionEvent e)
                  {
                        try
                        {
                              //Does not work.  Returns a main class not found exception.
                             externalProcessList.add(Runtime.getRuntime().exec("javaw com.space.TestFrame -1"));
                        }
                        catch (IOException e1)
                        {
                              e1.printStackTrace();
                        }
                  }      
            });
           
            launchTest2 = new JButton("Test 2");
            launchTest2.addActionListener(new ActionListener()
            {
                  public void actionPerformed(ActionEvent e)
                  {
                        try
                        {
                              //Correctly launches the separate process but does not get shutdown through the registered Shutdown thread :(
                             externalProcessList.add(Runtime.getRuntime().exec("javaw -Dsun.java2d.noddraw=true com.space.TestFrame -2", envp));
                        }
                        catch (IOException e1)
                        {
                              e1.printStackTrace();
                        }
                  }      
            });
           
            buttonPanel.add(launchTest1);
            buttonPanel.add(launchTest2);
           
            getContentPane().add(buttonPanel, BorderLayout.NORTH);
      }
     
      private class ShutdownThread extends Thread
      {      
            public void run()
            {
                  System.out.println("Shutting down external processes");
                  Iterator iterator = externalProcessList.iterator();
                  while(iterator.hasNext())
                  {
                        Process process = (Process)iterator.next();
                        process.destroy();
                  }
                  System.out.println("Finished shutting down external processes");
            }
      }
     
      public static void main(String[] args)
      {
            MainLauncher launcher = new MainLauncher("Launcher Test Suite");
            launcher.show();
            launcher.pack();
      }
}


1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
package com.space;

import java.awt.BorderLayout;
import java.awt.Font;

import javax.swing.JFrame;
import javax.swing.JTextArea;


public class TestFrame extends JFrame
{
     
      public TestFrame(int frameID)
      {
            super("Test Frame" + frameID);
           
            initComponents();
      }
     
      public void initComponents()
      {
            setFont(new Font("Arial", 0, 25));
           
            getContentPane().add(new JTextArea("This window was launched in it's own process"), BorderLayout.NORTH);
      }
     
      public static void main(String[] args)
      {
            int frameID = Integer.parseInt(args[0]);
            TestFrame frame = new TestFrame(frameID);
            frame.show();
            frame.pack();
      }
}
11  Game Development / Newbie & Debugging Questions / Spawning jvm processes on: 2004-02-20 18:37:24
This is kind of an experiment on my part and not absolutely critical if it can't be done easily, but I'm wondering if it's possible to launch separate jvm processes from an already existing jvm process.  The reason I want to do this is to be able to compare the behavior and performance of certain global settings side by side.  For example I run my "launcher" app, set my settings such as sun.java2d.noddraw true or false, click a button and then launch the new window with the approprate settings enabled.  Then I can launch as many processes as I want observe their behavior/appearance and then clean them all up by just closing the launcher/master application.

Anway, can this be done or is it more trouble than it's worth.  Thanks for any help.
12  Java Game APIs & Engines / Java 2D / Re: JDK1.5.0 beta is out on: 2004-02-06 20:02:46
And if you do it through code, make sure it's the very first thing you do, i.e. before displaying anything that might use Java2D.  I tend to forget that little tidbit on a regular basis.
13  Java Game APIs & Engines / Java 2D / Re: anyone wish to guess why it stutters? on: 2004-01-06 16:52:47
You're right, I do interpolate both the X and Y coords.  Unfortunately, I haven't had a chance to try it in fullscreen mode.  It is my current understanding that fullscreen and window mode require slightly different animation loops and I have been spending most of my time trying to optimize the loop for windowed mode since I explicitly limit the max fps.  It shouldn't be hard to remove the frame limiting, but it's still on my "to-try" list.

Anyway, I think you're right it is still a little jerky and it seems to me that the way to fix it would be to increase the value of GAMETICKS_PER_SECOND which actually might be a little on the low side.  From my experiments, increasing the value of GAMETICKS_PER_SECOND helps to smooth movement but at the cost of increased CPU usage.  

I had not thought of the physics benefit of the interpolation technique, but I suppose you're right especially for acceleration.  Rather than jumping to a new position when you increase speed, the interpolation should help it to ramp up  it's motion.

Thanks for the article link.  If I understand right, it sounds very similar to what both Jeff and Markus have been describing as far as the basic animation loop goes (which does not include the interpolation stuff).  Interesting that they would suggest using doubles.  I tried this once after reading an article on the popular java based MeatFighter game but it seemed to me that using doubles caused even more stuttering problems when coupled with the PerfTimer, but I could just have been doing something wrong at the time and I definitely had not yet adopted the interpolation techniques by then.

Edit - One thing I forgot to mention, that example doesn't handle pngs very well. (or is that Java?)  Anyway, you are likely to get better performance if you use -Dsun.java2d.noddraw=true when using it with PNGs.  At least that's the way it works on my box, so I forgot about it since I always have it enabled by default when I run that particular project on my machine.
14  Java Game APIs & Engines / Java 2D / Re: anyone wish to guess why it stutters? on: 2004-01-05 19:17:46
Kommi, I just tried your jar file and it looks just fine to me.  I can't tell if it's actually running in exclusive mode or just a full screen windowed mode.  If it is a windowed mode, then maybe you need to add some sort of frame limiter to keep it from stuttering on a slower machine.  I ran it on a P4 2.0GHz running XP with an NVidia FX graphics card.

Anyway, I'm no expert and still in learning mode too, but my understanding of the reasons for interpolation is that because actual framerates can fluctuate wildly, interpolation helps to keep the movement constant and smooth when framerates fluctuate, i.e. speeding up or slowing down when your framerate increases or decreases.  I've tried to write an animation loop before without using any interpolation and could never keep my image moving at a constant speed.  Since I write all of my stuff in windowed mode, every time drawing cycles were taken by some other window (like tooltips on the taskbar for example) my animation loop suffered.

Anyway, I wrote a little program testing Markus's examples and my animation loop looks very similar to yours.  I will post it if I can find a place to host it so you can at least compare if you want.

OK, I copied your hosting idea and uploaded it here.  http://www.angelfire.com/clone2/immudium/MMB.jar  Source is included as well.
15  Game Development / Newbie & Debugging Questions / Re: Found this game loop tutorial if anyone needs on: 2003-12-19 16:33:58
Thanks for sharing the link Kommi.  I'm always looking for new examples of animation loops.  I remember some time ago someone saying that a good animation loop could take months or years to develop and at the time I was just starting out and scoffed at the idea.  Well it's been several months later now and I find myself tweaking and adjusting and learning new techniques and realizing how true that statement was.  Anyway, my current algorithm probably marries different ideas from at least 4 distinct implementations so I'm always glad to see something new even if it's nothing more than different words to the same tune.  Smiley
16  Game Development / Newbie & Debugging Questions / Re: Help in new to java can you lead me in the rig on: 2003-12-13 21:29:47
If you're asking about a development environment, I would suggest using eclipse at http://www.eclipse.org.  It's free and IMO better than the majority of commercial Java development environments out there.  It's one Achilles heal, however is the lack of an integrated GUI builder, but plugins for that are in the works.  That said, I've never really had much use for a GUI builder personally.  Probably only really necessary if you're doing more traditional 2D applications.
17  Java Game APIs & Engines / Java 2D / Re: OMG it is still flickering. on: 2003-11-24 14:54:16
Is this the latest and greatest scroller code by chance?
https://misc-demos.dev.java.net/source/browse/misc-demos/

I was just looking at it recently which is why I had it handly.  By the way, thanks for the great example Jeff, it's helped me out quite a bit in learning some of this stuff.
18  Game Development / Performance Tuning / Re: An efficient discrete step timing loop. on: 2003-11-20 15:47:25
Here is my implementation of the hidden high performance timer in 1.4.2.  There has been alot of discussion about it already in the various forums if you want more information about it.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
public class PerfTimer
{
      private sun.misc.Perf hiResTimer;
      private long freq;
     
      public PerfTimer()
      {
            hiResTimer = sun.misc.Perf.getPerf();
            freq = hiResTimer.highResFrequency();
      }

      //return the number of nanoseconds per clock tick
     public long getResolution()
      {
            return (long)((1.0/freq) * 1000000000L);
      }

      //return the current time in milliseconds
     public long getCurrentTimeMillis()
      {
            return hiResTimer.highResCounter() / ((freq + 500L) / 1000L);
      }
}
19  Game Development / Performance Tuning / Re: An efficient discrete step timing loop. on: 2003-11-20 05:54:00
Well "unit" isn't an actual variable or anything.  It's just the distance you want to move in a given amount of time.  That could be 200 pixels per second or 1 inch per minute, etc.  So, in the example, clientTick is the actual framerate you get that may or may not fluctuate wildly from one second to the next, while gameTick is sort of the theoretical, constant framerate that you want to achieve a.k.a the "unit" value.  The interpolation mechanism, then, sort of works as an intermediary between the actual and theoretical framerate to keep the sprite moving at constant "unit" increments.  Thus, if you want ALL of your movement to appear to move faster, you would increase your "unit" value, which, in the case of the example given would be the value of GAMETICKS_PER_SECOND.  Anyway, that's my current understanding of it...
20  Java Game APIs & Engines / Java 2D / Re: OMG it is still flickering. on: 2003-11-18 16:16:19
Hmmm, I ran it on my box and to me it actually doesn't look like it's flicker per se...more like it's skipping a few pixels every so often as it slides back and forth.  It seems to me you need a way to interpolate the position of your spaceship so that when your framerate drops, your ship doesn't "hop" so much.  Maybe this thread might help?  http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=Tuning;action=display;num=1058296748

And maybe a couple of other ideas if that's not it.  Did you double check that your JFrame's double buffering didn't get turned of by checking isDoubleBuffered()?  Also is pScene.repaint() trying to paint the entire window?  You might already know this but you would get much better performance just repainting the square surrounding the spaceship if this is not already the case.
21  Java Game APIs & Engines / Java 2D / Re: Scroller suggestions on: 2003-11-18 15:04:25
Well, I don't have much experience with tiles, but for my little window-mode space scroller, I keep a sorted ArrayList of regions that don't contain a sprite.  Since my sprites cover 80-90% of my background (which is actually generated on the fly) at any given time, this seems to work pretty well for me.  Thus, as I go through and draw my list of sprites, I store a rectangle of the region between each individual sprite, sort it and then paint the background as appropriate at the end.  Maybe a sort of pseudo-tile implementation?  Anyway, like I said, it seems to work well for me because 1. My background is fairly simple (black with white pixels for stars) and 2. My sprites cover the majority of the background most of the time.  Anyway, don't know if any of that is useful to you, but it's what I know.  Good luck on it.
22  Java Game APIs & Engines / Java 2D / Re: Your votes please on: 2003-11-13 21:42:35
If you haven't been over to check out the discussion in the javalobby link above, Chet wrote a very nice explanation of the reasonings for and uses of the various APIs on the different platforms.  At least it's the most comprehensive explanation I've seen in any one spot.

Anyway, I'm with swpalmer, all I want for Christmas is hardware accelerated transforms whatever the underlying API might be.
23  Game Development / Performance Tuning / Re: Windows tooltips/menus hammer 2D drawing on: 2003-11-12 14:30:40
Wow, thanks.  The information and ideas are very much appreciated and more than I could have hoped for.

Anyway, part of the initial angst over this occurred when I suddenly realized that my new, cool, clever animation loop was neither cool nor as clever as I had hoped.  It suffered considerably with this particular fluctuation of framerate.  Thus, I was forced to take a hard look at it again and as a result, I'm happy to report my overall animation code seems to be much more solid now.  I was able to incorporate some of Marcus_Persson's excellent interpolation ideas from his descrete step timing loop thread as well as a few techniques from Jeff's scroller example for controlling framerates.

Anyway, I have also been trying a few of the additional switches you suggested and so far results seem to be as you predicted.  I didn't notice any difference with -Dsun.java2d.noddraw=true coupled with:
-Dsun.java2d.ddoffscreen=false
-Dsun.java2d.gdiblit=false
-Dsun.java2d.ddlock=true

However, one interesting phonomena I noticed; if I remove the noddraw flag above, but leave the others there, all tooltips external to Java flicker wildly including those in the Windows toolbar.  Tooltips internal to Java seem unaffected, though, and my framerate remains the same as noddraw=true in this case.

In any event, I've added a little dialog that will allow the user to turn off DirectDraw at the expense of some eye candy, if it is an issue for them and they are unwilling to tweak the fade effects in Windows which does seem to make a big difference.  And with the excellent explanation and UT benchmarks (Thanks Abuse, it never occurred to me to try another DirectX application such as Unreal Tournament) I have some ammunition in the event that anyone actually notices the performance hit and calls me on it. Cool

Many thanks to all.

-Immudium
24  Game Development / Performance Tuning / Re: Windows tooltips/menus hammer 2D drawing on: 2003-11-11 05:15:40
Welcome back!  I hope the fresh air and sunshine did you some good.

Anyway, my monitors refresh rate is set at 85Hz.  However, since I last posted I've had the chance to run my code on two additional test machines, both of which are similarly configured to my own (WinXP, DirectX 9, 512+ MB memory, NVidia video cards with identical video drivers and greater than 2GHz CPUs) and although both take a hit when tooltips show, neither seems to suffer nearly as much as my development system.  That said, the only real hardware difference my machine has that the other two do not is the use of Rambus system memory.  Perhaps it has a hard time simply due to the high latency nature of Rambus and perhaps not.  I wish I could test on another Rambus based system, but they have always been a little scarce and remain so especially now.  However, even with this blatant, non-scientific shot in the dark, setting -Dsun.java2d.noddraw=true absolutely fixes any hits to my framerate resulting from Windows tooltips, so the problem is definitely in DirectDraw somewhere.  Doesn't make any sense to me.  Perhaps it's nothing more than "Wall of Weird" material. [EDIT] I.e. if you're not familiar with Smallville, not something to forget about, but rather something you set to the side and look at every once in a while and say "Huh, that's kinda weird"  And then go back to your normal Java2D blissful routine until one day it decides to attack while you're taking a swim by yourself in the high school gym in the middle of the night. [/EDIT]
25  Java Game APIs & Engines / Java 2D / Re: CreateCompatibleImage using different bit dept on: 2003-11-10 16:58:53
Excellent, thanks for the clarification.  So GraphicsConfigurations do enumerate pixel formats as I thought they should, it's just that Windows doesn't really allow mixing different bit depths hence all the GCs returning 32 bits.  That also answered a number of other questions I had about the GC.  I always felt uneasy about simply calling getDefaultConfiguration to select the GC wondering if I was missing out on or not taking advantage of a more appropriate GC for what I wanted to do.  Now I know, at least on Windows, that they're all pretty much the same.
26  Game Development / Performance Tuning / Re: Windows tooltips/menus hammer 2D drawing on: 2003-11-07 16:50:21
OK, here's the stack traces from OptimizeIt.  The first one shows me leaving the mouse in one spot so that it doesn't accidentally hit anything that might render a tooltip.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
1.17% - 516 ms - java.awt.Component$BltBufferStrategy.show()
            0.16% - 72 ms - sun.java2d.SunGraphics2D.drawImage()
               0.16% - 72 ms - sun.java2d.SunGraphics2D.drawImage()
                  0.16% - 72 ms - sun.java2d.pipe.ValidatePipe.copyImage()
                     0.16% - 72 ms - sun.java2d.pipe.DrawImage.copyImage()
                        0.16% - 72 ms - sun.java2d.pipe.DrawImage.copyImage()
                           0.16% - 72 ms - sun.java2d.pipe.DrawImage.copyImage()
                              0.16% - 72 ms - sun.java2d.pipe.DrawImage.renderSurfaceData()
                                 0.16% - 72 ms - sun.java2d.pipe.DrawImage.blitSurfaceData()
                                    0.01% - 5 ms - sun.java2d.loops.Blit.getFromCache()
                                       0.01% - 5 ms - sun.java2d.loops.RenderCache.get()


In this second one I am simply hovering my mouse over the various icons in my taskbar.

1  
2  
3  
4  
5  
6  
7  
8  
9  
82.91% - 34324 ms - java.awt.Component$BltBufferStrategy.show()
            82.63% - 34207 ms - sun.java2d.SunGraphics2D.drawImage()
               82.63% - 34207 ms - sun.java2d.SunGraphics2D.drawImage()
                  82.63% - 34207 ms - sun.java2d.pipe.ValidatePipe.copyImage()
                     82.63% - 34207 ms - sun.java2d.pipe.DrawImage.copyImage()
                        82.63% - 34207 ms - sun.java2d.pipe.DrawImage.copyImage()
                           82.62% - 34202 ms - sun.java2d.pipe.DrawImage.copyImage()
                              82.62% - 34202 ms - sun.java2d.pipe.DrawImage.renderSurfaceData()
                                 82.62% - 34202 ms - sun.java2d.pipe.DrawImage.blitSurfaceData()


There is more to the stack trace that I can show, but these seemed to be the most different in execution time.  Is there anything to explain this?
27  Game Development / Performance Tuning / Re: Windows tooltips/menus hammer 2D drawing on: 2003-11-07 15:22:19
Hi swpalmer,
I initially thought it could be a conflict with heavyweights and lightweights in java, but the real blow to performance are really all the external windows tooltips and menus that I have no control over from within Java.  And the real kicker is when I add the flag "sun.java2d.noddraw=true".  Theoretically I should lose all hardware acceleration when that flag is enabled, but when I do so, there is no performance hit whatsoever from any external Windows XP controlled menu, tooltip or drawing.  And what's even better is that even though my total frames are less when that flag is enabled, my overall performance is more stable with sun.java2d.noddraw=true overall.

For some tangible numbers, with the default setting sun.java2d.noddraw=false my total fps will drop from over 300 fps to under 100 fps by just hovering my mouse over the system clock and allowing the tooltip to show.

With sun.java2d.noddraw=true, my total frames are at 150 fps and stay at 150 fps no matter what external windows tooltips or menus are being shown.  

It would seem, then, that there is something terribly wrong with DirectDraw in Java2D in windowed mode.  Perhaps directdraw cannot coexist peacfully with GDI?  But if that's the case, it seems to me sun.java2d.gdiblit=false would help matters when directdraw is enabled but it doesn't help anything.

Anyway, I'm going to try to run Borland's Optimizeit and see if I can spot anything.  Any ideas on what I should be looking for?
28  Game Development / Performance Tuning / Windows tooltips/menus hammer 2D drawing on: 2003-11-06 16:32:00
This may have been asked before, but for the life of me I can't find a fix or workaround.  I have an app in Windowed mode, using ManagedImages for sprites that are animated with a Canvas using a BufferStrategy of 3.  It hums along just lovely at about 300 fps until the off chance that the mouse "lingers" over an icon or anything that has a tooltip.  Once that tooltip pops up frame rate goes to hell even if my main java window still has the focus.  Once the tooltip's time is up and goes away everything returns to normal.  Menus hurt performance quite a bit as well outside of the app, but java menus within the program don't.  I'm not too concerned with the menus hammering drawing, but the tooltips are everywhere, the system clock, the taskbar, etc.

I've tried adding sun.java2d.ddforcevram=true and sun.java2d.translaccel=true as well as any other obscure 2D argument I can find to my VM arguments and none seem to make any difference at all.

I am using WindowsXP and JDK 1.4.2_02-b03.  The video card is an NVidia 5200 using the latest 52.16 drivers.  I can post any of my souce code if you think it might help, but I am just using a pretty general, frame-limiting animation loop using the Perf timer that has been discussed pretty extensively here in the Java2D forum.  Images are created using gConfig.createCompatibleImage(width, height, Transparency.OPAQUE)  Is this a pretty common problem, or am I missing something obvious or doing something wrong?

Thanks for any ideas.   Smiley
29  Java Game APIs & Engines / Java 2D / Re: CreateCompatibleImage using different bit dept on: 2003-11-02 20:43:05
Thanks for the info.  It seems like it should work, but it only returns 32 for every gc.  I can't seem to crack this nut.  However, the more I've thought about it the more I wonder if it's worth the effort.  If the desktop is in 32 bit mode, I wonder if there is actually any performance improvement in drawing images using 16 bits other than the reduced memory requirement.  And even then I wonder if the desktop/video card/whatever would just convert the 16 bit into a 32 bit image before displaying it anyway.  My main intention was to experiment, but it doesn't appear as this is even a possibility currently.
30  Java Game APIs & Engines / Java 2D / CreateCompatibleImage using different bit depths on: 2003-10-30 18:48:42
I've noticed that on older video cards I can a achieve a significant increase in frame rate in window mode if I set the desktop from 32 bits to 16 bits, for example.  However, I'm wondering if it's possible to achieve the same "effect" by enumerating through the GraphicsConfiguration array return by GraphicsDevice.getConfigurations() and then selecting the gc that corresponds to the desired bit depth.  The idea is to allow the user the select a "performance" or "quality" mode based upon the speed of their hardware.

However, all of the GraphicsConfigurations returned seem to contain no distinguishing information, but if I watch them in the debugger, I can see that each GC is in fact a sun.awt.Win32GraphicsConfig and that each one contains a variable call "pixel_fmt" that seems to contain the desired bit depth information I'm looking for.  However, since this class is not exposed, this is obviously the wrong way to obtain the information.  Calling gc.getColorModel().getColorSpace() returns 24 for each one.

So anyway, is there a way to get the supported bit depth for a particular GraphicsConfiguration through the abstraction?  Or is my understanding of the purpose of the GraphicsConfiguration wrong?  Is there a better way to obtain an accelerated image for n bits of color without forcing the user to change their desktop color space than what I'm trying to do?  Or is this not even a possibility technically?

Thanks for any help.
Pages: [1] 2
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

ctomni231 (33 views)
2014-07-18 06:55:21

Zero Volt (29 views)
2014-07-17 23:47:54

danieldean (24 views)
2014-07-17 23:41:23

MustardPeter (26 views)
2014-07-16 23:30:00

Cero (41 views)
2014-07-16 00:42:17

Riven (43 views)
2014-07-14 18:02:53

OpenGLShaders (31 views)
2014-07-14 16:23:47

Riven (30 views)
2014-07-14 11:51:35

quew8 (29 views)
2014-07-13 13:57:52

SHC (65 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!