Post by slimshader
I hear you, but I am in the niche of older machines, in fact I am having
trouble even getting users to get OpenGL 1.4 work correctly (for VBOs (in
fact I think it is about time I implement D3D renderer)), also mobile
devices are not what you'd consider 2010s "gaming rigs". That being said,
secondary thread is (as I said before) not used to speed-up level loading
but rather to keep main (event processing, rendering) thread responsive.
I do use task queues (double-buffered) but they are per-thread. Since
cross-thread tasks are very seldom I don't want them having locks all the
BTW. Since we are on threading / GL topic: do you guys render from main
thread? What are your update vs render step strategies? If you do them on
separate threads how do you sync later (condition vars seem obvious
After trying several threading strategies, my current preference is to keep
rendering and window management to the main thread, but handle input on a
secondary thread. So far, this has proven the best method to maintain
responsiveness without impacting compatibility.
Regarding D3D... I prefer to use ANGLE to get OpenGL ES 2.0 on systems
without proper OpenGL support. This way, I only need to maintain two
renderers: OpenGL everywhere and OpenGL ES for smartphones and (Windows &
~(Nvidia | AMD)).
This way, I can also use shaders across the board. ANGLE works all the way
down to GMA 950 (and probably GMA 500/Poulsbo, although I haven't tested
that), so there's very little reason to use the fixed-function pipeline.
Microsoft recently announced they will be working with Google to port ANGLE
on WinPhones and Metro, so D3D will be strictly unnecessary going forward -
as an indie developer, this suits me perfectly.
Post by slimshader
You should also question whether you need a second thread at all. In the
times that processor frequencies averaged in the lower megahertz range, it
made sense to do non-graphcal processing on another thread which was
capable of simulating concurrency with the graphical thread (gaming systems
were single-pprocessor back then). But that was the '90s, and this is the
2010s - processor frequencies on gaming rigs can be as much as 20x higher
than in the nineties, and while multi-core processors have made the use of
threads even less costly, they have done nothing to alleviate the design
issues associated with it or the limitations in graphics drivers.
Which is not to say that it makes no sense to have another thread
depending on your needs. But unless this engine you're developing is
strictly in-house, needs are for the programmer using the engine to decide,
and not the engine itself - the aim of the engine merely ought to be to
provide an easier means to meeting such needs.
If you aren't doing this to leverage multicore execution (which would most
likely be a premature optimization; the root of all programming evils), but
for concurrency, there are also better options. You might consider a task
queue (which carries the benefit that it can easily be made multi-threaded
if the programmer using the engine does find need to leverage multicore
execution, without at all necessitating it; it also carries lower execution
overhead than context switching, which is necessary for multithreading on a
uniprocessor or overburdened multiprocessor system; and may even wind up
costing less memory [once you consider all the locks, thread-local
variables, and the memory for the context itself]. It's also extremely
simple to implement - in C or C++, it can be implemented as nothing more
than a singly-linked-list of function pointers [having a tail pointer may
make things even simpler and faster]).
SDL mailing list