Post by Lukan Peixe in Visions of Ethereal jam comments

GDevelop BIG Game Jam #4 » Entries » Visions of Ethereal

Viewing post in Visions of Ethereal jam comments

Lots of light being brought to the conversation with these tests.

I understand that timer, DeltaTime() and frame count must have their moments to shine. Depends on the context.

Talking about the game with music sync, I'll still try, it won't be a very high rhythmic precision game. At the moment the thing is well connected to the timers (with BPM calculation and other details), so either with frame count or TimeDelta(), in order not to have to do a big rework, I'm going to use them as a second layer of confirmation of the events. It's something I'll think about later.

"Could you clarify what "deactivate the prices" refers to?"

Haha I'm sorry! Small mistake I missed after my review with the translation tool. The correct sentence will be

"My strategy for the spikes was to select the closest one (this one I had to deactivate in a hurry [near the end of the jam], because it was generating bugs) and turn them into tiles (they were animated sprites)."

And now, about: "I was very surprised that "Distance Below" is almost identical to not culling at all. I speculate that the collision algorithm already uses a similar distance calculation to "Distance Below""

I was as surprised as you are, and I believe in the same hypothesis you raised. Anyway, this test project was awesome, and now I'll be a follower of box method supremacy! haha

In the end, each strategy works well in specific cases.

Now, after doing some testing on the project...

First, I decided to do the jump smoothing using frame count instead of timers. The result started to look nice, but I still had problems with timing, when reviewing I remembered that the jump sustain time is measured in seconds (i.e., in fact, the platformer behavior has at least one timer running with it, solve turn it off and do a manual air control by frames).

However, I was a bit apprehensive, I started to print the frame count on the screen with the jump button pressed and to reach 60, it was taking more than a second.

I improved some events using the debugger tool (very nice tool!) but nothing particularly heavy, rendering and pre-events were still the biggest performance drains, but again, nothing serious.

So I decided to print other information, including FPS (using the extension), FPS which is constantly at 37 frames, and that's when things start to get even weirder...

Not understanding what could be draining so much performance, I did something extreme, turned off all events and deleted almost all objects from the scene, leaving only the character and the ground, the result:

As if everything wasn't confusing enough, I changed the FPS cap from 60 to 0 (unlimited) and at that point, my game went to 69~76 FPS in a regular scene.

I went back to 60fps, went to a blank scene, just copied the value printing events, and the result?

* "Scene Real Time" is the scene time counter.

** "Scene Frame Time" is a count of every frame/60.

I'm going to take a break from testing now and I'll come back to it later, but I don't know if there's anything else to be done. As soon as I had the first case of slowness a few days ago, I cleaned all Windows background processes leaving only the OS excencials and it didn't solve it. Detail, other games run here normally, even some 3D ones that require more GPU.

The mystery continues...

Thanks for another great reply :)

Like Reply

Clark Padmore1 year ago(+1)

.....

What is your monitor's refresh rate?

For reference: Web browsers use V-Sync by default. Electron, the JavaScript interpreter that GDevelop uses to make desktop builds (and, by extension, previews), uses V-Sync by default, because it is built on the same principles as a web browser. Basically, GDevelop games have V-Sync by default and necessity. I have my own opinions on this fact, but it is was it is.

This is also why it's hard to use FPS to determine performance.

Like Reply

Lukan Peixe1 year ago(+1)

I have 3 monitors, two are 1080p 60hz and the biggest one is 1440p 75hz.

Come had a report, this performance issue for me started suddenly in the same Windows session and never came back.

I've tried changing some properties like minimum FPS, rendering type/filter for the pixels and other minor things, and nothing delivers the expected FPS.

Like Reply

Clark Padmore1 year ago(+1)

Just to be clear, is it running at the same speed on the 60hz monitor as on the 75hz monitor?

Like Reply

Lukan Peixe1 year ago (2 edits) (+1)

Yes, the game runs at the same resolution regardless of where I place the window or start running the application, however, I decided to go deeper with your new message, and I disabled all the videos and ran the game again. Result: both 60hz monitors ran the application at 60 frames, the 75hz monitor ran at 37.5 frames.

I forced monitor 75 to 60, and again, framerate was stable. In the same case, I let the game run at unlimited maximum frame rate, but again, stable at 60fps. In that case is it the counter that doesn't work or the game really doesn't pass 60fps?

EDIT: Additionally, with the 3 monitors active, game in 60fps max, I left monitor 1 at 50hz (1080p, not the main one, just port 1). I ran the game from monitor 2 (1440p, 60hz, main) and the game ran at 50fps. In this case another monitor influenced the total frame count.

This story becomes more intriguing though, at least my case of lag was "resolved". Perhaps a background update from Nvidia was what started the problem over here? (even at 75hz the game ran normally before)

This also doesn't solve your lag case and other people's, but I certainly already have a point to keep an eye on and question about.

I wasn't prepared to think so far out of the box, maybe the next step would be to use a multimeter to measure the alternating current of the residential electrical network? haha

Like Reply

Clark Padmore1 year ago (2 edits) (+1)

