[java] drawOval problems

[Snake X]

Gah sorry for creating so many java threads.. but I get so many buggs 

Ok this time, I have a weird problem dealing with drawOval.

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

import java.awt.*; import java.applet.*; import java.util.Random;   public class sphere extends Applet {           public void paint(Graphics g)  {                   Random r = new Random();                 int wh = r.nextInt(300);                 while(true) {                         Color  c = new Color(r.nextInt(256), r.nextInt(256), r.nextInt(256));                         g.setColor(c);                         for (wh = 0;wh>=r.nextInt(300);wh++) {                                 g.fillOval(r.nextInt(1001),r.nextInt(701),wh,wh);                         }   //                      wh = r.nextInt(300);                         try {                   Thread.sleep( 20 );               } catch ( InterruptedException e ) {                   // do nothing             }                 }         } }

In this applet, There is supposed to be a random circle drawn at a random location. It's width/height starts at 0, and is supposed to increase up to the randomly generated number thus making the circle bigger in an animation style. However it stays at the same size that's defined in the for loop (0) so you can't really see it. How come it's not increasing?

[ben_g]

Look closely at this code:

Code: Select All | Copy To Clipboard

1	for (wh = 0;wh>=r.nextInt(300);wh++) {

It calculates a random number in every cycle of the for loop. This can be very irreliable.

further:

Code: Select All | Copy To Clipboard

1 2 3

int wh = r.nextInt(300); ... int wh = r.nextInt(300);

These two lines are a waste of size and CPU. I know that it's only a few bites and under a microsecound, but in a large applet, this kind of optimisation can tell the diference between fitting on a CD, and not fitting on a CD.

back to your question: You draw an oval with increasing the size, but always at a random location withouth deleting the previous one. I think your problem is that the screen is filled with hundreds of ovals so that you can't see a single oval. Instaed the screen will be just a solid color.

The first lines weren't an answer to your question, but I just wanted to help you to optimise your code.

[Snake X]

oh ok. Well thanks for helping anyways, but I figured it out though :p

oh btw:

but in a large applet, this kind of optimisation can tell the diference between fitting on a CD, and not fitting on a CD.

theres always winrar

[Ashbad]

Code: Select All | Copy To Clipboard

1 2 3

int wh = r.nextInt(300); ... int wh = r.nextInt(300);

These two lines are a waste of size and CPU. I know that it's only a few bites and under a microsecound, but in a large applet, this kind of optimisation can tell the diference between fitting on a CD, and not fitting on a CD.

Since it could be placed in a function format, space could be conserved that way.  However, that could be only ~50 bytes (random guess), and follows the idea of 'inlining' functions -- which increases size but speeds many operations up.

I think it would be fine, since declaring it as a method would just add that much more size back, and would not merit any reward for optimization.  I say keep it