In full screen mode, when the only screen initialisation flag I had enabled
was full screen I was getting about 150 fps. Sounds good, really good. The
strange thing is, when I added hardware and double buffering flags I dropped
to 50-60 fps. I mean, that’s not terrible, but amazingly less than with
software surfaces.
When you do double-buffering, the flipping is synchronized with the vertical
retrace. That might be what you’re seeing here.
Also, when I use:
SDL_SetColorKey(imageBMP, SDL_SRCCOLORKEY|SDL_RLEACCEL, 0);
The SDL_RLEACCEL flag crashes my program, but applying this to a surface
without the flag works fine.
This sounds like a bug with the new RLE code and hardware surfaces.
Xark, Yorick, can you help him?
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Sam Lantinga wrote:
SDL_SetColorKey(imageBMP, SDL_SRCCOLORKEY|SDL_RLEACCEL, 0);
The SDL_RLEACCEL flag crashes my program, but applying this to a surface
without the flag works fine.
This sounds like a bug with the new RLE code and hardware surfaces.
Xark, Yorick, can you help him?
Is RLE used even when DirectDraw has a blitter for this (which could be
hardware if both source and destination are in video memory)? Locking
the surface, then doing a RLE “accelerated” color key blit is probably
incredibly slow…–
Pierre Phaneuf
Systems Exorcist
I set up a small test program that simply blitted some data onto the
display, and then did a sdl_flip.
loop
{
sdl_blit(source, screen)
sdl_flip(screen)
}
In full screen mode, when the only screen initialisation flag I had enabled
was full screen I was getting about 150 fps. Sounds good, really good. The
strange thing is, when I added hardware and double buffering flags I dropped
to 50-60 fps. I mean, that’s not terrible, but amazingly less than with
software surfaces.
I’m using Windows 98, a TNT 2 Ultra and Direct X 7.0
Also, when I use:
SDL_SetColorKey(imageBMP, SDL_SRCCOLORKEY|SDL_RLEACCEL, 0);
The SDL_RLEACCEL flag crashes my program, but applying this to a surface
without the flag works fine.________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Sam Lantinga wrote:
SDL_SetColorKey(imageBMP, SDL_SRCCOLORKEY|SDL_RLEACCEL, 0);
The SDL_RLEACCEL flag crashes my program, but applying this to a surface
without the flag works fine.
This sounds like a bug with the new RLE code and hardware surfaces.
Xark, Yorick, can you help him?
Is RLE used even when DirectDraw has a blitter for this (which could be
hardware if both source and destination are in video memory)? Locking
the surface, then doing a RLE “accelerated” color key blit is probably
incredibly slow…
It shouldn’t be, but there may be a bug in the logic handling hardware
surfaces.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Sam Lantinga wrote in message …
It shouldn’t be, but there may be a bug in the logic
handling hardware surfaces.
Actually, there may be something wrong with the binaries. My stuff was
crashing with the development binaries but works fine if I compile the 1.1.3
source. Not sure where my stuff was crashing but I have a feeling it was
near the RLE blitting.
Regimental Command
Generic Armored Combat System
http://www-users.cs.umn.edu/~relander/regcom/index.html
Randi J. Relander wrote:
Sam Lantinga wrote:
It shouldn’t be, but there may be a bug in the
logic handling hardware surfaces.
Actually, there may be something wrong with the
binaries. My stuff was crashing with the development
binaries but works fine if I compile the 1.1.3
source.
I varified the problem, it has nothing to do with hardware surfaces. The
SDL.dll in both the binary and development Win32 runtime packages cause soft
blits with SDL_RLEACCEL to crash. If I compile the source and generate my
own SDL.dll then everything works fine. I am using Visual C++ 6.0 on NT4,
haven’t had a chance to try it on Win98 yet. What is normally used to
generate the Win32 binaries?
Regimental Command
Generic Armored Combat System
http://www-users.cs.umn.edu/~relander/regcom/index.html
Randi J. Relander wrote:
I varified the problem,
Doh! Add “varified” to the “SDL News Dictionary” 
Regimental Command
Generic Armored Combat System
http://www-users.cs.umn.edu/~relander/regcom/index.html
Randi J. Relander wrote:
I varified the problem, it has nothing to do with hardware surfaces. The
SDL.dll in both the binary and development Win32 runtime packages cause soft
blits with SDL_RLEACCEL to crash. If I compile the source and generate my
own SDL.dll then everything works fine. I am using Visual C++ 6.0 on NT4,
haven’t had a chance to try it on Win98 yet. What is normally used to
generate the Win32 binaries?
I compiled them with VC++ 5.0 and received no warnings. I don’t think
I tested testsprite with it, so I’ll do that when I get a chance.
Compiler bug?
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Sam Lantinga wrote:
Randi J. Relander wrote:
The SDL.dll in both the binary and development
Win32 runtime packages [1.1.3] cause soft blits
with SDL_RLEACCEL to crash. [using VC6]
I compiled them with VC++ 5.0 and received no warnings.
I don’t think I tested testsprite with it, so I’ll do
that when I get a chance.
Is anyone else seeing this? I just got another report of this happening and
so far my only solution is to either have them remove the SDL_RLEACCEL or
compile their own set of SDL binaries.
Regimental Command
Generic Armored Combat System
http://regcom.sourceforge.net
Is anyone else seeing this? I just got another report of this happening and
so far my only solution is to either have them remove the SDL_RLEACCEL or
compile their own set of SDL binaries.
are you linking in SDL_Mixer by any chance?
-dv
Daniel wrote:
Randi J. Relander wrote:
Is anyone else seeing this? [crashes with SDL_RLEACCEL
accelerated blits and Win32 SDL-1.1.3 binaries]
are you linking in SDL_Mixer by any chance?
Nope, not that far yet It might have something to do with VC5/VC6
compatibility. The Win32 SDL-1.1.3 binaries were compiled with VC5 and all
reported crashes have been using VC6. (Don’t know if anyone has tried using
VC5 though) Doesn’t seem to be platform related since it does the same thing
on Win98 and NT4. Using SDL_RLEACCEL works fine if I compile my own
SDL-1.1.3 binaries using VC6.
Regimental Command
Generic Armored Combat System
http://regcom.sourceforge.net
there is problem with compiling SDL 1.1.3 with VC6: the result dll is smaller (253 952 bytes) by 17 408 bytes then one on the http://www.libsdl.org site (271 360), and with that smaller dll it is imposible to work with sound neither then with mixer or with smpeg
is that a bug o VC6 or SDl?
marex>> > Is anyone else seeing this? [crashes with SDL_RLEACCEL
accelerated blits and Win32 SDL-1.1.3 binaries]
are you linking in SDL_Mixer by any chance?
Nope, not that far yet It might have something to do with VC5/VC6
compatibility. The Win32 SDL-1.1.3 binaries were compiled with VC5 and all
reported crashes have been using VC6. (Don’t know if anyone has tried using
VC5 though) Doesn’t seem to be platform related since it does the same thing
on Win98 and NT4. Using SDL_RLEACCEL works fine if I compile my own
SDL-1.1.3 binaries using VC6.
Regimental Command
Generic Armored Combat System
http://regcom.sourceforge.net
Randi J. Relander wrote:
Sam Lantinga wrote:
Randi J. Relander wrote:
The SDL.dll in both the binary and development
Win32 runtime packages [1.1.3] cause soft blits
with SDL_RLEACCEL to crash. [using VC6]
I compiled them with VC++ 5.0 and received no warnings.
I don’t think I tested testsprite with it, so I’ll do
that when I get a chance.
Is anyone else seeing this? I just got another report
of this happening and so far my only solution is to
either have them remove the SDL_RLEACCEL or compile
their own set of SDL binaries.
It looks like the “map->sw_data->aux_data” surface variable is being used
for two different things. In one place it is being used as the RLE
compression buffer and in other places it looks like it is being used as
pointer storage for the “asm blitter” stuff. Could this have something to do
with it?
Sam, if you get a chance, could you generate a debug SDL-1.1.3 binary with
VC5? I need to trace into the RLE stuff to see what is going on and I can’t
get it to fail with either release or debug binaries compiled with VC6.
Argh!
Regimental Command
Generic Armored Combat System
http://regcom.sourceforge.net
Hey All,
I’m using mouse motion events to control the position of the viewpoint in a
2d top-down game. I’m running in windowed mode. However, using the xrel
and yrel data from the event union doesn’t give me a lot of control,
because the mouse cursor is constrained to the edges of the window, and
stops generating events at that edge. Is there anyway to have the mouse
motion unconstrained by the size of the surface? Does this problem go away
in fullscreen mode? Is there another solution?
Hope that’s clear, and thanks for the help
I’m using mouse motion events to control the position of the viewpoint in a
2d top-down game. I’m running in windowed mode. However, using the xrel
and yrel data from the event union doesn’t give me a lot of control,
because the mouse cursor is constrained to the edges of the window, and
stops generating events at that edge. Is there anyway to have the mouse
motion unconstrained by the size of the surface? Does this problem go away
in fullscreen mode? Is there another solution?
Good question. The X11 driver seems to do a mouse grab with the pointer
confined to the window; you could try changing that and see if that helps.
You can also try warping back the pointer to the center of the mouse
input interval (either the center of the screen or of the window).
I don’t know if the mouse speed over pixels is kept when changing
resolutions. A hack would be to turn off the pointer acceleration
(XChangePointerControl) if you are using X11.
Unfortunately, I’m developing in Windows at the moment… I guess I should
have mentioned that 
SDL_WarpMouse generates a mouse motion event, otherwise that would be an
easy solution. I suppose I could warp the mouse, then immediately empty
the event queue, and ignore the first mouse motion event, but I’m not sure
if this would work very well, esp. if it’s possible for another mouse
motion event to squeeze in between function calls… Is there any way to
warp the mouse without generating a mouse motion event?
I was hoping there was a crossplatform solution, as I’m planning on porting
this project to Linux and BeOS.
Thanks again,
At 10:32 PM 7/7/00 +0200, you wrote:>>I’m using mouse motion events to control the position of the viewpoint in a
2d top-down game. I’m running in windowed mode. However, using the xrel
and yrel data from the event union doesn’t give me a lot of control,
because the mouse cursor is constrained to the edges of the window, and
stops generating events at that edge. Is there anyway to have the mouse
motion unconstrained by the size of the surface? Does this problem go away
in fullscreen mode? Is there another solution?
Good question. The X11 driver seems to do a mouse grab with the pointer
confined to the window; you could try changing that and see if that helps.
You can also try warping back the pointer to the center of the mouse
input interval (either the center of the screen or of the window).
I don’t know if the mouse speed over pixels is kept when changing
resolutions. A hack would be to turn off the pointer acceleration
(XChangePointerControl) if you are using X11.
Unfortunately, I’m developing in Windows at the moment… I guess I should
have mentioned that
SDL_WarpMouse generates a mouse motion event, otherwise that would be an
easy solution. I suppose I could warp the mouse, then immediately empty
the event queue, and ignore the first mouse motion event, but I’m not sure
if this would work very well, esp. if it’s possible for another mouse
motion event to squeeze in between function calls… Is there any way to
warp the mouse without generating a mouse motion event?
I was hoping there was a crossplatform solution, as I’m planning on porting
this project to Linux and BeOS.
Thanks again,
I think the “official” SDL policy on this is:
if the mouse is grabbed (confined to the window)
AND the mouse cursor is not visible
then SDL will transparently auto-warp the mouse
without producing a mouse-move event.
I could be wrong, but this is the impression that I got
from Sam when this feature was being introduced.
ie. If you are using a particular mouse button to drag
around your 2d world, the button-down event would hide
the mouse, and the button-up event would show it…
everything else should work the same.
Regards,
-Loren
…
Great news! Get free KNXmail here!
http://www.knx1070.com
I think the “official” SDL policy on this is:
if the mouse is grabbed (confined to the window)
AND the mouse cursor is not visible
then SDL will transparently auto-warp the mouse
without producing a mouse-move event.
That’s correct. This is implemented on Win32 and Linux.
I don’t believe that BeOS allows you to grab the mouse in the same way,
and I haven’t taken a look at the way MacOS would do it.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Well, this will have to do for now :). Thanks for everyone’s help.
- Chris>> I think the “official” SDL policy on this is:
if the mouse is grabbed (confined to the window)
*AND* the mouse cursor is not visible
then SDL will transparently auto-warp the mouse
without producing a mouse-move event.
That’s correct. This is implemented on Win32 and Linux.
I don’t believe that BeOS allows you to grab the mouse in the same way,
and I haven’t taken a look at the way MacOS would do it.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
The return code for SDLNet_ResolveHost() has changed between these two
versions. It used to return 0 or NULL if it failed to resolve the
hostname. It is now returning 0 or NULL on success.
SDL_net.h does not describe the return codes for SDLNet_ResolveHost()
anymore, but it does describe the return codes for SDLNet_ResolveIP().
It wasn’t listed in the CHANGES file, so I figured I’d point it out in
case this was not supposed to change in 1.1.1.–
Brian