questions about drawing and filtering fast

Java 2D
#1

well ok iv written my topic pressed on preview and it told me hey enter a subject and everything was lost… well my fist day… fcuk

however… first… iv learnd english only in school… and dont live in a country where english is the native language… so maybe ill use sometimes words wrong or whatever… just be prepared :wink:

i want to write a game… for that wanted to make some kind of layers with different behavior like one layer for particles wich would be heavyly blured… layers cause the background behind the particle layer should be unaffected by the blur
also the backgroudn should shine through the particles if they are translucent through the bluring or a lower alpha value than 0xff

iv tested buffered and volatileImages… though i want much transparency i have to use buffered ones couse (at least on my sytem) v’S dont want to be translucent whatever i do (well saw now that translucents are actualy not implemented)
with -Dsun.java2d.opengl=True the bufferedImages work fast enough… without it seems imposible to write a game with at least 2 fps :confused:
btw i create a bufferedImages through: Component.getGraphicsConfiguration().createCompatibleImage(…);

also if i use such a buffered image as a frame buffer to draw into instead of the graphics the paintComponent gets my drawing performance falls down around 100-200 times
as numbers:
just drawing some pictures on the graphics wich i get at paintComponent takes 239416ns

drawing the same into a buffered image takes 57210623 ns!!
and drawing this picture into the graphics in paintComponent takes again 9526071 ns
-> more than 250 times slower :confused:

btw vimages are much faster but jet again… cause they have no transparency i cant lay them over each other :confused:
drawing the pictures into: 982248
drawing into the Graphics2d i get:3873398
->20 times slower

well my questions:

  • how can i make a fast buffer in wich i can draw and manipulate (like blur) image data
    also how can i clear it with an alpha chanel of 0xff… didnt figure this out with buffered images :confused: and creating a new bimg or worse more than one every frame should be imposible
  • how can i manipulate this data fast enough…
    i dont believe that self written stuff over filters and pixel grabber or ConvolveOp will work fast enough for a game (i would like to make it at least in a size around 800x600)

