On Fri, Oct 19, 2012 at 12:37 PM, Henry Gomersall <heng@cantab.net> wrote:
On Fri, 2012-10-19 at 14:29 -0400, Ryan Hope wrote:
> Thanks for the ideas guys. I am a complete OpenGL noob, just started
> using it last week so things like VBOs and shaders are a little over
> my head at the moment. I start looking into these things though.
They're the modern way to do things. To the point that it's probably not
much worth learning anything else.

Just because they won't be supported in hardware in 10 years doesn't mean they're inherently a bad thing. Derakon is right; immediate-mode OpenGL is easy to use. No, high-end, forward-thinking applications don't use it (as much), but that doesn't mean it's a worthless technology. Plus, it sounds like the OP already knows how to use them (and they aren't hard to learn anyway). They may even have lower overhead than VBOs, because they don't require expensive buffer glBind(...).

It occurs to me that you could probably rig up a procedural texture
that would simulate a starfield for you. Then you could just use a set
of textured quads to do your parallax scrolling starfield. I'm not an
OpenGL expert though; would anyone more experienced have a sense of
how this would compare speedwise to the VBO approach? The advantages
to a procedural texture would be that there'd be no repetition to the
field, and that of course you'd never have to send more data over to
the card, except for the parameters to the shader used to generate the
I would suspect that this would be much slower: any such implementation would probably be implemented as a fragment program (or at best, and OpenCL kernel). As such, unless you were very very careful, it would be linear with the number of pixels on the screen, and opposed to linear in the number of stars. Randomly generating the stars on the CPU into a mapped VBO implementing a circular buffer would probably accomplish much the same thing, but faster.