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.

Quote from: "AGP"Totally agree with you two. Before jPCT I had pretty much given up on 3d programming. It's very hard for one programmer to do anything useful by himself from scratch, and the complexity of everything else out there is annoying. Except DarkBasic, but it doesn't work very well, and Basic isn't object-oriented, which sucks.

Ah, DarkBasic. I never tried that so far:)
I have to say, my favourite programming language is Assembly.
I was lucky enough to have started helping out on SolarOS(Assembly Language Operating System). It really is a fantastically logical, simple, powerful, fast, tiny binary files, well established language.

It's unfortunate its not hardware independent:P

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

This looks interesting.

I cant really give any advice because I have no idea how it works right now:)

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

These are shots of the GUI that I have implemented...




This is what it looked like when i was using 2D:)



I had items working properly in 2D! but its just not as good as the 3d beast
I could have;)

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: "EgonOlsen"

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.

Yes, hello world example does look hard, but its easy.

Once you get your head around using imports, and swing,
its not so bad.
I suggest you do not start by making a 3d game.

You really need to understand whats going on in general,
or you will find yourself a little stuck.

Trust me, I do it every time;).

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.

I don't know much about this, but I have heard of a class called PolygonManager, who's javaDoc sounds very similar to what you speak of.

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.

Raft, I dont know what to say. Thank you very much!:)
It explained, and/or confirmed everything I was confused about.

I will attempt to make this work for me, and will be back here with the screenshots.

I use Blender, but it shouldnt have trouble with exporting individual frames.

Thanks again!:)

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

Quote from: "EgonOlsen"Do have a screenshot of this problem?

I do not, but I will have one posted in the next few hours.

I am in awe of what you have created here;).

Quote from: "EgonOlsen"@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:)