I should probably elaborate on my earlier point about VSync.

A lot of software uses VSync, or "Vertical Sync." It tries to prevent "screen tearing," a phenomenon where frames rendering out-of-sync with the monitor's refresh rate results in the halves of two frames rendering at the same time. It does so by limiting the software's ability to process frames to either the refresh rate, or a half divisor of the refresh rate.

For example, in software with VSync, if a monitor has a refresh rate of 60hz, it will always output either 60hz, 30hz, 15hz, etc.. Even if the software could output 72fps or 120fps, it will only process, at most, 60fps. Or, if a monitor has a refresh rate of 75hz, it will always output either 75hz, 37.5hz, etc..

Basically all web browsers, by default, use VSync. Electron, the JavaScript parser that enables GDevelop to output desktop files and previews, is based on Chromium, which is essentially a web browser, so it, too, uses VSync. I'm not sure at present if it is possible to change this, but this results in the strange behavior.

[EDIT: Just saw your 50fps edit, added it to table]

Max FPS	Monitor Refresh Rate	Final FPS
60	60	60
60	75	(75 / 2 ) == 37.5
Unlimited	60	60
Unlimited	75	75
60	50	50

The reason it cuts in half into 37.5fps at a refresh rate of 75hz is because, as the Max FPS is 60, it's going down to the nearest half.

While it might seem quite stupid (and I'm not convinced that it isn't) this is also part of the reality of building HTML5 applications for web browsers, where the standard 60hz monitor is essentially king. Even if you did change the behavior of Electron to make it not use VSync, people's web browsers are going to use VSync, and most people have 60hz monitors.

I hope this doesn't sound patronizing, it's a very complex topic.

Like Reply

Lukan Peixe1 year ago(+1)

I knew superficially the concept of V-sync, but I didn't know that it only worked with fractions (/2). It makes sense when you think about the concept, which makes me understand the benefit and complexity of Free/G-Sync.

In the medium term, the way this game behaves on the Web won't matter so much, since the final version will have to compile an executable to be able to put it on Steam.

However, if I manage to get a publisher for the consoles, a port of the game would probably be done with a Unity browser running the HTML version of the game.

Anyway, maybe the V-sync is still in the executable. Would working with max frame 0 (unlimited) be a bad practice?

The monitor you used to test the game here at itch, is it 60hz?

Like Reply

Clark Padmore1 year ago(+1)

"The monitor you used to test the game here at itch, is it 60hz?"

Yes, my monitor is 60hz. As far as I am able to tell, 60hz is the general industry standard for computer monitors. While many high-end gaming hobbyists have a fondness for the fidelity of 75hz, 120hz, and 144hz monitors, the vast majority of software users and game players use monitors or TVs with a refresh rate of 60hz, which has been the NTSC industry standard for decades.

For context: the 60hz standard existed before video games or home computers; it was originally the American standard for AC (alternating current) electric grid frequency. CRT monitors used this as their refresh rate because it was easy to synchronize.

"Anyway, maybe the V-sync is still in the executable. Would working with max frame 0 (unlimited) be a bad practice?"

If the game's coding is going to be mostly or entirely Frame-based, it is probably a bad practice to export with an unlimited max frame rate. If the game's coding is going to be mostly or entirely Time-based, it will matter a lot less.

With Frame-based coding, non-standard refresh rate users are always going to experience problems until they set their monitors to 60hz, but I personally think limiting the frame rate is the correct course of action in this scenario. If the frame rate is unlimited, this can result in insanely high speeds (a game designed for 60fps running at 144fps, for example). If the frame rate is limited, this will result in slowdown, with one exception: 120hz monitors will experience a perfect 60fps. While this is probably a matter of preference, I think a bit of slowdown is preferable to a theoretically large speed-up.

There are no great solutions to this problem. I think a lot of this comes from mismanaged hype on the part of manufacturers of high-end computer monitors. Additionally, this is mostly a result of GDevelop's "Web-First" design philosophy, and while I would personally like it if there was native support for disabling VSync in desktop distributions, I do not currently expect them to devote resources to that, especially while they're still developing the experimental 3D engine.

Like Reply

Lukan Peixe1 year ago(+1)

I did see somewhere that the 60hz limitation was because of NTSC and powerline frequency (hence why I made that bad multimeter joke earlier). I personally like higher frequencies, but it's not my main concern.

I'll decide exactly what I'm going to do, but I'm going to avoid frame-based programming, to minimize these complications. However, I will continue with tests at 60fps to be closer to the experience most players have.

I'm going to have to come back to the topic of performance at some point, to avoid what happened in your experiment happening, the box method is something I'll be resorting to for sure.

Thanks again for this great conversation, it was a good learning experience! If I manage to finish this project as I want, your name will be in the thanks in the credits and I will give you a game key :)

If at some point you are launching a commercial game, talk to me too, depending on the situation, I can help a little with the promotion.

Like Reply

Clark Padmore1 year ago(+1)

Thank you for your time. This was an insightful conversation.

Like Reply

itch.io

Viewing post in Visions of Ethereal jam comments