Background Images

[Albareth]

How do you set background images?  As in a space flight simulator, the background image would be a starfield.

[EgonOlsen]

Blit the image into the framebuffer (before rendering the actual scene) by using the blit-methods from FrameBuffer. There is one method for int[] and one for blitting textures. I strongly suggest to use the second one. If the backdrop image doesn't fit into a power of 2 texture, just use the next power of 2 in which it fits, i.e. store a 640*480 bitmap in a 1024*512 texture (for example).

Code Select Expand


 buffer.clear();
 buffer.blit(backdrop,0,0,0,0,480,300,FrameBuffer.OPAQUE_BLITTING);

 theWorld.renderScene(buffer);
 theWorld.draw(buffer);
 buffer.update();
 buffer.display(g);


If your backdrop image covers the whole screen, you may set Config.isIndoor to true, even if outer space is not exactly indoor. This will prevent the framebuffer from being cleared each frame (which happens anyway because of the blit).

[Bregosch]

Hi,

that might have worked some time ago, but now the blit methods specifically state that only blitting to frontbuffer is possible. I would really like to blit a texture as the scene's background. Any suggestions how this can be achieved now?

[EgonOlsen]

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.

[Bregosch]

Hi,

thanks for your reply, but I wouldnt have posted it if it worked. I tried everything I could think of before posting.

What I do is essentially this:

Code Select Expand


   buffer.clear();
   buffer.blit(background, 0, 0, 0, 0, 512, 512,
       FrameBuffer.OPAQUE_BLITTING);
   world.renderScene(buffer);
   world.draw(buffer);
   buffer.update();
   buffer.display(g);


My configuration:

Code Select Expand


   Config.isIndoor = true;
   Config.fadeoutLight = false;
   Config.linearDiv = 50;
   Config.specTerm = 1;
   Config.maxPolysVisible = 9000;
   Config.farPlane = 1000;
   Config.lightMul = 1;

   World.setDefaultThread(Thread.currentThread());

   buffer = new FrameBuffer(512, 512, FrameBuffer.SAMPLINGMODE_OGSS);
   buffer.enableRenderer(IRenderer.RENDERER_SOFTWARE);
   buffer.setBoundingBoxMode(FrameBuffer.BOUNDINGBOX_NOT_USED);
   buffer.setBufferAccess(FrameBuffer.BUFFER_ACCESS_SPLITTED);


The world renders just fine, and yes, because of the Config.isIndoor the colorbuffer isn't cleared, BUT: no blitting occurs. Sometimes, very very rarely, I can see the texture for an instant, and then its gone again.

Any idea?  :?

[EgonOlsen]

Now i see...the problem is the use of oversampling in your application. It should work when you are using SMAPLINGMODE_NORMAL instead. However, that's not a real solution if you really want to use oversampling (or undersampling). The problem is, that when using X-sampling, there are two buffers and blitting happens in the output buffer. In this case, the docs are actually telling the truth...i have to think a bit about how to solve this...

[EgonOlsen]

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:

Code Select Expand

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.

[Bregosch]

Thanks very much, it works!  

I mean, the sampling mode really was the reason. I tested it with normal sampling, and it worked quite nicely. Unfortunatly I need the higher quality of the OGSS mode. So I am going to use your "hot-fixed" jar and I will consider your advise concerning the texture size.

If you come up with someway around this problem (the need for a 4-times bigger texture), I would be glad to hear from you! Its an applet and size DOES matter here

Cheers,
Bregosch

[EgonOlsen]

What do you mean by "size"? Size in memory or size when loading? If it's about file size, i have an idea about how to do the scaling yourself in the applet. Let me know, if you are interested.

[Bregosch]

Hi again,

by size I meant the loading size. Having people wait forever to actually download all applet data is really a problem, but bloating the image in memory doesn't make me loose any sleep  :twisted:.

So I would be glad to hear your idea how to scale the texture after its loaded (if I got you right on this point).

Cheers,
Bregosch

[EgonOlsen]

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:

Code Select Expand


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.

[Bregosch]

Excellent, thanks!  

Now everything should be fine! I'll try the new jar today and post again if I experience any more problems, but I don't think I will.

Thanks again,
Cheers
Bregosch