Best way to make a 2d application

Newbie & Debugging Questions
#1

Howdy! I’m a fairly experienced C/C++ programmer, and I’ve made some simple game demos using openGL, but I’m currently writing a game for a college project using Java. I’ve done a lot of looking around for information on all the 50 billion different ways of making windows and drawing little bitmaps on them, and I’ve decided the following:

  1. AWT sucks, so I want to use only Swing instead.
  2. Swing automatically uses hardware accelerated backbuffers using volatileImage.
  3. I don’t want to use any external .dll files or classes.
  4. I don’t see any point using openGL for 2d if Java2D and Swing are just as fast.
  5. I want to use an application, not an applet.
  6. JFrame is the best container to use.
  7. compatibleImage is the best way to make hardware accelerated sprites.

So, what’d be a good framework? Would my main class extend JFrame, or could I include the JFrame as a private variable inside my main class? Where would I implement the event and keyboard listeners? And how do I load and draw compatibleImages?

In short, could somebody point me to either a good tutorial, or show me a good code snippet for a basic framework?

#2

[quote]2. Swing automatically uses hardware accelerated backbuffers using volatileImage.
[/quote]
Actually SWING uses AWT for its rendering so someone has lead you astray.
By definition SWING can’t do anything that AWT doesnt do (at least currently.)

Okay so these are your givens.

This is a good thing as it avoids many problems.

Best for what? (See below)

Okay. so now its time to straighten you out a bit. As mentioned above, Swing is a just a layer over AWT. if you arent doing window/component GUIs there is really little point to it.

I am assuming you want to make a 2D game or other graphics intensive 2D application.

What you want to look at is active rendering with AWT. This is covered in the (somewhat misnamed) FullScreen tutorial here:

http://java.sun.com/docs/books/tutorial/extra/fullscreen/

These techniques actually work in full screen or windowed mode. For an example of a game skelleton that runs in either mode you can look at the Scroller demo. (I believe its on the Wiki, if you can’t find it there search for “Scroller” here as the URL has been posted multiple times.)

A fair warning thing: This technique works great under 1.4 under Win32. I believe Dmitri said it works about as well as it can under X given X’s limitations. Last time I tried it on the Mac it sucked performance-wise but Apple considers that a bug and is aware of it. I don’t know if its been fixed yet or not.

#3

This is not always true. On some platforms (windows) if an image goes over a given size even thought it will fit in the graphics card memory its not put there. For simple sprites compatibleImage fine but for big ones you might want to consider creating your own VolatileImage and managing it yourself.

Kev

#4

Helpful tip: Stick to 256x256, and pack your sprites into these images.

Cas :slight_smile:

#5

Just to be clear…basically, AWT is two things: the underlying native code to do windows images etc, plus the toolkit/widget-set/whatever-you-call-it :slight_smile: on top. Swing is an upgrade to the second part, but does none of the first part.

Hence, as Jeff said, “Swing uses AWT for it’s rendering” but if you are going to use anything in AWT that you can do in Swing it’s nearly always better to use Swing (this is a gross generalization, and java.sun.com has a tutorial specifically looking at this question in more detail, IIRC). The main reason for using Swing is that it has many of the same classes as AWT BUT WITH FEWER BUGS (some major bugs in AWT just didn’t get fixed for many years because Swing had already come along). Swing also re-designed parts of AWT to be easier to use, better designed, more responsive, more feature-rich. In particular, the code you have to write to get your Panel/Canvas/whatever to “paint()” anything non-trivial is significantly less painful in Swing than in AWT.

IMHO, if your game is going to have in-game menus which are used once the game has started (e.g. AlienFlux’s menus are only accessible when the game is over; freerails menus are available all through the game) then it’s worth using Swing if your alternative is to use AWT, and you aren’t going to OpenGL everything. Ditto if you expect to have multiple rendering panels in a non-trivial arrangement (e.g. a complex inventory for an RPG, perhaps with nested containers). Just my 2 cents.

#6

[quote]AlienFlux’s menus are only accessible when the game is over
[/quote]
Actually they can be used whenever or wherever… I use a very complete windowing toolkit in AF (vastly overengineered really). I just didn’t put the menus in the middle of the game.

Cas :slight_smile:

#7

Sorry, I meant in a gameplay sense. I.e. it’s not a game where you’ll expect to use those menus in the middle of a game :).

#8

Thanks for all the replies. To clarify things a bit, I don’t want to use AWT because everyone seems to be saying Swing is faster and prettier because it extends AWT’s functionality. For rendering in my game all I need to do is make a window, (in windowed mode) and draw small color-keyed sprites to it. (as quickly as possible too) If I could have some very simple menus on top of all that it would be bonus points, but I could just make menus with bitmaps too.

I’ve been doing some research on Swing, and it looks like JFrame is the actual main window of a Swing application, and it needs to have a JPane attached to it that you actually do the drawing on. Would it be a good idea to have my main class extend JFrame and implement runnable? Or should I have a seperate class that extends JFrame and includes a JPane as a private variable, and have my main class extend runnable? Or do I need runnable at all? And does Swing do double buffering automatically?

If somebody could hook me up with a good tutorial or show me a piece of code that makes a simple windowed rendering loop with Swing I would greatly appreciate it. And thanks for helping me out and all.

#9

Swing will do double buffering automagically, but its not very practical for game use. Instead you’ll be better off using a BufferStratergy and sticking that in a JFrame. Use of a BufferStratergy also allows you to hide any differences between windowed and fullscreen modes.

Actually, now I think about it you need some sort of component to create the buffer stratergy on. I seem to remember using a Canvas for windowed mode (and ironically a Window for fullscreen mode).

#10

What exactly is a bufferStrategy? Does it use volatileImage for back buffering? I remember reading on Sun’s main site that Swing uses volatileImage for back buffering, so that’s why I assumed I should use it.

#11

http://java.sun.com/j2se/1.4.2/docs/api/java/awt/image/BufferStrategy.html

I’m pretty sure it does use VolatileImages behind the scenes for the surfaces. The main advantage is that you manually control the flipping - draw your scene then manually call show() to display it. And in fullscreen mode it lets you use v-sync and the show() can use a proper pointer swap instead of the blit for better speed and consistancy.

#12

Is it possible to use VSync in windowed mode?

Also, I still really need to know if I my main class should extend the JFrame, or if it should include the JFrame as a private variable. I basically just really need to find a good tutorial for making the basic framework.

#13

It will vsync IF the underlying system supports it.

Win32 does not support Vsync for BLT to windows. Period.

The two resources I pointed you at (Mikes article and my Scroller example) should have all the examples you need. Mikes article also explains what a BufferStrategy is. Go and read then come back here with specific questions.

#14

[quote]Win32 does not support Vsync for BLT to windows. Period.
[/quote]
Ahh - now the funny thing is, I told this to my dad the other day, and he went ahead and showed me I was wrong with 1 line of code. I don’t know if it universally works but I’m going to look into it.

Cas :slight_smile:

#15

One of the members here is an author writting a 2d Java game programming book using 1.4.2. He posted the first chapter so you might want to look at it for some good examples. Note he also does not use anything that is not pure Java, so some of his solutions are creative, but some are not very the best way of programming as of 1.5 (like the thread.sleep work around which is no longer needed now that there is nanoTime(), also using a sleep loop instead of gametick / cienttick approach) Check the link here:http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=2D;action=display;num=1075798524

#16

Well properly DirectDraw does not support it.

With OGL for instance, I dunno.

#17

Too bad it is a whole line of code , or you could have posted it here ::slight_smile:

#18

Actually it is a directdraw call, I just can’t remember what it is… something like

DD.WaitForVerticalBlank DDWAITVB_BLOCKBEGIN, 0

Used to be in the LWJGL but we took it out when I got rid of the DD init code. Might put it back in so we get vsync in windowed mode.

Cas :slight_smile:

#19

HM.

Just because a call exists in the Win32 doesnt mean it actually works and certainly doesn’t mean it works under all circumstances. I know of plenty of API calls that don’t.

I’d be curious to hear Chet or Dmitri’s comments on this since I got my info from the 2D group…

JK

#20

It’s worth a try I think, it’s a neat little feature.

Cas :slight_smile: