Theory - Graphics Server for threaded apps

Greetings all!

I was thinking about the limitations that some systems have regarding threads
and drawing. That the main thread has to be the one that draws, or else the one
that initializes the functions, or whatnot.

So I started toying with an idea. The idea is pretty simple. Have a Drawing
queue with positions, colors, and a threadID. Each time a child thread needs to
draw something, it checks if it is already in the queue (hasn’t been drawn yet)
If it hasn’t, it just locks the queue and then adds the item.

The main thread then locks the queue, draws everything, then zeros it out.

With this method, you can use the SDL_PumpEvent, and SDL_PeekEvent to check
events in other threads.

With this method, you could have threads that handle GUI/HUD, Networking,
game/program display, sound, etc.

As long as it is done right all the main thread would do is handling the drawing
and pumping of events and offloads all other computations to threads, hopefully
handling multicore processors better.

I have a demo app if anyone is interested.

  • Micah

Yep, that technique works very well. It’s been in text books for about
40 years now, so it is well documented and well understood. It
suffers from the cost of having to search the operation queues for
existing commands. It is best to either not search and bear the small
cost of repeated operations or to use scene graphs on the renderer
side. Scene graphs can be edited from any thread and serve as a shared
memory of the current state of that part of the display. When the
renderer wants to render it just walks the scene graph. You can have
locks on low level items in the graph so that rendering and editing
can actually take place in parallel. Another thing I like about scene
graphs is that you can give each object access to only its own items
in the graph. Lots of other advantages too.

If you came up with this completely on your own, then congratulations
to you. It isn’t easy to come up with good answers to this problem. It
takes real mental effort to do it. On the other hand, I learned this
technique in school in the early 1970s from people who had been using
it for a long time. I really wish people would take a few years to
read the basic literature and then take on problems that are new and
unsolved rather than coming up with the same good solution for an
ancient and well understood problem. If you have the kind of brains
necessary to solve a problem like this, what kind of amazing things
could you do if you weren’t wasting time rediscovering solutions to
problems that were solved 40 years ago?

Bob Pendleton

P.S.

Old saying, “a year in the lab will often save a week in the library”.
I learned that one from my graduate adviser shortly after I
rediscovered Grosch’s law. He wasn’t giving me a hard time for finding
it. He was giving me a hard time for thinking that I might be the
first person to have noticed it. Grosh wrote it down in 1965. I
noticed it in 1983.On Tue, Jul 28, 2009 at 11:20 AM, Micah Brening<micah.brening at gmail.com> wrote:

Greetings all!

I was thinking about the limitations that some systems have regarding threads
and drawing. ?That the main thread has to be the one that draws, or else the one
that initializes the functions, or whatnot.

So I started toying with an idea. ?The idea is pretty simple. ?Have a Drawing
queue with positions, colors, and a threadID. ?Each time a child thread needs to
draw something, it checks if it is already in the queue (hasn’t been drawn yet)
?If it hasn’t, it just locks the queue and then adds the item.

The main thread then locks the queue, draws everything, then zeros it out.

With this method, you can use the SDL_PumpEvent, and SDL_PeekEvent to check
events in other threads.

With this method, you could have threads that handle GUI/HUD, Networking,
game/program display, sound, etc.

As long as it is done right all the main thread would do is handling the drawing
and pumping of events and offloads all other computations to threads, hopefully
handling multicore processors better.

I have a demo app if anyone is interested.

  • Micah

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


±----------------------------------------------------------

Bob Pendleton <bob pendleton.com> writes:

Yep, that technique works very well. It’s been in text books for about
40 years now, so it is well documented and well understood. It
suffers from the cost of having to search the operation queues for
existing commands. It is best to either not search and bear the small
cost of repeated operations or to use scene graphs on the renderer
side. Scene graphs can be edited from any thread and serve as a shared
memory of the current state of that part of the display. When the
renderer wants to render it just walks the scene graph. You can have
locks on low level items in the graph so that rendering and editing
can actually take place in parallel. Another thing I like about scene
graphs is that you can give each object access to only its own items
in the graph. Lots of other advantages too.

