I've just realized there are going to be scenarios where a single screen_refresh() doesn't work properly. As per this file:
https://www.box.com/s/2oheia1qs3u9n14i5p7c

Hold space to test, and you will see that the wrong drawn text is shown (because it's showing the text from the previous buffer). If you uncomment the other screen_refresh then it will display the correct text. The fact that it works at all to draw on the screen is kind of a hack that relies on the likelihood that the previous frame is the same.

EDIT: I've just thought of adding a moving object to it. When you do that you can see more easily that it jumps back when you hold space. So this is going to look nasty for people on Windows that use screen_refresh for a pause screen (which is common) because it's going to skip the frame back when they pause and it will be noticeable.

I want to be able to link to 64digit games on the EDC.

hmm I'm not sure.

Anyway this is the same problem that is cause draw_getpixel() to not work after screen_refresh() which is an incompatibility with GM. Also if you turn off background drawing in the room editor now, so the screen isn't cleared to a colour then this buffer swapping will also be seen.

You can test in this file:
https://www.box.com/s/p8w6bs1c0vf1gdj3ex9g

Press Right/Down to move the block on key press. E/S to move the block on key hold. At 30 fps pressing Right/Down to move the block doesn't cause the flickering to happen (because then it's getting drawn on both buffers, unless you press it super fast - you can get it to happen at lower frame rates) but if you use E/S to move on hold instead you will get the flickering.

So the solution to this problem is: Repeat all the drawing after a screen refresh so it's on both buffers. Or just don't call screen_refresh more than once
But I do also want to know why it's different in GM.

Well the set_synchronization() function was commented out, it needs to be rewritten.

Interesting. It must be different in GM due to Direct X? But this was working for me before on this system, so something must have changed in ENIGMA or (I think) I may have updated a driver at some point which could have possibly affected it. But the fact that it doesn't seem to be working for anybody on Windows now suggests to me that something in ENIGMA has changed, but I have no idea what that could be?

This is what ENIGMA is using to set-up the drawing in WINDOWSstd.cpp:

Code Select Expand

void EnableDrawing (HGLRC *hRC)
{
    PIXELFORMATDESCRIPTOR pfd;
    int iFormat;

    enigma::window_hDC = GetDC (hWnd);
    ZeroMemory (&pfd, sizeof (pfd));
    pfd.nSize = sizeof (pfd);
    pfd.nVersion = 1;
    pfd.dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER;
    pfd.iPixelType = PFD_TYPE_RGBA;
    pfd.cColorBits = 24;
    pfd.cDepthBits = 16;
    pfd.iLayerType = PFD_MAIN_PLANE;
    iFormat = ChoosePixelFormat (enigma::window_hDC, &pfd);

    if (iFormat==0) { show_error("Total failure. Abort.",1); }

    SetPixelFormat (enigma::window_hDC, iFormat, &pfd);
    *hRC = wglCreateContext( enigma::window_hDC );
    wglMakeCurrent( enigma::window_hDC, *hRC );
}

Then SwapBuffers(enigma::window_hDC); for screen_refresh(). Looking through git though, none of this has changed in 3 years which is before I originally posted the raytracing example.

Must be the vsync then.

Did you not update / rebuild?

Btw Deus could you please look at this:
http://enigma-dev.org/forums/index.php?topic=1268.0

I'm most interesting in what's happening to you, because you reported it flickering before.

Hey can I get some feedback please if anybody else is experiencing this issue?
https://github.com/enigma-dev/enigma-dev/issues/165

Yeah, it's been fine for me. I've not been seeing any odd results or strange speeds, it's all correlated very well with GM as well as to what I would expect.

OK my proper results:

room_speed: 10, fps: 10
room_speed: 30, fps: 30
room_speed: 45, fps: 45
room_speed: 60, fps: 60
room_speed: 100, fps: 100
room_speed: 200, fps: 200
room_speed: 500, fps: 500
room_speed: 1000, fps: 738
room_speed: 2000, fps: 735

Using GL1. You can get the fps a lot higher with a smaller room and turning off the background colour.

There's still that >= 170 room_speed code in ENIGMA. I asked Josh about it, he seems to think it's fine.

My specs:
http://pastebin.com/S2neAq4S

Anyway for some reason mine is coming out in ENIGMA as:
http://pastebin.com/5P2YxS3V

In GM as:
http://pastebin.com/d2KZ4GWr

So wtf, why is the fps getting capped at 100? EDIT: Ok I changed the fps of room 4 to 140 and then it gets stuck at that instead it isn't getting capped, so it's just not updating at room 5 (ie where the room_speed goes above the 170). But why, I''m not sure. EDIT: Oh I see, that code that Josh said to add is all wrong, all it's doing is stopping the current_room_speed variable being set. So the reason it must have worked before is because it was always tested in the first room - where it was keeping the room speed at 0 - which conveniently forthevin added a clause to remove the sleep at

One of those magically cases where doing something completely wrong made it look like it was actually working somehow.

Is it possible that we can ever see the serious bugs (ie the ones left on the tracker) be resolved?
https://github.com/IsmAvatar/LateralGM/issues

These are the ones that are hindering ENIGMA.

Ism just changed LGM to allow 0 being set.

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

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.