BufferStrategy Doublebuffer

Newbie & Debugging Questions
#1

Hello all,

I am having a sort of “problem” using double buffer with BufferStrategy.

Well, first of all, I am creating my strategy with two buffers (obviously) and I know, through the buffer capabilities, that it is possible to do a hardware flip.

However, my sprites animations are VERY, VERY slow, and I am clueless to why. Actually, when I use a strategy with only one buffer, the result is pretty much fast, and what I was hoping for. Unfortunetly, there are a lot of flickering in it. :stuck_out_tongue:

So, if anyone can answer why I am getting this slowness, and how to fix it, I would be very happy!!

Moon Pxi

#2

Post your code that involves bufferstrategy and your rendering loop.

#3

Yep. A few other things to consider:

(1) Are you sure yo uare creating both buffers in video memory? How much video memory do you have on your card?
(if you have enough and you are saying just that you want 2 it should do them in video memory for you.)

(2) What platform is this? Apple’s BufferStratgey implementation in JDK1.3 was very slow. Theyw ere supposed to be improving it in 1.4 but i havent tested that.

#4

I’m a complete newbie, and the following confession will attest to it:

I had the same problem, but it turned out I was doing the doublebuffering correctly afterall…my problem was that I had the read image method as part of my paintmethod (that was getting called over and over again). I just had to move it out of the loop and stick my sprites in memory first…then voila!

Yes…I’m a newbie…although I think I should have at least caught that one sooner than the hour it took me. :stuck_out_tongue:

#5

Backmask:
My code is basically the same as it was presented in the Wiki part of www.java-gaming.org.

Jeff:
I believe that both buffers are in video memory. I checked through the ImageCapability of both buffers and it said it was accelerated, or something. I wonder if it means it’s in the video memory

And, actually, the computer I was running is kind of old, and it was running Linux. The goal of my game is to actually be runnable on older machines. For a 2D game, I hope this is not too much to ask…

The strangest thing I noticed is that, with only one buffer, it runs quite fast. I thought page flipping was just a swap in memory pointers…am I wrong?

#6

[quote]And, actually, the computer I was running is kind of old, and it was running Linux.
[/quote]
Ah theres your problem!

It is, IF the platform allows it. AWT is implemented on Linux ontop of X. X has no true full-screen mode. Going full-screen in X just makes a screen-sized undecorated window.

X doesnt allow us to either get to video memory OR flip screen pointers, sorry :frowning:

#7

Jeff:
Just a quick clarification. My problem is that I am running Linux, right?? So, if I was running in a windows machine, but in a slower computer, I would be able to get decent framerates and use all hardware and video stuff??

Well, and what about if I did the game in windowed mode?? Is there a mechanism, similar to BufferStrategy, that I could employ (either in Linux or Windows) to get it fast??

By the way, thanks for all your answers!!

#8

[quote]Jeff:
Just a quick clarification. My problem is that I am running Linux, right?? So, if I was running in a windows machine, but in a slower computer, I would be able to get decent framerates and use all hardware and video stuff??
[/quote]
Well assuming the machien ash the spes to handle what yo uare doing, sure. You should get full hardware acceleration if you organize it right under Windows.

Well by dfinition in Windowed you can’t page flip, but you CAN still use BufferStrategy. BS will just do a BLT rather then a flip to get it to the screen.

Code-wise its almost the same whether you are doing full screen or windowed, there are 2 lines difference in set up and thats it. Take a look at Scroller demo in exampels which runs in either mode.

[quote[
By the way, thanks for all your answers!!
[/quote]
Thats what I’m here for.

#9

Jeff:
I just checked out your scroller demo. So, the diference between the two modes is that you set fullscreen in one, and not in the other?? Well, that’s pretty close!! :slight_smile:

I also noticed that you set a LOT of ignoreRepaints. This would make the frame not call the paint method, right? Would this improve performance???

If I thinkered with the BufferCapabilities, could I get better results???

And, lastly, Linux is a viable solution for game development?? Of course, I was testing on a older machine, but I expected to run reasonably well…

#10

If you are using active rendering (BufferStratgey) you do NOT use AWT repaint. Therefore if you try to use AWt components with active rendering you need to disable their use of it.

#11

Likely not, it already sets it self miximally for your environment.

Well yes, but not for AWT today in any form. If Linux is one of your targets you will likely have to use LWJGL or JOGL (3D libraries, but you can do 2D with them. 2D is just 3D with one eye closed :wink: )

#12

“2D is just 3D with one eye closed”

Ha, this one was great!!! :slight_smile:

Continuing on my endless series of question, why would I have to use LWJGL or JOGL?? They have faster mechanisms, or something??

And, by the way, should I generally use this libraries when even developing for Windows, and 2D??

#13

The most obvious benefits are fast (linear) filtering of textures, fast full alpha and beautiful rotations. Also it’s easy to add 3D effects (apparently heh).

Unfortunately there isn’t such a thing like the best API. It always depends on several factors wich API you should choose… otherwise we would all use the same APIs :slight_smile:

If it’s an (J)Applet you’ve to use plain Java2D.

Application (or webstart) and you are free to choose between 'em all.

Plain (fast) OpenGL -> LWJGL
Plain (fast) OpenGL (2D) -> LWJGL + SPGL
OpenGL + Swing (and the like) -> JOGL

And if you’re planning to do some more complex stuff it’s worth to checkout Xith3D. It’s a scenegraph API, wich does most of the stuff you usually need in games. However it’s overkill if you want to do a 2D game (rephrased: it won’t scale that well, because the “scene” would be to simple).

That’s it basically.

IMO it’s a good idea to start with Java2D (it isn’t that bad afterall). Once you understand the basic concepts of game programming you can move on to LWJGL or JOGL (it isn’t that much work to port a game from Java2D to one of that OpenGL wrappers).

#14

[quote]"
Continuing on my endless series of question, why would I have to use LWJGL or JOGL?? They have faster mechanisms, or something??
[/quote]
The big advantage the OGL libs (LWGL and JOGL) have is that on Unix they don’t have to go through X windows. Instead they talk to the native OGL library which is generally hacked into the system to bypass all the X issues.

For an exmaple of a 2D game written using OGL try Cas’s Alien Flux :slight_smile: Unfrotunately source isnt available but it will give you an idea of whats possible.

#15

I’d like to clarify some points. Java2D on linux uses Pixmaps to accelerate some type of images (those created with createImage, or loaded with Toolkit.getImage).

Depending on the hw and the driver you’re using, those Pixmaps may reside in video memory. This means that copying images to the screen will happen at hw speeds. Another good thing is that since we use X11 to render to those images, rendering simple primitives (those backed up by X11 protocol) may too be hw accelerated.

So unless you’re doing something X can’t really handle (translucency, AA-rendering, non-simple transforms, etc), a typical sprite-based game should run at very decent speed on linux.

#16

DT’s da man on these things.

But, correct me if Im wrong, it is true that you cannot do true full screen frame flipping under X?

JK

#17

Nope, not with our current implementation.

As Jeff correctly pointed out, going ‘fullscreen’ on linux is emulated by creating a frame w/o decorations with the size of the screen.

But since we do use DBE (double-buffering extension) with the Flip BufferStrategy, buffer flipping will be hardware accelerated (where dbe is accelerated, of course).