Anyone got a 24-bit or 16bit Graphics Card?

If so would you be kind enough to test this exe out for me on your PC:

http://www.greyaliengames.com/misc/Screentest.zip

On a 32-bit machine it runs and shows a black screen with white writing saying "Current Mode = 32-bit". Also is should run on 24-bit and 16bit cards and show the correct message. If it fails to set either of those modes it should run in windowed mode and say Current Mode=0-bit.

This is using my framework code to auto-downscale to the video card capabilities. However I've had reports that it's not working but I'm unable to test it as we've only got 32-bit cards here.

You will need to have DX7 installed (although in theory it should swap to OpenGL if that is not present).

Thanks in advance!

In 16-bit I get "Current gfx mode = 32-bit"
Win98se and ATI Radeon VE/7000 (which supports 4/8/16/32-bit).

Thanks for testing. You mean you have your desktop set to 16-bit but the card can support 32 bit right? Current Mode will be the full-screen mode it is using which is not the same as the desktop bit depth. What I really need to do is test a card which has no 32-bit capability.

Oh, okay sorry.

Alpha -> 16 or 32bit, 24 has no alpha. 16Bit has visible or invisible alpha only.

Reality: Cards that only capable of 16Bit (24 are out, 24bit mode is for desktop but totally worthless for games) will not run BM made games usefully. The last cards that were that slow that they needed that, don't have Hardware TnL ie they are not fully DX7 compliant.
They will suffer seriously from the full 3D approach of BlitzMax 2D support which will put an even larger strain on the CPU due to the missing TnL units. Those card most likely as well will have some pretty heavy constraints on the amount of VRAM that you can use.

What I first would need to check is how the Max2D handles image loading if you are on 16Bit only ie if you need to provide 16bit image data (would suggest to do that anyway so you see how the image will look at 16bit because automatic driver done conversion of the pixel formats can end in an ugly textures that only resembles the original very vaguely)

Dreamora- the intel 810 chipset is 16 bit only in fullscreen, that ran games quite well, and I don't doubt it'll handle Max just fine since it ran my old quad2 game with 64 cars just dandy, the cars were really low poly but they were 5 entities each so quite a bit of strain. Ran fine at 60fps with full texturing.

So while rare, these chipsets are around and it is important to try to support them. The system I am talking about was a celeron 1.2 with intel 80810 onboard gfx.

5 cars = 5 images (or 25 if they had 4 distinct wheels each) ... the amount of poly isn't the problem ... the amount of distinct objects that need to be transformed thought is ...

Show me a 2D game where you need less than 100-200 images ...
and thats the point where missing TnL will start to become a problem at least if you try to rotate and scale them in realtime all the time.

To work great on low end cards, a more batching oriented system that reduces the amount of transformation state changes would be very suitable. On modern GPUs that driver that once was created for DX7 didn't do much usefull ... but on a stone age pre 3D cards (intel before GMA900 and the like) it would reduce the amount of matrix multiplications that have to be done by the CPU.

I wrote tons of 2D games in 3D on that old chipset. :-)

Saying that I am leaning towards agreeing because Max has slowed down on my modern machines doing a 2d tilebased game.

You don't need your graphics mode to have an alpha channel in order to do alpha blending. Whether the 16-bit mode is 5:5:5:1 or 5:6:5 it doesn't matter, alpha blending uses the alpha from the source image not the destination display. Same goes for 24-bit screens. There is nothing in BlitzMax at the moment that uses the destination alpha channel.

Also some people's machines wil have support for 16-bit and 32-bit modes. If I set my desktop to 16-bit and run a Max2D program on it, the internals will likely be 32-bit and it will likely tell me that the color buffer is 32-bits depth, because it either dithers or downscales the colors when you do a Flip(), to convert to the desktop format. Similar to how it works for 256-color modes. Interally textures might still be stored as RGBA8888 32-bit data even if the screen is 16-bit, unless you specifically specify that you want textures stored as 16-bit data and only if the hardware supports that.

