Vista again

Hi guys
I did not get a reply on the vista crash when exiting, have you heard
of anyone having a similar problem? is it an open bug in SDL on vista?

TrishOn 3/2/07, sdl-request at wrote:

Send SDL mailing list submissions to
sdl at

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body ‘help’ to
sdl-request at

You can reach the person managing the list at
sdl-owner at

When replying, please edit your Subject line so it is more specific
than “Re: Contents of SDL digest…”

Today’s Topics:

  1. Re: N buffering and access to the hidden video surface
    (Alexis Naveros)
  2. (Off Topic) Re: problem with using socket from SDL_Net
    SDLNet_TCP_Accept (John Silicon)
  3. Re: Flickering and division by zero in Windows
    (Andre de Leiradella)
  4. Re: Flickering and division by zero in Windows
    (Andre de Leiradella)

Message: 1
Date: Thu, 01 Mar 2007 17:57:20 -0500
From: Alexis Naveros
Subject: Re: [SDL] N buffering and access to the hidden video surface
To: sdl at
Message-ID: <20070301175720.f4146bae.alexis at>
Content-Type: text/plain; charset=US-ASCII

Hi Ryan,

How much overhead does the extra copy cause here?

The difference between having to copy 300mb or 600mb around per second is
not negligible, plus the cost of receiving and decompressing all the data.
Briefly, the cheaper operations are, the more frames can be pushed per
second… so I would prefer to avoid any unnecessary waste.

I don’t think it would be something we’d add to SDL itself, but you
could probably wedge this in there fairly easily.

I think a function could exist to supply a different “shadow” surface for
the “screen”, replacing current_video->shadow, assuming it is of the same
resolution and format. SDL_UpdateRect() could then be used to read from this
new shadow suface and the previous one would become a regular independant

Do you see any problem with such a feature? Should I understand that there
wouldn’t be interest in such a patch? ( or anything equivalent to provide
similar functionality )


Message: 2
Date: Thu, 1 Mar 2007 16:17:54 -0700
From: “John Silicon”
Subject: [SDL] (Off Topic) Re: problem with using socket from SDL_Net
To: “A list for developers using the SDL library. (includes

Content-Type: text/plain; charset=“iso-8859-1”

Slightly off-topic (but I’m sending it to the list because everybody
know this!):

When using *scanf to read a string, always make sure you use the "%NNNs"
format specifier, where ‘NNN’ is the length of the character buffer you
passing in. Especially when we’re talking about networking
code. Laziness
and being less-than-specific are some of the quickest ways to creating
buffer-overflow bugs and vulnerabilities (the only quicker way is to
purposefully create one).

Here’s a link to the best list of anti-buffer-overflow tips I’ve found:<>

Message: 3
Date: Thu, 01 Mar 2007 22:59:40 -0300
From: Andre de Leiradella
Subject: Re: [SDL] Flickering and division by zero in Windows
To: sdl at
Message-ID: <45E7850C.6010003 at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

  1. Is the FPU control register something I can change just by reading
    it, and’ing or or’ing with a mask and writing back the new value?

Yes, but probably not in Lua directly. There’s an x86/amd64 assembly
instruction for reading and writing that register (and, from C, there’s
usually a non-standard function called _controlfp() or something similar
to do the same).

If you can’t figure out what’s changing the control word, or you can’t
stop it from changing it, forcing it back yourself will probably Just


I was already playing with fstcw and fldcw when I received your message.
For the records, to disable division by zero exceptions one can use

_control87(MCW_EM, EM_ZERODIVIDE);

Also for the records, here is a small assembler function that disables
the same exception for those who doesn’t have _control87 nor _controlfp:

segment _TEXT use32 align=4 class=CODE

global _setzm

lea eax, [esp - 4]
fstcw [eax]
or byte [eax], 4
fldcw [eax]

It can be compiled with nasm.

The strange part is that no function is resetting the flag, it already
comes zeroed when the program starts! I imagine that it must be
something from the bootstrap code… Oh well, using _control87 at the
beginning of the program solved the issue.

Thanks a lot Ryan for pointing me to both fldcw and _control87.



Message: 4
Date: Thu, 01 Mar 2007 23:31:58 -0300
From: Andre de Leiradella
Subject: Re: [SDL] Flickering and division by zero in Windows
To: sdl at
Message-ID: <45E78C9E.9010801 at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Lua code? Won’t help much… but here it goes:

– set the video mode
local screen = image_lib.set_video(800, 600)
– load and resize the background
local background = image_lib.load(‘background.png’)
background = background.resize(screen.width, screen.height)
– evaluates a half-transparent black color
local transparent = image_lib.color(0, 0, 0, 128)
– loop until the user presses the left mouse button
while true do
– query the mouse
x, y, left = input_lib.mouse()
– blit the background to the screen, covering all pixels
background.blit(screen, 0, 0)
– fill a square with the half-transparent black
screen.filled_rect(10, 10, screen.width - 10, screen.width - 10,
– update the screen
– if left mouse button was pressed, break the loop
if left then

. screen is obtained via SDL_SetVideoMode
. background is an 8bpp image loaded via IMG_LoadImage and resized via
SDL_ResizeXY from Dave Olsen et al.
. the transparent color is obtained combining red, green, blue and alpha
values into a single Uint32
. input_lib.mouse queries the mouse using SDL_GetMouseState
. background.blit blits the background image over another surface, in
this a screen, using SDL_BlitSurface
. screen.update() calls either SDL_Flip or SDL_UpdateRect, I tried both
in my tests

Thanks for the interest!


Well, I don’t know what else to do. I was thinking that the video
drivers could be broken in some way that the screen update wasn’t
waiting for the vertical retrace, so I tried the program in another
machine with a completely different hardware - video board included.
What made me think about it is the fact that only the rectangle
flickers, the background image doesn’t. Do SDL_Flip and SDL_UpdateRect
wait for vertical retraces? If not, is it possible to turn it on?

But the result was the same, the rectangle flicks. I removed the 8-bpp
code, changed boxColor to SDL_FillRect, tried many combinations of the
flags in SDL_SetVideoMode and yet the flicker appears.

I’ll put debug statements throughout my code to “translate” the Lua
program into a series of calls to SDL and friends, maybe I can find
something in them. I’m pretty confident that my code is ok though, since
most functions of the Lua glue just take the arguments, locks the
surface if necessary, do their work, unlocks the surface and returns.

Does anybody ever implemented a double buffer scheme to use with SDL? I
mean, creating a surface just equal to the screen (size and bpp),
drawing everything to it and then bliting it to the screen and calling



SDL mailing list
SDL at

End of SDL Digest, Vol 3, Issue 3

In a time of universal deceit, telling the truth is a revolutionary act.

Trish & Thy also Available on

Skype tranmaithy63,