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.

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.

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! :)

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?

SDL_FillRect is what you're looking for [smile].

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.

Ben, that made no sense.