If you came up with this completely on your own, then congratulations
to you. It isn’t easy to come up with good answers to this problem. It
takes real mental effort to do it. On the other hand, I learned this
technique in school in the early 1970s from people who had been using
it for a long time. I really wish people would take a few years to
read the basic literature and then take on problems that are new and
unsolved rather than coming up with the same good solution for an
ancient and well understood problem. If you have the kind of brains
necessary to solve a problem like this, what kind of amazing things
could you do if you weren’t wasting time rediscovering solutions to
problems that were solved 40 years ago?

Bob Pendleton

P.S.

Old saying, “a year in the lab will often save a week in the library”.
I learned that one from my graduate adviser shortly after I
rediscovered Grosch’s law. He wasn’t giving me a hard time for finding
it. He was giving me a hard time for thinking that I might be the
first person to have noticed it. Grosh wrote it down in 1965. I
noticed it in 1983.

Well considering I’m 100% self taught, too poor for schooling, and firmly
believe in looking at the code rather than the documentation, I didn’t know that
this was figured out already.

However, I do know that there have been several posts on here asking about
drawing on different threads and I never once heard anyone mention this as a
possibility. All that was ever said was “Drawing has to be done on the main
thread” and that was it. So, yes, while drawing is forced onto the main thread,
why can’t graphic processing be done on others?

So the idea has already been worked on. Has it been applied to SDL? Is there a
framework for it already writen? If so, I haven’t seen it, and no one was
suggesting it.

If I decide to pursue developing this, I guess I’ll do research on their
theories. And if nothing else, it’ll be fun for my own personal development.

Thanks for the heads up,

Micah

ancient and well understood problem. If you have the kind of brains
necessary to solve a problem like this, what kind of amazing things
could you do if you weren’t wasting time rediscovering solutions to
problems that were solved 40 years ago?

While reading the existing literature is important, reinventing the
wheel (and sometimes, failing to reinvent the wheel) is often the best
way to learn.

–ryan.

“Graphics” is quite easy to parallelise. Modern graphics cards have
hundreds of cores that execute relatively independantly. Recent
versions of DirectX can be initialised in a multi-threaded mode
(although I haven’t looked into great detail what this means). OpenGL
contexts can be shared across multiple threads, where each thread can
use some kind of MakeCurrent() call, and then do its drawing.

The problem is hinted at when you said “firmly believe in looking at
the code rather than the documentation”. There are a number of issues
with this:

  • Firstly, most API users are concerned with getting their
    game/program done. Not reading a vast code base like SDL. They rely on
    the documentation to decide what they can or cannot do.

  • Secondly, the code isn’t finished. It can be added to in the future,
    and more platforms can be supported. Only last year the iPhone and the
    Nintendo DS got SDL backends.

SDL needs to give freedom to the implementation, which allows for good
performance on many platforms. For instance, SDL surfaces may not be
in system memory, they may be in hardware memory. A SDL_Surface might
be the screen buffer. There may be restrictions on which threads may
access these special surfaces, and whether they can be accessed in
parallel.

AFAIK, SDL’s restriction comes mainly from Windows. However, for
writing cross platform API you must take the lowest common
denominator. In this case, SDL’s documentation insists that all
graphics operations must be in the main thread. However I am sure
there are platforms where this isn’t true.

When people ask about drawing in multiple threads, they are wondering
about what guarantees can SDL make about which functions are safe to
use in a multi-threaded fashion, across a host of platforms. Cross
platform issues are very important to SDL, many SDL users will want to
port their application to new platforms eventually.

Going forward to SDL 1.3, I wonder if more guarantees can be added.
The API separates hardware buffers into “textures” and software
buffers into what we know of as surfaces. Assuming one is not using
the legacy interface or requesting hardware surfaces, can we get
documented guarantees that SDL_BlitSurface() (or other functions) can
be called from any thread.On Tue, Jul 28, 2009 at 8:15 PM, Micah Brening<micah.brening at gmail.com> wrote:

