[IPAndrews]

Is there a flag to make the currently targetted ship view on the HUD show wireframe or solid wireframe ships? The brightly lit non-shaded game models it normally shows look very ugly.

[Starman01]

AFAIK there is a button were you can switch the target view to wireframe (ALT-SHIFT-Q). You can set the button in option/controls/misc.

Try it out, maybe it's exactly what you would like to have.

[IPAndrews]

Almost perfect. The only issue is that when I change to that mode the model goes really small. There's always something...

[Starman01]

You said it

Well, if you are going to use this all the time, then you can set the new zoomfaktor in the ships.tbl, but there will be always players who will like the other mode more, so you are screwed.
But maybe there is just a minor code-change required  *looks towards goober5000*

[StratComm]

Can't do that, it breaks the techroom if you do.  It should probably be fixed, not compensated for.

That said, has that feature always been there?  If so, I wonder how it's getting the wireframe, as the method may be quite slow on higher-poly models.  And if so, has the scaling always been an issue?

[Starman01]

I'm not really sure how long it's in there, but I remember Kazan pointing me toward it, when we get our first autopilot-version from him, which is nearly 10 months back.

I wasn't aware, that the target-view zoom is the same as in the techroom (good to know ). Then the wireframe-distance is a problem, and should be fixed in the code. Maybe you should mantis that IP_Andrews ?

[WMCoolmon]

No, it should be easy to do without breaking the techroom. The targetting view actually uses its own zoom value.

[IPAndrews]

Ok so the techroom uses closeup_pos and the targetting view uses closeup_zoom? That's all fine and dandy but the output from the standard targetting view mode and the wireframe mode ends up scaled differently. So if I set up the zoom values for one mode I break the other.

[WMCoolmon]

Yeah, I looked at the relevant code tonight and I'm not sure what's going on. The problem doesn't seem to occur in the lab, which uses basically the same method.

[IPAndrews]

If you or one of the SCP team could make the two modes scale the same that would be great for TBP. I'd like to turn wireframe mode on by default.

[taylor]

Never did update here, but this is fixed.  At least in part.

I need to fiddle with the numbers a little but it's not working properly in non-standard resolutions and the wireframe mode is working as it should.  Outline mode still isn't though but I don't really have time to figure out why right now.  I'm going through and making adjustments to the non-standard res HUD stuff just to fix a couple of stupid things that aren't needed now with my previous non-standard res update.  I'll get the code in CVS by Saturday and then perhpas WMCoolmon can work on the outline mode for everyone.

[IPAndrews]

Many thanks.

[taylor]

Ok, code is now in CVS.  It's part of a larger non-standard resolution fixing patch, which should fix any remaining problems and address several small speed issues too.

Just to document where I left off, since I'm not going to be around much, wireframe works (but has problems) however outline mode does not.  The problems with wireframe and outline modes are linked so I'll give the basic problem here in case someone else wants to fix it.  Basically, outline doesn't work because the HTL rendering code doesn't allow it.  Not sure why that was left out but it's a problem which needs to be reworked in order for outline mode to function.

Right now wireframe only works though non-HTL code because of the previously mentioned problem.  Because of this it sucks at rendering hi-poly models in an efficient way.  In other words, it's friggin slow.  REALLY slow.  I started rewriting the code in question this weekend but it will require much more work than I have time to give.

So if WMC or someone else can modify the HTL rendering to handle outline and no-poly drawing then it should fix slowdowns.  It will require changes to modelinterp in order to skip the stupid and inflexible stuff it does now as well as changes to both APIs to do with rendering without having to deal with textures.  If needed I'll do the OGL side if the basic modelinterp changes can be made by someone else.  After the code has been modified to not try and render textures on lines then we can switch back to the gr_set_fill_mode() method of model line drawing.

[Bobboau]

I realy hate to see people slave away on cod I've already obsoleeted.

[Goober5000]

...

Some people can't use HTL, so it's nice to support non-HTL as long as we can.

[taylor]

Originally posted by Bobboau
I realy hate to see people slave away on cod I've already obsoleeted.

I only slaved on the HTL code, cause it's crap.  The non-HTL code is the only thing that works.  You never fixed the HTL side of things, it's slower when drawing the jumpnode and it doesn't render lines but basic outlines where the textures are still rendered.  That's just a cheezy hack, not a fix.  It's only a very small part of a real fix for the problem.  The basic HTL rendering needs to be modified to do it right.  The poly_fill thing will only be useful when that happens which is why I disabled it, last year.

Assuming that it gets done right then it will work, but for now it doesn't unless you go the non-HTL route.  HTL is the better option but then it's not actually an option at the moment since the code doesn't work.

[Bobboau]

you misunderstand, I have fixed it right, localy, and totaly replaced most of the crappy HTL code.

[taylor]

Originally posted by Bobboau
you misunderstand, I have fixed it right, localy, and totaly replaced most of the crappy HTL code.

Yeah, would have been nice to know that ahead of time.

I only spent about 20 minutes on that part though so no big deal.  Most of what I did for this was just to hudtargetbox since it was hacked up a little too much in the past.  A lot more was going on there than needed to be.  Just a few long standing bugs which were long overdue for a fixin'.

[Bobboau]

but it's all part of that materials system thing. you can define all charicteristics of how something gets drawn, includeing conditional situations like the material getting drawen while in the target box and there being a comand line option (or whatever) set. the whole way HTL was setup was an abstraction inversion, and I've corrected this. all these minor graphical bugs will get slaughtered.

now might be a good time to mention a reorganisation I made, I merged a bunch of seperate API functions into one, it makes things a lot more expandable, as altering the one function is a hell of a lot easier than writeing a whole new one (and altering the seven files involved, and rebuilding EVERYTHING). I have reorganised stuff so that there are principaly two major API functions that handle state changeing. one function handles everything that has to do with global poly rendering (alpha blending, fill mode, lighting, zbuffer settings, anything that can be thought of as a state and a value) and a seperate function that defines a step in the texture cascade (color arguments, opperations, and outputs for both color and alpha, as well as texture wrapping on a step) this one sort of does everything in one call, because I didn't want to leave things to chance (and it all gets chaced by the stateblock code).
so basicly stuff like gr_zbuffer_set, gr_set_cull, gr_zbias, gets handled by gr_set_render_state, with values like Z_READ (glDepthFunc), Z_WRITE (glDepthMask), from what I've seen this won't be much of a chalenge for me to simply move the stuff, for the most part, though there might be one or two sticking points (looks like GL alpha blending won't fit into this, as it does source and destination at the same time) so I haven't removed any of the older functions, but the abstraction was built mainly for glide so changeing the way a few functions work seems like a good idea (alpha blending for example, rather than just haveing a hand full of modes we should have full access to source blend, dest blend, alpha opp, and alpha test, D3D and OGL both opperate more or less the same way, just have slightly diferent ways of calling it)