Basically, the current background's just a static bitmap with some quads that move at various speeds relative to the player's current velocity. It's OK, but it just doesn't feel right, because the background doesn't move and the quads slide over it.
Had a crazy idea about how to make it do true parallax with endless variety; it's So Crazy, It Just Might Work.
Basically:
1. Use two Mandelbrot Sets with different seed values, generating number values from 0-255.
2. As the ship travels, it's at a different point XY relative to the sets.
3. For each value generated by the two sets, a stellar object quad may be generated at the local coordinates, using simple rules:
A stellar object would be defined in a JSON as a name, bitmap file reference, a size range, random color range using two ranges RGBA (optional) and any number of number pairs between 0-255.
So for example, a really common star might be:
"common_star":{
"texture":"graphics/planets/common_star.png",
"size_range":[5.5,15],
"color_range":[255,255,255,255, 255,255,100,200],
"fractal_locations":[1,16, 231,45, 78,108],
}
To further simplify things, the fractal_locations field could just be an integer; this plus a random seed generated at game start (and saved thereafter) could be used to generate the number pairs at the start of the game or when reloading a save. Personally I like that idea, because it means controlling frequency's pretty easy.
How it would work:
When a point XY on the background's visible, calculating the position values via the Mandelbrot sets is straightforward and probably cheap enough to be done in real time. If the two values equal the value of the common_star object, the quad's generated by the engine and is drawn. Therefore the player moves past stars, creating parallax and a good sense of motion. The density of the grid checked could, of course, be varied for performance purposes, etc.
Anyhow, that's my Crazy Idea. It'd allow for almost infinite variety to the background, true parallax behavior and while a few more quads would have to get rendered to generate a convincing starfield, because we only have to draw the ones that are currently visible, it could probably be kept reasonably cheap, and it could be culled selectively at higher zoom levels if performance became an issue.
[EDIT]Ooh, and one last twist: a third set, or some sort of translation of the values of the two sets, or even absolute values XY transformed... could be used to generate a rotation value. So for clouds and stuff, it could be "static" in the sense that it'll look the same when you go there tomorrow, but it'll be rotated "randomly". That'd also be really handy for "star clusters" for distant point stars.
Ooh, and... it'd probably be possible to mandate the field values in cell XY (real space) via an editor or code, so that perhaps someday we could "paint" cloudy areas on the System maps, etc., etc., and heck, if there was a way to get that cell value, there could be battles "in a nebula", etc. with different battlefield conditions, just like for asteroids...