Let's see here... I was using straight 32x32 images for the sprites and background of this game on which i'm working. Then i decided to use a tileset image instead. So i went through and gave offset numbers to objects that previously had images. Then, in the drawing routine, i set a clipping region, moved the tileset image to the correct offset, then painted it. The problem is, it is a hell of a lot slower than using individual images. I don't want to keep using individual images outside of the game. Does anyone think using the ImageProducer/Consumer model to extract Image objects from the tileset image (one time only) would be a good idea? Would it be almost as fast as using individual images? Edited by - Jim_Ross on 1/22/00 6:49:43 PM

You could use the PixelGrabber to do the slicing and dicing of the tileset image and you''d get individual Image objects. This is as fast as loading individual images, but the downside is increased memory usage over one large image. So basically you have a choice between using lots of memory or having lot less speed.

Any idea why that technique is so slow? Is that the technique you use in your gameframe?

All the game graphics at www.hexadome.net is chopped from a large bitmap and alpha blended into the background run-time. I do all image manipulation in an integer array, convert it to an Image using the MemoryImageSource and then blit it to the screen...

(The map is drawn into the integer array first, pixel by pixel (alphablended), using splines to determine blending degree between the various textures)...

/Niels

Not too sure what ''blitting'' is exactly. So you break apart the image into pixel array data. Then associate that raw pixel data with a tile instead of a java Image object, then you combine all of those arrays into one large array. Send it to ImageProducer and then something like g.drawImage(WhatIGotfromImageProcucer,0,0,null) ...?
If that''s not what you do, would that be an okay thing to do? It seems like you would have to take the tiled 32x32 (or whatever) pixel array and turn it back into an Image to associate it with the Tile object. How else could you keep the lines staright when creating the large, entire map, array? Like print the first row of pixel data from tile 1,2,3... then the second row of pixel data form tile 1,2,3... and so on?

The speed decrease comes from using the clipregions, more specifically when you set a clip region in a graphics context you are changing the state of the graphics context and that is allways slow. When you have to do that changing each time you blit (draw) an image to the screen it is bound to have a negative impact on the speed.

The image producer thingie sounds very interesting as it would allow many fancy effects. I''ve known for a while that Java demos use this technique and that is understandable as most of the cool demo effects are based on wiggling the bits of an image. But is this technique really faster than using plain images and drawImage() method of the graphics object? Or is the main benefit the flexibility (ability to do alpha blits and other stuff)?

I don''t know if it''s faster, but if it''s the only way to use large (actually only about 192x192) tileset images instead of hundreds of individual images then it''s gotta be the way to go.

Doh! What happened to the post I made yesterday?

Anyway what I said was that while it is obviously not faster for raw copying of a single image (presumably, drawImage use the HW blitter if present, or at least a very fast memcpy() implemented in assembler or the like), it has certain advantages when doing a lot of pixel-level manipulation.

When manipulating the image you essentially set integers in an array which is substantially faster than using get/setPixel() on an image. The overhead comes from converting the integer array into an image for display (And this is surprisingly fast).

/Niels

so, you''re entire bg is one large array of data representing the pixels, then you make an image from that data and draw it to the screen. But how do you make that large array of data from the smaller arrays of data (the tiles). What i''m saying is, if i just copy the individual tile array to the larger map array, the tiles will just be long strands of images, not squares of images.... ya know?