Game graphics

Newbie & Debugging Questions
#1

Graphics have always been confusing to me since the beginning of my java experience. After some reading I understand that the whole Graphics thing is first sent to some sort of event handler, where it is actually drawn on the screen.

I was getting along fine by trying things and tweaking it until it worked, until I tried to make a real game, with a lot of things going on, and more complex controls and movement. I ran into some problems due to the gap between my understanding of what was going on and how Graphics actually worked. I eventually worked around it, but it was ugly. I thought concurrency would solve my problems, but that was just horrendous.

Since then I’ve been afraid of Graphics. I felt like there should be a more tame version of Graphics, or there must be at least some sort of convention when working with it that I wasn’t aware of.

I try to read tutorials, but reading tutorials is how I got in the position I am in, so I’m not so sure what is good and what isn’t, what I can combine and what conflicts. I also looked into full screen and it seems like that might be simpler to deal with, but I guess you could say I’m afraid that I’ll learn all about it and end up having a useless heap of knowledge that I can’t handle.

It just seems so confusing and wrong to me that I feel like I’m missing something. So how do “real” java game programmers implement graphics without running into problems when dealing with graphics that are relatively mundane for games?

#2

Im not quite sure what you mean? Do not really understand what your problem is. What are you trying to do?

#3

Graphics is pretty easy to deal with (assuming you’re talking about java.awt.Graphics).

Basically, every time step or so you call repaint() within any JComponent. The component should also override its paintComponent(Graphics g) or paint(Graphics g) method, and in there you should draw everything out. Whatever you draw last appears on top. There’s not much more to it.

#4

I think I had similar problems when I started using java for games, here’s what I generally did (in some form or another)


class Game extends Canvas implements KeyListener
{
    public Game()
    {
       JFrame frame = new JFrame("The Tomb of Argmet");
       frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
       JPanel panel = (JPanel)frame.getContentPane();
       panel.setLayout(null);
       panel.setPreferredSize(new Dimension(505,505));
       panel.setBackground(Color.black);
       addKeyListener(this);
       setBounds(25,25,480,480);
       panel.add(this);
       setIgnoreRepaint(true);
       frame.pack();
       frame.setResizable(false);
       frame.setVisible(true);
       requestFocus();
       createBufferStrategy(2);
       strategy = getBufferStrategy();
   }
   public void loop()
   {
      while(true)
      {
         Graphics2D g = (Graphics2D)strategy.getDrawGraphics();
          long delta = (System.nanoTime()-lastLoopTime)/1000000;
          lastLoopTime = System.nanoTime();

         //update logic
         //draw screen

         g.dispose();
         strategy.show();

         try{Thread.sleep(100);}catch(InterruptedException e){}
      }
   }
}

Basically you just take the Canvas as your starting point, leave the Graphics code as a black-box situation, and lay things out exactly how you want. I believe I picked this up from http://www.cokeandcode.com/spaceinvaderstutorial which is a really great tutorial for starting with java gaming.

I almost always used entity/widget/holder classes that over-ride a draw(Graphics g) and/or update(long delta) so I could just pass the Graphics down (events too). Oh and if you haven’t heard, plain Java and images don’t seem to be on friendly terms.

Oh, there’s something else you can throw into Thread.sleep() to get steady fps, but its simple and I don’t want to reboot to look it up at the moment…

I don’t like doing that after a few to many fights to get java to let me place things like I want, but that was before I knew setLayout(null) would get me absolute positioning. Having to recreate text-boxes/progress-bars/buttons on your own is also good experience.

#5

If you just draw things in the component you can do whatever you want, even pixel-by-pixel drawing. Then you can also put various buttons and things around the drawn component too, if you want.

#6

That’s perfectly reasonable, but I’ve always had problems with Java’s layout managers trying to be intuitive and failing miserably with random locations and more especially sizes (again, this is before I found out that I could disable that completely). Being able to throw together a multi-panel layout myself was quicker than arguing. Really though, I would assume that your way is the preferred/standardized way of going about drawing.

Side question: would my implementation have any relevant inherent effects on image-rendering speed? Everyone says Java2D sucks, but a single frame-size background would make my fps plummet from 90 to about 40, which has always struck me as ridiculous.

