[Nuke]

heres a basic gun camera script. it has some issues though. first off something is wrong with drawImage(). scripting.html says:

drawImage(Image name/Texture handle, [x1=0, y1=0, x2, y2, uv x1, uv y1, uv x2, uv y2])

however for some reason it wants the 4th argument to be a bool when it should be x2. as a result i cant flip the image and so its upside down. also backgrounds are a little screwy. it works ok on some skyboxes, like ones with 32 bit tga textures, or ones with white backgrounds. anything with efficient textures wont work.  using only a starfield you get trails like the image isnt cleared between rtt calls, dispite a black backfill to clear the texture between frames.

anyway here it is, its sorta cool. its hard coded to the medusa (or any ship with a turret01a), and will probibly crash the game otherwise. also find a good tga skybox.

Code: [Select]

;;render targets

#Global Hooks
$GameInit:
[

tex = gr.createTexture(256, 256 , TEXTURE_DYNAMIC)
cam = nil

]
$Simulation:
[
ship = mn.Ships["Alpha 1"]

if ship:isValid() then
tsub = ship["turret01a"]
end

if cam == nil then
cam = mn.createCamera("guncam")
end

if tex:isValid() and cam:isValid() then
gori = tsub.GunOrientation
gori.p = gori.p - math.pi*0.5
tori = ship.Orientation * (tsub.Orientation * gori)
cam:setOrientation(tori)
cam:setPosition(ship.Position + ship.Orientation:unrotateVector(tsub.Position))

mn.setCamera(cam)
gr.setTarget(tex)
gr.setColor(0,0,0,255)
gr.drawRectangle(0,0,256,256)
mn.renderFrame()
gr.setTarget()
mn.setCamera()
end

]
$Hud:
[
if tex:isValid() then
gr.drawImage(tex, 10, 400)
end
]
#end

another idea i had was a renderWireFrame() function. same as render frame, but does a faster line draw of the scene. this could be used to do combat scanners. i remember seeing a wire frame scanner in a star fury on an episode of b5, one of the things that can be done with it. another idea is to use it for a fog scanner. so you can have a wireframe overlay of where all the ships are in the nebula, dispitre the fact that they are invisible in the fog.

[Bobboau]

there needs to be a way to set detail level so you can put it to the lowest level before drawing the frame...

anyway, I know it still doesn't work properly all I did was prevent the low level poly drawer from thinking an RTT texture was a NP2 texture, and make sure the make texture function set the UV scaleing to 1.0. honestly I'm not realy trying to totaly fix this because I'd much more likely break a dozen other things, FS's bitmap manegment and drawing functions are loaded with all sorts of bizar interdependencies.

[Nuke]

looks like the z buffer is shot as well. some loding would be nice, maybe that wireframe render, and perhaps an option to not render certain maps, backgrounds, and weapons (though weapons appeared to render from the gun camera). there are some color discrepancies as well, i tried drawing a red circle on top of the gun camera texture and it came out green. would also explain why dds backgrounds didnt render too well. none the less im impressed that it worked at all.

i should probibly write in an automatic frame skip option as well, where the number of frames skipped would depend on the framerate. for me it never dropped below 60, but that was in simple test missions. i figure skipping between 0 and 10 frames depending on how far away from 60 fps the game happens to be running. so anyone with a good gaming rig with fps to spare, can get a full frmerate gun cam, lower end machines would skip a frame for every frame 5 frames below 60. another idea is to come up with a way to not use the rtt code if the texture is not on the screen, like if its on the panel in the back of the ship (and only visible when flying gunner), or if the dot product between your view vector and the vector to the screen is low.

[Nuke]

another problem i found is that all draw calls to the targeted texture seem to be additive, rather than replicative.  like if i try to draw a dark grey rectangle on the texture, it will keep adding up to white. if i set it to zero it only adds zero, it doesnt set it. this also seems to happen with mission backgrounds when i do renderFrame(), while everything else seems fine. i can get around that by using a fully opaque skybox.

[Bobboau]

try useing gr.CurrentOpacityType (ALPHABLEND_NONE)

[Nuke]

that didnt seem to work, it doesnt work as a function, but it works ok with an = (works meaning it doesnt crash). im still getting the same problem.

[Nuke]

seems i can draw on top of any 32-bit tga texture without the alpha problem.

so far i got the pb sepulture with 3 working displays. i have the gun camera, which not only operates the turret but, if you fire an infyrno, you can also guide it. its almost exactly like the desert storm missile camera footage, cept its in color. im sorta stuck on a turret aiming problem. the turret essentially wants to fire in a direction other than where its pointing. i think somone said somewhere that the game keeps 4 matrices for the turret. problem is i only have access to 2 of them. i came up with the idea to store the orientations of the parts, and change them so that they can fire in another direction, then i reset their original orientation. it shows promise but i need to know how the game calculates its matrix for firing of turret mounted weapons. 

i have a crude radar display as well. its just an orthographic projection of the ships on the xy plane, blips are represented with little circles. the radius depends on the distance, 10 - log(z), so it looks convincingly 3d. i might go as far as color coding the dots ot iff status. on the 3rd display i have a picture of some kittens. im just using this to print debug information. i thought about putting hud pong on it, but i think i need to rework and improve it.

im gonna post vids on youtube once i got this working on youtube. i might even release a demo vp that can be installed on top of nukemod '06, if i feel so inclined.

[Bobboau]

are the three displays on the actual ship geometry?

[Nuke]

indeed. i had to create a new sub object for them. all i did was copy the faces from the panel in the cockpit model and stuck them into their own submodel. they sit a couple units over the originals. gave each screen its own texture and uv mapped it so that any texture would cover the whole screen. they really dont have textures, i just used some bogus texture names, panel1, panel2, panel3. this way if the rtt code does not work, the painted on screens can  still be seen. i had planned to use invisible textures, but i wasnt sure they could be addressed individually. also all draw calls seem to be rendered in vertical mirror. i may work around this by flipping the uv space. also my 256^2 textures seem to think they are 200*185 textures

eventually i want to just use a single 512^2 texture, to which all panel gauges and cameras can be rendered to. cameras would need to be rendered to their own textures, then placed on the big texture with a drawImage() call. this way a panel template texture can be used when creating a ship. you can uv map the polies for the various elements to thatever section of the template you see fit. a section for radar and a section for video displayes, and smaller ones for individual gauges and other things like indicator lights.

im thinking about having 3 layers of surfaces in the panels, to make the gauges look realistic under various lighting conditions., an outter transparent layer, with glasslike textures, an inner layer which is a dummy pannel with glow but now shine or env. then a layer in the middle for rtt stuff. this is a good way to deal with screens. but id like to put some old skool analog gauges into some of my pirate ships, they can be done in almost the same way. i picked the sepulture because it already has working yoke and throttle animations, they use very little code so i dont see it being a huge problem merging that into the demo. so you will have a fully functional cockpit in a very short while (short in my terms can usually mean a few months ).

[attachment deleted by ninja]

[Bobboau]

SPACE KITTENS!!!!

...anyway....
nice work, though do keep in mind even thought this does sort of work, it's still got a lot of bugs, and any workaround you do will be invalidated eventually. also I get the impression from what taylor has said, that what I did wasn't suposed to fix it so there is probably more going on here.

[Nuke]

this is mostly a slap together job, the turret and missile code were scripts i had written before, now they can be put to use and integrated now that i have the interface to do so. the radar took me about 10 minutes to get working. thing is this setup eats up 5 small textures. so far the performance seems good, but i doubt it would be good in a big mission.

my mod features are frequently invalidated. the first time was with gatling guns, but it turned out the newer system was better. it happens all the time when dealing with scripting, as the system itself is an ongoing development. then we have a new cockpit system, so those have got to be re-done, hopefully retaining all of the features scripting has made possible. most of my work goes to adding new features to old ships. i dont think ive modeled a new ship since the chimera, which was the main feature of nukemod 2006. if anything im giving the coders ideas and proof of concepts for improving the engine

[WMCoolmon]

So is there any possibility of getting a patch or commit of the RTT 'fix' in the unstable branch?

[Nuke]

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
blending.

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

[Aardwolf]

Nuke + My FS2Open RTS mod Question: When a message pops up, alpha-blended HUD rectangles change brighntess (possibly a blending mode issue).

Is there a lua function we can use to fix this?

Edit: Apparently this only happens on my version, not Nuke's. However, I can tell quite clearly that the blending function is changing between additive and alpha blending. Please assist.