Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (601)
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  
  mouse trailers  (Read 2332 times)
0 Members and 1 Guest are viewing this topic.
Offline misterX

Junior Devvie




java forever!


« Posted 2003-07-18 10:24:03 »

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$!!!  Embarrassed Embarrassed Embarrassed
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #1 - Posted 2003-07-18 11:27:04 »

Read up on "particle animation" it won't be hard to write your own effect.

Offline misterX

Junior Devvie




java forever!


« Reply #2 - Posted 2003-07-18 12:45:23 »

any good link to tuts and examples?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #3 - Posted 2003-07-18 15:41:50 »

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

Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #4 - Posted 2003-07-18 16:27:09 »

Quote
any good link to tuts and examples?


The basic concept of a particle system is pretty easy. Let's say we have two arrays like this:

1  
2  
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.  Grin  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:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
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.:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
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!  Smiley

Java Game Console Project
Last Journal Entry: 12/17/04
Offline misterX

Junior Devvie




java forever!


« Reply #5 - Posted 2003-07-18 19:36:10 »

thanks for all
Offline troggan

Junior Devvie




no guts no glory


« Reply #6 - Posted 2003-07-24 06:37:50 »

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??

(http://www.wannawork.de) - Will work for food
(http://tvbrowser.org) - Java EPG
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #7 - Posted 2003-07-24 11:08:45 »

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.

Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #8 - Posted 2003-07-25 04:23:18 »

The fastest way to render a pixel is typically fillRect(1x1)..
Offline kevglass

« JGO Spiffy Duke »


Medals: 212
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #9 - Posted 2003-07-25 04:53:24 »

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

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

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #10 - Posted 2003-07-25 09:34:07 »

Quote
I've typically directly accessed the data for a BufferedImage


That is *the* quickest way in 1.2 or beyond.

Quote

or used a MemoryImageSource to do pixel-level effects.


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.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #11 - Posted 2003-07-25 15:10:16 »

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


Is this treated as a special case in the underlying code?

Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #12 - Posted 2003-07-26 04:55:31 »

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.
Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #13 - Posted 2003-07-26 04:58:41 »

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.
Offline Mark Thornton

Senior Devvie





« Reply #14 - Posted 2003-07-26 07:26:43 »

Quote
I've always been amazed that there is no setPixel method in the Graphics class.

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).
Offline JuddMan

Senior Devvie


Medals: 1


Your Ad Here


« Reply #15 - Posted 2003-07-26 08:48:39 »

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

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #16 - Posted 2003-07-27 01:14:03 »

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


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.

Offline Mark Thornton

Senior Devvie





« Reply #17 - Posted 2003-07-27 07:10:47 »

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).
Offline troggan

Junior Devvie




no guts no glory


« Reply #18 - Posted 2003-07-27 10:38:28 »

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

(http://www.wannawork.de) - Will work for food
(http://tvbrowser.org) - Java EPG
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.

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

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

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

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

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

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

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

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

toopeicgaming1999 (103 views)
2014-11-26 15:20:36

toopeicgaming1999 (31 views)
2014-11-26 15:20:08
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!