[gameprogrammer] Re: I wonder if I can go Remedial Applet on you all... :)
- From: "Mike Gillissie" <Niyoto@xxxxxxxxxx>
- To: <gameprogrammer@xxxxxxxxxxxxx>
- Date: Thu, 31 Mar 2005 06:24:04 -0500
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:
