[KeldorKatarn]

Are you talking about light-emitting muzzle-flashes, or the actual light source that moves along with the shots?

With either, if push came to shove, I imagine you could try to average the positions of the shots, and in the latter case, if one shot dies before the others (e.g. when it hits something that they manage to clear), the average would be recomputed.

I figured this was how it already worked, but it seems there are several discrepancies I was previously unaware of.

I was talkling about the light source that moves along with the shot. Saga implements different shaders that make gun lights even more visible and there it is extremely obvious when fighters have far apart firing points. I don't know about the muzzle flashes but I guess that's probably the same.
And as stated above, especially for fighters like the X-Wing this is extremely obvious and needs to be expanded.

[Nuke]

Almost like something I'd considered for use in my own programming... basically, using the actual ship's vertices to avoid z-fighting, and picking the proper uv coords to make the texture show up in the right position. Except it sounds like you're talking about actually doing a sort of real-time bake-to-texture. If you could save on drawing passes that way without sacrificing much quality, then it seems like a good idea.

for decals its not likely that you would have to draw to the texture every frame, or on the same frame that the collisions occure. im not sure if it would be more efficient to draw stuff as a batch or each as it happens. you might want to schedule the scorch map updates, if many occur at once, over several frames.

im still toying around with rtt in scripting. while it works ok with panels and stuff of that nature, mainly because of the lower resolution used (usually less than 512, i find 256^2 adequate for panels and hud elements). there are exceptions, like if you call renderFrame() to a couple dynamic textures every frame. im sure that with the increased resolution of larger textures that performance will be impacted. the question is how much.

[portej05]

Nuke: I've noticed during profiling that textures are swapped a hell of a lot - I'm pretty sure that we could achieve a large performance boost by avoiding that, but I'm not a graphics coder so I'm not sure how to go about that.

[Nuke]

what do you mean by profiling? i know that reducing the movement of data back and fourth between the video card is a good way to kill performance. im not sure how much of the render to texture capability is handled at the gpu level, or if at all. i do know that most video hardware is capable of doing rtt quickly and effectively and has been for some time. i remember seeing video monitors in games as far back as quake 3 (and even further back if you count older games that used software, glide or d3d). im very intrested in optimizing rtt in scripting.

one thing i tried is time slicing rtt operations, things like camera linked cockpit video displays get updated less frequently, every other frame or every third frame (depending on how many of them there were), and skipping a frame when updating the radar texture. though it didnt seem to work well, and in some cases actually degraded performance. in the future i might only allow one video display and even then skip frames with it. all the real fixes i can think of are at c level, such as adding render options to renderFrame(). for example, make it so i can disable things like normal maps and specular when i call it.

anyway i intend to report a slew of scripting bugs once the new cockpit demo rolls out (mainly because it uses many features which demonstrate the bugs). most of them deal with things not working right in an rtt context, or at all. scripting is a good way to minimize feature creep in the engine, however it seems to need some optimization in some areas. some of the new features in the cockpit demo will make it possible for scripters to write scripts which can be handed to modders who have little or no scripting knowledge, and then be used to add features which are not directly part of the engine.

[chief1983]

VS Team Editions can analyze code performance in real time, and profile it, to analyze it for bottlenecks.  Things like timing what functions are eating the most cpu time, etc.

[Nuke]

i just have the express edition, so im not sure i have that feature.

the render targets system to me is just some magic thing that makes rtt work, i have no clue how it works internally, or how to script it efficiently. things like this make me wish i had a better understanding of opengl. i think it might be possible to perform render to texture with a shader run on the video card. the textures would never need to leave video memory, only procedures for drawing stuff need be passed, which usually use very small textures. stuff like hud elements for example.

[chief1983]

You don't then, not even Pro does

[Aardwolf]

But express doesn't have plugin support.

[Sushi]

Very Sleepy is a free tool for basic profiling:

http://www.codersnotes.com/sleepy/

Works pretty well. Create a DEBUG build, throw it and the .pdb file into the Freespace directory, start it up, start up Very Sleepy, attach to process, and you're set. Pretty easy & straightforward.

[Nuke]

it works, but i havent a clue hat t look for.