I know that both of these have been posted about and I apologize if I shouldn't post this but I'm just a bit confused. Recently I posted on a Java Forums topic about things you disliked about Java, I mentioned the Java2D bug that causes stuttering and someone said there was no Java2D bug. I am pretty positive I read about a Java2D bug here. I posted how I drew and they said drawing with a Canvas is bad (I believe ra4king suggested this to me?). So I guess my question is who should I believe >_< I'm all confused now. Is there a Java2D bug that causes slight stuttering? Is drawing on a Canvas better or worse then extending paintComponent() in a JComponent?

I don't know how you define stuttering, or what you are trying to do exactly. Java 2D has worked fine for me and works well for basic click and drag animation and simple sprite animation (smoke, twinkling stars) that I am doing in Hexara. And it manages this despite a high use of cpu for the sound effects.

The Full-Screen Exclusive Mode API is designed for more demanding graphics. A lot of the folks here use it and champion it and I have no reason to doubt either them or the documentation. If I felt I needed it for the immediate project, I wouldn't hesitate to dive in. You can read about it here:http://download.oracle.com/javase/tutorial/extra/fullscreen/index.html

But with either path, there are lots of ways to go wrong and write less than optimal code. Maybe that's why some of the frameworks are so popular, as they both simplify away a many low-level complexities as well as greatly speed up development.

If you still have the stuttering problem, I suspect there are issues with the coding, not the API. At least for me, 98% of the time I start to suspect there's a bug in the system it turns out to be a mistake or misunderstanding on my part. But maybe you are programming at a superior level than I am. This would not be too difficult.

Whoever said drawing on Canvas is bad is either a troll or thinks he knows something that everyone else doesn't.And the only major Java2D bug I'm aware of is the V-Sync not available in windowed mode problem.

Ok, thanks for answering everyone. The stuttering is really small and it sounds like it might be screen tearing, but I certainly don't rule out my programming since it's not even close to perfect. The stutter isn't terrible but it is noticeable. I've been looking in the Slick2D API and have yet to find a way to use it with a Canvas, is this impossible? Now that I think about it I should probably use GUI components that are packaged with Slick2D or find a tutorial on Slick2D or something.

@philfrei Trust me I am not on a higher level by any means. It is very likely it is my coding, but I made a really simple game loop, and had really simple drawing just to test if it really is my programming. I still got stuttering. Also by stuttering I mean, if I have a cube moving across the screen it's movement will be broken slightly (kind of like it's not moving for a tiny amount of time) and then it will keep going.

@ra4king The poster who suggested using paintComponent() in a JComponent gave this reason:

Quote

Yeah, you're making it way more complicated than it should be. I would expect to see flickering if you're doing that, because you're fighting over what's being drawn- what you're drawing, and what the Component is drawing (which is probably nothing). Instead of any of that, simply override paintComponent (why are you using AWT instead of Swing?) and do all your drawing in there.

Swing uses AWT. AWT is a windowing system, Swing is a GUI library that uses AWT, aka Graphics2D, to draw the widgets. However, since passive rendering (aka calling redraw() and waiting for another thread to call paint()) is not recommended for games, Swing is not suitable for games.

@ra4king Nope I'm not noticing any tearing/stuttering or lag. It runs at a constant 59fps and looks good.

@Riven Oh. Thanks that seems to help.

I have it running at 60-61fps now and the cube moves 5px every update. At first it starts out fine no tearing/stuttering then after a little while it starts to tear/stutter. Could this be because my game loop has no way of catching up? Like skipping frames or something? My game loop is exactly the same as above, except for the change Riven pointed out on line 15.

What's this line doing? ONE_SECOND is a second in nanoseconds right? Is FPS the FPS you want or the FPS you're getting?

EDIT: Out of curiosity, would it be any more efficient to declare the variables used in the while loop outside of it so that they aren't being created for every iteration of the loop, or does it not make a difference.

EDIT 2: Here is what I have so far. I was using Thread.sleep(1) but it was causing stuttering and I'm not getting that with Thread.yield(). I was also getting 59 fps with Thread.sleep(1) and I'm getting 60 fps (which is what I request) with Thread.yield(). I think my loop now does what you are talking about. Any improvements to make?

EDIT: Out of curiosity, would it be any more efficient to declare the variables used in the while loop outside of it so that they aren't being created for every iteration of the loop, or does it not make a difference.

Variables are not 'created', they simply use space on the stack-frame. It's much faster than accessing instance fields, as they add a level of indirection.

EDIT 2: Here is what I have so far. I was using Thread.sleep(1) but it was causing stuttering and I'm not getting that with Thread.yield(). I was also getting 59 fps with Thread.sleep(1) and I'm getting 60 fps (which is what I request) with Thread.yield(). I think my loop now does what you are talking about. Any improvements to make?

Ah I didn't know it worked like that, I guess I need to go back and read up on it. I think I fixed the leak though, instead of setting pre each time, I set it before the loop and then increment it by period.

EDIT: @Roquen My CPU usage starts at about 8% right now, when using the above loop with Thread.sleep(1) it goes to between 15 and 20 percent, using Thread.sleep(0) it goes up to around 50% which is about the same as Thread.yield(). I'm on Windows 7 64-bit Home Premium.

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