Effects of draw_disable_drawevent() in Windows vs Mac/Linux

[obscene]

My game runs at 60 fps, but I allow frameskipping to allow less powerful machines to run it at 30 by disabling the draw event every other frame.

switch(frame_skip)
    {
    case 60: // No frameskipping
    draw_enable_drawevent(true);
    break;
      
    case 30: // Skip every other frame
    frame = 1 - frame;
    draw_enable_drawevent(frame);
    break;       
  
    case -1: // Auto on/off
    if (delta_time > 16667)
        {
        frame = 1 - frame;
        draw_enable_drawevent(frame);
        }
    else
        {
        frame=1;
        draw_enable_drawevent(true);
        }
    break;
    }

On PC, this works perfectly because GM allows the last drawn frame to remain on the screen during the previous step. See video...

The results on Linux are much different. When the draw event is disabled, it appears that the PREVIOUS frame is somehow drawn. See video...

Mac does something worse...

Not really sure if this is a bug I should file, or if this is expected behavior and perhaps there is a way I can work around this. Suggestions?

 

[Zep--]

Why wouldn't you just set a toggle to game speed at 60 or 30 instead of all that code for frame skipping?

 

[obscene]

That would slow the game to half speed... totally different thing.

 

[Mert]

That would slow the game to half speed... totally different thing.

Hello delta_time

Oh edit : you're partially right.

 

[Zep--]

That would slow the game to half speed... totally different thing.

Ahh, gotcha..but tweaking objects speeds * 2 and whatnot could compensate for that I think.

 

[Zep--]

After watching the windows video a few times...It doesn't look like you are frame-skipping at all when you change to 30.

Everything ELSE besides the screen blit would continue to operate, and the movement wouldn't be smooth as it is at 60 and also 30, as you blit every other "frame".

At 30 it would cause the player to move doubly every other screen blit.

Or perhaps frameskipping is the wrong choice of words you picked.

 

[obscene]

It's definitely frameskipping. You have to enable 60fps on the video, and the process of capturing and converting to YouTube makes it harder to see, but believe me I've looked at it for 3 years... it skips frames.

Frameskipping is the right word. The step events continue to run at 60... only drawing is skipped.

The point of the discussion is what's going on with the back buffer and application_surface when drawing is disabled.

 

[Zep--]

The point of the discussion is what's going on with the back buffer and application_surface when drawing is disabled.

Well, the documentation for that command says it can cause issues.

Perhaps the best course of action...is to say "tough luck" your computer sucks, if it lags, and forget all about the frameskipping. Or make it a windows-only toggle for the time being.

Game looks good, btw.

 

[Zep--]

I wonder...Can you blit the whole screen to a surface before the skip and then blit that surface to the application surface after the skip?

Also, Isn't there also a command to stop the application surface from being drawn? I seem to recall reading about one. Maybe look into that. Or a combination of both.