BouncingBallsBenchmark started to last for 30 seconds. (Hit ESC to cancel.)
Benchmark ended regulary after 31 seconds.
Rendered frames: 14
Average FPS: 0.4377736085053158
Triangles in the scene: 39680
Nvidia Geforce MX 440 SE 64MB, Athlon XP 2200+, 512MB Ram
EDIT : The strange things is performance is acceptable for the first 3 seconds then decrease dramatically.
ATI Radeon 9800 Pro 128MB, AMD Athlon64 3000+, 1024MB Dual-Channel
When I wrote this benchmark, I used as many and as highly-detailed balls as possible to stay above 64 frames on my machine and to have a load as high as possible. But we can reduce number and complexity it it is better for other systems. Play around with the constants in the head of the benchmark class. Maybe we can find better values. I know this benchmark is very challenging for your machine with many balls / highly detailed balls.
Edit.
[quote="<MagicSpark.org [ BlueSky ]>,post:1,topic:28345"]
The strange things is performance is acceptable for the first 3 seconds then decrease dramatically.
[/quote]
For me it’s the other way around. For the forst few seconds the movement lacks and then it’s acceptable. ???
For me it’s the other way around. For the forst few seconds the movement lacks and then it’s acceptable. ???
[/quote]
May be due to the collision system.
[quote="<MagicSpark.org [ BlueSky ]>,post:5,topic:28345"]
May be due to the collision system.
[/quote]
I had the high total system load as a suspect. But certainly the collision system is the evildoer.
I ran the BouncingBallsBenchmark again and realized that any time several balls hit each others the whole thing lacks. So the poos fps you had are certainly due to you slow CPU, since the collision system is computed by the CPU not the GPU.
What a CPU do you have?
[quote="<MagicSpark.org [ BlueSky ]>,post:1,topic:28345"]
Nvidia Geforce MX 440 SE 64MB, Athlon XP 2200+, 512MB Ram
[/quote]
If the collision systems lag when several balls it it’s really badly implemented : if it can’t handle 5 collisions simultaneously it’s completely useless.
[quote="<MagicSpark.org [ BlueSky ]>,post:8,topic:28345"]
If the collision systems lag when several balls it it’s really badly implemented : if it can’t handle 5 collisions simultaneously it’s completely useless.
[/quote]
It is useless anyway, since it doesn’t work properly. That’s why we should definitely go the JOODE way.
May I separate it or will you do it ?
[quote="<MagicSpark.org [ BlueSky ]>,post:10,topic:28345"]
May I separate it or will you do it ?
[/quote]
Please do it. I am very busy with the rendering code 
So what do you want to do? Extract the collision system from xith-tk and put it into a new project?
Please do it. I am very busy with the rendering code
So what do you want to do? Extract the collision system from xith-tk and put it into a new project?
[/quote]
“new project” is overwhelming. Releasing a .zip/.tgz with code and build is the most I would do.
hmm, would fixing it not be better? There should IMHO be a simple and fast integrated collision detection system in xith without a dependency on JOODE. Is the xith code wrong designed or is it just buggy?
Can’t say… knowing as David Yazel work I wouldn’t say it’s badly designed but everything’s possible…
Mmyeah but I’d prefer not to make it dependant of Xith3D. Maybe we could just extract it to a separate project which doesn’t depend on Xith3D (but we would provide facilities for using it from Xith3D).
Do we include 2D AND 3D collision detection ? My 3D game need 2D collision detection.
I use it in my game without any problems (I am back dated though) At some point in the past (previously to the last couple of months) the system stopped working dur to some code change side effect.
Other than my game and the demo code, this is the only other working example of the Xith3d collision system
Could you fix the collision system if you would ?
Not sure if this applies here (as i don’t use xith or know this demo) but this reminds me of some problem that i’ve had with my own collision system (a swept ellipsoid approach): If the movement is decoupled from the frame rate, i.e. entities are moving the same way in n seconds regardless of the actual framerate, the following can happen (time is simplified to “ticks” here to make it easier to follow):
1st frame:
rendering takes 1 tick. Entities should move 10 units per tick, in this case (1 tick), ten units. This may take 1 tick also on a slower cpu.
2nd frame:
rendering takes 1 tick, plus 1 tick from the former movement/collision detection results in 2 ticks, so entities have to move 2*10 units to compensate the low frame rate. Because of the increased movement, collision detection takes longer…let’s say 2 ticks.
3rd frame:
1 tick for rendering, 2 ticks for collision detection=>3 ticks overall=>entities have to move 3*10 units=>collision detection takes now 3 ticks.
…this can go on and on…and finally, you’ll end up with seconds/frame instead of frames/sec. because the whole system will never recover from this situation.
This is, of course, a very simplified example but it describes the basic problem. I just thought it could be helpful to mention it, because the description of the problem (fast startup but cripples to incredible slowness for no obvious reason) reminds me of it. If the cpu is fast enough, this will never happen, because the collision detection happens too fast to have greater influence, but if it isn’t, well… 
nasty…
Normal Performance then a slow down also reminds me when I forgot to clear the renderbins after rendering, so the models kept doubling every single frame. Those kind of bugs are annoying…
DP
That shouldn’t happen.
@EgonOlsen : may be that, if I wanted I could track that bug down anyway thanks v’ry much for the hint.