Bob Pendleton <bob pendleton.com> writes:

Well considering I’m 100% self taught, too poor for schooling, and firmly
believe in looking at the code rather than the documentation, I didn’t know that
this was figured out already.

However, I do know that there have been several posts on here asking about
drawing on different threads and I never once heard anyone mention this as a
possibility. ?All that was ever said was “Drawing has to be done on the main
thread” and that was it. ?So, yes, while drawing is forced onto the main thread,
why can’t graphic processing be done on others?

So the idea has already been worked on. ?Has it been applied to SDL? ?Is there a
framework for it already writen? ?If so, I haven’t seen it, and no one was
suggesting it.

If I decide to pursue developing this, I guess I’ll do research on their
theories. ?And if nothing else, it’ll be fun for my own personal development.

Thanks for the heads up,

Micah


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

Brian <brian.ripoff gmail.com> writes:

“Graphics” is quite easy to parallelise. Modern graphics cards have
hundreds of cores that execute relatively independantly. Recent
versions of DirectX can be initialised in a multi-threaded mode
(although I haven’t looked into great detail what this means). OpenGL
contexts can be shared across multiple threads, where each thread can
use some kind of MakeCurrent() call, and then do its drawing.

The problem is hinted at when you said “firmly believe in looking at
the code rather than the documentation”. There are a number of issues
with this:

  • Firstly, most API users are concerned with getting their
    game/program done. Not reading a vast code base like SDL. They rely on
    the documentation to decide what they can or cannot do.

  • Secondly, the code isn’t finished. It can be added to in the future,
    and more platforms can be supported. Only last year the iPhone and the
    Nintendo DS got SDL backends.

SDL needs to give freedom to the implementation, which allows for good
performance on many platforms. For instance, SDL surfaces may not be
in system memory, they may be in hardware memory. A SDL_Surface might
be the screen buffer. There may be restrictions on which threads may
access these special surfaces, and whether they can be accessed in
parallel.

AFAIK, SDL’s restriction comes mainly from Windows. However, for
writing cross platform API you must take the lowest common
denominator. In this case, SDL’s documentation insists that all
graphics operations must be in the main thread. However I am sure
there are platforms where this isn’t true.

When people ask about drawing in multiple threads, they are wondering
about what guarantees can SDL make about which functions are safe to
use in a multi-threaded fashion, across a host of platforms. Cross
platform issues are very important to SDL, many SDL users will want to
port their application to new platforms eventually.

Going forward to SDL 1.3, I wonder if more guarantees can be added.
The API separates hardware buffers into “textures” and software
buffers into what we know of as surfaces. Assuming one is not using
the legacy interface or requesting hardware surfaces, can we get
documented guarantees that SDL_BlitSurface() (or other functions) can
be called from any thread.

Brian,

Thanks for the information!

Ryan had posted jut a bit ago saying he’d like the focus to be on MacOSX, Linux,
and Win32. So as long as those three “main” OSs support it, it seems it should
be at least “enabled” in SDL.

But from what I understood from your message, OpenGL already supports it, so if
you use SDL for window management, event handling, graphics loading, etc. Then
you can call OpenGL routines from any thread.

My next question would be, is it permitted to load and share surfaces from
threads, or does a surface have to be loaded from the main? Doesn’t seem like
it would need to be. But I figured it’d be best to ask.

Thanks again for the info!

  • Micah

You say this, but not everyone has access to the literature or knows where to start; I bought my first graphics programming book in 1995 which had a wealth of information on tweaking settings in DOS character modes via the BIOS but was abysmal when it came to actual graphics techniques (and was one of those ‘C++’ books with little concept of classes or OOP) to a point that even my uninformed eyes could see when I had a proper look. Just an example of where unguided learning can end up.

Even now I find there are times where I know what I’m doing has already been done but I just can’t find the literature despite having a number of books on graphics programming and a variety of places I can ask.

