When will eventproblem be fixed

About Monkey 2 Forums Monkey 2 Development When will eventproblem be fixed

This topic contains 8 replies, has 3 voices, and was last updated by  abakobo 1 month, 1 week ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #15317

    SekaiChi
    Participant

    I don’t know if others have noticed but Monkey2 still have a minor problem with events becuase how it deals with sdl2 incorrectly my guess would be.

    You can see it sometimes whe you deal with things that need perfect timing. You can also see it in the timer actually and as a error popping up saing “peepevents” error. these problems are all related so they are not many problems just one but it is in the way for creating  beutiful games.

    In my perspective this is the only bug that needs to be solved now to make it a favorite game creation tool.

    #15348

    Richard Betson
    Participant

    Are you developing on Linux? This can be an issue on Linux and relates to SDL2 as seen in the IDE when moving a divider.

    #15349

    SekaiChi
    Participant

    No But I develop on macOS and Windows. Both have this and there are zero differences in how they are expressed. I am not sure about Linux. But my guess would be it has it too.

    #15350

    abakobo
    Participant

    I can “feel” it only when moving a mouse inside-outise of a window. It’s not a major issue to me but it would be great if it could be solved.
    It would take someone that masters sdl2..

    #15351

    SekaiChi
    Participant

    If timing does not matter to you then no problem, (you will only see a strange peep error sometimes while using timers, and if you do something heavy then you will also notice how Monkey2 tries to “catch up” events to a certain frame now and then after missing events in prev frames.

    It handles all events perfectly, so that is a big plus but very ireggurly and there are times where timing makes a difference.

    For starters the lagging of mouse events will always be one frame * more * than it has to be, not a particular good thing in mouse-ctrled games. The mouse is already one frame late in all languages vs the OS because of double buffering the graphics so having to wait yet another frame IS a big deal.

    It is not SDL2s own fault because if you read the mouseposition using direct sdl2 in M2 you can actually see this with your own eyes, so if you want mouse in Monkey2, do not use internal mouse commands, use the sdl2 commands instead.

    But of course it is much worse than that, as it will creep into the visuals and the audio in different ways.

    I think it is the same reason timers still can not be faster than 90 hz or so. I might be wrong on that one.

    #15355

    abakobo
    Participant

    Could you post some code with the sdl2 mouse? I would be very interested to see the difference!

    #15356

    SekaiChi
    Participant

    This is a good example where you can see the difference in detail on page 2

    Mojo Render Lagging

    #15376

    SekaiChi
    Participant

    To understand the timer issue look at the Spacechimp banana.
    The timer is set to fire 300 times per secand still it tops at 95-105 times per per sec when you enable the timer and disable the vertical refresh.

    I’m not an expert on sdl2 so I can’t fix Monkey2 alone. I know that you insert a delay of 1 – 10 millisecs or else the OS will insert a delay by itself around that same range. 10 millisecs would mean dividing a second to around a max firing around 95-105 per second.

    The rules that needs to be followed seem to be:

    You cannot use SDL_peepevents() you need to use the more thread-dangerous SDL_pollEvent() and you never do it using while (SDL_pollEvent(&event) but simply SDL_pollEvent()

    Alternatively you use eventWait() in its own thread with an inserted delay of 1-10 msec, and 5msec seems to be the better balanced choice.

    I also know that sdl2 creates automatic keydowns with no way of disbling this you have to manually filter them out, It only happens with keydown events.
    you do that by checking the member of SDL_keyboardEvent().

    You should never handle event by event but instrad loop trough events until there is no more of the same kind of event and then you push back the last two onto the queue. This way you get efficient code also when resizing windows etc. These kind of details are important actually.

    Im the videoinitilizing thread (which prefferable is also the main thread):
    sdl-pumpevents() this gathers all pending input fom devices and places them in the event queue this is done implicitly by Sdl_pollevent and sdl_pushevents().

    And in a dedicated thread :
    sdl_peepevents() and sdl_pushevents() are used to send own events or fake events by simply sending them (i assume timers use these user events).

    sdl2 always translates window events into Sdl_events and places them in a threadsafe queue.

    #15377

    abakobo
    Participant

    This is quite interresting.
    I’d like to dive deeper into this but have no free time till mid october..

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.