Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (541)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
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  
  2DGraphics PixelArray vs G2d.drawImage(...)..  (Read 4278 times)
0 Members and 1 Guest are viewing this topic.
Offline JayTech

Junior Devvie


Medals: 1



« Posted 2012-04-22 00:44:51 »

Ok, so i'm just starting to finish my GFx API in my game  and I've watched some tutorials where people add every entity into the games Pixel array instead of just doing g2d.draw(image,x,y) to a Canvas, they instead do pixel raster to images. Is this really needed or is G2D.draw(bufferedimages) suffice for mediocre game. My game art style is a 2D sidescroller like type gamerpg such as Dungeon Fighter online etc.

My question is, what benefits are there to using pixel arrays? Is this needed for my type of game? Also is this easy to integrate?

Thanks in advance,
Tips*hat*
Jay
Offline 65K
« Reply #1 - Posted 2012-04-22 06:18:42 »

Maybe they dynamically apply graphic effects.
Besides that, its only useful for slowing down things drastically.
So, if you just want to render static images, use draw().

Offline jonjava
« Reply #2 - Posted 2012-04-22 06:22:43 »

Isn't every image basically just wrapped up RGB pixel data anyway? I don't see why one method should be faster than the other.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline 65K
« Reply #3 - Posted 2012-04-22 06:31:28 »

There are managed images and unmanaged images in Java2D.
Fast vs. slow.
Pixel juggling is probably the second category.
Do a research on that. As far as I know, it even depends on your platform.

But luckily, pure image rendering is pretty fast in Java2D.

Offline Rorkien
« Reply #4 - Posted 2012-04-22 18:27:57 »

As far as i can remember, when notch made minicraft as a 320x240 game using a pixel array, it got around 2200 fps on the prototype
Then he added 2ms sleep between iterations and got 400 fps, which never came down, even on the finished game.
Offline JayTech

Junior Devvie


Medals: 1



« Reply #5 - Posted 2012-04-22 21:54:16 »

Thanks for the responses, I mean is there one that is more professional than another? Do you all just use Draw when making a game, is it acceptable for an app? Does one get higher fps than another? I just really want to make sure before I put the cap on my game's graphical capabilities =D
Offline StumpyStrust
« Reply #6 - Posted 2012-04-23 02:07:05 »

I would say that with  PixelArrays you could do some some effects to certain areas of the rendering. You know...things like bloom filter and stuff but it is very slow compared to just static 2D rendering.

g2d.drawImage is very fast and I have not done tests but I think it is faster then a PixelArray. I mean with a few tests with a bloom/glow filtering system (not at all optimized) you would be looking at a max resolution of about 200-300 pixels. Java was not designed to have dynamic access to pixels that way. 

So unless you need to access the pixel information before or after somethings is drawn, g2d.drawImage should be fine.

Offline gimbal

JGO Knight


Medals: 25



« Reply #7 - Posted 2012-04-24 12:57:01 »

Then he added 2ms sleep between iterations and got 400 fps, which never came down, even on the finished game.

I certainly hope not. Its a 2D game that doesn't even do that much on screen.
Offline seanrowens

Innocent Bystander





« Reply #8 - Posted 2012-10-05 03:40:59 »

The answer is, it's complicated.  It depends a lot on what you want to do with the pixels and such, and what you're doing with your graphics.   I'd take a stab and guess that you can probably just use g2d.drawImage(), but the simplest thing is to start with that and see if things run to slow for your tastes.  If they do, then profile and see where the problem is, it might be somewhere other than drawing. 

But for a bit of background, basically images can be in tons of different formats, and the image classes hide a lot of that complication from you.  If the format of your image doesn't match the format of your graphics device, then every time you draw the image the code under the covers does a lot of work converting each pixel in your image to the graphic device format.  On the other hand this code is usually written pretty well and they can take advantage of lots of other stuff like caching images inside the graphics card, etc.  Conceivably (a little bit of a guess here, as I don't muck around that deep in this kind of code) a call to drawImage() might be converted into a call across to the memory card, and use hardware to blit an image from one part of the graphic card memory into another part of the graphic card memory, very very quickly.

On the OTHER hand, if you know exactly what format your image or images are in and you know exactly what format you want to write it to, you can get at the underlying data structures (i.e. DataBuffers) and just munge the numbers yourself.  Unfortunately once you ask Java to get at that data, all that magical code the sun guys wrote way back when can't rely on you not pulling the rug out from under them, i.e. they mark that image as "do not cache on the graphics card, ever", because they have no way of knowing if you wrote to that underlying big honking array of pixels.  So now while you can do a lot of manipulations on the pixels a lot quicker, you can't take advantage of whatever hardware acceleration might be going on, or whatever other goodness the sun guys wrote under the covers. 

Make sense?  The real answer is that it greatly depends on what you're doing.  Mind you there are a lot of things you can do to make things faster without mucking around with the pixels and messing up acceleration.

Among other things make sure that you create the BufferedImage that you're drawing too by calling createCompatibleImage on GraphicsConfiguration.  This will hopefully avoid a having to convert all the pixels of the image you're drawing to the screen from one format to another, each and every time you draw. 

Overall I suggest you start with that, and if things are too slow ABOVE ALL PROFILE your code because the slow part may very well not be in drawing to the screen.  If you find it is the drawing that slows things down then do more research on the web.

Finally I leave you with the three Rules Of Optimization

1) Don't do it
2) Don't do it yet
3) Profile
Offline Oskuro

JGO Knight


Medals: 41
Exp: 6 years


Coding in Style


« Reply #9 - Posted 2012-10-05 11:40:09 »

It's just a tradeoff between more control over the rendering process and ease of use.

I'm with seanrowens, get the program running first, and only then optimize.

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.

Mr.CodeIt (24 views)
2014-12-23 03:34:11

rwatson462 (55 views)
2014-12-15 09:26:44

Mr.CodeIt (46 views)
2014-12-14 19:50:38

BurntPizza (91 views)
2014-12-09 22:41:13

BurntPizza (113 views)
2014-12-08 04:46:31

JscottyBieshaar (83 views)
2014-12-05 12:39:02

SHC (92 views)
2014-12-03 16:27:13

CopyableCougar4 (101 views)
2014-11-29 21:32:03

toopeicgaming1999 (160 views)
2014-11-26 15:22:04

toopeicgaming1999 (163 views)
2014-11-26 15:20:36
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
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!