Hello!
I did a little benchmarking today (patch attached) and there are some strange behaviours.
In a patch without renderer, just with a mainloop and a Timing node, vvvv seems to run always with a little more then half the fps entered in the mainloop. So with 120 fps, I’m getting max 64 fps. And it doesn’t seem to get any higher than that. With a 240fps Mainloop, I’m only getting 66fps tops.
When adding a renderer (just the renderer, nothing to draw is attached) my framerate drops to 40 fps, even if the mainloop is at 120 fps.
When I add a perf meter, the framerate jumps to 56-59 fps.
In the renderer I have to switch to Presentation Interval ‘immediatly’ to get more than 60 fps.
The computer I’m working on is a Athlon 64 4200+ with 2GB RAM and a NVidia 7600GTX so there should be enough performance…
one additional bug is the current frame output of the mainloop which is supposed to increment from 0 after each start - but only seem to produce wrong values on most computers (wrong around a factor of one million) and grossly wrong (wildly overflowing integers) on other computers
i think i can fix that current frame thing in some minutes, i already found it as i was working on the time filter… the 64fps with empty patch thing looks more advanced, but i will check that too.
hi there!
it could be a dualcore issue. but we have seen the testpatch run with 180fps on a dualcore laptop. the crazy thing is, that on the same laptop, the testpatch reaches now only 65fps. really crazy…
and why shouldn’t an empty patch run with only 60 frames? i can play quake3 with 120fps on my laptop, but not an empty vvvv patch!
as ampop said, it seems not to be only on dual core cpu machines… we should try to track this down. open ampops patch from above and report your machine config and the fps like:
–
fps renderer: 60
fps no renderer: ~90
cpu: pentium 4 mobile 2,0 Ghz
gpu: Ati Radeon 9000 Mobility
driver: Radeon Omega 3.8.252
dx: 9.0c (4.09.0000.0904)
trying this hotfix would be very interesting, as there seeem to be some problems in windows. can anybody see any relations between power/sleep mode events and the above timing problems?
@tonfilm: do you think GClock deals safely with negative deltas?
on the other side its good to see, that vvvv already follows very much the ms recommendations given in the Game Timing and Multicore Processors article.
ok, i’ve just updated the Clock.pas. the time delta is clamped now, according to their recommendation. min is 0 and max is one frame per hour. i fixed the current frame output aswell and the time filter reset condition should be better now, that should reduce the funny speed changes.
