mouse trailers

Java 2D
#1

hi!
do you know where i could find nice (free) mouse trailers including the code ?
I looked on the web a little but didn’t found java stuff, mostly flash and some basic javascripts. Do you know any good place to find some?

I’ve found one superb mouse trailer here, unfortunately it’s not free, it costs 40$!!! :-[ :-[ :-[

#2

Read up on “particle animation” it won’t be hard to write your own effect.

#3

any good link to tuts and examples?

#4

Some samples here:
http://www.cfxweb.net/modules.php?name=Content&pa=showpage&pid=4x

Here’s an older applet of mine:
http://www.cfxweb.net/java.php?op=contest&num=3rd&entry=marvin
with source code:
http://www.cfxweb.net/modules.php?name=Downloads&d_op=getit&lid=295&ttitle=Contest%203%20entry%205

#5

[quote]any good link to tuts and examples?
[/quote]
The basic concept of a particle system is pretty easy. Let’s say we have two arrays like this:


int[] x = new int[1000];
int[] y = new int[1000];

There you go! Everything you need for a particle system.

…

What do you mean you don’t get it? Oh fine. ;D :stuck_out_tongue:

A “particle” consists of either a pixel or a sprite on the screen. This “particle” lives until it either expires (assuming you put a lifetime on them) or is needed for recycling. So you could shoot your next particle like this:


int particle = 0;

...

while(true)
{
    x[particle] = savedMouseX;
    y[particle] = savedMouseY;

    repaint();

    particle = (particle+1)%x.length; //wraps back to the beginning
}

Assuming that you have a mouse motion listener and save the mouse X and Y coords, the above will plot “particles” where the mouse is. Of course, dots appearing and disappearing is pretty dull. So you need to add physics! I’m not going to go into to much detail (especially since it is really easy to figure out by playing), but the simplest form is to simply make the particles fall. i.e.:


int particle = 0;

...

while(true)
{
    x[particle] = savedMouseX;
    y[particle] = savedMouseY;

    repaint();

    for(int i=0; i<y.length; i++) y[i]++;

    particle = (particle+1)%x.length; //wraps back to the beginning
}

I’ll leave it to you to come up with the drawing code and more interesting effects. Good luck! :slight_smile:

#6

thanks for all

#7

I want to implement the above code…
but there is one quesion: what is the fastest way to draw
the pixels ?

should i create an 1x1 size Image and draw that? use drawLine() and create 1 pixel? or should i try to get the memory of that image and write directly into that??

#8

I’ve always been amazed that there is no setPixel method in the Graphics class. I’ve typically directly accessed the data for a BufferedImage, or used a MemoryImageSource to do pixel-level effects.

The links above have source code. Have a look at what they do.

#9

The fastest way to render a pixel is typically fillRect(1x1)…

#10

From the experiments I’ve done, MemoryImageSource setting of pixels is faster that g.fillRect(1,1), but I suppose it could be machine dependant…

Kev

#11

[quote]I’ve typically directly accessed the data for a BufferedImage
[/quote]
That is the quickest way in 1.2 or beyond.

That is the quickest way in 1.1.

Neither way has any hardware acceleration, so you will find them very slow in high resolutions.

If you wanted to mix regular image drawing with per-pixel effects, it maybe better to use fillRect(x,y,1,1), as you can still keep your image drawing hardware accelerated.

#12

[quote]The fastest way to render a pixel is typically fillRect(1x1)…
[/quote]
Is this treated as a special case in the underlying code?

#13

what I meant to say is that fillRect is faster than drawRect, drawLine, drawOval (we’ve seen people using drawOval to draw lines, believe me).

And it’s still the fastest way to turn a pixel on on an accelerated surface or on the screen, at least, with the latest jdk versions.

#14

I must add that on those latest jdks (basically, starting with 1.4) we’ve introduced some overhead to the operations like these. So 1.3.1 could actually be faster when rendering 1x1 fillrects of the same color. 1.4 is significantly faster if you change the color after each fillrect.

There’s a bug on operations overhead, youcan look it up on jdc.

#15

[quote]I’ve always been amazed that there is no setPixel method in the Graphics class.
[/quote]
Consider two displays one with a typical resolution of around 72dpi, the other one of those IBM LCDs with around 300dpi. A literal setPixel would produce very different visual effect on the two displays. However fillRect should produce roughly the same appearance on both (because the default scaling of the graphics object ought to ensure that 1 unit is approximately 1/72 inch).

#16

can anyone confirm that? i thought graphics operations were pixel based.

#17

As JuddMan eludes to, this is not true. The coordinates given to the graphics operations are based on the resolution of the graphics device. If your screen is 640x480 or 1600x1200 it makes no diffference to drawLine and such… the line segment from 0,0, to 100,100 will look smaller on the 1600x1200 display because of the higher resolution, but on both displays it will be 100 pixels. There is no such scaling on the graphics object to account for DPI, unless you set it yourself. 1:1 scalling operates at the pixel level.

#18

The following is from the documentation of Graphics2D

“The scaling of the default transform is set to identity for those devices that are close to 72 dpi, such as screen devices. The scaling of the default transform is set to approximately 72 user space coordinates per square inch for high resolution devices, such as printers.”

Now although those new 300dpi screeens are screen devices their resolution is certainly not close to 72dpi. So once such devices become common, Java implementations could (and should) start using non 1:1 transformations for them.

So you are correct in terms of present behaviour but in my reading the Java specifications do not guarantee this behaviour. Those high res displays are likely to cause problems in other areas a well although I notice that W3C has defined the px unit in an interesting way — it does not necessarily mean a single hardware pixel.

The way that Graphics2D has been defined means that, provided such non identity scaling is used, our applications will look reasonable on such high res screens without any effort on our part. A setPixel method wouldn’t scale in this way (unless the instruction wasn’t interpreted literally).

#19

OK… I tried several methods of writing a Pixel to the screen. as said earlier the fillRect-Methode is the fastest one. I used Java 1.4.2 for testing.

Now i have to write some neat effects :wink: