Realistic Expectations

General Discussions
#1

Currently, my game renders to a JPanel in a window, by drawing to a bufferedimage and drawing that image to the panel.
It works fine in windowed mode, but flickers in fullscreen. HELP ME. I’m really sick of java recently because I spend more time implementing low level stuff such as sound than I do working on gameplay.

I’ve tried setIgnoreRepaint(true) with every combination. Either it still flickers, or it doesn’t paint anything.
The JPanel doesn’t even center correctly in fullscreen mode. And why can’t you create a BufferStrat from a JPanel???

WHY CAN’T ANYTHING IN JAVA WORK WITHOUT WORKAROUNDS.
Am I wrong to expect this?

The fullscreen rendering is the most pressing of my problems. Hope you can help.

#2

Don’t have fullscreen in your game.

#3

Just to clarify that you do mean flickering, not tearing?

A JPanel by default clears itself to the background color before invoking it’s paint(Graphics g) method.
The clearing occurs in the update(Graphics g) method, override this method and have it just call paint.

On the other hand, tearing is caused by the lack of vsync & can only be eliminated by using a page flipping BufferStrategy in fullscreen exclusive mode.

As for why you can’t use BufferStrategy with a JPanel, who knows; it could be an intentional decision - all Swing components are afterall exclusively light-weight.
Alternatively it could simply be an unintentional limitation caused as a by-product of it’s class heirarchy not decending from the 2 components that support BufferStrategy - Canvas & Window.

If you are writing games in Java & don’t want to worry about the low-level stuff, may I suggest that you use one of the many game libraries around.
It isn’t realy the fault of Java or it’s core libraries, that they don’t provide an easy game development platform ‘out of the box’ - it isn’t their intended market.

#4

As Abuse said, its either a background repaint or tearing. For full screen, my money’s on tearing. A BufferStrategy approach will fix this and as you noted, that doesn’t work with panels. I would suggest placing a Canvas in the Frame. You can then get a BufferStrategy from the Canvas.

#5

JPanel is a component that gets painted by a container. The only containers that “talk” to hardware are Frames/Canvas. Hence buffer strategy etc needs to be done from the bit of the window hireacy that talks to and knows about the hardware.

A JPanel should be extended when you are using it as a component… not as the only drawing area generally.

Finally turning off repaint means that you must do all the painting and page flipping yourself. The components with this set to true will not get repainted when made dirty etc.

If you think doing these things are bad in Java, i think you don’t realize how much thats needed in most langs. Also in all langs you often need to learn the dirty details of whats going on underneath when you do things like games. The rendering pipeline is not so bad in java…

#6

Don’t use Java 2D? :slight_smile: You might try Slick.

#7

The reason I don’t use a game library is that most of them restrict you to a single game window. One of the neat features of my now entirely NPC mmo is that you can view 10 characters at once with instances of the camera objects.

I’ve never heard of tearing but that sounds like the cause.
I guess I’ll try the Canvas approach (another couple of days of conversion). Thanks.

#8

My guess would be that someone thought, “Swing does double-buffering automatically: why would it need BufferStrategy?”

#9

Sounds like you probably learned another language like C++ or Python first. I learned Java first, so I often ask this same question of other languages. Java, in my opinion, is one of the best languages because of its consistency, but that doesn’t mean there aren’t plenty of issues with it, too. Basically, you’re building a house, and you’re deciding to do it between different kinds of mortar. In the end, the house is going to look the same anyway, and the amount of work, once you know how to use the new kind of mortar, is also going to be almost the same.

#10

I agree. In C++ everything is different. I have had stuff that will compile in one ide and not in another :stuck_out_tongue:

#11

I’ve had that in Java. Resulted in bug reports against javac.