I’m a beginner in Game development using Java.
At first, I would like to create a simple scroller game in FSEM mode. I own both books “Killer Game Programming in Java” and “Developing Games in Java” and I have also read many articles and forum threads regarding Window/Fullscreen mode in Java2D, Buffer strategy, etc etc.
However I still have many questions.
I would like to create a game which switch into FSEM mode if available. A game feature would be the ability to switch between window and FS mode (if available). However many window game examples use a JPanel inside a JFrame using active rendering. In my case (window+FS), I think I don’t need any Panel, esp when using BufferStrategy. Only a JFrame would be required. Am I right?
When using bufferstrategy, I use a Graphics2D object (in my main JFrame) for the buffer, and I get the graphics context directly from BufferStrategy (also created in the JFrame).
In window mode, it would use active rendering and in FSEM it would use page flipping (if available), right? (createBufferStragegy would always choose for the best rendering mode) However, I’ve noticed I should re-init the BufferStrategy creation after switching from Window mode to FSEM and vice versa :
(switching to window/FSEM mode)
createBufferStrategy(3);
bufferStrategy = getBufferStrategy();
Using setIgnoreRepaint(true). Some examples use the method setIgnoreRepaint() in FSEM mode. Is it really useful (esp when disabling decoration)? What about this method in window mode? I think I shouldn’t use this.
My last question focuses on images when using BufferStrategy.
I’ve seen many examples using any of the following classes : Image, ImageIcon, BufferedImage and VolatileImage.
Should I opt for BufferedImage for my sprites, etc (read through ImageIO) in my project (with BufferStrategy)?
BufferedImage is used to be the most compatible. Image is a super-class you can use to make ref on the images intances. VolatileImage is used to be the fastest because of the direct VRAM it allocates. Finally, ImageIcon can be the fastest way to add some animated-painting : it supports .gif animation.
Unless you really need Swing for something I would suggest using
AWT’s Frame instead, with BufferStrategy, in both FS and windowed mode.
Actually, unless you want to fiddle with Frame insets in windowed mode
I would suggest using a Frame with Canvas for windowed mode
(and create your BS from Canvas), and use undecorated Frame
for FS mode (and create the BS from the frame).
That looks correct - although there’s not enough context to
tell for sure.
The main point is: do not cache the graphics object you get from
the BS. Always get a new one in your loop.
You’re right in that createBufferStrategy will create the best BS for you
given the number of buffers you asked for.
Note, however, that in some cases asking for 3 buffers may result in
getting a non-accelerated BS (especially in windowed mode). You might
want to check the BS’s caps
(see BufferStrategy.getBufferCapabilities() )to make sure it’s accelerated.
If it’s not, create a BS with two buffers.
It will not hurt to recreate the BS when changing from FS to windowed
mode, although it shouldn’t reallybbe necessary.
Although if you’re switching back and forth between FS and windowed
mode and also adding/removing decorations (for which you’ll have to
dispose() the FS frame) you may actually have to
recreate it.
If your application uses active rendering (meaning that you have
your own rendering loop that’s driving the animation) disabling repaint is a good
idea. Doesn’t matter if it’s FS or windowed mode.
In FS mode make absolutely sure you remove the decorations.
You may run into issues if you don’t. It is an unfortunate
glitch in the api that decorated frames are allowed in fs mode.
And do use Frame, not Window for your fullscreen window - another
API fart. We should have only allowed Frames as FS window.
Load your sprites using ImageIO. VolatileImages are really only needed
if you want to render part of your scene into something other than
back-buffer and then reuse it or something. It could also be used as
a backbuffer but BufferStrategy is better suited for that.
You can also roll your own sprite support using VolatileImages.
Like, load sprites using ImageIO, then copy them into a VI and
discard the loaded image thus freeing system memory. But I would
suggest against it as it’s too much hassle - just use ImageIO for your sprites.
The implementation will cache them in vram when possible.
One note: with jdks older than 6u10 (download a build from jdk6.dev.java.net)
only opaque and bitmask images are hw accelerated by default
(unless you’re in full-screen mode on windows, then everything
is accelerated).
So you might want to use translucent images sparingly - only where
needed.
In 6u10 (when it’s out) the default windows pipeline will hw accelerate
any kind of images (along with a lot of other stuff).
It depends on the type of game you’re building. If it is not a
fast paced shooter or something you can build it as Swing application
and use Swing repainting mechanism.
But in general there’s not much sense in using Swing top level
windows if your app is not swing. You will just pull a bunch of
classes you don’t really need, making your application start
slower and use more memory.
If you are not using any decorations in windowed mode then you won’t need Canvas.
Even if you do use decorations you don’t have to use Canvas, you’ll just need to
adjust your rendering for Frame’s insets (rendering a 0,0,width,height line
in a frame will result in a line with 0,0 at the frames top left corner,
not at the top left corner of the client area)
Some folks like to create an object once and then
reuse it forever, thinking that it’ll improve performance somehow.
Like, get the graphics context once when the BS is created,
stuff it into a field and use it in the rendering loop.
Firstly, there’s no advantage in caching graphics objects,
they’re really lightweight and don’t have any native
resources. Secondly, specifically for BufferStrategy:
it is validated during the getDrawGraphics() call, so
if you don’t call it in your loop bad things will happen.
