General fluff => Announcements => Topic started by: polygone on May 24, 2013, 03:34:31 AM

Title: Huge speed increase
Post by: polygone on May 24, 2013, 03:34:31 AM
I think this probably deserves an announcement so people know. Last night we added a condition so if the room_speed is set greater than 170 then Sleep is not called between frames (ie the fps is uncapped). When I tried this however I noticed a huge drag occurring, whereby blank games where still only running at 250fps. After a long debugging session it was found that the room caption setting was the single culprit (it was getting called liked 15 times a step and it's a rather bloated Windows function - not good). I have now removed the room caption temporarily (until it's sorted tomorrow) and after I removed it I found my fps shot up to an expected 1600fps in an uncapped blank room.

To summarize: this thing was a huge inefficiency so after you update, depending on your game, you might suddenly notice a large increase to your fps counter.
Title: Re: Huge speed increase
Post by: Goombert on May 24, 2013, 04:01:35 AM
After adding the uncapped using a process priority lower than Game Makers, I was able to churn out 8000 objects each one drawing its own cube with 2 extra triangles per cube or 16000 extra triangles at a solid 90fps...

I will rewrite this again in the morning to use a single object drawing them all as one batched model  (Y)
Title: Re: Huge speed increase
Post by: forthevin on May 24, 2013, 06:47:17 AM
I have an apology and a correction. sleep_for_framerate does not sleep in any way, it only sets the current room_speed. The bad name is my fault, and I apologize for it. While the function used to be correctly named, I changed it while working on improving the fps-handling, and I must have forgotten to change the name to reflect the new behaviour. The only reason the change you made works, is that the fps-handling system for the platform systems Win32 and xlib are configured to treat room_speed == 0 as being the same as unbounded room_speed. So, with the newest changes, if the room_speed is set to 190, the room_speed will be unbounded. This is buggy behaviour on systems where the fps above 170 worked correctly before. Before on my Windows system, when I set a room to have a room_speed of 213 or 1042, I got a fps of 213 or 1042, respectively. (Note that I have not tested this on a Linux system, primarily because my own Linux box is capped to 60 for whatever reason, but the overall method I implemented for handling fps is the same between Linux and Windows). With the current system, a room_speed of 213 results in a fps of about 1200-1800 (with most values lying around 1780-1795). I have only tested this on my Windows system; on my Linux box, I can at most get an fps of 60. I haven't tried on the same hardware with a virtual box, due to virtual boxes potentially bothering precise fps-handling.

I would also like to note that the current fps-handling system for the Win32 and xlib platform systems are designed to try to gracefully handle slow-downs as well as abrupt stops (like once in a while, a single step taking something like half a second). I designed the behaviour to be similar to that I believe GameMaker to have in this regard; according to my tests, GM also tries to gracefully handle slow-downs and abrupt stops.

Excellent find regarding the room caption; it slows my uncapped system from 1700-1800 to 500-600 when the window_set_caption is commented in. I have added an issue for it on the tracker.

In regards to process priority on Linux, it should be noted that on Linux, a lower process priority value, or niceness value, means a higher actual priority.

Robert, I would also like to request that you ensure that the room_speed can be set to zero in the new versions of LateralGM (if you haven't already done it); I don't think 1.6 of LateralGM allows a room_speed zero, while the system treats 0 as unbounded. On systems where the fps-handling works correctly, there is not really any difference between setting the room_speed to 0 or to a lot higher than the maximum effective fps; however, it seems that on systems where the fps-handling does not work correctly, there is such a difference, given that the newest updates sets the room_speed to zero when the user-set room_speed is above 170.
Title: Re: Huge speed increase
Post by: IsmAvatar on May 24, 2013, 09:35:22 AM
Room speed can be set to 0 as of f2c5c2f89adc (https://github.com/IsmAvatar/LateralGM/commit/f2c5c2f89adc). Robert has been maintaining the latest builds, so he'll probably build it for you.
Note that this behavior may lead to incompatibilities in GM.
Title: Re: Huge speed increase
Post by: polygone on May 24, 2013, 01:37:53 PM
@Ism: Yeah I'm not sure what will happen if you try to load a game in GM after you set the room speed to 0 (since GM doesn't allow the room speed to be set to 0).

@Forthevin: That whole > 170 room speed thing wasn't really thought out by Josh, I was thinking too that there might actually be some people that want the room speed at 170 properly. Maybe it could be set a little higher to be sure but what would be best to use?

I've done an interest fps comparison with GM though. Here's the file: https://www.box.com/s/00dpgpaj1wvz86s8qjqf
All it is, is a blank game with a single object drawing the fps in the room. But here are the results:

When it's run in GM alone:  GM = 800fps
When it's run in ENIGMA alone:  ENIGMA = 690fps
When both the GM and ENIGMA file are run together:  GM = 290fps, ENIGMA = 425fps

It should really be worked out why GM is running a little faster when it's run on its own.
Title: Re: Huge speed increase
Post by: Josh @ Dreamland on May 24, 2013, 03:03:16 PM
forthevin: Apparently either I was hallucinating last night or the GNU for Windows implementation includes the POSIX usleep() method. Could you refactor your code to use that? Other parts of the engine on Windows are already using it, so apparently it's not an issue.

EDIT: Also, check if that implementation contains nanosleep() in <time.h>.
Some of this shit might need to work with <features.h> to make sure it builds on everything, but frankly, I'm just sick of this mess.
Title: Re: Huge speed increase
Post by: Goombert on May 24, 2013, 03:08:57 PM
Forthevin, I have confirmed if you attempt to set it to 0 in the room editor, it will just revert. Now setting it to 0 where I was setting it to 1000 in obj_gamestate create event will uncap it and give the above results.
Title: Re: Huge speed increase
Post by: polygone on May 24, 2013, 03:26:50 PM
Ism just changed LGM to allow 0 being set.