So I'm now confused, at first it seemed that 24-bit and 16-bit cards may not be worth supporting as a) they may be too slow and b) they may not render Alpha properly. But then we've heard that they may be quite fast on some systems and that alpha should actually work properly (which was my understanding of it and if I make a 16-bit graphics mode in BMax all my particles work fine, unless Bmax is actually still making it 32-bite for some reason...).

Here's the specs of one of the failing system (from DX Diag):

   Operating System: Microsoft Windows 2000 Professional (5.0, Build 2195) Service Pack 4
           Language: English (Regional Setting: English)
          Processor: Intel Pentium III, 1000MHz
             Memory: 254MB RAM
          Page File: 70MB used, 546MB available
    DirectX Version: DirectX 7.0 (4.07.00.0700)

        Card name: Intel(r) 82815 Graphics Controller
     Manufacturer: Intel Corporation
        Chip type: Intel815
         DAC type: Internal
        Device ID: Enum\PCI\VEN_8086&DEV_1132&SUBSYS_00BE1028&REV_02
   Display Memory: 4.0 MB
     Current Mode: 1280 x 1024 (16 bit) (60Hz)
          Monitor: Plug and Play Monitor
  Monitor Max Res: 1600,1200
      Driver Name: i81xdnt5.dll
   Driver Version: 5.12.01.2641 (English)
      DDI Version: 7 (or higher)
Driver Attributes: Final Retail
 Driver Date/Size: 8/8/2000 16:18:36, 608640 bytes
 Driver Certified: Yes
              VDD: 
         Mini VDD: i81xnt5.sys
         Registry: OK

Sounds pretty crappy. Do you think it really only has 4Mb Ram, surely it must share system RAM? Perhaps this is simply too underpowered and I'm chasing a red herring...

work fine on mine :)

E6750 with 2GB Ram and Geforce 8800GTS 640MB

no chance to get it to work on that machine.

4MB of VRAM?
That means 640x480 is the total maximum screen resolution.
And even that already takes 1.2 MB of VRAM just for Backbuffer

And no that are 2D Cards, they didn't have shared RAM normally, as thats a card of the PCI generation. PCI was to slow for shared RAM, that feature was introduced with AGP.
The fact that DXDiag does not show that clearly makes this a fact as well.

Without implementing a pure 2D driver on base of DirectDraw (similar to BlitzPlus / Blitz3D 2D commands), which removes Alpha, rotation and scale in realtime, there is not the least chance to get that working.
DirectDraw works because its mainly using CPU and RAM, not GPU and VRAM

Alternative: trying to make a 2D renderer using something like Irrlichts apfelbaum software renderer, ie a high performance 3d software renderer.
Don't know, does Mesa3D exist? then you could use that one and fallback to OpenGL on such CPU based systems.

Yep, I'd say it's a pretty safe bet that this particular card is going to fail no matter what you do.

I wouldn't bother with that card, it would be lucky if B3D would work with that thing. Most onboard cards are rubbish and a waste of time. If it doesn't support 32-bit it's crap.

Hmm...

"Current Mode: 1280 x 1024 (16 bit) (60Hz)"

Yeah that = 2.6Mb VRAM. Maybe it only has a single buffer?

