Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
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  
  VolatileImage question - Help a newbie out here :)  (Read 2905 times)
0 Members and 1 Guest are viewing this topic.
Offline sambro

Senior Newbie





« Posted 2005-06-14 10:33:41 »

Alriiiight.

I don't know why, but I'm not seeing anyone complain of the fact you cannot manipulate single pixels in VolatileImage?  Huh

For instance, I set up a little stress test, I added a few dozen squares that render in random locations, and a few rotating cubes in the middle of the screen. With BufferedImage techniques I couldn't get above 100fps, and I have a decent comp (specs below). Then I read about VolatileImage, my heart soared! I implemented it and SHAZAM! 500-600fps max.

My pc isn't the problem either, it's a 3.2ghz, 512mb ram, and a Geforce FX 5500.

Now I wanna mess around with some pixel-effects, like texture mapping etc. I tried using things like drawRect/drawLine etc. Drawing a simple 300x300 area with pixels using the aforementioned functions results in a drop of 480 fps. Why is it that a simple pixel set function is not available to VolatileImage? I mean, VI is meant to be better for rendering etc, yet it doesn't support something so simple. Sad

Anyways, this isn't a rant. I'm just asking if anyone knows of a way to get around this problem? Is it possible to perhaps write to a BufferedImage first then copy it into the VolatileImage?

Thanks, Sam.
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #1 - Posted 2005-06-14 14:21:04 »

you're right, this is not possible or at least not very efficient. VolatileImage can be passed to a PixelGrabber but performance is TERRIBLE if you use an accerlated pipeline.

The main-reason is that pixel-operations can not be accerlated efficiently since there must be passed data from RAM -> Video-ram which is slow because of the many busses and so on... (data needs to be passed from your java-program to video-memory which is not efficient,regardless wether VImage is used or not)

The best is that you create an bufferediamge where you can modify pixels (I would recommend to use the setPixels(int[]... Method to set all pixels at once) and later on blit this image to the VolatileImage but its still very SLOW compared with accerlated operations.

lg clemens
Offline sambro

Senior Newbie





« Reply #2 - Posted 2005-06-14 14:49:21 »

Hi Linuxhippy (awesome name btw Tongue),

Thanks for the reply, I had a hunch this was the case. I'm starting to wonder whether Java2D has any real practical applications in regards to an applet... Sad
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #3 - Posted 2005-06-14 15:07:33 »

Glad you like my nick, I chose it when I was 13 ;-)

Why?

Java2D abstracts all the ugly downsides of the pipelines it relies on and offers great performance for most operations, its even much faster than GDI for many more complex operatios requiring 1/5 of GDIs code not to mention Direct3D or OpenGL where you need to have a lot of knowledge to get descent performance at all (not to metion incompatibilities for standards - hello ATI) so with java2d you can things easily native windows apps dream about it.

In our school we had a project for vizualitation of waves and they did a lot direct pixel manipulation, GDI failes so they choose OpenGL with the effect that they had it to pesent it on their own laptop since it didn't work on the presetation laptop. They needed 2 months to write the whole stuff  -  the same with Java2D I would have done in 1/2 hour with better performance and many accerlated backends to support even the most crappies hardware.

Be happy with what you get for free, its really very great - trust me.

lg Clemens
Offline sambro

Senior Newbie





« Reply #4 - Posted 2005-06-14 15:18:27 »

Yeah, but Flash has even more abstraction when it comes down to 2D stuff in a webpage. Not to mention I've seen some nice little 3D thigns done in Flash...

My point being that no optimized pixel set operation makes for very limited power Sad
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #5 - Posted 2005-06-14 15:29:11 »

no pipeline allowed fast per-pixel manipulations, regardless wether you choose OpenGL, Direct3D, X11 or GDI.
Java cannot do things not provided by operating systems.

since you compared java and applets with flash - flash isn't really useful for anything than "applets" or stupid "applet"-like applications.

btw. flash has much less features regarding to rendring - simple line drawing is so slow that it can be easily beaten by not accerlated java2d-pipelines. With abstraction I ment same commands on every platform, not vector stuff or anything like that. btw direct pixel manipulations are impossible with flash ;-)

lg Clemens
Offline sambro

Senior Newbie





« Reply #6 - Posted 2005-06-14 15:36:54 »

Hehe, well you're right of course.Can you think of any way to implement a basic particle system in java 2d though?

With no pixel operation it makes for some rather messy stuff, of course you could use images, but when you get to trying to scale and manipulate particles, things get ugly. Or do they? Enlighten meeee Grin
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #7 - Posted 2005-06-14 16:22:16 »

well, this really depends on the pipeline you're using. Scaling images is almost free on OpenGL and also on Direct3D but it can be quite costly on GDI or X11.

I would just try the unaccerlated pixel-access over buffered images I explained - for small images this is fast enough and particle-systems drawing over the whole screen are quite seldom ;-)
On my rather ugly GF488Go card in OGL mode it takes ~20ms to draw a unaccerlated image with 500x500 (SW->Surface blit).

lg Clemens
Offline sambro

Senior Newbie





« Reply #8 - Posted 2005-06-14 16:46:02 »

Pardon my ignorance, but what is OGL mode?

Are you referring to JOGL? Is it possible to use it's pipeline with Java2D? That would be rather nice Smiley
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #9 - Posted 2005-06-14 16:56:37 »

no, java2d has several supported backends: gdi/directdraw; direct3d, x11, OpenGL - this is not related with JOGL.

