Measurement of RenderWorld Time
Blitz3D Forums/Blitz3D Programming/Measurement of RenderWorld Time
| ||
| I am calculating the time of the RenderWorld. time1 = Millisecs() RenderWorld time2 = Millisecs() - time1 Then i am making tests loading lot of models with different textures to see the speed results. But some times, when loading lot of models, the render time keeps a value of 2-3 ms (same as when all goes good) but the rotation and movement of the camera is really slow. What more should I take into account when measuring the time of calculations? What is taking so much time?. My While is: While (Not KeyHit(1)) If (KeyDown(200)) MoveEntity camera,0,0,1 If (KeyDown(208)) MoveEntity camera,0,0,-1 If (KeyDown(203)) MoveEntity camera,-1,0,0 If (KeyDown(205)) MoveEntity camera,2,0,0 time1 = MilliSecs() RenderWorld time2 = MilliSecs() - time1 Text 0,0,"TR = " + TrisRendered() Text 0,20,"MS = " + time2 Flip Wend EDITED: This happens when i am really close the objects with the camera. Beeing far the trisrendered and the ms of renderworld calculation is the same, but speed is good! i can't understand... |
| ||
| Well, when you are really close to object, they take up more of the screen. It's all down to the graphics card. Some don't handle sprites/textures being close to them, because they have crappy fill rates. |
| ||
| But it is very strange. Is like if having lot of objects together (all at the same position) is bad... although perhaps is what you say... no words... |
| ||
| What Ross said... the smaller area card has to draw the faster the FPS is, obviously. You can test this using static camera very close to object(s) and then camera (otherwise identical setup) so far that object(s) are just a dot in the middle. Speed difference will be huge, and it's not because of object(s) position or distance, but because they take less screen space and are faster to draw (less pixels to draw). |
| ||
| Duh. Doublepost... first for me. |
| ||
| I would use 'Flip False' in all FPS calculations, otherwise your program is 'waiting' to synchronise with the monitor refresh rate. Perhaps your test with camera close was just slightly slower and was just missing a screen refrsh? Try putting timer (or second timer) around the whole loop? Rhy :) |
   |