Anyway thanks all, the issue has been written off after I said the card was a no hope (I'm not coding any software rendering to support a minority).

Yah there's no reason why you couldn't do alpha blending on 16-bit and 24-bit screens unless the graphics hardware or driver does not support the blending portion of the API, which would be silly.

Alpha blending pseudocode:

SourceAlpha=Value of the alpha channel pixel in the image you are drawing
SourceRed=Value of the red component in the image you are drawing
SourceGreen=Value of the green component in the image you are drawing
SourceBlue=Value of the blue component in the image you are drawing

DestRed=Value of the red component already drawn on the backbuffer
DestGreen=Value of the green component already drawn on the backbuffer
DestBlue=Value of the blue component already drawn on the backbuffer

An example:

Source image pixel is $FF,$88,$33,$80 (alpha is about 128 on a range of 0..255)
Dest image pixel is $22,$66,$AA (who cares what the dest alpha is, not used)

AlphaScaleSource=(1.0/256)*SourceAlpha (convert it to a number between 0 and 1)

SourceRed=SourceRed*AlphaScaleSource
SourceGreen=SourceGreen*AlphaScaleSource
SourceBlue=SourceBlue*AlphaScaleSource

AlphaScaleDest=1.0-AlphaScaleSource (invert the alpha value to get what's left in the dest)

DestRed=DestRed*AlphaScaleDest
DestGreen=DestGreen*AlphaScaleGreen
DestBlue=DestBlue*AlphaScaleBlue

FinalRed=Max(255,SourceRed+DestRed) (combine source and destination contributions)
FinalGreen=Max(255,SourceGreen+DestGreen)
FinalBlue=Max(255,SourceBlue+DestBlue)

SetColor FinalRed,FinalGreen,FinalBlue
Plot X,Y

Nowhere in this process is the destination alpha value used or needed. The source alpha is used only to scale both the source pixel colors and the destination pixel colors, which are then added together. So if you have 256-color displays, 15-bit, 16-bit, 18-bit, 24-bit, it doesn't matter. So long as there is support for blending in the driver, which is usually in hardware, alpha blending will work. And in Blitz, your source image will likely have 8-bit alpha channels, regardless of how much bit depth the screen has.

Grey Alien, Going back to your dump- Thats an inteil 8081x chipset like mine. It *should* be capable of running max fine.

It does have 4mb of ram, but does also use system ram- this is in the driver level. I believe my system used 64mb of ram altogether.

MarkCW- that card runs B3D apps just fine. My racer for example.

I no longer have access to the card so can't do any further testing.


Anyway, thinking about it the machine with that card was from 2001, and the chipset was old back then already, so you've probably chosen right not to worry about it.

OK thanks both, interesting info. I thought it must be using some system RAM and just DX was not reporting it.

These kind of issues are only going to occur on computers well over 5 years old, anyone seriously trying to play a game on one of these is either going to be used to having to deal with these kind of problems or (more likely) doesn't buy any current games because they know they won't work properly.

It's definatly not worth the time and effort to support this small number of potential buyers. The problems you can have are legion and the return is almost always going to be negligible. IMHO you'd be much better off spending the time on improving the game and simply raise the system requirements slightly than trying to deal with all the potential problems.

Fully compliant DX7 cards have been available since 1999.

Darkheart

Just a complement: you can even do alpha blending on 256 colors (aka 8 bit) resolutions - I did it once on a DOS game prototype (simulating darker and lighter areas in the game) - the only drawback is that both imagest can't use all colors - you need at least some colors free to calculate the resulting colors when the images overlap ;)

Also there's no way a 4Mb card can achieve "decent" 1280 x 1024 on windows -- unless it's using shared RAM, but even then, it should be too slow for any real use...

You can not do alphablending ON HARDWARE (what BM does, BM has no software fallback) below 32Bit.
At 16Bit it initializes single bit alpha if alpha at all (normally 16bit is not a1r5b5g5 but a0r6g5b5), so you don't get any alpha blending anymore on the hardware side.
Having a 16Bit display enforced as well means that the hardware is seriously trash and has serious problems at working with 32Bit textures so you can not even use those parts behind the scene.

Thats why I suggested Apfelbaum or something a like as base for a software based solution. Much higher chance to be successful than trying to use "hacks" and trash like that. Games that ran on those cards were pure CPU driven actually so get a driver that does the same.

Hmm. I guess if 32-bit is really not supported at all even for textures then images will at best have 1-bit alpha and maybe not even that, so then they would not be able to do blending at all, or it would be an on/off masking.

Judging by how many people have 16-bit desktops these days which is a really small percentage I don't think it's worth trying to support. Everyone is going to be at 32-bit in the new year or so probably.