You say now that using a scene graph would be superior but which are the best websites or books to read to learn how this should be done? How does anyone know these exist without some guidance? Sure, these things can be looked up (on Wikipedia for a start) but given the amount of absolute dross that somehow still manages to get published (like my favourite bugbear Numerical Recipes) it’s still going to be an uphill struggle without some guidance. I had the advantage of lecture notes from a very specific degree course to get me started off on things but even then some things are somewhat lost to me.— On Tue, 7/28/09, Bob Pendleton wrote:

From: Bob Pendleton
Subject: Re: [SDL] Theory - Graphics Server for threaded apps
To: “A list for developers using the SDL library. (includes SDL-announce)”
Date: Tuesday, July 28, 2009, 7:05 PM
If you came up with this completely on your own, then
congratulations
to you. It isn’t easy to come up with good answers to this
problem. It
takes real mental effort to do it. On the other hand, I
learned this
technique in school in the early 1970s from people who had
been using
it for a long time. I really wish people would take a few
years to
read the basic literature and then take on problems that
are new and
unsolved rather than coming up with the same good
solution for an
ancient and well understood problem. If you have the kind
of brains
necessary to solve a problem like this, what kind of
amazing things
could you do if you weren’t wasting time rediscovering
solutions to
problems that were solved 40 years ago?

I think the triple buffering concept is better maintain three pointers
to scene graph roots, one which is locked for use by the display, one
which is locked for use by code that modifies the scene graph, and one
free one which may be taken up either as the target of the next
frame’s scene graph, or taken up as the next scene graph to render to
the display. This adds a little memory, and throws away some of your
computing resources, but for games decreases latency and increases
throughput.On Tue, Jul 28, 2009 at 3:05 PM, Bob Pendleton wrote:

Scene graphs can be edited from any thread and serve as a shared
memory of the current state of that part of the display. When the
renderer wants to render it just walks the scene graph. You can have
locks on low level items in the graph so that rendering and editing
can actually take place in parallel.


http://codebad.com/

Oh, and use three allocation pools.On Wed, Jul 29, 2009 at 2:58 AM, Donny Viszneki<@Donny_Viszneki> wrote:

On Tue, Jul 28, 2009 at 3:05 PM, Bob Pendleton wrote:

Scene graphs can be edited from any thread and serve as a shared
memory of the current state of that part of the display. When the
renderer wants to render it just walks the scene graph. You can have
locks on low level items in the graph so that rendering and editing
can actually take place in parallel.

I think the triple buffering concept is better maintain three pointers
to scene graph roots, one which is locked for use by the display, one
which is locked for use by code that modifies the scene graph, and one
free one which may be taken up either as the target of the next
frame’s scene graph, or taken up as the next scene graph to render to
the display. This adds a little memory, and throws away some of your
computing resources, but for games decreases latency and increases
throughput.


http://codebad.com/


http://codebad.com/

Bob Pendleton <bob pendleton.com> writes:

Yep, that technique works very well. It’s been in text books for about
40 years now, so it is well documented and well understood. It
suffers from the cost of having to search the operation queues for
existing commands. It is best to either not search and bear the small
cost of repeated operations or to use scene graphs on the renderer
side. Scene graphs can be edited from any thread and serve as a shared
memory of the current state of that part of the display. When the
renderer wants to render it just walks the scene graph. You can have
locks on low level items in the graph so that rendering and editing
can actually take place in parallel. Another thing I like about scene
graphs is that you can give each object access to only its own items
in the graph. Lots of other advantages too.

If you came up with this completely on your own, then congratulations
to you. It isn’t easy to come up with good answers to this problem. It
takes real mental effort to do it. On the other hand, I learned this
technique in school in the early 1970s from people who had been using
it for a long time. I really wish people would take a few years to
read the basic literature and then take on problems that are new and
unsolved rather than coming up with the same good solution for an
ancient and well understood problem. If you have the kind of brains
necessary to solve a problem like this, what kind of amazing things
could you do if you weren’t wasting time rediscovering solutions to
problems that were solved 40 years ago?

