Basically behavior about that is back to how it was in Irrlicht 1.8 - not perfect, but useable.
So window still jumps a bit when dragging toolbar, but no longer outside the sreen. And it's possible again to alt+tab to other windows.
The problem was caused by a combination of FPS camera changes and that we stopped doing mouse-coordinate clipping in the Linux device in r5593.
Basically that clipping had the side-effect that the fps-camera never considered a mouse "outside" on Linux.
Now on Linux we only update after we get a mouse-event (which we still get when the mouse is outside the window).
On Windows we still grab the mouse in the camera, thought that's likely _not_ the best way to do that. Windows has some mouse-grabbing support,
and I suppose we could use that (or camera should check if that is used as it also can be set by users I think). So maybe in future this can be further improved.
Other operating systems (OSX) should behave like in 1.8 I hope, but as usual I can't test.
Also did a few minor cleanups in the camera.
- Back to using animateNode time instead of real-time. That's because that was not causing the problems I thought back then it might cause as time is only used for keyboard input and not mouse input.
- Moved updating CursorPos to the rest of the code checking CursorControl
Note: A future improvement would be to add support for systems without CursorControl object (could still use mouse-events to get it working usually).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6142 dfc29bdd-3216-0410-991c-e03cc46cb475
Thx @Marko Mahnič for the patch (https://sourceforge.net/p/irrlicht/bugs/449)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6135 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously project file was at 3.2 which seems to no longer work with newer XCode versions.
Patch is from Maksym Hamarnyk, no testing from my side for this.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6131 dfc29bdd-3216-0410-991c-e03cc46cb475
It's never really done much in c++, was deprecated in c++11 and is reserved since c++17.
Thanks @Maksym Hamarnyk for remdinding me about this.
Note: there are few more register commands in third library .c code. It's still a valid keyword there.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6130 dfc29bdd-3216-0410-991c-e03cc46cb475
Introduced in r5818. Might be part of the OSX compile troubles.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6125 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @Maksym Hamarnyk for sending those.
Note: More patches are needed and I can only apply, not test, this.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6123 dfc29bdd-3216-0410-991c-e03cc46cb475
The change to the scaling code caused scaling to read outside of original image memory.
Was caused because scaling step factor was based on image-sizes, but has to be based on amount of scaling steps taking (off-by-one error).
Thanks @Maksym Hamarnyk for reporting that there was some problem.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6121 dfc29bdd-3216-0410-991c-e03cc46cb475
Before it crashed when index-count wasn't a multiple of 3, now it just doesn't create the last triangle then.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6110 dfc29bdd-3216-0410-991c-e03cc46cb475
This changes the behaviour on Win32 somewhat when Windows returned a CURSOR_SUPPRESSED state (touch-screen input hiding cursor globally).
Previously we set IsVisible it to false when CURSOR_SUPPRESSED was set.
Also we handle the CURSOR_SUPPRESSED state slightly different now and still try to hide cursors once when requested.
Reason for the change is that the old behaviour made it harder to recover from touch-screens hiding the cursor because Irrlicht didn't
know anymore which state is _should_ have. This also unifies the behaviour on all drivers as the other drivers already returned the visible
flag independent of the system being able to actually show the cursor.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6109 dfc29bdd-3216-0410-991c-e03cc46cb475
UI and scenenodes are often connected. And while it was possible to work around this already by using custom draw functions
or deriving from gui and scene-nodes at the same time, it did already lead a few times to uglier code for me.
So I guess adding one more pass to the engine has it's uses.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6107 dfc29bdd-3216-0410-991c-e03cc46cb475
- 10 year anniversary update
- Lighting model reworked. moved to eyespace like openGL. [Specular Highlights, Fog, Sphere/Reflection Map]
- increased internal s4DVertex to support 4 Textures and 4 Colors [switchable]
- Textures are handled as sRGB during Mipmap Generation. More accurate, less visual disruption
- 2D is drawn as 3D like hardware drivers. [switchable]. enables viewport scaling, material2D
- Texture Spatial Resolution Limiting working. [lower memory consumption,SOFTWARE_DRIVER_2_TEXTURE_MAXSIZE]
- SuperTuxKart 8.0.1 playable
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6086 dfc29bdd-3216-0410-991c-e03cc46cb475
Sorry, just a hack to make it easier to work around Irrlicht :-(
Would be nice to have a general mechanism to load native gl functions in Irrlicht from apps...
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6074 dfc29bdd-3216-0410-991c-e03cc46cb475
65536th vertex has index 65535 which is still fine, was going 1 too low in last commit.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6053 dfc29bdd-3216-0410-991c-e03cc46cb475
Those are not supported by any graphic card and we just end up with invalid textures.
Returning 0 now instead in addRenderTargetTexture for OpenGL and D3D9.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6047 dfc29bdd-3216-0410-991c-e03cc46cb475
