Updated wxIrrlicht

[n00bc0de]

I have been using wxWidgets as the GUI library for my project. I recently tried to build on linux and it would not compile. The last release of wxIrrlicht was a very long time ago so I made some modifications to it to support wxWidgets 3+ and fix the performance issues.

The performance issues were a huge problem on linux but it was only a problem if the window and irrlicht were both trying to render at the same time. So my solution was to have the irrlicht window only render when it is the active control in the window. It works really well but it also means that the irrlicht window only updates when the mouse cursor is over it or you manually set it as an active control. The renderer does not slow down the entire window on Windows so I might change this behavior back on Windows later on.

Here is the link: https://github.com/n00b87/wxIrrlichtNE

Also, here are the compiler and linker flags I use to build on linux:

Compiler Flags

Code: Select all

`wx-config --cflags` `pkg-config --cflags gtk+-3.0`

Linker Flags (I use a lot of wxWidgets but you can remove all the libs in the wx-config block you don't need)

Code: Select all

`wx-config --libs std,stc,aui,propgrid,ribbon` -lIrrlicht `pkg-config --libs gtk+-3.0`

Also, in addition to wxGTK3, you will also need to install the following packages:
libgtk-3-dev
libgdk-pixbuf-2.0-dev


On Windows you can just use the normal wxWidgets flags since the window handle stuff is all provided by windows.h.

[CuteAlien]

Thanks, that is good to have.

I recently learned something about using OnTimer to render on Windows. The resolution of the timer is only around 15ms which means the fps limit is around 66 FPS (actually more like 65 in my experience). Learned about that when I updated to a 144Hz screen. My old game also messes this up as even sleep(0) in Irrlicht 1.8 or earlier was always at least 15ms (changed in svn trunk by now).

[n00bc0de]

Thanks for the tip about the timer. I will play around with that and see if I can have it render without having mouse focus. It did seem to sort of work on Windows but it did feel a little clunky. It was flatout unusable on linux however and my linux machine is way more powerful than my windows machine.

[Noiecity]

Thanks, that is good to have.

I recently learned something about using OnTimer to render on Windows. The resolution of the timer is only around 15ms which means the fps limit is around 66 FPS (actually more like 65 in my experience). Learned about that when I updated to a 144Hz screen. My old game also messes this up as even sleep(0) in Irrlicht 1.8 or earlier was always at least 15ms (changed in svn trunk by now).

A question, what you observed in OnTimer is related to Irricht getTimer?

[CuteAlien]

@Noiecity: Yeah - it's about Windows timer in general which are used for example in Windows sleep(). Irrlicht uses those for it's device->sleep(). Which I don't recommend using anymore therefore. Up to (including) Irrlicht 1.8 we also used sleep(1) for device->yield(), so that was just as bad. But that is now using sleep(0) in Irrlicht svn trunk (aka Irrlicht 1.9), so that can be used again as it now only gives up the thread (reason it used sleep(1) in the past was some Windows 98 behavior where using sleep(0) wasn't guarenteed to give up threads, but Microsoft changed that behavior afterwards).

@n00bc0de: Are you on Irrlicht 1.8 or svn trunk? Could be something changed. Also if you show me your main-loop I might have more ideas.

[n00bc0de]

@n00bc0de: Are you on Irrlicht 1.8 or svn trunk? Could be something changed. Also if you show me your main-loop I might have more ideas.

I was on Irrlicht 1.8. I can pull 1.9 svn and try it out with that. I still have the changes I mentioned in wxIrrlichtNE but I can change the code back to its original behaviour and see if there is a difference on 1.9.

Also, for anyone interested, I have current WIP version of my level editor with the linux build script here: https://github.com/n00b87/SerenityEditor

Its currently just the initial version of the UI and uses the hello world example to test the wxIrrlicht frame. Once you build it, you can just click the play button to test the irrlicht integration which right now works fine but irrlicht only updates when the mouse is over the frame.

[CuteAlien]

Link gives me a 404, maybe not public?

[n00bc0de]

Sorry. I just made it public.

[CuteAlien]

Thanks. Code looks actually pretty similar to code in my current project (except we use WTL instead of wxWidgets in our project). Using timers should on Windows allow ~65 FPS. No idea really about wxWidgets on Linux and timers, thought I would have expected it to be rather a better resolution (usually is for timers). Sorry, guess I'm not much help with this one.

[n00bc0de]

I made a video covering the issues I am having.
https://youtu.be/LJXe6rRsfJY

[CuteAlien]

Ah thanks for the video. I didn't realize when browsing quickly over the code earlier what m_windowIsActive really was (I thought it was some wxWidget variable if the window is active...).

