Vista again

SDL Development
1

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 lists.libsdl.org wrote:

Send SDL mailing list submissions to
sdl at lists.libsdl.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
or, via email, send a message with subject or body ‘help’ to
sdl-request at lists.libsdl.org

You can reach the person managing the list at
sdl-owner at lists.libsdl.org

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 lists.libsdl.org
Message-ID: <20070301175720.f4146bae.alexis at rayforce.net>
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
surface.

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 )

Thanks,
Alexis

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
SDLNet_TCP_Accept
To: “A list for developers using the SDL library. (includes
SDL-announce)”
Message-ID:

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

Slightly off-topic (but I’m sending it to the list because everybody
should
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
are
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:
http://www.ibm.com/developerworks/library/s-buffer-defend.html<
http://www-128.ibm.com/developerworks/library/s-buffer-defend.html>

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 lists.libsdl.org
Message-ID: <45E7850C.6010003 at bigfoot.com>
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
Work.

–ryan.

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:

-------------------8<-------------------
segment _TEXT use32 align=4 class=CODE

global _setzm

_setzm:
lea eax, [esp - 4]
fstcw [eax]
or byte [eax], 4
fldcw [eax]
ret
-------------------8<-------------------

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.

Cheers,

Andre

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 lists.libsdl.org
Message-ID: <45E78C9E.9010801 at bigfoot.com>
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,
transparent)
– update the screen
screen.update()
– if left mouse button was pressed, break the loop
if left then
break
end
end

. 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!

Andre

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_Flip/SDL_UpdateRect?

Cheers,

Andre

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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,