Bob Pendleton

P.S.

Old saying, “a year in the lab will often save a week in the library”.
I learned that one from my graduate adviser shortly after I
rediscovered Grosch’s law. He wasn’t giving me a hard time for finding
it. He was giving me a hard time for thinking that I might be the
first person to have noticed it. Grosh wrote it down in 1965. I
noticed it in 1983.

Well considering I’m 100% self taught, too poor for schooling, and firmly
believe in looking at the code rather than the documentation, I didn’t know that
this was figured out already.

That statement makes me very angry, no one should be to poor to have
access to an education.

OTOH, you’re doing really well on your own.

However, I do know that there have been several posts on here asking about
drawing on different threads and I never once heard anyone mention this as a
possibility. ?All that was ever said was “Drawing has to be done on the main
thread” and that was it. ?So, yes, while drawing is forced onto the main thread,
why can’t graphic processing be done on others?

AFAIK no one ever said that graphics processing couldn’t be done in
other threads. Drawing and graphics processing are two very different
things. Drawing is a subset of graphics processing.

So the idea has already been worked on. ?Has it been applied to SDL? ?Is there a
framework for it already writen? ?If so, I haven’t seen it, and no one was
suggesting it.

Does it matter? Using a queue to communicate between threads is as old
as computers. In fact, it predates computers. We got it from watching
how the real world works. And, yes, I and many other have suggested it
over the last several years. How long have you been on the list?

If I decide to pursue developing this, I guess I’ll do research on their
theories. ?And if nothing else, it’ll be fun for my own personal development.

Yes, both the research and the development will be good for you.

Thanks for the heads up,

You are welcome, stay in touch.

Bob PendletonOn Tue, Jul 28, 2009 at 2:15 PM, Micah Brening<micah.brening at gmail.com> wrote:

Micah


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


±----------------------------------------------------------

You say this, but not everyone has access to the literature or knows where to start;

Correct. That is what schools are for. Of course, a lot of schools are
not very good.

I bought my first graphics programming book in 1995 which had a
wealth of information on tweaking settings in DOS character modes via
the BIOS but was abysmal when it came to actual graphics techniques
(and was one of those ‘C++’ books with little concept of classes or
OOP) to a point that even my uninformed eyes could see when I had a
proper look. Just an example of where unguided learning can end up.

Yep, I feel your pain and frustration. The thing is the book you
bought was a book on platform specific material for coding DOS games,
not a book on computer graphics. Looking at my book shelf I see all
the graphic programming gems books, “Computer Graphics” Foley, Van
Dam, et al., Jim Blinn’s books, “Mathematics for 3D Game Programminng
& Computer Graphics”, and the venerable “A Programmers Geometry”.
Those are books on computer graphics. I have several shelves full of
books on platform specific topics.

And, if you want the details of C++ read books on C++. If you want to
learn about OOP, read books on OOP. C++ doesn’t have all that much to
do with OOP and IMHO doesn’t do a very good job with it, though it has
gotten better through each new incarnation. Remember, C++ was an
attempt to bolt objects on to C. C++ provides classes as an extension
to C. It isn’t all that OO in and of itself.

Even now I find there are times where I know what I’m doing has already been done but I just can’t find the literature despite having a number of books on graphics programming and a variety of places I can ask.

Yep, I get that. Often the material you need is not on the web. And,
it doesn’t show up in book stores in the local mall either. All the
good stuff on basic algorithms was published long before the web
existed. Start out by finding a copy of the USENET graphics FAQ. It’s
out there, easy to find. Then learn to search the ACM Siggraph
literature data base and get used to paying for copies of papers. IEEE
is another good place to search for references. Once you have titles,
authors, and abstracts you can search the web using keywords from the
papers and find related free materials on the web. The best stuff
seems to have been published starting in the late '60s and ending in
the middle '80s. When I was first looking for books on computer
graphics I would look up what text books were being used for the
subject at major Universities with recognized computer graphics
research programs and buy those books.

