This might belong in the Alternative Game Libraries, but my problems are too "beginner" for that place, hence I'll post in this forum. Here's the link to the code I'm going to be talking about (it's big): http://rapidshare.com/files/87683590/p_sunrise_3.zip.html It's a Visual C++ 2005 project. The SDL files needed are included in the project. The First Problem: I see many SDL programs use the printf() to output errors. Whenever I do that, the command prompt doesn't even appear when I compile my program. Am I missing something? I tried using <iostream> but that doesn't do anything. The Second Problem: I have a "interface" (called Locatable, though it should be called something else) that has a draw function. Classes that implement Locatable have a draw function fully implemented (except for Sprite which is abstract). This draw function is called in the Environment class through a loop. Thing is, it doesn't draw a single thing. I do know why. This line of code...

SDL_FillRect( screen, NULL, 0 );

...blacks everything out. However, when I remove that line of code, it draws, but it leaves a trail behind like a game of Snake. That's not supposed to happen. I tried many things but all are to no avail and, quite frankly, I am tired of this problem. Here's the segment that draws all the sprites and such.

// Renders the environment and shows it on the screen.
void Environment::show()
{
	// Clears the screen first.
	SDL_FillRect( screen, NULL, 0 );

	// Shows the environment.
	apply_surface( posX, posY, screen, shell->get_surface(), NULL );

	// Shows each of the objects within the environment.
	for ( unsigned int index = 0; index < objects.size(); index++ ) {
		Locatable* loc = objects.at( index );
		loc->draw();
	}

	// Updates the screen.
	update();
}

Thanks.

When run in the windows subsystem, SDL redirects output from streams to files these files should show up in the application directory. You can also go to your linker setting and change the subsystem from windows to console and the console window should appear.

A quick and simple method I use for printf type error logging in lieu of using an actual logging class:



Depending on how you're using it (and whether it's a release or debug build of the library) SDL may do something similar to this, redirecting the stdout and stderr streams to files.

In answer to your second question, it looks like an order of operations error. You have a bunch of different offscreen rendering surfaces (some with similar names) so it's easy to get them mixed up. Try moving your apply_surface() call until right before your buffer flipping:

Quote:Original post by sigsegv42
In answer to your second question, it looks like an order of operations error. You have a bunch of different offscreen rendering surfaces (some with similar names) so it's easy to get them mixed up. Try moving your apply_surface() call until right before your buffer flipping:

That did the trick but why? My initial understanding of applying surfaces is that the bottom (the screen) goes first, then the objects. How come the opposite works?

Actually, you can remove the update() method from your show() method also. It's a bit of a herring here - the SDL_Flip() call is not contributing anything (since you're not using hardware surfaces with double buffering). Your apply_surface() call is doing the same thing as what the flip call would do - it copies the contents of your screen surface into the surface that was allocated by your window when you did SDL_SetVideoMode(). Obviously, you don't want to do this copy until after you've also done all of your Locatable draws (since they are drawing on the same screen surface).