So…
How many people use the SDL_THREADSAFE flag?
How many people use SDL’s color cursor support?
If I remove them, will it inconvenience anyone?
I am fixing the software cursor support in SDL.
It results in the loss of color cursor support, and thread-safe surfaces
no longer being necessary. The speed of blits slightly improves, and the
cursor no longer blinks in fullscreen mode (unless you are writing directly
to video memory)
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Sam Lantinga wrote:
So…
How many people use the SDL_THREADSAFE flag?
How many people use SDL’s color cursor support?
If I remove them, will it inconvenience anyone?
I am using the color cursor, but have been contemplating a change.
Working around the cursor flicker in X11 is tiresome, and the Mac
version doesn’t hide the system cursor. Guess this is a good time for me
to fix that code. 
Thanks,
Max Watson <@Max_Watson>
Sam Lantinga wrote:
So…
How many people use the SDL_THREADSAFE flag?
How many people use SDL’s color cursor support?
If I remove them, will it inconvenience anyone?
I am using the color cursor, but have been contemplating a change.
Working around the cursor flicker in X11 is tiresome, and the Mac
version doesn’t hide the system cursor. Guess this is a good time for me
to fix that code.
When I upload the patch for the cursor, you can see how I do it so it
doesn’t flicker, and apply the same logic to your own code. You’ll
have to implement the cursor as a sprite that you manage, moving it
in response to mouse messages.
By all means, fix the Mac mouse code (SDL_sysmouse.c)
Thanks,
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Regarding SDL color cursor: I will always be running with SDL_ShowCursor(0);
Meaning I draw my own cursor. I didn’t like the flickering so I did the
cursor myself in my loop. So I don’t care what changes to the sdl cursor
stuff are done, just so long as I can make the cursor vanish.
So…
How many people use the SDL_THREADSAFE flag?
How many people use SDL’s color cursor support?
-Dave
Sam Lantinga wrote:
Sam Lantinga wrote:
So…
How many people use the SDL_THREADSAFE flag?
How many people use SDL’s color cursor support?
If I remove them, will it inconvenience anyone?
Bah, remove it (color cursor), it sucked anyways, heh, do you think you could
elaborate a bit more on the bitmask format used for the mono system mouse
cursor?.
People: just write your own color cursor routines. Geez
Paul Lowe
spazz at ulink.net
Hm well then to do a color cursor youd have to get the cursor position
on the screen and blt your own sprite to the location, which would then
update at the framerate of the game (which means a laggy cursor)? Actually I
don’t use the colored cursor support, but I can’t think of any good way of
implementing one myself.
-Garrett, WPI student majoring in Computer Science.
“He who joyfully marches in rank and file has already earned
my contempt. He has been given a large brain by mistake, since
for him the spinal cord would suffice.” -Albert EinsteinOn Thu, 15 Jul 1999, you wrote:
I am fixing the software cursor support in SDL.
It results in the loss of color cursor support, and thread-safe surfaces
no longer being necessary. The speed of blits slightly improves, and the
cursor no longer blinks in fullscreen mode (unless you are writing directly
to video memory)
Yes indeed. This is precisely the reason for adding the SDL_INIT_EVENTTHREAD
flag. If the events are being gathered in a seperate thread, the mouse will
update smoothly even if the framerate is uneven. Unfortunately this flag is
unsupported on Win32, and code that I’ve seen solving this problem polls
DirectInput in a separate thread.
The problem on Win32 is that only the thread that creates a window can get
messages for that window. One solution would be to turn the Win32 video/event
code into a sort of X server. That probably would lower the speed.
Another solution might be to run the DirectInput polling loop in a
separate thread if SDL_INIT_EVENTTHREAD is used, but the rest of event
handling would run in the main thread normally.
Thoughts?
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software> On Thu, 15 Jul 1999, you wrote:
I am fixing the software cursor support in SDL.
It results in the loss of color cursor support, and thread-safe surfaces
no longer being necessary. The speed of blits slightly improves, and the
cursor no longer blinks in fullscreen mode (unless you are writing directly
to video memory)
Hm well then to do a color cursor youd have to get the cursor position
on the screen and blt your own sprite to the location, which would then
update at the framerate of the game (which means a laggy cursor)?
–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
In win32 what about running GetCursorPos() in another thread to get the cursor
position along with a blt and a screen update? Although I don’t think you can
have two threads bltting to the same surface in win32 at the same time so if
the user takes a long time bltting the cursor will slow down to. I also thought
there was another feature in windows that allowed you to load colored cursors?
Windows themes do it. And Visual C++ has a utility to make colored cursors.
-Garrett, WPI student majoring in Computer Science.
“He who joyfully marches in rank and file has already earned
my contempt. He has been given a large brain by mistake, since
for him the spinal cord would suffice.” -Albert EinsteinOn Thu, 15 Jul 1999, you wrote:
Hm well then to do a color cursor youd have to get the cursor position
on the screen and blt your own sprite to the location, which would then
update at the framerate of the game (which means a laggy cursor)?
Yes indeed. This is precisely the reason for adding the SDL_INIT_EVENTTHREAD
flag. If the events are being gathered in a seperate thread, the mouse will
update smoothly even if the framerate is uneven. Unfortunately this flag is
unsupported on Win32, and code that I’ve seen solving this problem polls
DirectInput in a separate thread.
The problem on Win32 is that only the thread that creates a window can get
messages for that window. One solution would be to turn the Win32 video/event
code into a sort of X server. That probably would lower the speed.
Another solution might be to run the DirectInput polling loop in a
separate thread if SDL_INIT_EVENTTHREAD is used, but the rest of event
handling would run in the main thread normally.
In win32 what about running GetCursorPos() in another thread to get the cursor
position along with a blt and a screen update? Although I don’t think you can
have two threads bltting to the same surface in win32 at the same time so if
the user takes a long time bltting the cursor will slow down to.
I’ll think on it a while. For now, Win32 won’t support mouse events in
a seperate thread.
I also thought
there was another feature in windows that allowed you to load colored cursors?
Windows themes do it. And Visual C++ has a utility to make colored cursors.
They don’t work in DirectX fullscreen mode.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec