Advice on Background Coding.

[Roose Bolton of the Dreadfort]

Hey All,

Hope all are having a great Monday!! 

I am currently working on my 1st real game and I have hit a problem.

My game is a space game where you must 'survive' for as long as possible by dodging asteroids and collecting scrap metal.

The game world is roughly 8000x8000 pixels and I want a beautiful space background.

I am stuck in terms of how to approch the background.. I know that max textures I should load are 512x512 as people with older graphics card have trouble loading large size images so obviously making lots of massive textures and displaying them in a tile format is out of the question...

if I DO make a tilesheet for the background, it looks slightly funny because the player moves quite fast.. so he goes across the 'background' really fast, making it look a little wierd...

I thought about making the background move when the player does but slightly slower, thus making the background slower, but the problem is im using box2d.. so I end up Apply Force to my background.. which just seems.... wrong..

Check out this video..

http://www.youtube.com/watch?feature=player_embedded&v=gf0crpqeAlU#at=26

thats an awesome game I have been following and has a vey good background simulation with the clouds.. Thats essentually what id like. Its obviously quite a large background and its made of clouds.. so I doubt he used a tilesheet... what did he do?

[Walker]

There is many, many ways to do what you want to do. It really depends on how you want it to look.

More importantly though - you probably shouldn't be moving your background at all, much less simulating it with a rigid body. Construct your background/scene with whatever you want, then leave it be and move a camera around on it (sf::View).

I would go for a tiled thing or just freely placed sprites, which you could place semi-randomly.

[thePyro_13]

In addition to what Walker is saying, you can use two sf::Views and move the background view at a different rate than the view following your character.

By adding even more sf::Views you can create different layers moving at different rates which can produce a very nice star field effect. Just like the star and cloud layers in your example video.

[Roose Bolton of the Dreadfort]

More importantly though - you probably shouldn't be moving your background at all, much less simulating it with a rigid body. Construct your background/scene with whatever you want, then leave it be and move a camera around on it (sf::View).

This is what I originally did, but the player and other entities move quite fast.. so they look silly flying over a space background, I wanted it to be slower..

By adding even more sf::Views you can create different layers moving at different rates which can produce a very nice star field effect. Just like the star and cloud layers in your example video.

I understand, the problem is that im using Box2D for my movement simulation.. not simple (moveX, moveY) movement when I hit keys... so moving a view slower than the player is very hard without making it a Physics Objects.. because say I have it so when I press 'W' i move forward it also tells the background to move foward in my direction, now say my ship collides with an asteroid and the player continues holding 'W'.. my background is going to start moving while my ship remains static...

Only thing I can think off is to make a 8000x8000 world via tiled sprites.. but thats going to be not brilliant on performance.. and seems excessive for a background.

[thePyro_13]

I'm not sure how your movement and physics system work. But I would imagine that your character would be a physics object, and your view would simply set its position to the characters position(or follow it at a set or variable movement rate).

You can calculate the delta position of the view each update step and use fractions of it for each of your background layers views to achieve the slow movement effect.

In such a set up the views shouldn't need to be physics objects.

[Roose Bolton of the Dreadfort]

I'm not sure how your movement and physics system work. But I would imagine that your character would be a physics object, and your view would simply set its position to the characters position(or follow it at a set or variable movement rate).

You can calculate the delta position of the view each update step and use fractions of it for each of your background layers views to achieve the slow movement effect.

In such a set up the views shouldn't need to be physics objects.

Right, is there any chance you could expand on your explination? I think I understand what you mean..

Thank you very much for the help Pyro

[thePyro_13]

I'm not sure what more to say, so I'll write some psudocode to show what I mean:

//some kind of update step called at a constant rate
void update()
{
   //move player useing whatever control scheme you have
   // eg. if(keypress.w) player.move(forward) or just pass your sf::events into the physics system

   //store the main views current position
   sf::Vector2 oldviewpos = playerView.getPosition();

   //move the main view to the position of the player so that we remain focused on them
   playerView.setPosition(playerpos);

   //create vectors pointing from the old views position to the new player position,
   //this gives us a direction in which to move
   sf::Vector2 moveVector = player.getPosition() - oldviewpos;

   //move the background views by this move vector,reduce them all by a variable amount so that
   //that they all move at different but slower rates, this could be done using any math you like
   //I'm doing it here by dividing them
   backgroundview1.move(moveVector  / 2);
   backgroundview2.move(moveVector  / 3);
   backgroundview3.move(moveVector  / 4);
}
 

Then simply draw each layer using whichever view is appropriate. eg draw the player and game relevant stuff using the main view and each of the background layers using one of the background views.

[Roose Bolton of the Dreadfort]

I'm not sure what more to say, so I'll write some psudocode to show what I mean:

