Windows NT4 issues

I’m an SDL beginner, using SDL-1.2.3 on a PPro 200/NT4 with a Matrox
Mystique 8Mb video card. I have a demo MSVC6 program that does some
simple video things (no OpenGL), and I’m seeing some odd behaviours.
I’d like to know if these are likely to be caused by my hardware, by the
Windows implementation of SDL, or by my code. I already sent a code
sample to Sam, so I won’t send it again unless requested.

I’ve been testing use of the palette with 8-bit graphics. One problem
I’ve observed is that when I paint the screen with vertical stripes with
pixel values going from 0 to 255 (i.e. each stripe is 4 pixels wide and
has a constant pixel value), the last few stripes displayed (i.e. those
with pixel values from about 246 - 255) all display the same colour,
which I think is that associated with 255.

When I repeatedly recreate the palette table (actually I’m cycling it) I
observe that the rate at which the screen display changes gets slower
the longer the program runs. What can cause this slow-down? Also the
time taken for the program to completely terminate and return control to
Windows seems to be proportional to how long the program ran for.
Sometimes it is distinctly unwilling to restore the screen (i.e. MS Dev
Studio). Another (probably insignificant) little thing I’ve noticed -
there is hard disk activity as my program runs, though my code is not
writing to any files at that stage.

Perhaps these various effects have a single cause. Are there any
general things I should know about SDL with Windows? Ultimately the
code I’m developing will run on Linux. Should I expect such
difficulties to disappear with Linux, or is life likely to get more
complicated?

Thanks for any advice
Gib--------------------------------------------
Gib Bogle @Gib_Bogle
1/44 Arthur St Tel: (64-9) 525-6878
Ellerslie, N.Z. Fax: (64-9) 525-6878

Gib Bogle wrote:

I observe that the rate at which the screen display changes
gets slower the longer the program runs. (…) Also the time
taken for the program to completely terminate and return
control to Windows seems to be proportional to how long the
program ran for. (…) Another (probably insignificant)
little thing I’ve noticed - there is hard disk activity as
my program runs, though my code is not writing to any files
at that stage.

This sounds like memory leaks.

Hi

With regards to your first question – this is normal behaviour. When
running in windoweed mode, windows reserves 16 (I think) colours to display
the desktop, menus, icons and suchlike. This explains why you are only able
to individually access 240-some of the 256 colours.

Your second problem sounds like you almost certainly have a memory leak. Run
your program with Windows Task Manager on screen - you will almost certainly
see the memory going up and up… This also explains the hard disk activity
(swapping).

Check your code and see that you are not repeatedly creating a memory
resource and never releasing it.

Best wishes,

Steve> ----- Original Message -----

From: Gib Bogle
To: sdl at libsdl.org
Sent: 24/12/01 04:21
Subject: [SDL] Windows NT4 issues

I’m an SDL beginner, using SDL-1.2.3 on a PPro 200/NT4 with a Matrox
Mystique 8Mb video card. I have a demo MSVC6 program that does some
simple video things (no OpenGL), and I’m seeing some odd behaviours.
I’d like to know if these are likely to be caused by my hardware, by the
Windows implementation of SDL, or by my code. I already sent a code
sample to Sam, so I won’t send it again unless requested.

I’ve been testing use of the palette with 8-bit graphics. One problem
I’ve observed is that when I paint the screen with vertical stripes with
pixel values going from 0 to 255 (i.e. each stripe is 4 pixels wide and
has a constant pixel value), the last few stripes displayed (i.e. those
with pixel values from about 246 - 255) all display the same colour,
which I think is that associated with 255.

When I repeatedly recreate the palette table (actually I’m cycling it) I
observe that the rate at which the screen display changes gets slower
the longer the program runs. What can cause this slow-down? Also the
time taken for the program to completely terminate and return control to
Windows seems to be proportional to how long the program ran for.
Sometimes it is distinctly unwilling to restore the screen (i.e. MS Dev
Studio). Another (probably insignificant) little thing I’ve noticed -
there is hard disk activity as my program runs, though my code is not
writing to any files at that stage.

Perhaps these various effects have a single cause. Are there any
general things I should know about SDL with Windows? Ultimately the
code I’m developing will run on Linux. Should I expect such
difficulties to disappear with Linux, or is life likely to get more
complicated?

Thanks for any advice
Gib


Gib Bogle bogle at ihug.co.nz
1/44 Arthur St Tel: (64-9) 525-6878
Ellerslie, N.Z. Fax: (64-9) 525-6878


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


This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com


It is hard to see how I can be creating a memory leak, since I allocate
no memory. In fact, all my program does is repeatedly call
SDL_SetPalette() with a revised color table. The first full cycle
through the palette, i.e. 256 calls to SDL_SetPalette(), takes 11
seconds. Successive cycles take 15, 21, and 28 seconds!???

However, I am now (belatedly) looking at the available video card
information, using SDL_GetVideoInfo(), and what I see surprises me.

Video driver: windib
Hardware surfaces are NOT available
Window manager is available
Hardware to hardware blits are NOT accelerated
Hardware to hardware colorkey blits are NOT accelerated
Hardware to hardware alpha blits are NOT accelerated
Software to hardware blits are NOT accelerated
Software to hardware colorkey blits are NOT accelerated
Software to hardware alpha blits are NOT accelerated
Color fills are NOT accelerated
Video memory: 0 Kb

