marcuiulian13
|
 |
«
Posted
2012-04-10 20:24:01 » |
|
Hello there!  I'm here again to ask next thing: As the title says, what is the best type of image (BufferedImage, Image, etc.) to render on a screen with BufferStrategy? With best i mean the one that is most fast.  Thanks! 1.
|
Getting a project done is by far the most hard thing in game development.
|
|
|
Geemili
|
 |
«
Reply #1 - Posted
2012-04-10 20:28:09 » |
|
Buffer strategy just means that you don't draw directly to screen, you draw to an image that is drawn to screen so that you don't have flickering. You can just use the regular image. Buffered image is an image that the program can edit, instead of just loading it from a file.
|
|
|
|
ra4king
|
 |
«
Reply #2 - Posted
2012-04-10 22:08:30 » |
|
Image is an abstract class, you can't instantiate a copy of it. As far as I know, there are only 2 types of images: BufferedImage and VolatileImage. These days with the complex inner stuff Java2D does, there is no point bothering with VolatileImage. However, since as Geemili said BufferStrategy handles double buffering for you, it's best to directly draw on the Graphics2D object you get from BufferStrategy.getDrawGraphics();
|
|
|
|
Games published by our own members! Check 'em out!
|
|
marcuiulian13
|
 |
«
Reply #3 - Posted
2012-04-11 05:38:22 » |
|
Oh, this means that i am on the right path. What about BufferedImage type? Is ok to use any type or a specific type?
|
Getting a project done is by far the most hard thing in game development.
|
|
|
ra4king
|
 |
«
Reply #4 - Posted
2012-04-11 05:43:52 » |
|
Yes BufferedImages are the best to use. When loading images from file, you will also get BufferedImages using ImageIO.
|
|
|
|
Vladiedoo
|
 |
«
Reply #5 - Posted
2012-04-11 05:44:48 » |
|
I hope this isn't off topic (it seems related) but is there a list somewhere of the files that Java supports and which are preferred? For example to my knowledge Java wants to use .wav format for sound. I currently use .png for pictures, is that perhaps not efficient with Java?
|
|
|
|
ra4king
|
 |
«
Reply #6 - Posted
2012-04-11 05:54:43 » |
|
Java supports GIF, PNG, JPG, BMP, and WBMP image files. PNGs are best because they are lossless and support transparency. Java Sound supports WAV, AIFF, and AU 
|
|
|
|
sproingie
|
 |
«
Reply #7 - Posted
2012-04-11 06:00:47 » |
|
Images are loaded into bitmaps, they're all the same format internally, so whatever image format works best for you is going to be as fast to draw as any other. PNG is probably the best format given that it's lossless and still supports decent compression.
Sound's a bit of a different story, but outside of third party sound libraries, you don't get much real choice anyway, so again it's largely down to whatever works, usually what has the best quality for the size. A .wav (assuming you mean 44.1 stereo PCM) is certainly not compact, but you can be assured it's going to play on just about anything. For lossy formats, ogg vorbis seems to be pretty popular these days (again, it'll need a third party lib like JOrbis)
|
|
|
|
Vladiedoo
|
 |
«
Reply #8 - Posted
2012-04-11 06:02:50 » |
|
 The information is appreciated, thanks!!!
|
|
|
|
nsigma
|
 |
«
Reply #9 - Posted
2012-04-11 11:45:03 » |
|
Neither of these points are really aimed at the OP! Just me nitpicking.  These days with the complex inner stuff Java2D does, there is no point bothering with VolatileImage.
A bit like saying there's no point in bothering with an FBO in OpenGL. If you need an image that can be an accelerated rendering target then a VolatileImage is still the way to go. Images are loaded into bitmaps, they're all the same format internally, so whatever image format works best for you is going to be as fast to draw as any other.
The format of BufferedImages loaded from files can be different, and if they don't become managed or you're doing an operation that won't be accelerated, are not going to draw at the same speed.
|
Praxis LIVE - hybrid visual IDE for (live) creative coding
|
|
|
Games published by our own members! Check 'em out!
|
|
ra4king
|
 |
«
Reply #10 - Posted
2012-04-11 12:20:57 » |
|
BufferedImages are also managed, meaning their performance is similar to VolagileImage.
|
|
|
|
nsigma
|
 |
«
Reply #11 - Posted
2012-04-11 12:37:34 » |
|
BufferedImages are also managed, meaning their performance is similar to VolagileImage.
Did you read what I wrote??? I even italicized it!!! 
|
Praxis LIVE - hybrid visual IDE for (live) creative coding
|
|
|
ra4king
|
 |
«
Reply #12 - Posted
2012-04-11 15:46:49 » |
|
So what exactly is a render target.
|
|
|
|
BoBear2681
|
 |
«
Reply #13 - Posted
2012-04-11 17:02:19 » |
|
I think he's referring to the fact that writing to a BufferedImage marks it as "dirty" so it can no longer be accelerated.
|
|
|
|
nsigma
|
 |
«
Reply #14 - Posted
2012-04-11 17:43:02 » |
|
So what exactly is a render target.
Reading from a BufferedImage can be accelerated when they're managed. However, writing to them (ie. using their Graphics2D) uses software rendering. Drawing on a VolatileImage can be accelerated in the same way that drawing to the BufferStrategy graphics can (AFAIK BufferStrategy uses a VolatileImage behind the scenes anyway), hence my parallel with FBOs. Whether the drawing is actually accelerated depends on the operation, the pipeline, whether there's an r in the month, which way the wind's blowing, whether there's a blue moon ... well, you get my drift.  I think he's referring to the fact that writing to a BufferedImage marks it as "dirty" so it can no longer be accelerated.
No, I'm not. If a BufferedImage is marked dirty by you rendering to it, as opposed to you grabbing the databuffer (or array in JDK7), then at some point in the future it will be re-accelerated. This used to happen on the second draw - presume that's still the case. The actual rendering to the BufferedImage will always be unaccelerated though.
|
Praxis LIVE - hybrid visual IDE for (live) creative coding
|
|
|
Z-Man
|
 |
«
Reply #15 - Posted
2012-04-11 23:32:10 » |
|
... (AFAIK BufferStrategy uses a VolatileImage behind the scenes anyway) ...
BufferStrategy is just an abstract class so whether or not it uses VolatileImages is implementation dependent. However, as far as I can tell Component's implementation of createBufferStrategy() creates buffers that use VolatileImages. Unless of course you use a single buffer strategy, in which case it renders directly to the component. Reading from a BufferedImage can be accelerated when they're managed. However, writing to them (ie. using their Graphics2D) uses software rendering. Drawing on a VolatileImage can be accelerated in the same way that drawing to the BufferStrategy graphics can
Then using a BufferedImage to load a sprite and draw that sprite to the screen is fine  as long as your not planning to edit the image frequently BufferedImage will work just fine.
|
|
|
|
nsigma
|
 |
«
Reply #16 - Posted
2012-04-12 09:56:13 » |
|
Reading from a BufferedImage can be accelerated when they're managed. However, writing to them (ie. using their Graphics2D) uses software rendering. Drawing on a VolatileImage can be accelerated in the same way that drawing to the BufferStrategy graphics can
Then using a BufferedImage to load a sprite and draw that sprite to the screen is fine  as long as your not planning to edit the image frequently BufferedImage will work just fine. Yes, of course - that's what they're for! I'm not arguing against that, just @ra4king's assertion that there is no point bothering with VolatileImage at all. There are valid use cases for VolatileImage too.
|
Praxis LIVE - hybrid visual IDE for (live) creative coding
|
|
|
ra4king
|
 |
«
Reply #17 - Posted
2012-04-12 18:01:38 » |
|
And what use cases would make VolatileImages better than BufferedImages?
|
|
|
|
nsigma
|
 |
«
Reply #18 - Posted
2012-04-12 18:20:03 » |
|
And what use cases would make VolatileImages better than BufferedImages?
I have a general feeling of going around in circles!  If you need an off-screen image that has a chance of being drawn into using the accelerated pipeline. eg. if you had a complex sprite that was animating every frame, and you were drawing multiple copies to the screen, then you might consider drawing into a VolatileImage. All drawing to a BufferedImage happens in software, so will be a bit / lot slower depending on the pipeline. Using a VolatileImage is similar to using an FBO to render to a texture. In fact, if you use the OpenGL pipeline (and hope) your VolatileImage should be backed by an FBO.
|
Praxis LIVE - hybrid visual IDE for (live) creative coding
|
|
|
65K
|
 |
«
Reply #19 - Posted
2012-04-12 19:09:16 » |
|
With Java2D, I did all image blitting with volatile images exclusively, and it was pretty fast.
|
Lethal Running - a RPG about a deadly game show held in a futuristic dysoptian society.
|
|
|
|