[gameprogrammer] Re: I wonder if I can go Remedial Applet on you all... :)

That's fantastic stuff, Dave! :)

I'm off to read up on the Swing tutorial - got a bit excited with the 
now-working code last night... ;)

Back in a bit with Mike's Newbie Update... ;)
-Mike

PS: 4 line message, 3 smilies. I need more than just Java help...

----- Original Message ----- 
From: "Dave Slutzkin" <daveslutzkin@xxxxxxxxxxx>
To: <gameprogrammer@xxxxxxxxxxxxx>
Sent: Thursday, March 31, 2005 12:42 AM
Subject: [gameprogrammer] Re: I wonder if I can go Remedial Applet on you 
all... :)


> On Wed, 30 Mar 2005 22:32:56 -0500, "Mike Gillissie" <Niyoto@xxxxxxxxxx>
> said:
>> - loads an image I've got (grass) into a BufferedImage object
>
> I don't think you want to read the image each time you paint.  That
> should be done in the constructor so you just have to refer to the
> already loaded BufferedImage object in the paint method.  (Not the paint
> method, actually, as I'll get to.)
>
>> - tiles the image on the screen (by drawing it x*y times) - this will
>> change
>> soon to allow me to draw appropriate tile images based on which part of
>> the
>> map I'm showing
>
> The code to do this is correct.  But.  Before you do any custom painting
> (which is what you're doing, rather than letting components draw
> themselves) you need to read this stuff:
> http://java.sun.com/docs/books/tutorial/uiswing/14painting/index.html.
> The long and the short of it is that you shouldn't override the paint()
> method, you in fact need to override paintComponent().
>
> Also, I wouldn't override the method in JFrame.  Just let the JFrame
> paint itself however it sees fit (this is probably the heart of your
> resize problems).
>
> Instead, I'd try creating a (for instance) MapPanel class which extends
> JPanel.  That's encapsulation, right?  The JFrame has nothing to do with
> painting its children, the children should each paint themselves.
> Remember, Java loves having lots and lots of classes.
>
> I'd imagine this could look something like this:
>
> class MapPanel
>  extends JPanel
> {
>  private BufferedImage mImage;
>  public MapPanel(BufferedImage image)
>  {
>    super();
>    mImage = image;
>  }
>  public void paintComponent(Graphics g)
>  {
>    Graphics2D graphics = (Graphics2D)g;
>    for (int x = 0, width = getWidth(); x < width; x +=
>    mImage.getWidth())
>    {
>      for (int y = 0, height = getHeight(); y < height; y +=
>      mImage.getHeight())
>      {
>        graphics.drawImage(mImage, x, y, this);
>      }
>    }
>  }
> }
>
> Same code, different place, basically.
>
>> Two main questions so far:
>>
>> 1) Is my method of using BufferedImage and Graphics2D.drawImage the most
>> efficient method? Although the overall map will be very large, the
>> visible
>> portion will be quite managable - but am I making things more difficult
>> for myself than need be?
>
> At this point, do the simplest thing that could possibly work.  This
> should work fine.  If you start to have performance problems later, then
> worry about it, but at the moment you just want to get something on the
> screen.
>
>> 2) What's the deal with Paint and Update? Resizing the window is
>> automatically painting on me, which isn't bad, but sometimes resizing
>> just
>> leaves me with an empty-looking window - should I be overriding some sort
>> of
>> window resize events, painting only when the resize is done? Or would I
>> do
>> better to (*gag*) lock the window size?
>
> It may _eventually_ end up being useful to lock the window size.  For
> the app as it currently exists, it shouldn't be necessary.  Get it
> working with resizing, then decide if the cost is worth it.
>
> All the stuff about paint (and probably update as well) is explained in
> the section I pointed out.  The Swing painting model is a little
> complicated, but you need to have some idea of what's going on behind
> the scenes.
>
> Dave. 




---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts: