Goombert
|
|
Posted on: May 24, 2013, 12:28:47 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Yah I think it is suffice to say I as well as many others have a few discrepancies regarding the frame rate counter. 1) The darn thing is so inncarute, it would be a better measure to use a random number seed to generate the proper count 2) Everybody who tries ENIGMA asks the same question, why does an empty game run at only 53 fps? Because its not doing anything, make it draw something. Why are 1000 objects in Studio faster? Because its not doing enough make it 100,000 objects. 3) It is horrible for when you are developing a game, take for instance when I was programming Project Mario. I knew that when I added particle effects my fps took a hit of 30fps, in ENIGMA it would probably go from 53 to 78fps because its alloted more CPU time, this is just stupid, there is no way then to accurately compare, and I for one can't work without it 4) A lot of Game Maker users I know will set_automatic_draw(false); then implement their own redrawing timer to lock draw events to 30fps and let the rest of the time go to updating, so you'd have perhaps 73 step events per second and 30 locked draw events, this is going to cause serious inconsistencies 5) Most game engines like Unity3D completely unlock the framerate and let vsynch catch, not even possible with ENIGMA, because ENIGMA may just decide your game does not need more than 53fps Unity3D Reference 1 http://answers.unity3d.com/questions/15574/fixed-frame-rate.htmlUnity3D Reference 2 http://forum.unity3d.com/threads/4607-Locking-the-framerateIf anything we need to have the option to uncap it if we want and control the CPU usage ourselves from Global Game Settings like you can in Game Maker, at least there I used to have control, but ENIGMA wants to just assume that every game runs at the same framerate, ignoring any other implications of testing and design of a game in the works.
|
|
« Last Edit: May 24, 2013, 12:32:56 am by Robert B Colton »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
Josh @ Dreamland
|
|
Reply #1 Posted on: May 24, 2013, 12:46:56 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Oh, listen to you. perhaps 73 step events per second and 30 locked draw events In an engine without threading. Physics systems do that sometimes. With threading. because ENIGMA may just decide your game does not need more than 53fps Boo-hoo; ENIGMA won't let my game run faster than 53. You're as bad as polyfuck. Neither of you two fucking understand how an operating system works, so you blame (and try to compensate for) features of the OS you don't understand in the engine. Here's what's happening: Exhibit A: User with IQ of 6 - Exhibit A wants to test ENIGMA's POOOOOWAAAAAAAAAAAAAAAAAAAAAAAH
- Exhibit A creates a new game and sets the FPS to NINE THOUSAAAAAAAAAAAAAAAAAAND
- Exhibit A presses Run
- Compile takes a really long time because Exhibit A has never built any piece of the engine before
- While Exhibit A is looking for the firefox button in his 50-page start menu, compile finishes
- The empty game begins
- The event loop begins, and then terminates immediately because, oh yeah, IT'S FUCKING EMPTYYYYYYYYYYY
- The draw loop begins. It clears the screen to gray and exits, because, oh yeah, IT'S ALSO FUCKING EMPTYYYYYYYYY
- The necessary amount of time required to sleep is calculated. This value equates to 1000 / (NINE THOUSAAAAAAAAAAAAAAAAAAND) = 0 milliseconds
- The max of that time and 1 is taken to prevent Sleep() from aborting the game and/or crashing Windows, and Sleep() is invoked.
- Since 6 microseconds have passed, the scheduler sticks the process at the end of the wait queue and forgets about it for a few thousand years
- After the few thousand years (or about 17 milliseconds, if you aren't watching as an electron) pass, the scheduler remembers, OH SHIT
- The scheduler removes your game from the waiting queue and returns context to it
- This loop continues, resulting in a framerate of 53
- Why is my game running at 53 FPS? ENIGMA IS SO CRUEL
- I'm going to kill myself, but not before crying about how bad ENIGMA is on the internet
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Goombert
|
|
Reply #2 Posted on: May 24, 2013, 12:51:50 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Least YoYoGames managed to code a stable update loop, where as you can not. Edit: After adding the IQ test 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
|
|
« Last Edit: May 24, 2013, 03:18:52 am by Robert B Colton »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
forthevin
|
|
Reply #3 Posted on: May 24, 2013, 07:13:59 am |
|
|
Joined: Jun 2012
Posts: 167
|
Robert: 1) On the systems I have tested, the fps is very accurate. That said, I only have access to very few systems, so it may well be the case that many, possibly most systems have issues with the fps. 2) That is definitely an issue. If ENIGMA is faster than GM, and yet the fps-handling makes it seem slower, that should be fixed. 3) Uncapped fps is supported internally in the currently implemented fps-handling. Implement support for setting the room_speed to 0 in your LateralGM version, and the fps should be unbounded no matter what (the sleep function is never called if the room_speed is 0 internally in neither xlib or Win32). 4) If I understand you correctly, the users that allow uncapped updating lets the game simulation depend on how many steps are taken each step, basically variable delta time. That is in general not a very good idea. See this link for more information: http://gafferongames.com/game-physics/fix-your-timestep/. 5) If I understand correctly, the uncapping is due to issues in the current fps-handling for some systems. Setting room_speed to 0 should bypass these problems, because "sleep"/"usleep" is never called when room_speed is 0. I haven't read up on how Unity does things, but I will read up on it later. Josh: I changed how fps is handled in xlib and Win32, so the system acts in a more complicated way than just sleeping a fraction of 1000/room_speed.
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #4 Posted on: May 24, 2013, 02:25:19 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
I was being dramatic, forthevin. The scheduler doesn't care how long you ask it to sleep; if you're not using the CPU when you're given it, it's going to forget about you. But Sleep() cannot take a value less than one, meaning your game, by definition, cannot use Sleep() and have a framerate higher than (or even equal to) 1000.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #6 Posted on: May 24, 2013, 02:52:43 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
That might be okay. What I'm thinking is using [snip]usleep[/snip], which apparently some holy GNU implemented in MinGW. [snip]Sleep[/snip] is not guaranteed to return, ever, but I believe [snip]usleep[/snip] is.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Goombert
|
|
Reply #7 Posted on: May 24, 2013, 03:10:23 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Forthevin:
4) No, they let step events happen at 60hz and drawing happen at 30hz or vice versa.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
|
|
Goombert
|
|
Reply #10 Posted on: May 25, 2013, 09:11:10 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
... no forthevin, people do it manually; you set_automatic_draw(false); then add a delta timer and in your step event manuall screen_redraw or event_perform the draw events, for instance 70step events a second and 30fps draw events a second. You don't get it? People do it in Game Maker to allow more time for logic instead of drawing.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
forthevin
|
|
Reply #11 Posted on: May 25, 2013, 09:36:04 am |
|
|
Joined: Jun 2012
Posts: 167
|
Robert, I can see how people can do that manually, but it seems to me that doing it manually can be problematic. For instance, if you want to have 30 updates per step, and 120 draw events per step, you could repeat the draw events 4 times each step. But if you do that and the drawing is relatively very quick, there is the risk that the draw events are not spaced out properly between updates, but instead is done in one quick batch just after the update, effectively becoming one draw event. You could then try to sleep manually, but that tend to have very low resolution and other issues. Therefore, I believe it would make sense to support it in the engine if we want that functionality.
Then again, you said that people do that manually, not that it is a good way to do things. What is your opinion on doing things that way?
|
|
|
Logged
|
|
|
|
|
Goombert
|
|
Reply #13 Posted on: May 25, 2013, 05:55:12 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
forthevin, I really don't care I don't need it, but this goes back again to the fact that physics simulations generally run at a different frequency, I just wanted you to know that some Game Maker games do it. Rarely though I should mention, you don't see it very much if at all.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
Josh @ Dreamland
|
|
Reply #14 Posted on: May 25, 2013, 08:11:12 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Make no mistake; physics engines are a great point in favor of having multiple steps for one draw event. I'm sure that Bullet demo Robert keeps posting uses a dozen steps per frame, easily. But they have absolutely nothing to do with the framerate issue. At all. Half the issue with the framerate arises from all the shit that happens when redrawing the screen. (That, and the fact that Sleep() can't sleep for less than a millisecond, thereby eliminating framerates past about 700). The other half is not actually an issue unless you have a small IQ. There was no problem with the system as it was before these "fixes" insofar as having five step events to a draw event is concerned. You just set an alarm in a control object and call screen_redraw() every five frames, with automatic draw off. Not even the vertical sync will stop you, then. The vertical sync is our first framerate "problem." It just makes sure the monitor (a 60Hz or less device) is not scanning when you go to dump your buffer to the screen. It doesn't stall your game to ensure that you only have 53 frames per second; it stalls it to ensure that you don't *draw* more than 60 times per second. So if you're not drawing, your graphics card can't stall your program. Now, the other "problem," which is even less a fucking problem, is the system scheduler. I've mentioned this like three times now. The system scheduler is the piece of the kernel responsible for deciding what programs get to run when, because as you may have forgotten, your empty game is not the only thing running on your machine. Windows is fat; it needs the CPU to bask in. And also, you probably have other programs open. Point is, if you aren't using any CPU, just sleeping periodically, the scheduler will have no inclination to give you priority over Windows Calculator, which needs that CPU time to send usage data back to Microsoft to help improve your customer experience. So basically, your program has the CPU, uses it for maybe 2K cycles between SYSCALLs, and then makes another SYSCALL to sleep. The scheduler doesn't want anything to do with you. It'll treat you just like Calculator, and call you when you next click the window or when the number of milliseconds you asked it to sleep has expired, and it's done dealing with everyone else. So basically, this huge, cruel and unusual problem ( ) is only huge, cruel and unusual ( ) because your system doesn't want to waste CPU time on a program that doesn't do anything. ( ) And users are too damn dumb ( ) to figure out, hey, maybe I should conduct my stress testing using actual stress!
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|