Basically you can see: Accerlated features are REALLY fast under accerlated pipelines (direct3d, OPenGL) but software-operations can really destroy performance on those pipelines so its always good to have a look what's happening under the hood:
-Dsun.java2d.trace=count (as command-line argument). sun.java2d.loops is software

I would suggest downloading the lastest mustand-snapshots, a lot has changed since 1.5: j2se.dev.java.net

enable OpenGL pipeline (preffered by me): -Dsun.java2d.opengl=True
enable D3D pipeline (hmm...): -Dsun.java2d.d3d=true

lg Clemens
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sambro

Senior Newbie





« Reply #10 - Posted 2005-06-15 02:10:25 »

Do those switches work with Applets?
Offline sambro

Senior Newbie





« Reply #11 - Posted 2005-06-15 04:22:54 »

Actually I think I found a decent enough solution to this problem.

I tried MemoryImageSource before, maybe I did something wrong before, 'cos it didn't work well.. I just tried implementing it again in my graphics subsystem, and it works great! Filled a 500x500 image with pixels, and blitted it to my backbuffer. I'm doing this every render frame and still tossing out 200fps max! Hurray!
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #12 - Posted 2005-06-15 07:50:26 »

you are blitting the same image over and over, don't you?
Try to create a new image every paint, otherwise your image gets accerlated and you do not see the effect of direct-pixel access at all.

Btw. MemoryImageSource is part of the very old ImageProducer/Consumer API introduced in Java-1.1 and isn't well supported anymore. The more advanced the rendering backends become the poorer is the support for those APIs.
What do you mean with "implementing it again in my graphics subsystem"? You just ran it on another backend?
Why don't you what I've told you, are you analphabethic?

1.) Create a bufferedImage of TYPE_INT_ARGB
2.) Create an int[] of the same size
3.) set the pixels in the array
4.) set the pixels of the image using "setRGB(int startX, int startY, int w, int h, int[] rgbArray, int offset, int scansize)"
5.) Blit the image.

Clemens
Offline sambro

Senior Newbie





« Reply #13 - Posted 2005-06-15 11:32:33 »

"analphabethic"?!  Shocked  Are you trying to show off your vocabulary, or hurt my feelings? Or both?

Besides, I tried using the BufferedImage method, it didn't work that well. And yeah I'm creating a different image each time, I'm randomizing the colours in fact, and moving the box across the screen, as well as using translucency, and the framerate is staying above 70. That's without adding any optimizations too.

When I referred to "graphics subsystem", I was referring to MY graphics subsystem, a simple little thing that allows you to attach objects implementing the interface "Renderable" and have them automatically drawn each frame.

The way I'm doing my pixel plot is I wrapped my VolatileImage and MemoryImageSource into a class. You can query the class for the Graphics2D object of course. It also supplies pixel setting functions, which manipulate a local array, then let you use "copyPixels()" to throw all the pixels currently in the array into the VolatileImage backbuffer.

It's working great, much better than BufferedImage did, even when I tried grabbing the WritableRaster and throwing a block of pixels into the Image in one go.

BTW. I do believe it's spelt "analphabetic"  Roll Eyes
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #14 - Posted 2005-06-15 12:15:28 »

> as well as using translucency, and the framerate is staying above 70. That's without adding any optimizations too.
So not 200fps ;-)
I get 85fps on my rather underpowered laptop (in terms of graphic-chipset) when using the OpenGL pipeline. (Its a GF2-class chipset) using the bufferedimage-approach.

For what you are using MemoryImageSurface it wasn't designed for, its almost the same as using PixelGrabber for periodically get the pixels of an VolatileImage. It works find for now, if you've look it will too on newer pipelines or not - not. Well it leaves me ... cold?

lg Clemens
Offline sambro

Senior Newbie





« Reply #15 - Posted 2005-06-15 12:50:07 »

I never specifially asked for your attention, though I am appreciative. What I don't appreciate is you trying to soudn superior using big words and sounding all tough.

And whether or not the new image data is being changed in one thread or the other, the new image data is just that, new image data. It's NEW. Meaning it hasn't been cached. So yes, I'm blitting a new Image every frame.

Maybe I'll give the BufferedImage another go, I'm having slight problems with the MemoryImageSource, namely, I can't clear the array very fast, 'cos Images created with an ImageProducer don't allow you to use a Graphics object with them.
Offline sambro

Senior Newbie





« Reply #16 - Posted 2005-06-15 15:24:11 »

Well, I tried BufferedImage again, 50fps drop in speed, from 80fps to 30fps.

It's using the same system my MemoryImageSouce code is using too, I just substituted the MemoryImageSource and it's corresponding image with a bufferedimage.
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #17 - Posted 2005-06-15 15:35:01 »

I never specifially asked for your attention, though I am appreciative. What I don't appreciate is you trying to soudn superior using big words and sounding all tough.
well thats right so I actually wont waste my time anymore ;-)
Offline sambro

Senior Newbie





« Reply #18 - Posted 2005-06-15 15:39:55 »

Alright... I forgot your time was so much more important than mine!  Shocked
Offline kevglass

JGO Kernel


Medals: 122
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #19 - Posted 2005-06-15 16:35:27 »

Seems the original question has been answered and the conversation is going down hill.

LOCKED.

Kev

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.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (26 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (13 views)
2014-07-29 10:59:34

E.R. Fleming (34 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (44 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
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!