Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Best type of image  (Read 3597 times)
0 Members and 1 Guest are viewing this topic.
Offline marcuiulian13

Senior Member


Medals: 5
Exp: 3 years



« Posted 2012-04-10 22:24:01 »

Hello there! Grin

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.  persecutioncomplex

Thanks! 1.

Getting a project done is by far the most hard thing in game development.
Offline Geemili

Senior Member


Medals: 9
Projects: 1
Exp: 2 years


No Games Finished


« Reply #1 - Posted 2012-04-10 22: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.
Offline ra4king

JGO Kernel


Medals: 322
Projects: 2
Exp: 4 years


I'm the King!


« Reply #2 - Posted 2012-04-11 00: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!
Legends of Yore - The Casual Retro Roguelike
Offline marcuiulian13

Senior Member


Medals: 5
Exp: 3 years



« Reply #3 - Posted 2012-04-11 07: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.
Offline ra4king

JGO Kernel


Medals: 322
Projects: 2
Exp: 4 years


I'm the King!


« Reply #4 - Posted 2012-04-11 07:43:52 »

Yes BufferedImages are the best to use. When loading images from file, you will also get BufferedImages using ImageIO.

Offline Vladiedoo
« Reply #5 - Posted 2012-04-11 07: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?
Offline ra4king

JGO Kernel


Medals: 322
Projects: 2
Exp: 4 years


I'm the King!


« Reply #6 - Posted 2012-04-11 07: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 Smiley

Offline sproingie
« Reply #7 - Posted 2012-04-11 08: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)
Offline Vladiedoo
« Reply #8 - Posted 2012-04-11 08:02:50 »

 Grin The information is appreciated, thanks!!!
Offline nsigma
« Reply #9 - Posted 2012-04-11 13:45:03 »

Neither of these points are really aimed at the OP!  Just me nitpicking.  Grin

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 - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ra4king

JGO Kernel


Medals: 322
Projects: 2
Exp: 4 years


I'm the King!


« Reply #10 - Posted 2012-04-11 14:20:57 »

BufferedImages are also managed, meaning their performance is similar to VolagileImage.

Offline nsigma
« Reply #11 - Posted 2012-04-11 14:37:34 »

BufferedImages are also managed, meaning their performance is similar to VolagileImage.

Did you read what I wrote???  I even italicized it!!!  Tongue

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline ra4king

JGO Kernel


Medals: 322
Projects: 2
Exp: 4 years


I'm the King!


« Reply #12 - Posted 2012-04-11 17:46:49 »

So what exactly is a render target.

Offline BoBear2681

JGO Coder


Medals: 18



« Reply #13 - Posted 2012-04-11 19: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.
Offline nsigma
« Reply #14 - Posted 2012-04-11 19: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. Wink

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 - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline Z-Man
« Reply #15 - Posted 2012-04-12 01: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 Tongue as long as your not planning to edit the image frequently BufferedImage will work just fine.
Offline nsigma
« Reply #16 - Posted 2012-04-12 11: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 Tongue 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 - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline ra4king

JGO Kernel


Medals: 322
Projects: 2
Exp: 4 years


I'm the King!


« Reply #17 - Posted 2012-04-12 20:01:38 »

And what use cases would make VolatileImages better than BufferedImages?

Offline nsigma
« Reply #18 - Posted 2012-04-12 20:20:03 »

And what use cases would make VolatileImages better than BufferedImages?

I have a general feeling of going around in circles!   Clueless

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 - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline 65K
« Reply #19 - Posted 2012-04-12 21:09:16 »

With Java2D, I did all image blitting with volatile images exclusively, and it was pretty fast.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (54 views)
2014-04-15 18:08:23

BurntPizza (53 views)
2014-04-15 03:46:01

UprightPath (66 views)
2014-04-14 17:39:50

UprightPath (49 views)
2014-04-14 17:35:47

Porlus (66 views)
2014-04-14 15:48:38

tom_mai78101 (90 views)
2014-04-10 04:04:31

BurntPizza (151 views)
2014-04-08 23:06:04

tom_mai78101 (246 views)
2014-04-05 13:34:39

trollwarrior1 (204 views)
2014-04-04 12:06:45

CJLetsGame (211 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!