//Do stuff in this loop, but this loop is never iterating since there aren't any events.}

FLOAT elapsedTime = pollEventsStopwatch.GetElapsedTime();if(elapsedTime >50){int breakHere =0;//<---- I'm hitting this breakpoint since elapsed time is usually above 150 milliseconds even when counter is 0.}

I've been struggling with this for awhile. The best theory I have is maybe because there many window handles in this application. The application I have is basically runs multiple unit tests so it pops up about five windows on a thread. And to test this theory, I closed all but one of the windows. And it seems to never hit that break point when it's down to one window handle.

I tried moving one of the tests to its own thread, but by doing so, I'm running into a new issue where creating a new window handle on the separate thread causes an infinite recursion crash.

//Other stuff here. Let me know if you want me to post the full context of this function.

While reading through docs and forums, I learned about sf::Window::setActive. Although I call setActive(true) during the draw/render stage, it did not seem to make a difference. Then I started calling setActive(false) everywhere (after creating sf::RenderWindow, before render calls, before pollEvents, etc...). I know that's not the right way of doing things, but I was hoping it would at least 'lock' the windows instead of crashing whenever I create a window handle on a different thread.

I've did this for sf::RenderTextures, too. And I'm still crashing whenever I create a window handler on the other thread.

And here I am currently stuck. I'm running SFML version 2.4.0. I suppose I can upgrade it to a later version in case there was a bug fix for this.

Questions I have are:1. Any idea why polling events sometimes take over 150 milliseconds even though there aren't any events?

2. When do I need to call setActive on a window handle? Can it only be activated before calling clear, draw, display functions? Or do I need to activate the window handles when polling events, too? I presume the same should be done for sf::RenderTextures, too.

3. Any idea what could be causing the infinite recursion crash? If the windows are self contained in their own threads, is it possible to handle windows and render textures in multiple threads if setActive is called appropriately?

I have made a wrapper for SFML in the Ruby programming language. This updates it to 2.5. It is based off the C port of SFML. I used FFI to help make things easier. I have most of the modules wrapped. The only one I don't have wrapped is the Net module. I noticed the last SFML wrapper for Ruby hasn't been updated in a long time. I don't have this on Github or anything yet. Just wondering if anyone would be interested?

Build the website and make tutorialsAs of now, I will focus on building the Engine Website and making some youtube tutorials. I'll try to make 2 or 3 tutorials per week.

Engine developmentI will slow down with the Engine 2 development in order to focus on tutorials. But just for info, the next thing I'll be working on is the Engine Android Backend. Like Unreal on Unity, the Engine will able to deploy your game in android automatically.

The DRM backend is almost finished. But we stumbled across an issue that we can't find an elegant way aroud. There was a problem with rendering locking up after pressing the Enter key. We discovered that it was due to the keyboard input being passed to the terminal underneath. We solved that by grabbing an exclusive rights to all keyboard events in /dev/input by calling `ioctl(*itr, EVIOCGRAB, 1);` unfortunately this left us unavle to generate a TextEvent. Can you think of any way of converting a keycode to utf32 without relying on tables for each codepage like in SDL?