StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POStrange BufferStrategy issue - Game runs fast only on Intel GPUs
text
Body
copied!<p>I ran into a very strange problem, I tried searching for an answer for days and days. My game just got a new particle system, but was too slow to be playable. Unfortunately, BufferedImage transformations are very slow. The explosion effect consists of about 200 white sprites loaded from a .png file, rotated, scaled and coloured randomly, moving with a random speed.</p> <p>I tried to make the performance better with triple / double buffering, and ran into some problems.</p> <p>My first try was with the JPanel the game was drawn on. I set up the buffers in the JFrame's class (Main), then done the drawing in the Game (extends JPanel) class, BUT, without Graphics g = bufferstrategy.getDrawGraphics();. Then, at the end of the drawing method, i showed the buffer IF it wasn't lost. The buffer was always "lost", as I didn't do the drawing with it's Graphics object. But! The game run as fast as hell! With no buffer in practical use! But how?</p> <p>This try ended up with no graphical errors, and with a HUGE performance boost - but only on nVidia / AMD cards. Intel GPUs couldn't handle this, the screen was flashing white.</p> <p>So, i ended up setting and using the BufferStrategy correctly. The Game class now extends Canvas, not JPanel, as getting the Graphics from a JFrame, and using it to draw on a JPanel ends up in an offset, as it is drawing under the title bar. Still fast, fix 60 FPS.</p> <p>Now, when i created the BufferStrategy in the JFrame (Main class), there was no picture at all. I corrected this by setting up the BufferStrategy in the Game class (Canvas). The picture is correct now, but the game itself is slow like a snail. One explosion tears the FPS down to ~10, but only on nVidia / AMD. Ironic. Even old Intel GPUs handle it with 60 FPS, i managed to get 10000 particles in motion at 60 FPS on a 5-6 year old integrated Intel GPU. My card bumps up to 100% load when an explosion occurs.</p> <p>Here is my major code (the whole code is unclear and long) :</p> <pre><code>public class Game extends Canvas { -snip- public void tick() { BufferStrategy bf = getBufferStrategy(); Graphics g = null; try { g = bf.getDrawGraphics(); paint(g); } finally { g.dispose(); } if (!bf.contentsLost()) { bf.show(); } else { System.err.println("Buffer lost!"); } Toolkit.getDefaultToolkit().sync(); } public void setBuffers() { GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); GraphicsDevice gs = ge.getDefaultScreenDevice(); GraphicsConfiguration gc = gs.getDefaultConfiguration(); if (gc.getBufferCapabilities().isMultiBufferAvailable()) { createBufferStrategy(3); System.out.println("Triple buffering active"); } else { createBufferStrategy(2); System.err.println("Triple buffering not supported by the GPU"); System.out.println("Double buffering active"); } System.out.println("FullScreen required: " + getBufferStrategy().getCapabilities().isFullScreenRequired()); System.out.println("Page flipping: " + getBufferStrategy().getCapabilities().isPageFlipping()); } public void paint(Graphics g) { super.paint(g); //set up RenderingHints, draw stuff } -snip snip- } </code></pre> <p>Of course, I call setBuffers() as soon as the Game is started.</p> <p>I hope you can help me, this problem is very important, as using VolatileImage in my opinion won't give a performance boost, as image manipulating needs to be done using BufferedImage. I bet I'm missing something trivial, or doing something the wrong way.</p> <p>Here are my computer specs, just to show it's not a hardware problem: Intel Core i7-3770k @ 4.3GHz, nVidia GTX 460, 12 GB ram</p> <p>The "fast" computer: Intel Core 2 Duo @ 2.7 GHz, Integrated Intel Graphics, 2 GB ram</p> <p>Thank you for your help and time! :)</p> <p><strong>EDIT</strong> Could VolatileImage help? If I know right, image manipulation must be done using BufferedImages, but drawing them is sluggish.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload