No. Instead I have some 3 rendering methods.1: Do nothing, 2: ReRender the Actor Sprites3: Render the Background image, and generate the clips

Then based on the return of my update() method run the the correct rendering...

Working great so far except one little problem: I can't seem to make areas have exact pixel values without having antialiased edges. I think that it might be caused by the internal storarage of the coorinates being double...

I keep having the problem of not being able to get an area to cover by a per pixel basis. There are always antialiasing:

This is the basic tile:

Any ideas on how to make it not blur those edges? I've tried using rendering hints to turn off antialiasing, but no difference...

I think that there is a way to dynamically gererate an area based on the transparency of a graphic with PixelGrabber... any help on how to change a BufferedImage to a area based on whether on not the pixels are transparent?

This is how I'm working it:This is a Final Fantasy Tactics/Tactics Ogre clone. Tiles sit on top of blocks.When you go to draw actors, they have to be behind any blocks that are in front of him.

So, I render everything in the Tile format, and make a new Area for every Y. Then, when I go to render a actor, I create a new area the size of the screen and subtract any areas that have a greater Y then the actors.

When I do that, I get a clipped area so that it appears that the acctor is behind the blocking tiles. This prevents me from having to render the entire image, and allows me to draw just the Actors.

that looks very nice. if you are able, i'd really like to have a look at the whole source... also, what's the problem with the anti-aliasing? is it slow or is it making the edges look funny when in front of the actor?

Its making the edges look funny. I found out that it is caused by Java2D storing the polygon as floating point coordinates. To get around this I started using the Rectangle class, but this is taking to long... I really need a way to use PixelGrabber to create an Area based off of an image's alpha channel.

Also, is there a way to translate an area?

Juddman: send me an email at: [backwards]moc.liamG AT snikpoh.m.ffej[/backwards] and I'll email you the source...

anti-aliasing rendering hints do nothing for images. Those only affect Strokes or Shapes being drawn. What you want for your image to retain its anti-aliased quality is to save them as png's with full translucency. If the space around the isometric tile has a 0 for it's alpha value, you should never have any need for setting Clips or using Areas because when you draw with the tile, it should only use its colored portion.

I know that when I display my tiles that the alpha is... well alpha. And I know that when drawing without using clipping that it works fine.

What I want to do is make it so that if I want to display an Actor behind a tile that I don't have to rerender the entire map (I can't use the standard dirty rect logic because there are layering issues).

So in order to redraw an actor to the background I need to clip out of the actor's graphic where the tiles are that are over the character. For instance if the character is half visible behind a low wall, you don't want to render the entire actor, just his top half.

I fixed the antaliasing issue by resorting to a bunch of Rectangles (because they store their coords in int). But the issue with this is that it takes too much cpu to clip with an Area of 20 rectangles per tile.

The solution to my problem would be able to make a pixel acurate Area from a given png.

I've tried that also, the problem again is that because it is isometric the layers are in diagonal lines, causing the BufferedImage for each layer to be the size of the window. This gets increasingly more taxing on the system because you can't just redraw one of those layers, you have to draw every layer above the one you want to redraw.

Lets say that I have an actor on Y:3. And lets also say that the screen is big enough to handle 20 Y. This means that in order to redraw Y:3 you also have to redraw (to the screen, not the actual tiles) everything between 3 and 20.

I found it more taxing on the system to redraw 17 buffered Images then to just redraw the entire thing tile by tile, actor by actor.

With doing it by clipping and Areas I can make it so that a minimal amount of drawing is going on no matter the screen size. It would all be based on how many actors were being refreshed.

ahh I wasn't talking about y layers, I was talking z layers, so like in ff tactics the most buffers you would ever have would be perhaps 5 layers. I don't know why your image shows areas so tall... but hey, it's your game If you want to make it this intricate perhaps you could just use a better rendering engine like LWJGL.

Instead of using clipping, how about draw a separate alpha channel based on the foreground/background separation. Then when you blit your player, change the compositing rule to use the alpha that you created.

E.g.: Assuming you only blit one pass to draw the terrain.- Clear the screen so the screens alpha is 0- Blit background objects with compositing rules that copy the alpha channel to the background image.- Blit foreground objects such that the background alpha is left at 0- Blit the player so it only shows through where the dest alpha is 1

I'm not certain the rules on AlphaComposite cover all the needed cases.. but it might be an approach that works out.

Instead of using clipping, how about draw a separate alpha channel based on the foreground/background separation.

The problem comes with actually generating the alpha channels... if I could generate seperate alpha channels I could just apply the clippings this way also...

Okay, I have a quick question that might solve all of this....

I have an object called a Sprite_Cache. His job is to store all the graphics as Images and provide keys in String format. In order to store these Images he uses a HashMap, and put()s the image in there...

This way when I want the Sprite named "Actor_001_d_1" I just go:Image AnImage = (Image)sprites.get("Actor_001_d_1"); Is this accelerated? Because I store my tiles in there, and for every tile being drawn it gets its image this way....

well first off, I don't think Image's are accelerated period. If you're asking about the .get() and the type cast, I don't think any optimization happens there. Even Generics which make it look better don't even optimize (my biggest peeve) it. What I do with my stuff is something like this:

i would perhaps try clipping the sprite graphic when you draw it rather than clipping the terrain. then you could use just one large buffer for the entire background / foreground. the tricky part might be making the formula that generates a polygon to use as the clip bounds.

i'm not sure how this would affect performance but i think calculating a polygon that represents the area that is in front of the player sprite and clipping just the sprite(s) when you draw it (or them) should be faster as its a much smaller image you're clipping, and the anti-aliasing shouldn't be as much of a problem, and in fact might look nice. as they say, logic is 1000 times cheaper than rendering in games, so adding complexity to the logic in order to reduce the amount of rendering done almost always pays off in performance.

i'm just throwing ideas around now, and i'll probably even test a couple when i get your source, but one way to do it would be to calculate a polygon for each layer and clip the sprite based on a combination of all layers in front of it when you draw it.

So I went through and changed it over to using a BufferedImage[], and there wasn't any change between the two as far as the performance... I was rather hoping that this would speed everthing up... Thanks though!

Objects that have references to BufferedImages don't affect how it gets accelerated. Having it stored in an array or Hashtable don't make a bit of difference in that department. Am I understanding you correctly? I don't think I know what it is you're asking now.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org