Two Questions: Threading and Framebuffer

Hi! At last I show up on the SDL mailing list too!

I Have two questions.

First: I have read some times ago on the fine SDL manual that using
multi-threading should be a good technique in order to make an SDL
game (since it should give consistent gameplay even with slow
machines)… now… I only saw single-threaded games, and I was
wondering if you could suggest a Multithreaded one. Do you know any?
BTW: I don’t mean how to initialize threads and stuff, that was
already in the wonderful manual, but how to deal with graphical
updates and the like…

By The Way: I couldn’t find the reference on the new edition of the
manual. Maybe was it in the pages that presented the SDL api on
libsdl.org?

The second: what are the prerequisites to run SDL applications on the
Framebuffer? I tried to run plaympeg on SDL 1.1.6 on a 2.2.16 kernel
with Matrox framebuffer, (didn’t check for sound however) but it came
up with a garbled screen. (If it may help, I know there is an apm
monitor sleep function I defined that shouldn’t be there, haven’t had
time to recompile the kernel… :frowning: ) and I tried to stop X11 and gpm
services…

Am I failing to do something else?

Hoping to be starting coding my sdl game, I salute you.
Byez!–
Davide Inglima, limaCAT - @Davide_Inglima
-> Kondara MNU/Linux Developer - http://www.kondara.org <-
-> Mount Is Not Unmount! <-

Davide Inglima wrote:

First: I have read some times ago on the fine SDL manual that using
multi-threading should be a good technique in order to make an SDL
game (since it should give consistent gameplay even with slow
machines)… now… I only saw single-threaded games, and I was
wondering if you could suggest a Multithreaded one. Do you know any?

The multithreading techniques problably begin refered to are decoupled
and semi-decoupled game loops. If you seek out these you will find some
example but they are really simple concepts. Unfortunitely I don;t have
time to describe them in detail but I am writting a library that sits on
top of SDL, and I plan to write a couple of examples using it, all of
which will use full decoupled game loops (try
http://sourceforge.net/projects/libksd/ in the near future).

My short description:

In the classic game loop you would:

  1. calc AI
  2. get input
  3. draw screen
  4. goto step 1

The problem with this is that on fast computers, the game loop would
operate to quickly. you could time it and tell it to skip frames to
when it runs to fast but this is a waste the more advanced processor.
So essenttially (remember this is a short description) what you do is
have two threads lilke this:

Thread one:

  1. calc AI
  2. get input
  3. go to step 1

Thread two:

  1. draw screen
  2. goto to step 1

This would allow the game to look BETTER on fast processors. The real
problem is to coordinate access to the data objects (like any other
multi-threaded application). I hope this helps you on your quest!!

-- David Snopek

David Snopek wrote:

So essenttially (remember this is a short description) what you do is
have two threads lilke this:

Thread one:

  1. calc AI
  2. get input
  3. go to step 1

Thread two:

  1. draw screen
  2. goto to step 1

This would allow the game to look BETTER on fast processors. The real
problem is to coordinate access to the data objects (like any other
multi-threaded application). I hope this helps you on your quest!!

-- David Snopek

All the documentation I can find on SDL says not to do this. I would like
to know if it is or is not possible/safe to have one thread get input and
one thread paint graphics.

mark kimsal wrote:

David Snopek wrote:

So essenttially (remember this is a short description) what you do is
have two threads lilke this:

Thread one:

  1. calc AI
  2. get input
  3. go to step 1

Thread two:

  1. draw screen
  2. goto to step 1

This would allow the game to look BETTER on fast processors. The real
problem is to coordinate access to the data objects (like any other
multi-threaded application). I hope this helps you on your quest!!

-- David Snopek

All the documentation I can find on SDL says not to do this. I would like
to know if it is or is not possible/safe to have one thread get input and
one thread paint graphics.

Yes it is possibly. It will probably not give you the results you might
expect, especially if the drawing thread can consume 100% CPU (most can
if you allow them to get the maximum frame rate).