|
2006-04-26 21:33
|
With autotargeted asteroid.jpg (238,804 bytes) |
|
2006-04-26 21:33
|
Without autotargeted asteroid.jpg (208,523 bytes) |
|
|
I've noticed this recently as well. I've assumed that it's something with the targetting brackets (the white ones), but I haven't actually found a cause yet. Don't suppose you know about when this starting happening? |
|
|
No, I have just tested with latest builds (Redmenace's last one and later CVS own-compiled). As I have a record of previous builds (and vp 3.6.7) I will try to find a begining date for this. I've tried 3.6.7. release version and this isue was present. I think I have 3.6.5. I don't have retail FS2 anymore (I deleted original exes, and I don't want to reinstall it) so can anyone check if this happens also with the original game version? edited on: 04-27-06 01:52 edited on: 04-27-06 12:16 |
|
|
My latest tets: I've used oficial releases 3.6.5 and 3.6.7 but both with oficial vps 3.6.7. And I've switched to D3D as 3.6.5. had a bug with OGL 2.0 (saying you had 1.0 and needed 1.2 bla, bla, bla...). I have also disabled VSync. I have used the sixth mission of FSPort BUT v2.3, to use the same version with all the builds. When the mission starts I stay still and just turn arround to face asteroid field. In redmenace 20060323 (vp 3.6.8. delta) there is a drop from 60-70 to even 10 FPS. And it seems the drop increases with the number of autotargeted asteroids. With just one asteroid it drops to about 30-40, two to about 20-30. In 3.6.7. there is a also a severe FPS drop like in actual builds from 60-70 to even 10 FPS. I think the behaviour is more or less the same as actual builds. In 3.6.5. there is clearly much less FPS drop. From 60-70 it hardly drops to 30-40. It also seems to be less dependant on the number of autotargeted asteroids. I haven't got neither previous builds nor retail FS2 so I can't do more tries. I hope this info would be useful. |
|
|
As I've been playing around in similar code recently, I'll give this a stab. Edit: Nope, as far as I can tell, it's not the multitarget bracket DISPLAY that's causing the slowdown. It does happen at the same time, but that's just because there are asteroids on a collision course. I've narrowed it down to this: in asteroid.cpp, function asteroid_time_to_impact , there's a call to asteroid_test_collide . If I comment out the asteroid_test_collide, no more slowdown, and yet collisions still work, so I'm not sure what that's for. It looks like something complicated involving rotating parts, and I'm not sure if it's really necessary for asteroid collisions, or if there's a better way. (Currently it iterates through all subsystems of the ship in question, FOR EACH INCOMING ASTEROID.) I've hit my limit of understanding -- hopefully someone can take this and run with it. Attached is a rather entertaining mistake :-D [which, funny, DIDN'T cause a slowdown] edited on: 04-28-06 02:47 |
|
|
No, if I multitarget a wing there's no performace loss. But your build, (at least the first one), also suffers this issue within asteroids storms. I was using it when I noticed the bug in the sixth mission of Port v3.0.3. I do think the screenshots were taken with your build (I can't remember now). (Maybe, there is a function which is being constantly called to make the asteroids target autoupdate and this causes the performance drop ???) edited on: 04-28-06 01:35 |
|
|
This doesn't actually have anything to do with the brackets, it's the collision checking for asteroids. Or, more precisely, I guess it would be the collision-with-escort detection that is the trouble. I'm pretty sure this is an issue with the turret targetting code, though I haven't had a chance to track it down yet. I'd bet cash that it's related to asteroid_time_to_impact() somehow. That function is used to prioritize targets for turrets, and for the time display of asteroid impact on the hud. The hud impact time display also creates a drop in FPS all by itself. It probably boils down to a function that ends up just being too slow to be used for target priority (since it gets called a LOT per frame). That asteroid function itself doesn't appear to be slow, by way of profiling. But the model_collide stuff is very slow here. Finding a way to simply the collision detection for this may be needed. |
|
2006-04-28 06:48
|
|
|
|
taylor wins the cash. :-D (silly me, editing without checking replies. I should take StratComm's sig's advice.) From what you say, I'm guessing that commenting out asteroid_test_collide might be a viable solution. As far as I can tell, the asteroid that even GOT this far was already on a collision course at some point, so it's not it's a big deal if the turrets shoot at one that ends up barely missing. Plus actual collision detection doesn't use this function anyway, right? |
|
|
Nope, asteroid_test_collide() is required there for it to work properly. You can fake it with basic object location but the imprecision would be considered a bug. The way I see it there are two possible fixes: 1) (the good but not great one) Remove the asteroid_time_to_impact() call from the turret target check. This isn't a great thing since it will go from shooting at the asteroids that are the greatest threats to just targeting the ones that are closest. 2) (maybe better but needs testing) Based on profiling the model_collide slowdown is test related. It's checking sphereline and that is chewing up a ton of cycles. Changing to a bounding-box-only check demonstrates almost no slowdown so this is apparently the problem. That's not a fix though, we need to add a variable to the function so that we can do the faster test for the time-to-impact call. I like 2, but I don't have time to test it. The asteroid_test_collide() already has the bounding-box-only flag line, which is commented out, so just the var test to pick which flags to use should be all we need. This will reduce precision though, not a big deal for the target checks, but the hud time-to-impact display may suffer from it. Don't suppose you have time to test that out yourself? ;) |
|
|
1. works, but as you say. 2. ...I've got the time but not all the knowledge. I can't figure out the syntax, what to pass to fvi_ray_boundingbox. However, I tried a few things, and in asteroid_test_collide , changing mc->flags = MC_CHECK_MODEL | MC_CHECK_SPHERELINE; to mc->flags = MC_CHECK_MODEL; seems to have the desired effect. Course, this could be just going back to the basic object location thing. I don't really understand this collision stuff yet. |
|
|
If you haven't already, check out code/model/model.h for the MC_* defines. It has a description of what they do. I really don't think that just MC_CHECK_MODEL will be enough, the asteroids are tumbling and oblong, so you have to take the entire object into account when doing the collision check. It's basically the same thing as standing next to a brick wall. As long as you stand a foot or so from it you can be sure you won't collide with it as you walk around. But if the wall falls over, ya get squished. The problem with only checking the bounding box is that I don't know if it sets the hit_point var properly. Since that var is used for the distance check it needs to be pretty accurate. Unless we can figure out why the sphereline check is so slow and try to speed it up, we are going to have to sacrifice accuracy for performance. It's a fine line though, this does need to be pretty accurate in general. Just using MC_CHECK_MODEL and MC_CHECK_ONLY_BOUND_BOX should be enough for the turret targetting priority however (provided that hit_point is basically ok). It doesn't need to have an exact measurement, just a pretty good idea of where the asteroid is and when it will hit. When it will hit being the most important part of that. MC_CHECK_SPHERE should be faster than the bounding box check, but it may have too much of an accuracy problem which is why I didn't suggest it already. I guess it just needs to be tested to find out for sure. |
|
|
Yeah I see model.h, but it's pretty vague about MC_CHECK_ONLY_BOUND_BOX. I'm assuming I'm supposed to call mc_ray_boundingbox, but I can't figure out where to get the figures min, max, and pdir; sorry. You're right, sacrificing accuracy for performance is less of a problem in this case -- again, I'm pretty sure the actual collision detection is still very accurate, this is just the check-whether-it's-a-threat and/or time-to-collision. To use your illustration, the turrets are currently taking a long time to decide "hmm I'm a foot away from the vertical wall, I'm good"; we'd rather them say "OMG there's a wall a foot away!" :-) I agree about the MC_CHECK_MODEL not being enough, in theory. Still, my suggestion to do that is only my opinion from observing how it behaves when I make the change -- for some reason it works really well. I'm trying to think up a good way to test situations that would break this (or show something obviously wrong like something hitting empty space), like with a test mission or strange model for the asteroid or something. Wait! Model.h says that model_collide returns the number of polys that were hit. Maybe that's why it's taking so long, we don't need to know how many [especially on something like an Orion], just that there's a hit! Can we do that? (Or, heh, maybe this is already what you were getting at and I didn't understand.) |
|
|
This will be fixed with my commit this weekend. |
|
|
Fixered. Temporarily at least. May trade up to something even faster later if the accuracy drop is acceptable. |
- Anonymous