#7

What is the difference between paintComponent and paint?

What is the difference between overriding paintComponent/paint and this way of doing it:

Graphics2D g = (Graphics2D)strategy.getDrawGraphics();
…
g.dispose();
strategy.show();

Not to mention what is each line doing in the second case? Like what data is in “g”, what data is in “strategy”? How do Graphics2D and BufferStrategy work together?

My problems were mostly from some sort of incongruence between the way I coded painting and key events. They were interfering with each other and weren’t working properly. Maybe I was just coding poorly, but that was a very difficult problem to work around at the time.

#8

g is a variable. okmore accurately it is an instance of the Graphics 2D class. you must understand that all java commands are is just running java vlasses that you imported. so when you do g.drawImage(Image). you runt he method drawImage inside Graphics2D. and then give it the image. and you set it to a strategy so that you can display it later. g.dispose just runs the dispose method wich disposes the Graphics2D instance.

I might be talking crap here so some1 correct me pls if I am completely wrong here.

#9

[quote]What is the difference between paintComponent and paint?

What is the difference between overriding paintComponent/paint and this way of doing it:
[/quote]

[quote]My problems were mostly from some sort of incongruence between the way I coded painting and key events. They were interfering with each other and weren’t working properly. Maybe I was just coding poorly, but that was a very difficult problem to work around at the time.
[/quote]
This post may be helpful for you, in particular CommanderKeith’s post about threads and event handling:

In the code segment, the BufferStrategy stuff is used to achieve Double Buffering, which is a technique for preventing that nasty screen flickering which we all have experienced.


createBufferStrategy(2);  //creates 2 buffers [contiguous areas of memory]
strategy = getBufferStrategy();

with double buffering, an application draws to a single back buffer and then moves the contents to the front (display) in a single step, either by copying the data or moving the video pointer. Moving the video pointer exchanges the buffers so that the first buffer drawn becomes the front buffer, or what is currently displayed on the device; this is called page flipping. 

Graphics2D g = (Graphics2D)strategy.getDrawGraphics();

strategy.getDrawGraphics() returns the graphics on the drawing buffer. It return a Graphics object which we cast into Graphics2D for access to those spiffy Graphics2D methods.

g.dispose();

Disposal of the graphics object obtained must be handled by the application.
We keep resetting g to the current drawing buffer at the top of the loop, so there is no need to hold on to it for longer than necessary.

strategy.show();

Makes the next available buffer visible by either copying the memory (blitting) or changing the display pointer (flipping).

#10

Java2D uses software rendering most of the time, which, in short, does suck. There are various ways to accelerate Java2D graphics, but they will never be as fast as something like OpenGL.

That being said, for games you typically should be ignoring Java’s layout stuff altogether. You usually add one JPanel to a JFrame and then do all your drawing coordinate based within the JPanel. No layout management required.

#11

Here comes some dummy explanation, which I would’ve needed at my beginnings…

You can compare the graphic stuff of the game excellently to a flip-book…

First we have to create a digital flip-book, which will display our game gfx: use a JPanel or Canvas for this.

Now we say, that we always use 2 pages of the flip-book at the same time:
One that the video game player is seeing on the screen and the one behind it, that is invisible as long as we draw all the bullets, explosions, … on it. It would really look strange if the player would see how all the effects are drawn on the screen :wink:

createBufferStrategy(2);  //our strategy for a fluid motion: display 1 page and draw on another page => 2 pages
strategy = getBufferStrategy();

Now we create a Graphics2D object, which we can draw on. This is our invisible next page.
By calling g.drawXXX you can draw shapes and images on it…

Graphics2D g = (Graphics2D)strategy.getDrawGraphics();

When we finished drawing, we release all the used resources, by finishing the flip-book page

g.dispose();

Finally, we show the next page of our flip-book to the player(the one that we have been drawing on) and everything starts from the beginning.

strategy.show();
#12

Hi,

Here is a good tutorial and gives some nice base code:

http://www.gamedev.net/reference/articles/article2418.asp

If you want to set your canvas to be smaller than your Jframe you’ll have to get rid of the pack() call and setBounds of the JFrame larger than your canvas.

I got thru the first issue with that but now I’m trying to figure out how objects draw themselves.