i don't mean something need to be fixed/changed.
i'm just saying, i might have found the way to guarantee the blit result is correct.
after setRenderTarget(tex), we either only do blit or do blit after rendering any World.
if we only do blit, we use scaling, if we blit after calling World.renderScene, we use position offset. both lead to correct blit result.
i can miss other conditions, but in the 2 situations i tested, i got correct results.
you can test in your RPG game, if you add emptyWorld.renderScene(fb) just before blitting the quest book, you can see the blit result becomes different. if you add a position offset and remove scaling, you can see the blit result become correct again - if i am right.

i don't want to copy my code here because my code is scattered in places and there are a lot of dependencies.
but the environment is this: fb size 1920x1080 , tex size 1024x512 , tex has several regions and each has borders to avoid clearing other regions , setvirtualdimensions(1024,512) is called once for the tex before calling setRenderTarget.
i tested removeing rendering of object3d, found that simply resetting the fov (emptyworld.renderscene) can lead to the situation of needing offset but not scaling. which means World.renderScene() changes the situation. test result is consistant.

hi, i encounter a situation that blitting is not fixed by scaling but by offsetting position.
offset size = (fb.width-tex.width)/2 , (fb.height-tex.height)/2 .
the situation is this: setVirtualDimensions(tex size),  render some object3d , then blit.
also ,if camera fov is very small, i must reset fov to a normal one (calling emptyWorld.renderscene) before blitting or blit result is inaccurate.
i think blitting after rendering object3d is different from pure blitting (into texture).

there is another problem which we know already: the rendered image is flipped in texture. but it can be counteracted from app level. i just think it's strange.

it works , thanks.

another problem i encounter again is the wrong scaling of blitting , when the target texture is of different size from the real fb.
the blitting system thinks the texture is the same size as real fb, so i need to scale again. for now i can make a scaling function to solve it.
the current api would confuse new users, sometimes it's hard to figure out what is wrong, i encountered that several years ago.
i think the best solution is to use normalized value for positioning if the engine provides a widely compatible api.

the question is not about the color , but about the border of texture being cleared , when clearAll option is set to false,
while the java doc says otherwise.

anyway, now i use blitting (from a pure color texture) to replace clearing.

fb.setRenderTarget(tex,9,9,9,9,false); fb.clear(0xffff);

with the above code, the whole texture turns blue, why?
tested on powervr 6250.

Hi Egon,
i thought of a situation which i am not sure is necessary at all, that temporarily switching the render target.
if that happens, a getRenderTarget method can ease the problem of (the engine user) keeping track which texture is the current target.
like this:
b=getRenderTarget();
setRenderTarget(a);
render something;
setRenderTarget(b);

but if the engine doesn't call setRenderTarget, only the app code call it, then the user can use a global variable to keep track of the target texture. then getRenderTarget is unnecessary.
and temporarily switching render target might be a wrong thing to do.

i see, thanks.

i found some feature of es3.0 that i like to have, such as occlusion query (a better object3d.wasVisible() function)
is it possible to enable es3.0?

thank you Egon.
i am just exploring possibilities, i have little experience in collision detection.
overall i think using simplified mesh with JPCT's collision detection methods is the best solution.

hi Egon,
the java doc says getPixels costs a lot of time (for realtime rendering).
is the time related to the size of framebuffer?
if the framebuffer is of size 1x1, does it still cost that much time or is the time much shorter?
i think of using getpixels to do collision detection, is it possible?
the method is like this, place a camera at a bullet, set farclip to the distance that bullet travels in delta time, read the resulting depthbuffer to know whether/where/when the bullet hits something.
if this is possible, is it better or worse comparing to the ray-polygon collision detection in jpct engine?

hi Egon,
if i write a shader with sampler2D only in vertex shader but not in fragment shader, (other thing are similar to default shader) will jpct prepare the texture for the shader?
this is because i use pure color texture on some objects, texture color doesn't vary.

one of the best screenshots i have so far. most recent 3D model,(i made dozens of models before this one , as practising)

can you use while loop?
int i=lightcount; while (i>0) { do something; i--; }
i never used a loop though.
using variable in array seems fine for me. i did something like this:
int i=int(position.x); position.x=uniform[i*3+1];