Jump to content
  • Advertisement
Sign in to follow this  
chad_420

SDL_flip always required?

This topic is 4946 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

SDL_Surface *screen; screen = SDL_SetVideoMode(640, 480, 32, SDL_HWSURFACE); should be the actual screen right? when i draw to it i cant see anything until i call sdl_flip(screen); This is what i expected with : screen = SDL_SetVideoMode(640, 480, 32, SDL_HWSURFACE|SDL_DOUBLEBUF); I want to draw directly to the screen without buffering is this possible in sdl? here is the code im attempting to use... mostly from the cone3d tutorial foud here
[source lang=cpp]

#include <cstdio>
#include "SDL.h"


int bRunning;
void Slock(SDL_Surface *screen)
{
  if ( SDL_MUSTLOCK(screen) )
  {
    if ( SDL_LockSurface(screen) < 0 )
    {
      return;
    }
  }
}

void Sulock(SDL_Surface *screen)
{
  if ( SDL_MUSTLOCK(screen) )
  {
    SDL_UnlockSurface(screen);
  }
}

void DrawPixel(SDL_Surface *screen, int x, int y,
                                    Uint8 R, Uint8 G, Uint8 B)
{
  Uint32 color = SDL_MapRGB(screen->format, R, G, B);
  switch (screen->format->BytesPerPixel)
  {
    case 1: // Assuming 8-bpp
      {
        Uint8 *bufp;
        bufp = (Uint8 *)screen->pixels + y*screen->pitch + x;
        *bufp = color;
      }
      break;
    case 2: // Probably 15-bpp or 16-bpp
      {
        Uint16 *bufp;
        bufp = (Uint16 *)screen->pixels + y*screen->pitch/2 + x;
        *bufp = color;
      }
      break;
    case 3: // Slow 24-bpp mode, usually not used
      {
        Uint8 *bufp;
        bufp = (Uint8 *)screen->pixels + y*screen->pitch + x * 3;
        if(SDL_BYTEORDER == SDL_LIL_ENDIAN)
        {
          bufp[0] = color;
          bufp[1] = color >> 8;
          bufp[2] = color >> 16;
        } else {
          bufp[2] = color;
          bufp[1] = color >> 8;
          bufp[0] = color >> 16;
        }
      }
      break;
    case 4: // Probably 32-bpp
      {
        Uint32 *bufp;
        bufp = (Uint32 *)screen->pixels + y*screen->pitch/4 + x;
        *bufp = color;
      }
      break;
  }
}

int main( int argc, char* argv[] )
{
  
	SDL_Event event; /* Event structure */
	
	SDL_Init(SDL_INIT_VIDEO);
	bRunning = 1;
	SDL_Init(SDL_INIT_VIDEO);
	atexit(SDL_Quit);
	SDL_Surface *screen;
	screen = SDL_SetVideoMode(640, 480, 32, SDL_HWSURFACE);
	if ( screen == NULL ) return 255;
	while (bRunning)
	{
		
		/* Check for events */

		while(SDL_PollEvent(&event))
		{  /* Loop until there are no events left on the queue */

			switch(event.type)
			{
			case SDL_QUIT: 
				bRunning = 0;
				return 0;
				break;
			default: /* Report an unhandled event */

				break;
			}

		}
		Slock(screen);
		for(int x=0;x<640;x++)
		{
			for(int y=0;y<480;y++)
			{
				DrawPixel(screen, x,y,y/2,y/2,x/3);
			}
		}
		Sulock(screen);
		//SDL_Flip(screen);
	}
	return 0;
}

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by chad_420
But there is no way to draw directly to the video suface thats being displayed?


Think about the call to SDL_Flip as a way to tell the screen that something has changed. Think about a situation like this. You have a can of tuna in the store. It costs 55 cents. The tag for it on the shelf displays 55 cents. Now if the manager changes the price of the tuna to 45 cents, the tuna doesn't know the price is different and neither does the buyer. That is, not until a sales associated goes and changes the price tag. That is what SDL_Flip essentially does, it tells the system that something might have changes, so it better update all the internal data.

You are writing directly to the video surface, you just are not updating it so it is not being displayed. To see if this is the case, I'm not sure if it is or not, it depends on computer hardware to which I know nothing about, change the pixel, then try to get it again and see what it reads. I think this is more of a hardware issue not knowing to display the new data rather than "it not working".

As a side note, calling SDL_Flip is a one glove fits all solution for updating. If you are not using double buffering, it will interally call SDL_UpdateRect.

Does this make more sense now?

- Drew

Share this post


Link to post
Share on other sites
I'd say that the display mode you are using does not support this direct writing. I know there are modes that support it ( I'm using fancy 320x200, thought not with SDL but by direct memory access ), but I dont know which are the ones...

Share this post


Link to post
Share on other sites
I don't think SDL differentiates between which resolutions have DMA and which ones don't. But the only way you can get SDL to update what is visible onscreen, is to tell it (via SDL_UpdateRect, or SDL_Flip) that a change has been made.

Not sure why it's behaving as such in your case, but I would investigate SDL_UpdateRect.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
If this is for windowed mode, then on pretty much every system SDL implements "double buffering" for windowed mode whether you like it or not. Whats really happening is SDL is drawing everything to a seperate surface, and then when you call SDL_Flip() (which internally calls SDL_UpdateRect() for windowed mode) it does a format conversion to display your buffer on the window.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!