Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Game graphics  (Read 2423 times)
0 Members and 1 Guest are viewing this topic.
Offline saus

Junior Newbie





« Posted 2009-02-17 03:25:02 »

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?
Offline Swattkidd7

Junior Member





« Reply #1 - Posted 2009-02-17 04:10:47 »

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

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #2 - Posted 2009-02-17 06:00:21 »

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.

See my work:
OTC Software
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Del-ONE

Senior Newbie





« Reply #3 - Posted 2009-02-17 06:05:44 »

I think I had similar problems when I started using java for games, here's what I generally did (in some form or another)
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  
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...

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.

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.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #4 - Posted 2009-02-17 08:41:37 »

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.
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.

See my work:
OTC Software
Offline Del-ONE

Senior Newbie





« Reply #5 - Posted 2009-02-17 16:34:40 »

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.

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. 
Offline saus

Junior Newbie





« Reply #6 - Posted 2009-02-17 20:29:04 »

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.
Offline h3ckboy

JGO Coder


Medals: 5



« Reply #7 - Posted 2009-02-17 22:29:04 »

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.
Offline Hsaka
« Reply #8 - Posted 2009-02-17 23:40:30 »

Quote
What is the difference between paintComponent and paint?

What is the difference between overriding paintComponent/paint and this way of doing it:
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.

This post may be helpful for you, in particular CommanderKeith's post about threads and event handling:
http://www.java-gaming.org/topics/about-game-loop/19902/view.html

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.

1  
2  
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.

1  
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.

1  
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.

1  
strategy.show();

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

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #9 - Posted 2009-02-18 06:25:49 »

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. 
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.

See my work:
OTC Software
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline damaxxed

Senior Newbie




I ♥ Prototyping


« Reply #10 - Posted 2009-03-05 23:47:47 »

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
1  
2  
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..
1  
Graphics2D g = (Graphics2D)strategy.getDrawGraphics();


When we finished drawing, we release all the used resources, by finishing the flip-book page
1  
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.
1  
strategy.show();
Offline Darrin

Junior Member


Projects: 1



« Reply #11 - Posted 2009-03-06 19:10:17 »

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.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

E.R. Fleming (20 views)
2014-07-29 03:07:13

E.R. Fleming (8 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

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

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

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

MustardPeter (45 views)
2014-07-16 23:30:00
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!