Small question
Blitz3D Forums/Blitz3D Programming/Small question
| ||
| I'm running my FPS code with the tweening from the Castle demo. Everything seem fine so far ... but I have a problem when the fps drops to less than 25-20fps, it happens that the inputs take a small delay untill you see the result on the screen, for example if I press the up arrow there is a small delay untill you actually see the camera going forward. It is not a big problem but it's certainly annoying because you can feel the delay, and the same happens with the mouse movement for turning the camera, you move the mouse and a few millisecs later the camera start to ... Now, my question is if you think this is just because of the low framerate or you think I should check for something wrong in the code ... Thanks Paolo. |
| ||
| It could be some sort of camera smoothing... I have to run the demo though to see if the same thing happens to me. -RZ |
| ||
| It must be a problem with the code. I have implemented the tweening thing in a lot of games and all working perfectly. It the game drops to 10fps the screen goes at 10fps, but the physics keep the rate. Post it for us to check! |
| ||
| This sounds like Mark's tweening code playing 'catch-up'. As if some activity has taken a little too long, and the tweening code tries to smooth, in particilar, things like animation steps in a running mesh animation. If you've taken the tweening code out of Castle and are building your code own around it then start looking for time-consuming code segments. |
| ||
| I was reading the help on Renderworld() in the Blitz3D docs just a second ago... look there. -RZ |
| ||
| Thanks for the help, I think Blackledge might be right, will check it out ... |
| ||
| Don't forget that you can get this effect if you don't precache sizeable levels - be aware that one of the time-consuming code segments might be something you're NOT doing rather than something you ARE. [Dizzy] |
| ||
| @Sledge, I don't understand nothing of what you said ... what you mean about ""don't do something you should do before not doing whatever you did behind""...? :-) Anyway, I think I found the problem or at least it is gone in my PC, Old flip buffers code was: vwait:flip false New flip buffers code and working good till now: vwait:flip Any comments about this ??? Paolo. |
| ||
| what you mean The common sense thing to do if you've got sluggish code is to look for superfluous stuff to take out - but often it's the other way around and your code's whacked because you haven't taken the time to prepare things fully. Precaching fits into this category - you fly your camera around the level before letting your player loose and, VRAM willing, there won't be any pauses as things are fetched during play. You used to see the awful effect of not precaching on PC FPS games when you selected a weapon for the first time - quite a few of them would stutter and jump as the computer went "Cripes - I've got to display the Humung-O-Matic 5000 and I've just realised I've no idea what it looks like! Er, hang on while I check..." But that's not the problem in your case evidently, so just file it neatly at the back of your mind. |
   |