//some kind of update step called at a constant rate
void update()
{
   //move player useing whatever control scheme you have
   // eg. if(keypress.w) player.move(forward) or just pass your sf::events into the physics system

   //store the main views current position
   sf::Vector2 oldviewpos = playerView.getPosition();

   //move the main view to the position of the player so that we remain focused on them
   playerView.setPosition(playerpos);

   //create vectors pointing from the old views position to the new player position,
   //this gives us a direction in which to move
   sf::Vector2 moveVector = player.getPosition() - oldviewpos;

   //move the background views by this move vector,reduce them all by a variable amount so that
   //that they all move at different but slower rates, this could be done using any math you like
   //I'm doing it here by dividing them
   backgroundview1.move(moveVector  / 2);
   backgroundview2.move(moveVector  / 3);
   backgroundview3.move(moveVector  / 4);
}
 

Then simply draw each layer using whichever view is appropriate. eg draw the player and game relevant stuff using the main view and each of the background layers using one of the background views.

Riiiight I see! Thats a very good idea. That way if my player hits something etc etc the background will actually slow/stop as its in reference to my position. Brilliant! I will get to it.

Another thing.. how do you think I should handle the size of the backgrounds? Obviously making a massive background image would be silly, so should I make a large image in photoshop and extract it into tiles? Then display it as tiles? Whats your advice here?

Cheers!

[thePyro_13]

If you make a really big image and cut it up into tiles, then you'll have the same result as just drawing the big image(except that you won't have to risk hitting the max texture size limit). :p

However if you make a few small images that you can draw on many tiles, then you'll have a much smaller performance hit. Although your background may look more repetitive and you'll have to make sure the smaller repeating tiles tessellate well.

Since it's space you can always just clear the screen with a black colour and generate many small entities in random positions that look like nebulae and stars with a hand full of variant textures for each entity type(which is probably what is being used in your example video). Whether this looks better than a nice big image would probably depend on your art style and so on.

With one or more large images you can achieve some really pleasing space views. You can see the results of this type of approach if you do a google image search for "homeworld". They have large colourful backgrounds, sometimes with very large scrap objects in them. Here's a good example of what I'm talking about.

[Roose Bolton of the Dreadfort]

If you make a really big image and cut it up into tiles, then you'll have the same result as just drawing the big image(except that you won't have to risk hitting the max texture size limit). :p

However if you make a few small images that you can draw on many tiles, then you'll have a much smaller performance hit. Although your background may look more repetitive and you'll have to make sure the smaller repeating tiles tessellate well.

Since it's space you can always just clear the screen with a black colour and generate many small entities in random positions that look like nebulae and stars with a hand full of variant textures for each entity type(which is probably what is being used in your example video). Whether this looks better than a nice big image would probably depend on your art style and so on.

With one or more large images you can achieve some really pleasing space views. You can see the results of this type of approach if you do a google image search for "homeworld". They have large colourful backgrounds, sometimes with very large scrap objects in them.

Yeah.. Well like I said I would want the game world to be around 8000x8000 so fairly large really.. that would be alot off 512x512.. do you think drawing that many would hit performance that much?

Maybe I should do random spawning of stars etc but then they wud still have to be sprites though right? So having 10,000 stars would surley smash performance pretty hard?

I am tempted to make the backgrounds move very very slowly... for instance, the far background image will be around 2000x2000 and will move 1/8th speed of the player so it doesnt have to be the same size as the world.. then the other 2 views could just be moving stars or something that can just be paralax and repeating..

[thePyro_13]

I don't know how well it would run(I haven't tried drawing such large object with SFML yet).

If the background is moving slowly then you can make it smaller and not have to worry about running into its edges like you say. And trying to wrap them around the screen edges like a parallax effect should also work.

Combining these things into vertex arrays will also make things much faster. You'll just have to try them out and see if they run at an acceptable rate or not.

[Laurent]

If your stars are points (white pixels) then a vertex array of 10,000 will be very fast to draw. If the visual result is acceptable for you, you should definitely choose this solution.

[Roose Bolton of the Dreadfort]

If your stars are points (white pixels) then a vertex array of 10,000 will be very fast to draw. If the visual result is acceptable for you, you should definitely choose this solution.

Right okay. I need to do some research into how Vert Arrays work, im assuming its just 4 verts making a quad and coloured white?

[Laurent]

You don't need to define a square to draw a single pixel, you can directly define a primitive made of a single vertex (with the sf::Points primitive type).

The "Shaders" example of the SFML SDK has an effect which uses a vertex array of (40,000) points.

[Roose Bolton of the Dreadfort]

You don't need to define a square to draw a single pixel, you can directly define a primitive made of a single vertex (with the sf::Points primitive type).

The "Shaders" example of the SFML SDK has an effect which uses a vertex array of (40,000) points.

Okay so I dont have to use shaders?

I am a bit confused about the difference between VertexArrays and sf::Points, sf::Sprite etc..

I have read before that sf::Points & sf:Sprites basically vertax arrays internally.. so why does using a vertex array externally cause such better performance?

Is making 40,000 sf::Points slower than 40,000 verts in a vertex array?

Same with sprites.. why is making a vertex array of tiles and setting their texture so much faster than drawing sprites.