You say now that using a scene graph would be superior but which are the best websites or books to read to learn how this should be done? How does anyone know these exist without some guidance?

They know they exist by reading books and journals on computer
graphics. Not books on how to write DOS games or even Windows Games.
As for guidance, what did you just get in my last posting on this
list? Guidance. That’s what it was, Guidance.

Sure, these things can be looked up (on Wikipedia for a start) but
given the amount of absolute dross that somehow still manages to get
published (like my favourite bugbear Numerical Recipes)

One of my favorite numerical books, what do you dislike about it?
Anyway, Wikipedia is one of my favorite starting places for doing
research. It gives you the keywords and might link to a few key web
sites. From there you work your way out to books, papers, and more
websites. If you want to learn about scene graph systems plan to spend
at least a few months to get the key ideas. And, get over the idea
that there is a “best” way. That idea leads to madness.

it’s still going to be an uphill struggle without some guidance. I
had the advantage of lecture notes from a very specific degree course
to get me started off on things but even then some things are somewhat
lost to me.

Take a look at open courseware on the net. MIT is working to make all
of the materials for all of its classes available for free online. Try
typing “open courseware consortium” into google and working from
there.

As for “lost to me” so what? If can get through a class without having
something that was “lost” to you then you should have started with a
harder class. Do you actually expect to understand everything the
first time you look at it?

Bob PendletonOn Tue, Jul 28, 2009 at 4:38 PM, Paul Duffy wrote:

— On Tue, 7/28/09, Bob Pendleton <@Bob_Pendleton> wrote:

From: Bob Pendleton <@Bob_Pendleton>
Subject: Re: [SDL] Theory - Graphics Server for threaded apps
To: “A list for developers using the SDL library. (includes SDL-announce)”
Date: Tuesday, July 28, 2009, 7:05 PM
If you came up with this completely on your own, then
congratulations
to you. It isn’t easy to come up with good answers to this
problem. It
takes real mental effort to do it. On the other hand, I
learned this
technique in school in the early 1970s from people who had
been using
it for a long time. I really wish people would take a few
years to
read the basic literature and then take on problems that
are new and
unsolved rather than coming up with the same good
solution for an
ancient and well understood problem. If you have the kind
of brains
necessary to solve a problem like this, what kind of
amazing things
could you do if you weren’t wasting time rediscovering
solutions to
problems that were solved 40 years ago?


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


±----------------------------------------------------------

Bob Pendleton <bob pendleton.com> writes:

That statement makes me very angry, no one should be to poor to have
access to an education.

I completely agree. However, the fact remains that I’m at a point where I
cannot afford it on my own, and I’m being denied assistance. So the best I can
do is make use of the Internet.

How long have you been on the list?

Over two years, but I am known to overlook posts from time to time. Not to
mention, I just use the web viewer for the newsgroup, so when someone posts on
an older thread it is easy to slip by.

Yep, I feel your pain and frustration. The thing is the
book you
bought was a book on platform specific material for coding
DOS games,
not a book on computer graphics.

Oh no, I meant it was only good at that bit. It did also have material on scanline rendering, phong and gouraud shading and even a little bit on raytracing. If you wanted to know incredibly slow and inefficient ways to do these things you could use that book.

Looking at my book shelf I
see all
the graphic programming gems books, "Computer Graphics"
Foley, Van
Dam, et al., Jim Blinn’s books, “Mathematics for 3D Game
Programminng
& Computer Graphics”, and the venerable “A Programmers
Geometry”.
Those are books on computer graphics. I have several
shelves full of
books on platform specific topics.

Yes, the Foley, Van Dam, et al book is canonical as are others I have and even apparently platform specific books such as “Tricks of The 3D Game Programming Gurus” can be very useful for generic information (in fact so far as I’ve read, despite using DirectX the 3D graphics are done entirely in software, it’s actually quite useless for Direct3D).

