> That'll have to be fixed in SDL2 if possible, or disable the hiding altogether.
If the problem has been occurring for a long time as @pjs wrote.You can probably disable the mouse hiding. That would be the easiest way. I had a similar problem with the sdl12-compat implementation under mplayer. Here the mouse is always visible.
I have tested on Linux that SDL_MOUSEMOTION behaves similarly: event is reported only when mouse pointer is hovering on the window surface.
But SDL_ShowCursor() behavior is different. On AmigaOS, window area doesn't matter, only window activation / focus. On Linux, mouse pointer seems to reset when it leaves the window boundaries.
Maybe this can be changed by using Intuition tick events and checking mouse X/Y against window boundary. Have to investigate more.
I have tested on Linux that SDL_MOUSEMOTION behaves similarly: event is reported only when mouse pointer is hovering on the window surface.
This confuses me a bit. Wouldn't then the same behaviour happen with the mouse disappearing even if outside of the window? Or is the behaviour different between Windows and Linux?
@pjs
In the meantime, I have updated ffplay to not hide the mouse cursor.
I don't know about Windows but SDL_MOUSEMOTION seems to work as documented on both Linux and AmigaOS.
SDL_ShowCursor is not documented in details. Its behavior could be OS-specific. Of course we can try to ask SDL folks to specify its behavior.
On Linux disabled cursor and special cursors behave consistently: they are only active when mouse is hovering on the window surface, but cursor resets when moved outside.
On AmigaOS side, (for example) busy pointer is active anywhere on the screen as long as its window is active. I'm not sure if this should be changed in context of SDL. It would then be maybe inconsistent from AmigaOS point of view.
I tried my old port of ffmpeg 3.1.1 which is on Aminet, and that uses SDL1 rather than SDL2. I don't know which version of the SDL1 library I built it against. In that version, the pointer is a different black pointer when inside the window, and only disappears when kept motionless inside the window. When outside, it's the regular mouse pointer, and doesn't disappear.
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
Improve UTF-8 text input support. Update install script. Reset mouse pointer when it leaves its window. Improve audio recording.
Thanks for the new release candidate. The installer works perfectly and all SDL1/SDL2 applications work as before. Reset mouse pointer when it leaves its window works good
Is the fact that the mouse cursor is hidden after a while in the SDL output also new? I never noticed it before.
is that long standing vanishing mouse pointer after moving it outside the sdl window finally gone? :-O
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
I have tested the new version and it also shows the mouse pointer behavior in some applications. Just pay attention to it.
@Caphill
One more bug I could observe is that Prefs or SDL2 simply switches to OpenGL mode in some applications, even though the Prefs settings for software were set and I saved them. You can see it in my video, the whole thing can be replicated again and again and should not be like this.
p.s. of course I could only test the software mode as usual, but OpenGL via Wazp3d is also possible, but leads to a messed up color display in most applications (Wazp3d error) But that's not the point, but that the saved prefs change their behavior even though they are saved.
Is the fact that the mouse cursor is hidden after a while in the SDL output also new?
Hmmm, shouldn't be. My first guess is application is hiding it.
It is quite possible that the option was simply added when the application was compiled. It does not look like an error, but fits the respective application.
However, I have not noticed that the SDL Prefs settings of software randomly switch to OpenGL mode when the prefs were first set and saved. Maybe also an error when compiling the application.
Otherwise your SDL2 port works as usual, all SDL2 applications work without problems. (Software)
Edit: I can also replicate it in the same way with Os4Depot version 2.28.4, so it has always been like this and is not a bug in the RC of SDL2.
I have not noticed that the SDL Prefs settings of software randomly switch to OpenGL mode when the prefs were first set and saved. Maybe also an error when compiling the application.
What do you mean exactly? Do you choose "software" driver, save it and when check the SDL_RENDER_DRIVER file on ENVARC:, it's somehow turned to "opengl"?
What do you mean exactly? Do you choose "software" driver, save it and when check the SDL_RENDER_DRIVER file on ENVARC:, it's somehow turned to "opengl"?
All settings that are selected via SDL2 are also saved in the SDL_RENDER_DRIVER file under ENVARC. For example, when I select and save software, it is also saved in SDL_RENDER_DRIVER as "Software".
When I run SonicCD RSDKv3 from Os4Depot, the SDL2 Software Renderer is also used. But as soon as I quit the game and open another SDL2 game, the SDL2 prefs changes from Software to OpenGL. But in SDL_RENDER_DRIVER prefs it still says software as sdl2 output. I'm not sure, but it could also be a problem with porting SonicCD RSDKv3 which just changes the SDL mode.
Note: The video is still being edited for playback.
I will delete this video later, it should only show the problems.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
