feature freeze time

[chuck_starchaser]

that's what i was suggesting, if there is a second mesh that the unit has, less detailed, i could use that to generate my collider mesh. But as far as i know, we only use one mesh per model and we dont do any sort of modification to this mesh once it's loaded...meaning we dont swap between different mesh LOD's. The only sort of LOD stuff we do as far as i know is texture related and is handled by GL transparently once we give it the mipmaps.

Oh, no; we most definitely do switch between LOD's at run-time; depending on how many pixels the unit takes on the screen, at the current distance, and depending on the vegafig setting for level of detail the user chooses. (This doesn't apply to the collision mesh, of course.)
The problem is that most models don't have any LOD meshes.
Why? Because artists are laaaazy.
That's why I almost said you'll get nowhere asking them to provide another mesh for this or that; they won't listen.
But yeah, every model should have at least two LOD's. Specially space stations.
But for the ones that do have LOD's, you could use the second for collisions.

[chuck_starchaser]

By the way, you're confusing mesh LOD with texture LOD. Two different things. They happen independently of each other.
Texture LOD (trilinear filtering) happens automatically in the gpu. Mesh LOD switching is definitely cpu-based, in code.

[klauss]

@safemode: I have played VS with a TNT.

It runs, fast enough.

You have to limit texture size to 512, cubemap size to 512 (they're separate limits), and disable factionalized textures.

See that?

Disable factionalized textures. That reduces the amount of texture RAM threefold at least, since then the engine loads only the generic texture and not the faction-customized ones.

The engine has the ability to run in a TNT with decent performance. Sure, we'll need some LODs (meshes with less polygons) for a bunch of new artwork to lower CPU usage both by the collider and by vertex processing, which in crappy hardware (TNT, GMA too) is done by the CPU.

What is really needed is careful testing and tweaking of vegastrike.config options, which date back like 5 years or more.

Sure... we have to document that maintaining the engine running on such hardware isn't a priority. But given how many people use crappy hardware (I'm not referring to the TNT, I'm referring to the GMA), then I guess we could do the small effort of preparing a vegastrike.config preset that works reasonably well for them.

[klauss]

@safemode: I have played VS with a TNT.

It runs, fast enough.

You have to limit texture size to 512, cubemap size to 512 (they're separate limits), and disable factionalized textures.

See that?

Disable factionalized textures. That reduces the amount of texture RAM threefold at least, since then the engine loads only the generic texture and not the faction-customized ones.

The engine has the ability to run in a TNT with decent performance. Sure, we'll need some LODs (meshes with less polygons) for a bunch of new artwork to lower CPU usage both by the collider and by vertex processing, which in crappy hardware (TNT, GMA too) is done by the CPU.

What is really needed is careful testing and tweaking of vegastrike.config options, which date back like 5 years or more.

Sure... we have to document that maintaining the engine running on such hardware isn't a priority. But given how many people use crappy hardware (I'm not referring to the TNT, I'm referring to the GMA), then I guess we could do the small effort of preparing a vegastrike.config preset that works reasonably well for them.

[safemode]

for the vegastrike.config. can we come up with a set of option names that dont reference hardware brands/chipsets or cpu's or anything that is going to make zero sense in 5 years when people look at it and go " WTF is a voodoo3" or some such nonsense like we currently have in there .

the .config does _NOT_ need to be end_user readable. and it isn't currently anyway, it's barely developer readable. It should reference exactly what it modifies. It's up to the GUI to make that something understandable to the user.

Once all the options are finally put into the options class, i can create a verify routine that will check the vegastrike config and fill in any missing variables and report any variables in the config that dont exist in the game.

Such a feature would be extremely valuable to mods... (newcomers: we used to have more than 1 mod, so it was important that development in the engine be treated as a shared engine used by other projects other than VS, rather than just treat all of the VS code as a straight game. This is why we have some features that VS - the game - doesn't use and why we try to keep certain things we no longer use still functional. )

[chuck_starchaser]

Once all the options are finally put into the options class, i can create a verify routine that will check the vegastrike config and fill in any missing variables and report any variables in the config that dont exist in the game.

Such a feature would be extremely valuable to mods..

That would be AWSOME!

[safemode]

Once all the options are finally put into the options class, i can create a verify routine that will check the vegastrike config and fill in any missing variables and report any variables in the config that dont exist in the game.

Such a feature would be extremely valuable to mods..

That would be AWSOME!

unfortuntately, the only thing keeping me from completing that is lack of time. it's just tedius work, simple but tedius. But it'll get done soon enough. It's on my todo list after documentation ...and before squashing all warnings.

[chuck_starchaser]

As I mentioned before, I'm quite willing to relieve you of the warning squashing burden.
I was proud of having got rid of them all; but that was compiling with autotools; now
that I've switched to cmake there's gazillions of them, again, and they itch...
Just let me know.

[safemode]

you can hit the warnings if you want. I'm hoping we can all focus on warning and documentation work and if need be, little bugfixes from now until we are ready for the release.

[chuck_starchaser]

Okay, I will hit them with a 2x4. If you have any warning fixes to commit, do it before sunset EST

[safemode]

yea, i wont be at the computer for any appreciable time till saturday and sunday (daystimes) ... was gone all friday. Hoping to get some of my pet sources documented then.

I'm going to try and be documentation only until we release.

[safemode]

i was looking over the commit and only have one real issue. Typedef's in the headers. for unsigned int and the like

we already have typedef's in C / C++ for this, in sys/types.h __USE_MISC must be defined. They're considered obsolete ...but i guess you can use them if you want.

further, i'm hoping to get rid of all typdef's in headers in an effort to reduce obfuscation of their true datatype. No need to hunt down headers when in a source mucking around with some shorted datatype, just climb to the top of the file and it will be there.

Headers thus, have to be written with the real datatype, just like they have to be written with the full namespace.



The alternative is to create a single header for VS datatypes and put the typedef's all there.

[safemode]

<stdint.h> contains everything we need.

without the added macro protections and such that sys/types.h uses and the opcode data var types header warns about.

just straight typedef's.

so instead of uint, we do uint32_t

edit: inttypes.h seem to just include stdint.h, and the additional macros are used only by request, not automatically in some way. So i dont know what opcode was talking about when it says that using the bit-length specific typedef's was slower than just the regular ones when they are the same thing except more explicit (which is good here).

So since we already search for inttypes.h, we dont have to worry about what to do if it's not found in our sources.

So do we have a good reason for not using the typedef's already defined to shorten unsigned ?

[chuck_starchaser]

Okay; I'll do this as soon as I'm done with the warnings.
Lots of hard work with the warnings...
Luckily I've been testing often; I replaced three int members in techniques.h by size_t's, and the game just crashed.
Had to revert the changes and add static casts <int> to the other expression in comparisons.
Now I changed the Multitexture member of gl_options to size_t and the warnings multiplied; but the game still
runs, so I think the change is legitimate, and it's everything else that should change to size-t also.

[safemode]

careful with the changing of signed types to unsigned. You have to look at what exactly you're comparing to or assigning from. Sometimes negative ints are used as an assignment to unsigned as a way to assign the int to it's maximum value as a marker. I came across this a couple times in my warning squashes.

i would not change an int to an unsigned int unless you know for sure that the int is never going to be negative, and that we dont use negative values for it as some type of error notification. In the cases where we use a negative int to assign an unsigned int it's max value, we can get around that and it's fine to change things, but for the other two cases, you have to watch out. there's no real performance benefit to changing things to unsigned int, only a capacity benefit, and currently we dont have much that hits up against the capacity of a signed int that's already not unsigned.

edit:
what usually gets warnings is unsigned int vs size_t. now this can be done fairly safely. But another thing that's much more important to fix is conditionals involving std:: types that dont use ::size_type and dont use ::npos when appropriate.

[chuck_starchaser]

careful with the changing of signed types to unsigned. You have to look at what exactly you're comparing to or assigning from. Sometimes negative ints are used as an assignment to unsigned as a way to assign the int to it's maximum value as a marker. I came across this a couple times in my warning squashes.

i would not change an int to an unsigned int unless you know for sure that the int is never going to be negative, and that we dont use negative values for it as some type of error notification.

I'm probably dealing with such a problem right now. I've changed a few members in ani_texture.h/.cpp from int to size_t, and it compiled; but the S button for SPEC in the cockpit has now a white square around it, and station lights have visible squares. I'm trying to find where any of these variables are used with negative values and so far I can't find any; but they are passed as parameters to functions.
Damned BAD programming practices...
I may have to revert ani_texture; getting tired of struggling with this problem; and I have to do my laundry.

In the cases where we use a negative int to assign an unsigned int it's max value,

That's AWFUL.

we can get around that and it's fine to change things, but for the other two cases, you have to watch out. there's no real performance benefit to changing things to unsigned int, only a capacity benefit, and currently we dont have much that hits up against the capacity of a signed int that's already not unsigned.

edit:
what usually gets warnings is unsigned int vs size_t. now this can be done fairly safely. But another thing that's much more important to fix is conditionals involving std:: types that dont use ::size_type and dont use ::npos when appropriate.

I don't get this last part... Got an example?

[safemode]

I already squashed 99% of those gcc 4.x does not like unsigned int to size_t and such. i fixed just about all of them. You may still see a couple in the last remaining vegastrike-only sources.

vegaserver and it's dependencies and most of the dependencies to vegastrike have been fixed.

I'm about to commit some changes to remove obsolete debug calls in vsimage.cpp also, i'm including an image regarding some issue i'm not sure is a bug or intentional with llama. I'm noticing some white saturation along all the seam lines on the ship's textures that change depending on the lighting. It's very distracting from the overall look of the ship. Does this happen on your system? I'm using very high shader (probably shouldn't be) and very high detail on an Nvidia 6600

large:
http://signal-lost.homeip.net/images/ve ... tifact.png

[chuck_starchaser]

Yeah, that's an "intentional artifact", you might say.
Long story.
Previous shaders tried to guess the shininess of materials, so materials didn't look ultra-shiny by default; they looked somewhat passable, bearable, which is a Good Thing...
The Bad Thing, is that artists didn't bother producing a shininess map and putting it in the alpha channel of the specular texture. The only textures we got that have a shininess channel are those for the agricultural and diplomatic stations; --because I put them there.
And if we don't let models look weird like they should without a shininess map, I'm afraid we will never get artists to produce them.
But with regards to the llama, I will either finish the new one or fix the existing one before release.

Yeah, what's happening, in technical terms, --what you're seeing there--, is reflections of the local star. With proper shininess (low shininess), the reflections would be big, blurry and dimmer; but with high shininess they look sharp, defined, and very bright (far beyond saturation); --as if the ship was wrapped in very glossy shrink-wrap plastic.
Well, at some point one has to say "Basta!" and pull the plug; otherwise the art will forever depend on shader hacks.
Let the art be fixed, for a change.

[safemode]

k, i got no problem with that method of "commenting" artwork. was just wondering if this was a fault of mine or intentional. If it's possible, we should add a vs_dprintf (level 1) of any textures missing stuff you're expecting to be there .

then when someone comes to us with issues, our troubleshooting guide will tell them to run with --debug=1 prior to posting a bug report so we can see "hey, this that and this were missing whatever " so that's why it looks the way it does. etc etc.

edit: also, let me know when your cubemap generator is ready to be compiled so i can add it to cmake.

[chuck_starchaser]

k, i got no problem with that method of "commenting" artwork. was just wondering if this was a fault of mine or intentional. If it's possible, we should add a vs_dprintf (level 1) of any textures missing stuff you're expecting to be there .

This is an idea that has crossed my mind; but the problem is it would be rather complex. Some ships and most planets only have a diffuse texture, for example, and it's okay for now; won't be okay in the future for planets (normalmap will be required), but for now it IS okay. And some things need different sets of textures from others. Glass doesn't need a diffuse texture, for instance; nor a specular. That is to say, they use the default diffuse and specular from the /textures folder (bubble_diff and bubble_spec), but can use a local, specially baked ambient occlusion.
Well, we could issue warnings, generally, when a specular texture (or a glow texture) exist, but don't have an alpha channel. This would work:
Anything that HAS a specular texture should have shininess in its alpha channel.
Anything that HAS a glow map should have an ambient occlusion bake in its alpha channel.

then when someone comes to us with issues, our troubleshooting guide will tell them to run with --debug=1 prior to posting a bug report so we can see "hey, this that and this were missing whatever " so that's why it looks the way it does. etc etc.

Sounds good.

edit: also, let me know when your cubemap generator is ready to be compiled so i can add it to cmake.

Haven't got any work done on it this weekend; except a math problem I solved on paper while riding the bus yesterday.
Yeah, it's nowhere near ready to even begin trying to compile anything, yet.

[safemode]

I was gonna document the collider and vsimage but found that i and others already have. Forgot i did that.

Also, what gcc version are you using chuck? I'm not seeing all these warnings you seem to be getting, even now at -O2.

[chuck_starchaser]

4.4.1

Yeah, I'm somewhat surprised, myself; I was checking out the warning options page, and some of these
warnings are only produced with -Wextra. But that's good; they are good and useful warnings; like
labels not used, or enums not covered in a switch statement.
EDIT3: Or initialization lists in ctors that disagree with the order of member declarations...
I'd like to add -pedantic, eventually; and do a deeper cleaning.

EDIT:
What we need to do first, before any other clean-up, is header inclusions. Compilation takes too long,
right now; we need to drastically cut down on the headers cascade, so that other cleanup work can
proceed more speedily.

EDIT2:
First step in that inclusion endeavor is to reorder header inclusions, so that foo.cpp includes foo.h
before anything else; and system header inclusions are last; just so that we know what headers
NEED to be included by foo.h. (Headers should be self-sufficient, rather than rely on the cpp file
to include some other header first.)
This is kind of counter to the goal of reducing header header inclusion, but establishing needs to
include will save us from having to go through all headers twice, in the task of replacing header
inclusions by forward declarations, pimpl_-ing, etceteras.

[klauss]

The alternative is to create a single header for VS datatypes and put the typedef's all there.

I like that option a lot more.

[klauss]

careful with the changing of signed types to unsigned. You have to look at what exactly you're comparing to or assigning from. Sometimes negative ints are used as an assignment to unsigned as a way to assign the int to it's maximum value as a marker. I came across this a couple times in my warning squashes.

A more proper idiom for that is ~0UL.

i would not change an int to an unsigned int unless you know for sure that the int is never going to be negative, and that we dont use negative values for it as some type of error notification.

^ Pay real attention to that.

[safemode]

How long does compilation take for you? For me it's probably about 10 minutes. and my machine is years old.

edit: Most headers protect against multiple inclusions, so regardless of how often they are specified, they wouldn't affect compile time.

What you have to worry about is including headers you dont need. And you have to worry about including headers in the project that are templated when you dont need to.

Having enough ram is crucial to compiling C++ projects, as is decent disk performance.