i thought about a solution in wich i dont have to blur the picture for a particle system… but for that i would have to draw a round gradient instead of a pixel or draw a picture of a round gradient wich i filter through an rgba filter to get the color i want to… and store the new pictures into a hashmap… but in the worst case i would have 2^32 pictures with a sice around 3x3 or 5x5 (100gb data :wink: or whatever
also i dont think this would look like a nice interpolation or blur… and with such u could make effects wich use the picture from the frame before do slowly blur out something till u wont see it anymore
the gradient seems to be another problem… cause i dont think creating hundrets of gradient fills with slightly different color values per frame would be much efficient :confused:
also i didnt jet figure out how to make round gradients only the ones i can create with GradientPaint

p.s. iv got a little old system (800mhz cpu and some crappy gf2)
however… a game i write should work on my pc shouldnt it? :wink:
p.p.s. if someone wants to see my testprogg i can clean it a bit and post it

#2

Hi.

I am not sure if I understood you completely, but in the matter of layers, you usually do not need several backgrounds that you draw into. You can stick to one graphics context (for instance gained through use of BufferStrategy which uses a VolatileImage for blitting or flipping), and then draw your layers into this one backbuffer in succession. (lower layer first, top layer last).

Bottom line: You do not need to draw into any images except your one VolatileImage that resides in the backbuffer of your BufferStrategy.

#3

but how do i interpolate/blur/whatever my particle layer? if i draw it directly into the same backbuffer in wich iv drawn my background image(s) i cant blur it after painting the particles cause then the background would seem nasty unsharp

#4

If you want a layer to for instance fill the screen completely, just use a BufferedImage and apply the effects to it, then do:

g.drawBottomBackground();
g.drawSomeObjectsOnLowerLayers();
g.drawABlurredBufferedImage();
g.drawSomeStuffAboveTheBlurEffect();

where g is your BufferStrategy’s backbuffer graphics.

If you want to blur stuff at “runtime”, perhaps it would be better for you to create an Animation class, which basically just swithces out an un-blurred image A with a blurred image B.

If you do not want to have one blurred image filling the screen, but rather several small ones on the same “layer” being blurred, I would recommend just blurring them individually, and then drawing them into g.

#5

[quote]BufferedImage and apply the effects to it, then do:
[/quote]
well iv shown in my first post how fast bufferedImages are if u write to them…

[quote]g.drawBottomBackground();
g.drawSomeObjectsOnLowerLayers();
g.drawABlurredBufferedImage();
g.drawSomeStuffAboveTheBlurEffect();
[/quote]
well yeah um… i know the order how i would have to draw my layers… my question is how do i make it fast… wich classe to use… wich commands…

[quote]If you want to blur stuff at “runtime”, perhaps it would be better for you to create an Animation class, which basically just swithces out an un-blurred image A with a blurred image B.
[/quote]
again… how should this work internaly to be fast enough for a game?

[quote]If you do not want to have one blurred image filling the screen, but rather several small ones on the same “layer” being blurred, I would recommend just blurring them individually, and then drawing them into g.
[/quote]
well i want it all blured cause there should be a lot particles on the screen to be usefull

well iv made a short test:

      protected void paintComponent(Graphics arg0) {
            for (int i=0; i<images.length; i++){
            arg0.drawImage(images[i],xpos[i],ypos[i],null);
            }
}

images is a bufferedimage array with 6 images wich have something drawn into and are around 300*100 big
this works (as it should) realy fast… .around 100 fps with a sleep(10) in the main loop… so it cant get fastet than 100fps

if i add:

            Graphics2D g2d = (Graphics2D)tmpImg.getGraphics();
            g2d.setColor(new Color(0x000000));
            for(int i=0; i<20;i++){
                  int x=rand.nextInt(getWidth());
                  int y=rand.nextInt(getHeight());
                  g2d.fillRect(x,y,5,5);
            }
            
            arg0.drawImage(tmpImg,0,0,null);

tmpImage is also a bufferedimage around 800*600 (my window size)
my fps drop down to ~40

if i add between drawing black rects into tmpImg and drawing tmp image onto the screen this:

            if (co==null){
                  float[] arr= {
                              0.1f,0.1f,0.1f,
                              0.1f,0.1f,0.1f,
                              0.1f,0.1f,0.1f,
                              };
                  co = new ConvolveOp(new Kernel(3,3,arr));
            }
            tmpImg = co.filter((BufferedImage)tmpImg,null);

it works like i want it to… with uhm 3 fps…
edit: iv changed it a bit so that there must not be created an new image every frame… now i get nasty 5fps

so how do i do the same stuff without loosing 97% (95%) of my fps?
i think loosing arount 20-30% should be enough for such a simple test

#6

Hi again.

Like we both said, writing into your BufferedImage’s during your drawing loop-cycle just won’t work. When I said you could apply effects to the BufferedImage’s, I did not mean effects that indicated using its graphics object to draw things into it directly.

I am not sure what kind of effects you need to perform on each loop cycle, and which effects you can precalculate, but if you truly feel you must write into these BufferedImages, I suggest precalculating a whole lot. (Will eat much more of your memory, but you won’t have to do all the things you currently do, inside your loop).

As for animation…

What I meant here, is that for each effect you implement, you may have X individual states (assuming that prior to your loop, you can know or foresee the result of effects). Then you create a class containing an array of bufferedimages of size X, each index representing a state of the effect. Easiast way is of course to define the indexes as constants so that it all makes more sense to read. Then, inside your game-logic update, based on whatever flags that decide the state of your game, set your currentState variable to whichever state you want to draw, and then in your draw method, you can reduce it to the single line

drawImage(images[currentState], … ) etc.

Of course, I stress again that your effects cannot be truly “random” in the sense that you cannot in some way predict them. And, to really reach your goal, you might have to make tables like these for every different effect you plan to implement.

A suggestion, anyway. Good luck.

#7

well… in short this means i cant do it… :confused:

cause i cant predict what a particle system will be doing in the next frame… particles usualy float around on the screen and change their color continualy… this produces an infinete amound of posibilitys wich nobody could predict

this link shows a nice particlesystem: http://www.jhlabs.com/java/particles.html
but however its not realy fast and it looks like its only using 255 colors
but its made for java 1.1 so isnt there a way in 1.5 to make it faster? (especialy while using the ogl pipe)

also for a game u would have a lot particlegenerators (wich wouldnt emit so much particles like this applet but all together should be posible to emit more [because of the higher resolution]) wich would not have a constand position on the screen

#8

Your out of luck I’m afraid. The slow part is copying the image from main memory to the gfx card. In this case java 1.1 is almost as fast as java 5. Look at the bottom of the Java 2D FAQ on the best way to get directa access to the pixels.

If you need the speed, you can use OpenGL directly through JOGL or LWJGL. Blur is commonly used to create a glowing effect around lights. There should be an article about it on gamasutra by the Tron creators.

#9

thx tom
just before reading this iv installed and tryed jogl out :wink:
but now i would like to read a tut about working with jogl… well google or whatever…

well… i would only acces the raw imagedata if i would know that bluring it with a selfmade method would be much faster than using ConvolveOp like in my example

or maybe i should use another kind of image? but wich one?
cause i use the ogl pipe (-Dsun.java2d.opengl=True) to get my 100 fps without it would be 20… and if it is aktivated the buffered images should be placed into the texture buffer of my graphics card… and i recall that reading from this is verry slow… only writing into it is fast…

#10

[quote]thx tom
just before reading this iv installed and tryed jogl out :wink:
but now i would like to read a tut about working with jogl… well google or whatever…
[/quote]
The nehe tutorials is a good way to start. You also need to read the red book. It is mandatory.

That said. Creating blur effects with OpenGL is very advanced. Nothing you will be able to do first starting out.

Btw. There are many examples of bluring effects in scene demos. Try some out and you probably see what is possible in hardware. Although your particular hardware sucks, so it might not run, or run very slow :frowning:

ConvolveOp accesess the the pixels directly. That is why it is slow. Doing it yourself might speed it up slightly.

Using the opengl pipeline does NOT mean all buffered images will be permanently placed on the graphics card. If you access it like you need to when creating the blur effects it will be placed in main memory. Then it will be uploaded to the graphics card every frame. This is damn slow. Reading from and too the graphics card is slow.

#11

thx… nehe i know already but didnt read it… also iv heard not so good things about nehe… however redbook looks nice

[quote]Btw. There are many examples of bluring effects in scene demos. Try some out and you probably see what is possible in hardware. Although your particular hardware sucks, so it might not run, or run very slow :frowning:
[/quote]
well this is the same link as to the redbook and the demos there where c and i saw nothing with heavy blur… maybe wrong link in your clipboard :wink:

my question for tuts was not for ogl tuts it was for jogl tuts
i got a first impression how to work witch jogl through How to: Getting started with JOGL
but there are some unanswered questions like what is different in jogl than in ogl
are there ways to create non 2^n sized textures (pbuffers?) or whatever so that i can make a buffer wich i dont have to resize when drawing it onto the screen
more or less the same with pictures… how to load and process non 2^n x 2^m sized pictures… without resizising it (if u dont want to) or storing a (2^n)+1 picture into a 2^(n+1) texture
how to masure the fps (time to create one frame bot working parralel in 2 threads [awt and game logic]) in jogl… where to draw how to syncronise my main thread with the drawing of my oglcanvas in the awt thread (as an Example: so that i wont let the game logic calculate 50 frames while only drawing 10)

only to mention the important ones :wink:
btw this should be in the jogl not the j2d forum… :confused:

edit: now it is

#12

Ops, here is the correct link to www.scene.org. There is tons and tons of stuff on the site. For a quick start go down to the “Scene.org Awards 2004 nominees announced” list of nominees section. I think “Conspiracy The Prophecy - Project Nemesis” under 64k has some blur in it.

[quote]my question for tuts was not for ogl tuts it was for jogl tuts
[/quote]
Most of the nehe tutorials have jogl ports aswell as other languages/libs. Just go down at the end of the totorial and see the list of ports.

#13

thx again…
the demos wich work on my gc are realy nice slow but nice :wink:
but i couldnt figure out why u gave me this link… the demos dont include sourcecode :wink:
well… but i could disassamble one grin