Nice work:) Thats similar to what im doing.

Im using a jpanel to display the images,
but i use paintimmediately to get the maximum speed.

I must say I disagree with you there .

If you install something like Eclipse or Netbeans,
then you get syntax highlighting, and run buttons,
which is probably a lot easier.


Maybe its worth getting a decent book on Java?
Its by no means required but it does help. They are pricey though.
I bought one and it was £54:)

I agree with you there:).

A lot of the "alternatives" have so many classes and methods,
and strange render hints and flags, that you would probably be less confused making one from scratch;).

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;)

Quote from: "cyberkilla"

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.

This 3D api is so intuitive. I did have confusion about 3d in general,
but, in terms of using this api, there is little trouble.

I was looking into j3d, and I was shocked at how annoying it is to use.

If you happen to drop that code in here, Ill certainly appreciate it:)
If you dont, its no problem.

You have pointed me in the right direction now, and I wil be spending the rest of tonight making a proper character model.

There would be no use making weapons for a model i dont use, afterall:)


When(if?) I get it working, I promise to paste my implementation here.

Please do:) I am interested in all things about clothing
in 3d;).

@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:)