Sign in to follow this  
SticksandStones

SDL - tile based maps and trailing

Recommended Posts

From reading the cone3d tutorials, and from personal experience, moving an object in 2d causes a trailing effect. Now, with a single-image background this is easily fixable by taking a small portion of the background and bliting it back on to the surface *screen. However, from what I have tried, this isn't possible in tile based maps. Assuming a 20x15 grid of 32x32 tiles, how could I possible prevent the trailing from moving an image in screen coordinates? Is there a way to use the surface *screen to get the information similair to the way you would do it with a surface that loaded an image (by which I mean, finding out what was blited onto the surface at x,y, and re-bliting it after moving the image)? The only other way I could think of fixing this is taking the object's x,y coordinates and incrementing them until both newX and newY when devided by 32 are integers > 0, then using those to load the tile represented in the tile array and reloading them before re-drawing the image. Basicly, I just want to know how I could go about preventing the trailing in a tile-based map where images moving in screen coordinates instead of the tile coordinates.

Share this post


Link to post
Share on other sites
So many people who go through those (horrible) tutorials have the same problem. What the Code3D tutorials don't teach you is the standard in design of games. Usually in the main game loop you clear the screen and then paint ALL graphics and then move the objects. When the loop is effective, it's similar to a simple animation one frame after another, just like cartoons. The main point is that you clear the entire screen before redrawing the graphics.

Share this post


Link to post
Share on other sites
Quote:
Usually in the main game loop you clear the screen and then paint ALL graphics and then move the objects. When the loop is effective, it's similar to a simple animation one frame after another, just like cartoons. The main point is that you clear the entire screen before redrawing the graphics.
Isn't that really slow though, to repaint all the graphics? I guess it doesn't really matter as long as it works, but I thought you didn't want o redraw the background every frame.

Oh well, thanks for the tips; now I can get some work done! :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Gunslinger RR
Quote:
Usually in the main game loop you clear the screen and then paint ALL graphics and then move the objects. When the loop is effective, it's similar to a simple animation one frame after another, just like cartoons. The main point is that you clear the entire screen before redrawing the graphics.
Isn't that really slow though, to repaint all the graphics? I guess it doesn't really matter as long as it works, but I thought you didn't want o redraw the background every frame.

Oh well, thanks for the tips; now I can get some work done! :)


It's not that slow.

It is useful, though, to allow the screen to be split into windows. (Think, the old arcade games had two windows: the play window, and the scoreboard window on the right-hand side.) A window may have a state variable telling whether or not it needs to be redrawn, which is set whenever this window changes. Hence, because the scoreboard doesn't change as often as the play window, it wouldn't need to be cleared and redrawn as often. The clearing and redrawing would mostly happen to the play window (because of all the action going on there).

Sound good?

Of course, if the game is full-screen, the story is a bit different. But you're smart; you'll figure something out.

Share this post


Link to post
Share on other sites
Quote:
Original post by Benjamin Heath
Quote:
Original post by Gunslinger RR
Quote:
Usually in the main game loop you clear the screen and then paint ALL graphics and then move the objects. When the loop is effective, it's similar to a simple animation one frame after another, just like cartoons. The main point is that you clear the entire screen before redrawing the graphics.
Isn't that really slow though, to repaint all the graphics? I guess it doesn't really matter as long as it works, but I thought you didn't want o redraw the background every frame.

Oh well, thanks for the tips; now I can get some work done! :)


It's not that slow.

It is useful, though, to allow the screen to be split into windows. (Think, the old arcade games had two windows: the play window, and the scoreboard window on the right-hand side.) A window may have a state variable telling whether or not it needs to be redrawn, which is set whenever this window changes. Hence, because the scoreboard doesn't change as often as the play window, it wouldn't need to be cleared and redrawn as often. The clearing and redrawing would mostly happen to the play window (because of all the action going on there).

Sound good?


Sounds good :)

Just one question: when redrawing the main window, is there a way to literally clear it first, or do I just draw over whatever is drawn on it?

Share this post


Link to post
Share on other sites
Quote:
Original post by Gunslinger RR
Just one question: when redrawing the main window, is there a way to literally clear it first, or do I just draw over whatever is drawn on it?


I would clear it by filling it with a solid color. If you don't, you're back to the same problem as before: your sprites will be smeared all over the place.

Share this post


Link to post
Share on other sites
Quote:
Original post by Benjamin Heath
Quote:
Original post by Gunslinger RR
Just one question: when redrawing the main window, is there a way to literally clear it first, or do I just draw over whatever is drawn on it?


I would clear it by filling it with a solid color. If you don't, you're back to the same problem as before: your sprites will be smeared all over the place.


Only it will have a weird strobing effect as well cause the memory keeps swapping back and forth.

Share this post


Link to post
Share on other sites
Quote:
Original post by PnP Bios
Quote:
Original post by Benjamin Heath
Quote:
Original post by Gunslinger RR
Just one question: when redrawing the main window, is there a way to literally clear it first, or do I just draw over whatever is drawn on it?


I would clear it by filling it with a solid color. If you don't, you're back to the same problem as before: your sprites will be smeared all over the place.


Only it will have a weird strobing effect as well cause the memory keeps swapping back and forth.


Okay, do just track what objects are in that window and redraw all of them or what?

Share this post


Link to post
Share on other sites
Quote:
Original post by PnP Bios
Only it will have a weird strobing effect as well cause the memory keeps swapping back and forth.



No it won't. You fill the surface with a color, you draw your sprites over, it, THEN you call the flip function to display the surface to the screen.
And you don't even need to do the color-fill if you're using a single background that covers the whole play area. The new images just gets drawn right over the old one.

Share this post


Link to post
Share on other sites
Quote:
Original post by Benjamin Heath

Okay, do just track what objects are in that window and redraw all of them or what?


i think what he is getting at is weather to just render every object or just the objects that are in the screen. If thats the case, i usualy just do a check at every render function to see if the object is on the screen. something like:(pardon ths psudoness of this)

int ux = Location_X; //upper right location in terms of x
int uy = Location_Y; //upper right location in terms of y
int wx = Screen_Width + ux; // number of pixels wide
int wy = Screen_Height + uy; // number of pixels tall
//now do a quick check asume object_x is x cord of object and object_y is y cord
if(object_x > ux && object_x < wx && object_y > uy && object < wy)
{
//do rendering stuff
}

thats a real simple version, but should work...

Share this post


Link to post
Share on other sites
I don't know, but I think what I was getting at was giving the window a list of all objects that are inside it. Then the window renders itself by rendering those objects, thus acting like a camera. But this would only create more problems because there could be more than one window on the screen, each with its own list of objects to render.

Oh well, I tried.

Share this post


Link to post
Share on other sites
You could always make a camera class that holds the Camer Ux and Uy, and a Exactx and y, which would be were the begining X and Y of the camera. You would also need a width and height
class camera
{
int ux;
int uy;
int actualx;
int actualy;
int width;
int height;
}
store this in an array or something
then you could store all your objects to be rendered, in an array or hashtable whatever. call their draw functions like so

for (int z; z <= numofobjects; ++z)
for (int i; i <= numofcameras; ++i)
{
int ux = cameras[i].ux;
int uy = cameras[i].uy;
int wz = cameras[i].width + ux;
int wy = cameras[i].height + uy;

if(obj[z].object_x > ux && obj[z].object_x < wx && obj[z].object_y > uy && obj[z].object < wy)
{
int drawx = (objectx -ux) + cameras[i].actualx;
int drawy = (objecty -uy)+ cameras[i].actualy;
obj[z].draw(drawx, drawy);

}


}
}

you could do something like that, it should work.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this