Too late here right now to really test things, but on another quick view at sources I notice you also render in OnPaint. And you probably shouldn't, rendering in OnTimer should be enough. Maybe you did that to prevent flickering? In that case - overload OnEraseBackground and check if that is called. It should do nothing (depending on window flags it will erase background and cause flickering... on Windows at least - again not sure on Linux).

But the real reason is probably that Irrlicht and wxWidgets are fighting for the system events. In render() you have a call to m_pDevice->run() - and that checks system events. Just don't call it at all. Instead only call something like the following (don't know how to get the rect in wxWidgets, this is how we do that in WTL, but I think you'll figure that part out):

Code: Select all

// absolute coordinates of the window rendering your Irrlicht stuff
RECT r;
GetWindowRect(&r);
irr::core::rect<irr::s32> rect = irr::core::rect<irr::s32>(r.left,r.top,r.right,r.bottom);

m_pDevice->getCursorControl()->setReferenceRect(&rect);

// And tick timer for animation
m_pDevice->getTimer()->tick();

All other events you already forward with the postEventFromUser calls.

[n00bc0de]

I got it working. I took out the m_pDevice->run() from the Render() function and added m_pDevice->getTimer()->tick() to the OnTimer() function. Then I just added a call to Refresh() in the OnRender() function to manually trigger a PAINT event in wxWidgets when the scene is updated. I pushed the changes to the wxIrrlichtNE repo https://github.com/n00b87/wxIrrlichtNE

I haven't tested it on Windows yet but I am assuming it should work without any issue since I did not add any OS specific code.

[Noiecity]

@Noiecity: Yeah - it's about Windows timer in general which are used for example in Windows sleep(). Irrlicht uses those for it's device->sleep(). Which I don't recommend using anymore therefore. Up to (including) Irrlicht 1.8 we also used sleep(1) for device->yield(), so that was just as bad. But that is now using sleep(0) in Irrlicht svn trunk (aka Irrlicht 1.9), so that can be used again as it now only gives up the thread (reason it used sleep(1) in the past was some Windows 98 behavior where using sleep(0) wasn't guarenteed to give up threads, but Microsoft changed that behavior afterwards).

@n00bc0de: Are you on Irrlicht 1.8 or svn trunk? Could be something changed. Also if you show me your main-loop I might have more ideas.

I recent watch this: https://learn.microsoft.com/en-us/windo ... dfrom=MSDN

It's interesting, I wonder if something like that could be implemented in Irricht

Although it depends on the processor, the range of precision is low to be in such a low time scaling, if I understood correctly, in a 2.7ghz processor would take approximately 300 picosecond with an access time of 27 nanosecond, something like that varies between 0.0000000...0000....3ms to 0.000027ms well, 100,000 Picoseconds to Milliseconds = 0. 0001, but the access time is 27 nanosecond, which would be the range to consider, that is, between 0.00001ms to 0.000027ms, a timer of these characteristics would be useful for very low latency timers, such as calculating the movement and frames of an animation, it is much less precise, but can work well in low interval times, values that do not require a highly accurate precision, it would come in handy.

Ironically, RTCs do indeed have 15.625 milliseconds of clock resolution, just as you had understood, and as I read, it is much, much more accurate, as opposed to RDTSC where the clock resolution is much faster.

Here is more information:
https://learn.microsoft.com/en-us/windo ... dfrom=MSDN

Besides, many of the associated problems are solved by using a single thread, i.e. irrlicht is fine with it, and anyway, for low end games probably the error time, which would be highly unlikely in a low end game that is not susceptible to sudden changes in the cpu, you would have to be using the entire cpu in running other programs with drastic changes in temperatures for there to be a continuous error, and if it were to arise in a low-end game without abrupt cpu changes, the drop would be so minimal that it would be unnoticeable.

I wouldn't use it in my games, but it would be useful to have it added to show examples haha, I prefer the current irrlicht stability, most games crash because of this kind of events, it's the same with bilinear and trilinear filter, I'm developing a game with the trilinear filter and with 256 pixel jpg images as it offers 800 fps on an old laptop, and the graphics are not bad, they automatically become retro graphics haha

[n00bc0de]

I think the issue was the event systems clashing. Removing IrrlichtDevice->run() seems to have resolved all the issues I had with slow down and adding Refresh removed the need to only have it update when it had mouse focus. I did not originally write wxIrrlicht. I only added GTK3 support to the original library so I never really looked to deeply at the code which was just a mistake on my part.

Thanks CuteAlien for the tip on the timer.

[CuteAlien]

Great. One day we'll add 3rd party integration examples I hope :)