And, if you want the details of C++ read books on C++. If
you want to
learn about OOP, read books on OOP.

I’m better with Java at this moment than I am with C++ but one of the things I like about C++ is that it’s not a pure OOP language and the conventions which can be so limiting in a pure OOP language can be ignored if appropriate.

Yep, I get that. Often the material you need is not on the
web. And,
it doesn’t show up in book stores in the local mall either.
All the
good stuff on basic algorithms was published long before
the web
existed. Start out by finding a copy of the USENET graphics
FAQ. It’s
out there, easy to find. Then learn to search the ACM
Siggraph
literature data base and get used to paying for copies of
papers.

Been through that FAQ and I don’t personally have that kind of spare cash right now. It’s probably worth mentioning that what I’m currently working on right now is much more in the realms of 2D graphics manipulation and the literature isn’t so ‘cool’ as to be linked in 8 dozen places on every website. For one example, have a look at the disparity on gamedev.net (and the usefulness of what’s there).

One of my favorite numerical books, what do you dislike
about it?

Mainly? The code: cramming it all onto as few lines as possible making it difficult to read, using objects where variables would do, using techniques that are only useful for ‘objectifying’ C (such as putting function prototypes inside structs) instead of using proper classes and writing functions in header files.

It’s one thing having a disclaimer that the code should not be considered ‘best practice’ but quite another to make it so abominably bad that anyone using it even as a vague guide will develop programming practices that will cause them severe problems.

It’s not even like they haven’t had time to improve, I went through Numerical Recipes in C (from 15 years previous) as it’s available (legally) for free online and the quality of the code had me wincing.

If a book is to be used as learning material for programming then it needs to provide correct examples.

Take a look at open courseware on the net. MIT is working
to make all
of the materials for all of its classes available for free
online. Try
typing “open courseware consortium” into google and working
from
there.

Yeah, the MIT open courseware is limited and quite often consists of lecture slides without notes or transcript which is of limited usefulness. I’m sure this will change with time but for now it’s not a lot of use. I wasn’t aware of the Consortium, I’ll have to check that out.

As for “lost to me” so what? If can get through a class
without having
something that was “lost” to you then you should have
started with a
harder class. Do you actually expect to understand
everything the
first time you look at it?

I didn’t mean the material lost me, I mean there are times where I’m sure the material exists but I just can’t find it, ergo it’s lost to me in the sense of being unavailable.

Well, thanks for replying and the links.

Paul— On Wed, 7/29/09, Bob Pendleton wrote:

From: Bob Pendleton
Subject: Re: [SDL] Theory - Graphics Server for threaded apps
To: “A list for developers using the SDL library. (includes SDL-announce)”
Date: Wednesday, July 29, 2009, 5:31 PM
On Tue, Jul 28, 2009 at 4:38 PM, Paul Duffy<@Paul_Duffy> wrote:

That statement makes me very angry. No one should be poor enough to
feel that they need institutionalized education.

http://codebad.com/On Wed, Jul 29, 2009 at 12:39 PM, Bob Pendleton wrote:

That statement makes me very angry, no one should be to poor to have
access to an education.

What kind of software are you writing that has you so convinced that
you need asynchronous drawing?On Tue, Jul 28, 2009 at 12:20 PM, Micah Brening<micah.brening at gmail.com> wrote:

I was thinking about the limitations that some systems have regarding threads
and drawing. ?That the main thread has to be the one that draws, or else the one
that initializes the functions, or whatnot.


http://codebad.com/

Donny Viszneki <donny.viszneki gmail.com> writes:

What kind of software are you writing that has you so convinced that
you need asynchronous drawing?

Oh I’m not convinced that I need it.
I just thought it would be a neat project.
As for the programs I write.
Small games, image manipulation (filters and such)
I’m also working on a generic 2d animation.
(Had to start teaching myself trig for angles and whatnot… pretty fun)

The projects I do are to teach myself new things.
Not really for an end result of a program.

