Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Dragon on August 10, 2012, 06:37:24 am
-
This is a small request about a minor annoyance, but I hope it's doable without rewriting half of the engine.
Basically, I'd like a way to disable the archaic explosion LOD system, which assumes there are four LODs for each weapon impact or piercing explosion. Nobody uses effect LODs since mipmaps were introduced, so this means making a weapon_expl table with the list of all explosion effects just to make the debug shut up. Otherwise, this table is completely useless.
I'm not sure if removing the warnings and making FSO determine the amount of LODs by itself is an option, but I have a feeling that considering only retail uses this feature and it's no longer of any use for it's intended purpose, removing the explosion LOD system altogether might not do that much harm.
-
Eh don't remove the system, it's still useful for say, anyone still using *.ani effects.
But yes it should default to a single LOD...not four, that'sdumb.
-
Eh don't remove the system, it's still useful for say, anyone still using *.ani effects.
When was the last time you've seen an .ani effect that would require LODing? As I said, the system became useless for it's intended purpose due to advancements in technology. Also, I'm not sure if four anis with decreasing resolutions wouldn't actually be less efficient than one big ani, because they'd take more memory.
You could, in theory, think off one or two uses for this system, but as of now, they haven't been used. While parsing of the weapon_expl.tbl could be retained, I doubt it'd be used in the future. All new effect anims are made in .eff format and the most popular .ani ones (or in fact, all that I've ever seen) have resolutions that aren't likely to cause performance issues (not to mention I haven't seen a LODed .ani effect outside retail and INFR1).
-
Sounds like you aren't considering how this might affect retail assets. I don't know the issues behind this stuff, but it sounds like you are asking for the removal of some that might be required for retail.
-
Yeah, don't break retail.
Bu changing the default should be fine >.>
-
Sounds like you aren't considering how this might affect retail assets. I don't know the issues behind this stuff, but it sounds like you are asking for the removal of some that might be required for retail.
It's used in retail, but no longer required. I checked. Effect LODs are essentially mipmaps, just much less efficient. Stuff that uses them in retail doesn't go above 256^2. I've seen a computer that could have some trouble with them about two months ago, and it was on an exhibition in CERN. So, unless you're using a museum piece (in which case FSO wouldn't run anyway), this is not an issue.
Of course, if unexpected issues do turn up, changing the default would work too. If it's easier than getting rid of the system and removing it doesn't provide any performance benefits, then it'll work just as well for the end user.
-
If it's used in retail then it can't be removed, plain and simple, in my understanding.
-
If HUD.tbl is any indication, not really. It also was used in retail, in a similar way (though it was even more useless, considering it was a list of shield icons with no additional purpose). It's been deprecated long before I came to HLP.
-
Leaving the functionality is fine.
Just change the default so that it won't throw errors if you don't bother to use it, and then retail compatibility is preserved, as with all functionality. There's not need to forcibly kill something if it's not entirely redundant.
You might not want to use it, but what if someone has a use for effect LODs?
Leave it be because it works fine, and it isn't a stupid limitation like the HUD tbl which did nothing but limit the number of shield icons.
Changing the default will allow people to just define an effect and not have to edit the -wxp.tbm or whatever, while leaving the option of having effect LODs if so desired for whatever reason. Goddammit Dragon, why would you limit options that may one day prove useful?
-
As I said.
If it's easier than getting rid of the system and removing it doesn't provide any performance benefits, then it'll work just as well for the end user.
We can go with just changing the default, as long as it's easier than just removing the system. As far as I've seen in other areas of the code (I don't remember this one being ever touched), this might or might not be the case.