Confusing results with SDL_GetVideoMode?

Hello,

I 'm testing the new SDL 1.2.10 and noticed some confusing things with the
SDL_GetVideoInfo() method. On each system it reports that creation of
hardware surfaces aren’t available (hw_available) and for the video memory
amount I always get 0.

When I use previous SDL release, it works fine. So I suggest this is a
bug, or
I’ve done something (completely) wrong?

So long,
Gunnar

I 'm testing the new SDL 1.2.10 and noticed some confusing things with the
SDL_GetVideoInfo() method. On each system it reports that creation of
hardware surfaces aren’t available (hw_available) and for the video memory
amount I always get 0.

This is because the windib driver is the default on Windows for 1.2.10,
due to problems with DirectX on newer systems.

You can select the DirectX driver by setting the SDL_VIDEODRIVER environment
variable to “directx”. We’re adding a driver selection API to SDL 1.3.

See ya!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

/ I 'm testing the new SDL 1.2.10 and noticed some confusing things with the
/>>/ SDL_GetVideoInfo() method. On each system it reports that creation of
/>>/ hardware surfaces aren’t available (hw_available) and for the video memory
/>>/ amount I always get 0.
/
This is because the windib driver is the default on Windows for 1.2.10,
due to problems with DirectX on newer systems.

You can select the DirectX driver by setting the SDL_VIDEODRIVER environment
variable to “directx”. We’re adding a driver selection API to SDL 1.3.

Thanks for you tip but I didn’t managed it to get it working. I tried it with
putenv() and checked back with getenv() but it doesn’t seems to really work for
me. Can you please provide me with some snippets of code, maybe I’m just
completely wrong ??

Thanks,
Gunnar

Hello Gunnar,

Tuesday, May 30, 2006, 7:55:34 PM, you wrote:

/ I 'm testing the new SDL 1.2.10 and noticed some confusing things with the
/>>>/ SDL_GetVideoInfo() method. On each system it reports that creation of
/>>>/ hardware surfaces aren’t available (hw_available) and for the video memory
/>>>/ amount I always get 0.
GP> /

This is because the windib driver is the default on Windows for 1.2.10,
due to problems with DirectX on newer systems.

You can select the DirectX driver by setting the SDL_VIDEODRIVER environment
variable to “directx”. We’re adding a driver selection API to SDL 1.3.

GP> Thanks for you tip but I didn’t managed it to get it working. I tried it with
GP> putenv() and checked back with getenv() but it doesn’t seems to really work for
GP> me. Can you please provide me with some snippets of code, maybe I’m just
GP> completely wrong ??

The best way is to just build your own SDL with only DirectX support
and use that with your product.

I’m afraid I don’t agree with WinDib being default - the only systems
that need this are very, very old… such as NT4 or Win95.
Win98/ME/2K/XP all support DX5, and Vista, regardless of the rubbish
I’ve heard will still support the DX5 interfaces.–
Best regards,
Peter mailto:@Peter_Mulholland

That’s not it. windib is now default because a growing number of video
drivers have broken DirectDraw support (remember, DirectDraw is an
obsolete API since DirectX 8), and the SDL devs decided that
reliability was a bigger priority than performance.On 5/30/06, Peter Mulholland wrote:

I’m afraid I don’t agree with WinDib being default - the only systems
that need this are very, very old… such as NT4 or Win95.
Win98/ME/2K/XP all support DX5, and Vista, regardless of the rubbish
I’ve heard will still support the DX5 interfaces.

  • SR

Hello Simon,

Wednesday, May 31, 2006, 12:57:38 AM, you wrote:

SR> That’s not it. windib is now default because a growing number of video
SR> drivers have broken DirectDraw support (remember, DirectDraw is an
SR> obsolete API since DirectX 8), and the SDL devs decided that
SR> reliability was a bigger priority than performance.

Care to name some?–
Best regards,
Peter mailto:@Peter_Mulholland

I’ve seen some problems with some intel integrated cards. However in
all cases a windows update fixed it.

I haven’t heard of any other problems. There seems to have been more
problems from the switch to windb IMHO.On 5/31/06, Peter Mulholland wrote:

Hello Simon,

Wednesday, May 31, 2006, 12:57:38 AM, you wrote:

SR> That’s not it. windib is now default because a growing number of video
SR> drivers have broken DirectDraw support (remember, DirectDraw is an
SR> obsolete API since DirectX 8), and the SDL devs decided that
SR> reliability was a bigger priority than performance.

Care to name some?


Best regards,
Peter mailto:darkmatter at freeuk.com


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Everyone using Tux Paint on various Win32 versions who had one of the
following issues:

  • Weird mouse positioning issues in fullscreen
  • Weird mouse positioning issues with tablet PCs
  • Monitor sync problems in fullscreen
  • Crashes (or system reboots) on startup

…were able to solve those issues by swithcing to WinDIB.

(As a strange datapoint, many desktop users were mentioning they were on Dells.
Dunno if that matters, but I was assuming Dell was shipping broken up DX.)On Wed, May 31, 2006 at 01:02:03AM +0100, Peter Mulholland wrote:

Hello Simon,

Wednesday, May 31, 2006, 12:57:38 AM, you wrote:

SR> That’s not it. windib is now default because a growing number of video
SR> drivers have broken DirectDraw support (remember, DirectDraw is an
SR> obsolete API since DirectX 8), and the SDL devs decided that
SR> reliability was a bigger priority than performance.

Care to name some?


-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/