   Can't create hardware video mode in SDL
  Hey,I'm having a bit of an issue with my current project. The resolution is 800x600 and I'm not directly accessing pixel data so hardware mode should provide a performance boost.I create the screen with this line:Screen = SDL_SetVideoMode(800,600,32,SDL_HWSURFACE | SDL_DOUBLEBUF | SDL_FULLSCREEN);It creates a video mode but it is never a hardware surface. I know this because the performance is the exact same as if I choose SDL_SWSURFACE and I check Screen->flags to see if it has the SDL_HWSURFACE bit, which it doesn't. My system is relatively high spec and should have no problem creating a hardware surface. I tried a few other resolutions from the supported resolution list in the DirectDraw tab of the DirectX SDK control panel, none created a hardware surface.I have no idea what could be causing it, and it is resulting in unnacceptable performance. Any help with this would be brilliant. I don't want to have to change my backend over to D3D at this stage, just to get hardware support. Thanks a million.   
  The last I heard, SDL can only get hardware surfaces on linux in fullscreen (And then only with certain X extensions installed, on certain hardware with certain drivers)The only realistic way to get hardware surfaces is to use OpenGL (directly or through glSDL)(BTW, you are using SDL_DisplayFormat right? It's a very common mistake to omit it, leading to horrible performance)   ;  I am using SDL_DisplayFormat, so all my surfaces are in the right format, but that isn't the issue so much as getting hardware support. According to this SDL does support hardware mode on windows. Thanks for the suggestion though.   ;  I have never had a problem getting fullscreen hardware modes in Windows, including 800x600. Do you have a copy of DXDiag, and does everything look ok in there? If the worst comes to the worst, you could try a minimal DirectDraw example and see if that is capable of giving you the surface you want; it would at least narrow down the problem.   ;  Why not check its available before assigning it?Something like://get display infoSDL_VideoInfo const * video_info = SDL_GetVideoInfo( );    if ( !video_info ){ throw("SDL Video query failed.");//or something else}    ...    //checks to see if surfaces can be stored in memoryif ( video_info->hw_available ){ m_video_flags |= SDL_HWSURFACE; }else { m_video_flags |= SDL_SWSURFACE }Where m_video_flags is a class member of sdl_window class.   ;  OK. Following the APs suggestion I apparently don't have the facility to create the window in hardware mode. And as per Kylotan's suggestion I checked out DXDiag and everything seems to be in order. And in the DirectX Caps viewer my gfx card supports all features of DirectDraw.This is odd. I even compiled the SDL dll from source to ensure that DX was supported and it behaves the exact same. I'm stumped. I'm on a bit of a deadline (this being my 4E5 entry), so if I can get SDL performance where I need it I'll just move over to Direct3D.   ;Quote:Following the APs suggestion I apparently don't have the facility to create the window in hardware modeYou may not be able to, but the contest machine surely will be able to, so is there really a problem? Just check if its supported and set the flags depending on the result.   ;  Why not follow TravisWells' suggestion and use glSDL?  It should give you the speed you need.   ;  Ah well. I was going to have to get a rotozooming lib anyway, so may as well just make it one big job and upgrade to D3D. I know D3D better than SDL anyway. But if anyone has had this problem before and knows the answer please post it here, it may help others.Thanks for all the suggestions from everybody.   