2009/7/29 Donny Viszneki <donny.viszneki at gmail.com>:> On Wed, Jul 29, 2009 at 12:39 PM, Bob Pendleton wrote:

That statement makes me very angry, no one should be to poor to have
access to an education.

That statement makes me very angry. No one should be poor enough to
feel that they need institutionalized education.

Either way, technical texts, IEEE membership, MSDN & Dr Dobb’s
subscriptions, whatever, cost money, and not just a little bit, and
their usefulness varies.
You can sometimes get lucky if you check out used book stores, but
people don’t generally get rid of the GOOD books.

For free technical journals, you might want to try here:


(specifically here: http://www.doaj.org/doaj?func=subject&cpid=114 )

For 3D graphics techniques, there’s http://graphics.pixar.com/research/
There’s open source software (like Rigs of Rods) which you can find
through sf.net and freshmeat, and student theses and professors notes
available through university websites.
Blender ( http://www.blender.org/ ) sometimes has useful / interesting
information in their announcements, education section, movie and game
project blogs, and user discussions. And it’s open source, so you can
refer to the code for the program itself, and various plugins and
external renderers.
WikiBooks ( http://en.wikibooks.org/wiki/Main_Page ) SHOULD be useful,
but isn’t much. Though once you find the information elsewhere, you
can fix that.
Also, while Wikipedia isn’t always a great help, the references and
external links often are.

Other than that, IETF, W3C and ECMA make their standards available
free online. None of them are exactly light reading though, and
you’re not likely to find tutorials there (though there is
http://www.w3schools.com/ ). Not much is related to computer
graphics, but you’ll find a few bits and pieces.

As for the programs I write.
Small games, image manipulation (filters and such)

Ah, image manipulation is definitely something that can benefit from
parallelization. But probably the GPU is a better place to do it. If
not, though, all you really ought to be required to do is make sure
you have a “software surface” and make sure each thread only gets one
chunk of to work with.

I’m also working on a generic 2d animation.

Raster or vector graphics?On Wed, Jul 29, 2009 at 5:01 PM, Micah Brening<micah.brening at gmail.com> wrote:


http://codebad.com/

cough … understatement. I’ve met maybe 3 US-taught uni grads that
were worth anything when giving them interviews :). (Yes, I’m in the
US btw). When they dunno who Knuth or Huffman are, ya start to
wonder. As such, seeing ‘uni grad’ on a resume or in a discussion
means little more to me than the determination to stick it out and
complete the degree.

Sadly, most informational resources I’ve seen online focus entirely on
just dumping code into the reader’s lap. No good ‘eureka’ discussion
on the theory behind what’s being done. The few I’ve seen which
discuss theory do so in a very deep manner and offer no ‘here is a cut
down version implementation or psuedo’ code to get a feel/start from.
Many books have pdf/ebook versions available, shouldn’t be too hard to
find a (hopefully legit) retailer.

BTW, I do happen to own several of the books mentioned here in paper
form, thumbs up :).

-WillOn Wed, Jul 29, 2009 at 12:31 PM, Bob Pendleton wrote:

On Tue, Jul 28, 2009 at 4:38 PM, Paul Duffy wrote:

You say this, but not everyone has access to the literature or knows where to start;

Correct. That is what schools are for. Of course, a lot of schools are
not very good.

I think the triple buffering concept is better maintain three pointers
to scene graph roots, one which is locked for use by the display, one
which is locked for use by code that modifies the scene graph, and one
free one which may be taken up either as the target of the next
frame’s scene graph, or taken up as the next scene graph to render to
the display. This adds a little memory, and throws away some of your
computing resources, but for games decreases latency and increases
throughput.

While I can see the theoretical advantages of triple buffering (double
to stop sheer/corruption, triple to not lock the drawing virtual
surface during retrace etc) - off hand I can only think of one game
that offered triple buffering. That’d be DOS quake’s vesa stuff.

From what I recall on a pentium … 90mhz (?), triple buffering was
slower than the other options.

There any real world examples of triple buffering offering the
theoretical speed improvement ?

-Will