2D Isometric Maps With 3D Models...

[cyberkilla]

@cyberkilla: I've to think about this a little...i'm not in the position to give a good answer for this now, i'm afraid.

No problem. I realise its something that is rarely done.
It do not know why, however, because it is a fantastic way of
permitting detailed maps with a tiny polygon count:)

[athanazio]

Egon, learned a lot from the sample that you said to look at, but I'm still missing how to add diffetent textures for pieces of the map.... any idea ?

[EgonOlsen]

No problem. I realise its something that is rarely done.
It do not know why, however, because it is a fantastic way of
permitting detailed maps with a tiny polygon count:)

I took the time to read this over....and i would basically stick with what you are doing atm. Just make sure that your tiles are being hardware accelerated by making them "compatible" images. If you don't know what this means...the Buggaroo-sources (my 4k submission for this year's contest) do this, just have a look at the a(int mode, JFrame w, int wi,int hi, Color col)-method: http://www.jpct.net/4k/buggaroo/Buggaroo.java
Creating a new image every time seems quite expensive. I suggest to create a BufferedImage instead and refill its pixel data with the one from the framebuffer. You can't make these images "compatible" because you are accessing the pixels directly but as long as not 1000 avatars are on screen, this shouldn't matter. And as Mizuki mentioned, you can use one World and make only one object visible at a time to render it.

[cyberkilla]

Aha! Well, this is good to know:)
Actually, I have each tile stored as a VolatileImage,
and the backbuffer is a buffered image.

They are all using createCompatible, but you have reminded me of a major mistake!
The function I made for quickly creating bufferedimages makes them ALWAYS bitmasked. And ive read a thousand times that bufferedimages with any transparency are not sped up as much as their opaque counterparts. In fact, I read last night that an opaque bufferedimage is a separate subclass of bufferedimage:).

I also found "getOutputBuffer()" which works for me, but just incase, I use "getType()" to make sure its compatible.

Since Microsoft is no longer leaving JVM1.1 on their browsers, and
forcing a lot of people to upgrade soon, I dont think JVM1.1 is a major concern for me. It is always nice to support it though.

My point is, I can use the actual backbuffer to make the transparent image. Its still creating a new instance every time it's painted,
but it is better than the 2 new instances I had to do before this.

Thank you Egon:)


EDIT:
Im using Swing for the gui you see, and to stop the need for repaints,
I have set the components to ignorerepaints, switched off the repaint manager, and now use a bufferStrategy.

The only problem is, we are talking about another backbuffer here.
I cant just paint the map to this backbuffer for some reason, because
it goes blank every time:) Ill figure it out eventually;)

No problem. I realise its something that is rarely done.
It do not know why, however, because it is a fantastic way of
permitting detailed maps with a tiny polygon count:)

I took the time to read this over....and i would basically stick with what you are doing atm. Just make sure that your tiles are being hardware accelerated by making them "compatible" images. If you don't know what this means...the Buggaroo-sources (my 4k submission for this year's contest) do this, just have a look at the a(int mode, JFrame w, int wi,int hi, Color col)-method: http://www.jpct.net/4k/buggaroo/Buggaroo.java
Creating a new image every time seems quite expensive. I suggest to create a BufferedImage instead and refill its pixel data with the one from the framebuffer. You can't make these images "compatible" because you are accessing the pixels directly but as long as not 1000 avatars are on screen, this shouldn't matter. And as Mizuki mentioned, you can use one World and make only one object visible at a time to render it.