Unexpected async reply

SDL Development
1

I have a game that runs some animations. Every once in a while I get
the unexpected async reply message. From what I have been reading this
is do to the fact that more then one ‘thread’ is trying to write to the
video surface.

My questions are 1) do SDL_Timers create there own ‘threads’? 2) is
there a way to detect if the display surface is locked so as not to try
and draw the graphic? And 3) this doesn’t appear to happen when I use
the hardware surfaces, why?

Thanks,
Walt

2

I have a game that runs some animations. Every once in a while I get
the unexpected async reply message. From what I have been reading this
is do to the fact that more then one ‘thread’ is trying to write to the
video surface.

My questions are 1) do SDL_Timers create there own ‘threads’?

They may, depending on the underlying OS. In general you MUST NOT do
graphics in a timer callback function.

	Bob PendletonOn Sat, 2004-04-10 at 08:51, Walter Crowley wrote:
  1. is
    there a way to detect if the display surface is locked so as not to try
    and draw the graphic? And 3) this doesn’t appear to happen when I use
    the hardware surfaces, why?

Thanks,
Walt

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+

3

I have a game that runs some animations. Every once in a while I get
the unexpected async reply message. From what I have been reading this
is do to the fact that more then one ‘thread’ is trying to write to the
video surface.

My questions are 1) do SDL_Timers create there own ‘threads’?

Maybe this leads to beyond the scope of this discussion group, and
please don’t take this as me questioning the logic, but why not use
graphics in a timer function? It seems that using the SDL_Timers are
great tools for animations at a particular speeds.

(I am using Fedora Core 2)On Wed, 2004-11-10 at 18:59, Bob Pendleton wrote:

On Sat, 2004-04-10 at 08:51, Walter Crowley wrote:
They may, depending on the underlying OS. In general you MUST NOT do
graphics in a timer callback function.

  Bob Pendleton
  1. is
    there a way to detect if the display surface is locked so as not to try
    and draw the graphic? And 3) this doesn’t appear to happen when I use
    the hardware surfaces, why?

Thanks,
Walt

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

4

I have a game that runs some animations. Every once in a while I get
the unexpected async reply message. From what I have been reading this
is do to the fact that more then one ‘thread’ is trying to write to the
video surface.

My questions are 1) do SDL_Timers create there own ‘threads’?

Maybe this leads to beyond the scope of this discussion group, and
please don’t take this as me questioning the logic, but why not use
graphics in a timer function? It seems that using the SDL_Timers are
great tools for animations at a particular speeds.

You don’t do it because it doesn’t work. Only the thread that
initialized SDL can access the graphics. Timers can run in their own
thread. Therefore you can’t do graphics from timers.

You use timers to send custom events that are processed in the main
event loop. When the timer fires it sends an event (this is guaranteed
to work). Then when your event loop reads the event you do the graphics
associated with the event.

	Bob PendletonOn Sat, 2004-04-10 at 11:49, Walter Crowley wrote:

On Wed, 2004-11-10 at 18:59, Bob Pendleton wrote:

On Sat, 2004-04-10 at 08:51, Walter Crowley wrote:

(I am using Fedora Core 2)

They may, depending on the underlying OS. In general you MUST NOT do
graphics in a timer callback function.

  Bob Pendleton
  1. is
    there a way to detect if the display surface is locked so as not to try
    and draw the graphic? And 3) this doesn’t appear to happen when I use
    the hardware surfaces, why?

Thanks,
Walt

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+

5

Thanks. I think I understand more now. I will make the adjustments and
see how these work.

WaltOn Wed, 2004-11-10 at 23:50, Bob Pendleton wrote:

On Sat, 2004-04-10 at 11:49, Walter Crowley wrote:

On Wed, 2004-11-10 at 18:59, Bob Pendleton wrote:

On Sat, 2004-04-10 at 08:51, Walter Crowley wrote:

I have a game that runs some animations. Every once in a while I get
the unexpected async reply message. From what I have been reading this
is do to the fact that more then one ‘thread’ is trying to write to the
video surface.

My questions are 1) do SDL_Timers create there own ‘threads’?

Maybe this leads to beyond the scope of this discussion group, and
please don’t take this as me questioning the logic, but why not use
graphics in a timer function? It seems that using the SDL_Timers are
great tools for animations at a particular speeds.

You don’t do it because it doesn’t work. Only the thread that
initialized SDL can access the graphics. Timers can run in their own
thread. Therefore you can’t do graphics from timers.

You use timers to send custom events that are processed in the main
event loop. When the timer fires it sends an event (this is guaranteed
to work). Then when your event loop reads the event you do the graphics
associated with the event.

  Bob Pendleton

(I am using Fedora Core 2)

They may, depending on the underlying OS. In general you MUST NOT do
graphics in a timer callback function.

  Bob Pendleton
  1. is
    there a way to detect if the display surface is locked so as not to try
    and draw the graphic? And 3) this doesn’t appear to happen when I use
    the hardware surfaces, why?

Thanks,
Walt

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

6

Bob Pendleton wrote:> On Sat, 2004-04-10 at 11:49, Walter Crowley wrote:

On Wed, 2004-11-10 at 18:59, Bob Pendleton wrote:

On Sat, 2004-04-10 at 08:51, Walter Crowley wrote:

I have a game that runs some animations. Every once in a while I get
the unexpected async reply message. From what I have been reading this
is do to the fact that more then one ‘thread’ is trying to write to the
video surface.

My questions are 1) do SDL_Timers create there own ‘threads’?

Maybe this leads to beyond the scope of this discussion group, and
please don’t take this as me questioning the logic, but why not use
graphics in a timer function? It seems that using the SDL_Timers are
great tools for animations at a particular speeds.

You don’t do it because it doesn’t work. Only the thread that
initialized SDL can access the graphics. Timers can run in their own
thread. Therefore you can’t do graphics from timers.

You use timers to send custom events that are processed in the main
event loop. When the timer fires it sends an event (this is guaranteed
to work). Then when your event loop reads the event you do the graphics
associated with the event.

  Bob Pendleton

(I am using Fedora Core 2)

They may, depending on the underlying OS. In general you MUST NOT do
graphics in a timer callback function.

  Bob Pendleton
  1. is
    there a way to detect if the display surface is locked so as not to try
    and draw the graphic? And 3) this doesn’t appear to happen when I use
    the hardware surfaces, why?

yes. lock() passes 1 back if it locks. just keep track if your locks
succeeded or not.

–

michael bernstein

Lead Developer
Simoniac Studios
http://www.simoniac.com

email: @Michael_Bernstein
web: http://www.michaelbernstein.info