nice to see you back

for 4 type of terrains ( dirt, rocks, grass and sand),  and 10 levels of transitions 62 textures were generated. I used 64x64 images for tile textures.

I was never gone. :wink:
So that means around 1MB of textures...that's not much, i thought it would require more.
I noticed some jPCT/AWTGLRenderer related problems in your client and i spent some time today to get rid of them. I've uploaded a new version that includes this fixes here:

http://www.jpct.net/download/jpct107a2.jar

Changes are:

Fixed a threading issue in the AWTGLRenderer when changing the FOV. Added the option to blit into the backbuffer. This is a fix for a problem that occures when one tries to blit into the background of a over-/undersampled framebuffer. Added on option to modify sorting order of the VisList. Can be helpfull in case of sorting issues with transparent objects. Added on option to Loader to disable vertex sharing (helpfull for loading otherwise unusable keyframes in some cases). Added a new constructor to Texture to create Textures directly from Images. Improved texture loading a little bit.
Some fixes for the AWTGLRenderer: Fixed an occasional class cast exception when setting RGB-Scaling. Fixed a stupid bug that caused green color values to be mapped to green and blue when rendering (i can't believe that this one remained unnoticed). Modified frustum handling to cover a problem that could occur if two or more frames lie between two actually painted ones and the fov has been changed in between. Fixed a bug that prevented the command queue from being resized when needed in some cases which could result in some polygon missing for a frame or two. Fixed a bug that caused queued commands to be removed from the queue in some cases.


However, there still is a problem which i couldn't get fixed and i'm at a point where i'm having my doubts that's its reason can be found in jPCT but in the client. The problem is: Trees are flickering/disappearing (not sure what they really do) sometimes for a frame. I'm not talking about the "normal" sorting problems on transparent objects...this must be something different. To me, it looks like a kind of threading problem (because i had this kind of problems myself on hyperthreading/dual cpu machines). I'm just not sure if it's located in my code (i doubt it because it seems to affect trees only) or in yours. Are you by any chance doing some matrix/object/world/...-manipulation in a different thread than the one that executes the calls to World.renderScene() or World.draw()? Or in other worlds: Is there a chance that rendering and manipulation of the scene and/or objects interfere sometimes?

Das Problem liegt bei Java bzw. bei AWT...es läuft unter Unix standardmäßig nicht ohne X11 Server. Um das zu lösen, gibt es mehrere Ansätze.

1. X11-Server installieren (Ja, nicht immer eine gute Lösung...)
2. X11-Dummyserver installieren (z.B. Xvfb)...das soll gehen, ich habe es aber noch nie probiert
3. Java 1.4+ im Headless-Mode betrieben. Dazu muss man einen Aufrufparameter angeben: -Djava.awt.headless=true
Aber auch damit geht nicht alles...manches wirft eine HeadlessException. jPCT als API sollte damit aber gehen.

I've added Google's Adsense to the site. Maybe this helps to cover the hosting costs of jpct.net...but i somehow doubt it. Well, it's worth a try. I hope the ads are not too distracting...

I've added a new constructor to Texture that offers a possibility to create a Texture directly from an Image. Now you can do something like this to load and rescale your image before making it a texture:


Image image=Toolkit.getDefaultToolkit().getImage(<yourfile>);
MediaTracker myTracker=new MediaTracker(new Canvas());
myTracker.addImage(image, 0);
try {
    myTracker.waitForAll();
} catch (Exception e) {
   // do stuff here
}
image=image.getScaledInstance(512, 512, image.SCALE_SMOOTH);
TextureManager.getInstance().addTexture(<name>, new Texture(image));

I hope this helps to solve your problem. You can download this version by clicking the link i provided above. I've updated the jar.

Yep! There are more updates for phpbb than there are for jPCT.

Ok, i've added a fix for this...i'm not really satisfied with it, but it's the best i could come up with. The fixed JAR can be found here: http://www.jpct.net/download/jpct107a1.jar

Is has a new method in FrameBuffer to set the blitting target and it's used like this:

buffer.clear();
buffer.setBlittingTarget(FrameBuffer.BLITTING_TARGET_BACK);
buffer.blit(TextureManager.getInstance().getTexture("rocks"),0,0,0,0,256,256,FrameBuffer.OPAQUE_BLITTING);
buffer.setBlittingTarget(FrameBuffer.BLITTING_TARGET_FRONT);
theWorld.renderScene(buffer);


All you have to take care of yourself is, that the blitting texture will now be scaled according to the sampling mode, i.e. if you are blitting a 256*256 quad into the back buffer and are using OGSS, it will result in a downsampled 128*128 quad on screen. Or in other words: You need different texture sizes for the different sampling modes if you want them to look the same in the final image.

A small flaw: The 3d.bat misses a ; after the %CLASSPATH%

Well, it still works this way. Just try it. But i agree that the docs are a bit confusing. Must be a relic from the times where MemoryImageSource was the only kind of frame buffer that jPCT supported. What it actually meant was, that the blitting has to be applied after the newPixels()-call for the rendered image if the blitted content should lay on top of it. I'll remove or reword the front buffer part from the docs in the next version to avoid this confusion in the future.