Decals for features please
Moderator: Moderators
Decals for features please
Decals for features please
Heck, if we could call the COB Interpreter and at least look for a script (and execute if found) when loading models... We could do some amazing stuff, with the new particle FX code... everything from fairly convincing water to missiles that finally didn't need the default (slow) smoketrails to flamethrowers that acted in a physically accurate fashion, to persistant weapons, to weapons that had timers, to Gaia objects that could be helpful/hurtful to players, to...
Basically, the problem here is that Features and the models for weapons never are treated as Units. Which is lame. Every object that operates in the gameworld should be treated as a Unit. If it doesn't have a script, then it should fail gracefully, and execute the equivalent of a blank Create().
Having looked through Unit.cpp, I see no real reason why this can't be done. Features and weapons are treated as seperate objects within the loop, but they don't have to be- they could be merged, saving us a whole lot of bother. I am not claiming I'm good enough to do so- the big issue, as Jelmer has pointed many times, is the code that's not well-abstracted. I may want to look at this in detail, if I ever have free time, and see what can be done- I think it's really lame that the S3O and 3DO code are still highly interlinked in the current Spring, and that so much of the 3DO code is interlinked in borked ways with other parts of the main game loop. I strongly suspect that this stuff is why S3O has never been as fast or efficient as it should be.
Basically, the problem here is that Features and the models for weapons never are treated as Units. Which is lame. Every object that operates in the gameworld should be treated as a Unit. If it doesn't have a script, then it should fail gracefully, and execute the equivalent of a blank Create().
Having looked through Unit.cpp, I see no real reason why this can't be done. Features and weapons are treated as seperate objects within the loop, but they don't have to be- they could be merged, saving us a whole lot of bother. I am not claiming I'm good enough to do so- the big issue, as Jelmer has pointed many times, is the code that's not well-abstracted. I may want to look at this in detail, if I ever have free time, and see what can be done- I think it's really lame that the S3O and 3DO code are still highly interlinked in the current Spring, and that so much of the 3DO code is interlinked in borked ways with other parts of the main game loop. I strongly suspect that this stuff is why S3O has never been as fast or efficient as it should be.
The reason would be performance:
I'm afraid it could hurt the perfomance too much, if something as simple as a rock was treated like a unit, with script, sound,decal, particle emitter, multi-piece model, etc...
It has been said that what hurt the perfomance the most was the "sim time", and I'm not sure maps will win from moving from having hundreds of static tree to having half of dozen animated tree and not anymore or it'd go in slideshow mode.
By having simplified feature, we can have more of them per map.
I'm afraid it could hurt the perfomance too much, if something as simple as a rock was treated like a unit, with script, sound,decal, particle emitter, multi-piece model, etc...
It has been said that what hurt the perfomance the most was the "sim time", and I'm not sure maps will win from moving from having hundreds of static tree to having half of dozen animated tree and not anymore or it'd go in slideshow mode.
By having simplified feature, we can have more of them per map.
Common trees no, but a huge tree could move it's branches according to wind strength/direction... or beat all those unlucky bastards up which come in it's vicinity. :P
You'd only have one or two on your map then anyway so it doesn't matter but I agree that'd it be a lot of useless load if every feature got it's own script and so on.
You'd only have one or two on your map then anyway so it doesn't matter but I agree that'd it be a lot of useless load if every feature got it's own script and so on.
But, if Features weren't a whole separate process, used the same code loop standard Units do, and obeyed LOS they wouldn't cause so much lag. Half the reason they cause so much lag, I strongly suspect, is because they are being drawn 100% of the time. The other half, I suspect, is because they just aren't optimized like the Unit code is, being a relatively minor feature of Spring. And a script that reads:
Create()
{
}
Will terminate after running ONCE. At game start. So, it wouldn't hurt one bit to do this. Really. If you have 10,000 Features, all with scripts that dynamically reshape them according to the Wind direction... that's another story. But with typical non-moving Features, making them just another case of Unit would actually increase Spring's speed rather significantly.
The only tricky bit, in fact (because, frankly, making Features Units would probably not be incredibly hard) is that Units would now have to have a FBI tag that forced them to be drawn at X range from other Units, so that we could have things like Lathan's giant trees be visible 100% of the time. But think about Lathan's Black Swamp without massive overdraw issues- it would probably run at a decent framerate even on relatively weak machines, if most of the Features didn't draw most of the time...
Create()
{
}
Will terminate after running ONCE. At game start. So, it wouldn't hurt one bit to do this. Really. If you have 10,000 Features, all with scripts that dynamically reshape them according to the Wind direction... that's another story. But with typical non-moving Features, making them just another case of Unit would actually increase Spring's speed rather significantly.
The only tricky bit, in fact (because, frankly, making Features Units would probably not be incredibly hard) is that Units would now have to have a FBI tag that forced them to be drawn at X range from other Units, so that we could have things like Lathan's giant trees be visible 100% of the time. But think about Lathan's Black Swamp without massive overdraw issues- it would probably run at a decent framerate even on relatively weak machines, if most of the Features didn't draw most of the time...
Actually, features do get culled after they're a certain distance away from the camera.
This was a problem for agorm as the trees on his tree map would disappear and he could never get it to look filled up to look like a forest.
There was also a map with a big suspension bridge feature and the bridge would appear and reappear randomly based on the camera position.
So I believe it was in v0.7 that I submitted a patch adding a tag that forces a feature to always be drawn.
This was a problem for agorm as the trees on his tree map would disappear and he could never get it to look filled up to look like a forest.
There was also a map with a big suspension bridge feature and the bridge would appear and reappear randomly based on the camera position.
So I believe it was in v0.7 that I submitted a patch adding a tag that forces a feature to always be drawn.