Further refinements made to update.c script. Overall use of variables reduced and some variant retrieval moved out of nested secondary loops. A bit of general cleaning done as well.
Probably just micro optimization, but update.c’s two hundred per second execution frequency makes any trimming worth while.
You do realize that the 200 updates per second limit only applies to Windows, Mac OS X, and Darwin, right? Consoles have no such limit; the Wii can even go over 400 fps.
Of course, that just makes optimization even more important.
I’m fully aware of that, but if I’m not mistaken, OpenBOR is specifically regulated to 200fps for timing consistency. I’d need to take another look at the update loops to be sure, but it really doesn’t matter anyway. First, consoles barley have enough power to run a reasonably ambitious module at 60fps, much less the full 200fps or above. Second, I don’t support consoles anyway. I couldn’t care less if they run at 2fps or 200,000fps.
Look in sdl/video.c. The framerate limiter is in that file, and all of its code is very clearly enclosed in an “#ifdef WIN || LINUX” directive. Also, the 200fps limit might be changed to something else in the future.
The Wii has enough power to run every module I’ve tried at a framerate of between 100 and 1000 fps. And that last number is not a typo. It’s one thousand updates every second. Ambitious, script-heavy mods like this one run between 100 and 200 fps at present, but that number will most likely go far past 200 when the script engine is optimized more.
That said, I doubt your code has a dependency on a 200fps frame rate anyway. 🙂