The Matrox Mystique has 8 Mb of VRAM, and the NT driver is dated 1998.
If SDL thinks that I have no video memory, I guess all kinds of strange
behaviours are possible. Can someone please enlighten me about
supported video cards. Am I just out of luck with this card? Since I
am thinking about a new machine, I’d like to know what are the
recommended video cards, for both W2k and Linux (priority).

Gib

Hi

SDL on Win32 uses DirectX 5 or later for its hardware acceleration. Windows
NT 4 only supports DirectX 3.

I am not speaking completely authoritatively on this matter but I do suspect
that this is where your problem lies. Perhaps someone else can confirm this?

Either you are creating a memory leak, or SDL is - why don’t you post a code
fragment showing what you are doing?

Someone else on the list will be able to confirm the behaviour you are
seeing, or point out where the problem is.

Regards,

Steve> ----- Original Message -----

From: Gib Bogle
To: sdl at libsdl.org
Sent: 24/12/01 22:36
Subject: [SDL] Re: Windows NT4 issues

It is hard to see how I can be creating a memory leak, since I allocate
no memory. In fact, all my program does is repeatedly call
SDL_SetPalette() with a revised color table. The first full cycle
through the palette, i.e. 256 calls to SDL_SetPalette(), takes 11
seconds. Successive cycles take 15, 21, and 28 seconds!???

However, I am now (belatedly) looking at the available video card
information, using SDL_GetVideoInfo(), and what I see surprises me.

Video driver: windib
Hardware surfaces are NOT available
Window manager is available
Hardware to hardware blits are NOT accelerated
Hardware to hardware colorkey blits are NOT accelerated
Hardware to hardware alpha blits are NOT accelerated
Software to hardware blits are NOT accelerated
Software to hardware colorkey blits are NOT accelerated
Software to hardware alpha blits are NOT accelerated
Color fills are NOT accelerated
Video memory: 0 Kb

The Matrox Mystique has 8 Mb of VRAM, and the NT driver is dated 1998.
If SDL thinks that I have no video memory, I guess all kinds of strange
behaviours are possible. Can someone please enlighten me about
supported video cards. Am I just out of luck with this card? Since I
am thinking about a new machine, I’d like to know what are the
recommended video cards, for both W2k and Linux (priority).

Gib


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


This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com


Steve Lupton wrote:

Hi

SDL on Win32 uses DirectX 5 or later for its hardware acceleration. Windows
NT 4 only supports DirectX 3.

I am not speaking completely authoritatively on this matter but I do suspect
that this is where your problem lies. Perhaps someone else can confirm this?

Either you are creating a memory leak, or SDL is - why don’t you post a code
fragment showing what you are doing?

Someone else on the list will be able to confirm the behaviour you are
seeing, or point out where the problem is.

I have sucessfully compiled code with VC++ 6 using SDL with NT4 SP6 with
a Matrox G200 card ( using only software surfaces tough ). I use 800x600
16-bit so there’s no palettes involved. When I shifted to hardware
surfaces the whole thing freaked out - since I have the same problem
when using Linux I guess it’s a bug of mine. Which will be hunted down
and killed in it’s time. I don’t remember which version of DirectX i
have installed.

Sincerely,
Magnus> Regards,

Steve

-----Original Message-----
From: Gib Bogle
To: sdl at libsdl.org
Sent: 24/12/01 22:36
Subject: [SDL] Re: Windows NT4 issues

It is hard to see how I can be creating a memory leak, since I allocate
no memory. In fact, all my program does is repeatedly call
SDL_SetPalette() with a revised color table. The first full cycle
through the palette, i.e. 256 calls to SDL_SetPalette(), takes 11
seconds. Successive cycles take 15, 21, and 28 seconds!???

However, I am now (belatedly) looking at the available video card
information, using SDL_GetVideoInfo(), and what I see surprises me.

Video driver: windib
Hardware surfaces are NOT available
Window manager is available
Hardware to hardware blits are NOT accelerated
Hardware to hardware colorkey blits are NOT accelerated
Hardware to hardware alpha blits are NOT accelerated
Software to hardware blits are NOT accelerated
Software to hardware colorkey blits are NOT accelerated
Software to hardware alpha blits are NOT accelerated
Color fills are NOT accelerated
Video memory: 0 Kb

The Matrox Mystique has 8 Mb of VRAM, and the NT driver is dated 1998.
If SDL thinks that I have no video memory, I guess all kinds of strange
behaviours are possible. Can someone please enlighten me about
supported video cards. Am I just out of luck with this card? Since I
am thinking about a new machine, I’d like to know what are the
recommended video cards, for both W2k and Linux (priority).

Gib


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


This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com



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

Steve Lupton wrote:

SDL on Win32 uses DirectX 5 or later for its hardware
acceleration. Windows NT 4 only supports DirectX 3.

SDL falls back to “windib” on NT4, it doesn’t use DirectX.

  • Randi

Regimental Command
Generic Armored Combat System
http://regcom.sourceforge.net