this is related to the 4k competition,
publicvoid paint(Graphics g)
{
System.out.println(g.getColor());
}
Is it ok to assume the initial color on a Graphics object is black, as it seems fine on all the Windows machines i've tried.
a second thought..... in the specification for the paint method of a Component, shouldn't the default values of the Graphics object be defined somewhere? (or atleast be defined as undefined?)
g.getColor & g.setColor deals w/ the foregroung color for painting. Default is black.
If you create an image though its color will be the same color as the background color of the component. lightGray is default.
To save some byte code:
I got rid off paint(Graphics g) method from mine. Instead, I got a hold off the graphics object within the game loop and did the drawing to it there. If your sleep length is small, you won't even know the difference.
And also don't keep a Thread as a private member. Just use it and of your init or constructor of your applet as new Thread(this).start();
That saves you some more.
This 4k game contest is really great! It makes me concious about every line of code I write. I was only used to focus on speed vs memory trade offs, not at all on byte code size.
> g.getColor & g.setColor deals w/ the foregroung color
> for painting. Default is black.
just so I know - where did you find that out from?
i've never noticed the default values being mentioned in the java doc.
>
> If you create an image though its color will be the
> same color as the background color of the component.
> lightGray is default.
>
> To save some byte code:
>
> I got rid off paint(Graphics g) method from mine.
> Instead, I got a hold off the graphics object within
> the game loop and did the drawing to it there. If your
> sleep length is small, you won't even know the
> difference.
yeah, im doing the same (though I still have the paint method, because the pregame/postgame screen is drawn through regular repaint events, not the gameloop)
>
> And also don't keep a Thread as a private member. Just
> use it and of your init or constructor of your applet
> as new Thread(this).start();
> That saves you some more.
yes, it would have saved space.... if jax wasn't optimising the code :)
(jax removes the Thread private member, because it is only used in 1 method)
>
> This 4k game contest is really great! It makes me
> concious about every line of code I write. I was only
> used to focus on speed vs memory trade offs, not at
> all on byte code size.
I totally agree, from what I initially thought was size optimal code, i've managed to squeeze another 400 bytes!! (im down to 3694bytes now - which leaves plenty of room for car handling improvments, and a little better front-end)
> > g.getColor & g.setColor deals w/ the foregroung
> color
> > for painting. Default is black.
>
> just so I know - where did you find that out from?
> i've never noticed the default values being mentioned
> in the java doc.
You won't find it there. Because creation of the Graphics context is os dependent. Whatever color you set up for your font in your desktop env. will be default in java. I have done programming w/ Win32, Motif, and Mac Toolkit. I know the fact that they all use black as 'default' foreground color. But there is a risk. Because any fool can simply go to display props and change the font color :) So it's up to you...
As long as you document that you rely on the default desktop settings you are fine. Just like a release note...
> > And also don't keep a Thread as a private member.
> Just
> > use it and of your init or constructor of your
> applet
> > as new Thread(this).start();
> > That saves you some more.
>
> yes, it would have saved space.... if jax wasn't
> optimising the code :)
> (jax removes the Thread private member, because it is
> only used in 1 method)
I haven't used jax. I know it is used a lot w/ midlets. But I thought jax just did obfuscation on methods and member names. More than that huh? I'll use it to see how much I can squeeze out..
