August 21, 2018 at 5:57 am #15317
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.August 29, 2018 at 12:30 am #15348
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.August 29, 2018 at 12:51 am #15349
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.August 29, 2018 at 6:45 am #15350
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..August 29, 2018 at 7:48 am #15351
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.August 29, 2018 at 4:14 pm #15355
Could you post some code with the sdl2 mouse? I would be very interested to see the difference!August 29, 2018 at 5:15 pm #15356
This is a good example where you can see the difference in detail on page 2September 4, 2018 at 6:51 pm #15376
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.September 5, 2018 at 7:01 am #15377
This is quite interresting.
I’d like to dive deeper into this but have no free time till mid october..December 3, 2018 at 3:11 pm #15661
I’m back on mx2. Could you give me the state of your analysis on this “event” problem? And also on the Mac/ios problem?
I have a Mavericks, a ElCapitan, a HighSierra and a Mojave machine to run tests and would like to see what’s going on there (and if it is a problem for my game project as it is). I only have an IPhone6s for the ios tests though.
ThxDecember 4, 2018 at 12:02 am #15664
The only example I have on this computer is closed source.
I’ve said this so many times and no-one seem to care. But sure, one last time.. This is the complete list of ONE SINGLE problem.
* Timers are limited to 90-120 times per second. Monkey2 seems to use SDL2 user-events to implement them, and that’s how all this is weave together to all the rest.
* Sometimes timers crash ios and Android. The easy fix is to comment away any timers but I do not know why this happens. Windows and macOS always run code with any timers without any problem, but they will give you an error message on exit instead. I read that even TED itself has this problem, probably bc it uses timers.
* Touch and Mouse always are always at least one or two frames behind what it should be (other events is not synchronized either).
* Graphic updates as events are processed, and events seem to try to catch up now and then. Keyboard releases, downpresses, mouse actions, touch and timers, they all have control over graphic updates.
The last one is important, because it allows some kind of visual test how event affects even the screen. It’s not the best test for this, but it shows what needs to be shown. I include a zip with source code for Monkey2, and also a Monkey1 version for those who happen to have that laying around, for contrast..
Monkey1 handles everything mentioned above perfectly, even if the test in the zip-file only shows how events affects screen updates, it should be noticed that the problem goes far deeper than that. But still the screen becomes a good reliable indicator.
Attachments:December 4, 2018 at 12:41 am #15666
I want to say that I’m trying to get faster touch input which is very important for the current project. The input must match perfectly to what is on the screen. The project is very picky and that is my main driving force.
A bonus would of course to also get smoother graphics compared to what Monkey2 currently allows, as I do know that it’s possible, but it is not a must. It’s fine.
I keep Monkey1 for my OCD that I have about perfect smoothness hah.
Monkey2 gives you a busines so I forgive it for not being OCD-Smooth (Im old school and like that kind of shite).December 4, 2018 at 8:35 am #15667
Thanks. I’ll reinstall latest monkey-x and have some tests.December 5, 2018 at 11:50 pm #15668
btw the reason I use Monkey2 v06 (June) is maybe because of the threads, which also made ted feel slower, and the whole packages slowed down, if you have a weak computer you can actually notice it. But mainly because of this code change which seem to do made more harm than good if you ask me.December 6, 2018 at 12:35 am #15669
It may be that SDL2 is not an easy API to deal with, there’s a lot of confusion and questions from many people how to handle things, It is not very well documented.
This is one of those areas where people ask lot of questions about, how to handle Operating System delays correctly.
SDL2 is so much different from SDL, e.g. you have to throw out repeated events yourself and make sure only the last one is left in the queue.
You must be logged in to reply to this topic.