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?

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.

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.

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.

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.

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.

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.

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.

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

Graphics2Dg = (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).

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.

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

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