ive been messing around with rtt quite abit lately. merging it with the virtual cockpit scripts ive been working on. i found some intresting info out that might help pinpoint the scaling issues.
a 255^2 texture seems to have an accessable resolution of 205 * 192 when drawing an unfilled rectagle or text. the 0,0 coord seems to always be the top left corner. also the textures are flipped on y so i had to flip the uv space on the panel submodels to compensate.
filled rectagles seem to be off by a few pixels (which apears to be down and right about 2), circles seem to want to be drawn in a range of 164 * 144 (that being the bottom right corner), its just really strange behavior.
also to completely cover a 256^2 texture with drawImage, a texture of 205 * 192 (in a 32bpp format) is required.
if you do not fill in a texture with drawImage with a 32 bit texture, the texture will behave as if it has additive
if you render the frame on top of the texture, and you dont have a 32bpp skybox with no alpha, then the image
behaves as additive. i presume i can fix this by drawing a "background" first with drawImage and a 32-bit non-trans image
and then the frame on top of it. edit, i presumed wrong, without a 32-bit skybox, and overlaying over a fully opaque black texture, the additive behavior is still there.
any other draw calls after the "background" is drawn seem to work fine, save the coordinate scaling postion issues.
problems with using renderFrame() on a texture, aside from the additive glitch, is pretty much just what appears to be a busted z buffer. you can see some geometry through other geometry. its possible that this is being calculated after the call to renderFrame(), since im doing the rtt in the $simulation: global hook, instead of the $on frame: conditional hook, its possible that the z buffering is done between the hooks and it might be preferable to do the rtt in $on frame.
theres also that problem with the optional parameters on drawImage. where the bool is the in the 4th parameter, where your y2 coord should be. anything past that bool does not work. i think i mentioned this before. it might be a bug in scripting though. further investagation seems to be required.
another thing thats odd is the getScreenCoords() function is returning some really obscene numbers. ive seen it go as high as 8000 and even go negative. is this new behavior or a bug? it used to only go between 0,0 and 640,480 or 1024,768 (depending on video mode).