Next topic

[polygone]

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.

[forthevin]

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.

[IsmAvatar]

Room speed can be set to 0 as of 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.

[polygone]

@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.

[Josh @ Dreamland]

forthevin: Apparently either I was hallucinating last night or the GNU for Windows implementation includes the POSIX [snip]usleep()[/snip] 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 [snip]nanosleep()[/snip] in [snip]<time.h>[/snip].
Some of this shit might need to work with [snip]<features.h>[/snip] to make sure it builds on everything, but frankly, I'm just sick of this mess.

[Goombert]

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.

[polygone]

Ism just changed LGM to allow 0 being set.