Hello, maybe someone can help me? I have a big problem with Color Key transparency! Instead of using 3D tree models, which slow down my game greatly, I decided to just load in a texture of a tree, color key the black background and use bill boarding technique to make them face the camera. All went well, until I tried the game on my older Intel computer, which has a 4mb integrated graphics card. The black background around the trees was still there! Color key doesn't work on that video card, I even tried updating to the latest drivers. So my question is, will this really hurt my sales or do most graphics cards support color key transparency? I really don't want to give it up and use 3d models as the frame rate drops to 30fps - for a racing game I think it’s unacceptable.

Any suggestions appreciated!

I assume you are using your color key to build an alpha channel, AFAIK color keys per se are not really used with 3d cards. Have you tried various combinations of alpha blend and alpha test? I seem to remember some problem with alpha on very old intel cards, but you could get at least basic transparency. But to answer your question every half way modern card supports alpha transparency.

Jack

i'll bet ya it must be that piece of garbage by intel called
I740.

Intelgooks never bothered to release proper drivers for it.
They basically ripped off buyers by never updating or fixing
their driver bugs. It's a dead product anyway.

I have one lying somewhere in the closet.

Actually its a piece of garbage called Intel 82810. I tried everything, nothing seems to fix the problem. Oh well, hope not too many people have graphics cards like that.

aha! the i810 is a built in gfx chip for *MANY*
motherboards released between 1998-2000 i think.

A LOT of cheap mobos with built-in gfx chipset used that.
It was the fastest built-in 3D chipset that time.

Targetting 2D games on those machines are ok, but
for 3D, better think properly.

Try running DXCapsViewer.exe on that machine, and have a look at the texture formats supported by the card. It is true that in 3d, no colorkeying is being used, instead it makes use of alphachannels (though there is a helper function in the D3DX library to create a texture from file, where you can specifiy a colorkey. Internally it is converted to an alphachannel anyway). If your card does not support any texture format with alphachannels, there's not much you can do, really.

On the other hand, even though many might say that 30 fps is not acceptable for a racing game, extensive studies have shown that players are not able to tell the difference between racing games that run at 60 or 30 fps. Bystanders might be able to differentiate between it, but not the player.

I sure as hell could. hehehe...

But you need to understand, those days are over.

Long ago monitor vsync refreshes at a fixed 50/60 hz

so theoritically if you sync the frame rate to those hz you
can get very smooth scrolling and animation whether 2d
or 3d.

The problem is, you cannot guanrantee players will be
using those fixed hz anymore, some monitors come with
100 hz, some even more up to 120hz.

To get the smooth panning effect means we have to make
the game update as fast as the monitor would refresh,
which is impractical gameplay wise or processor usage wise.

Nowadays, preferably lock the game to 30 fps since it
won't make a difference if you go 60 fps on a machine that
has it's monitor vsync set above 60 hz.

As for console devices, you can safely assume a 50 fps interlaced
(25 frames non-i) for PAL units or 60 fps interlaced or (30 frames
non-i) on NTSC units.

I don't think that card supports alpha channels. I'm thinking I am going to lock the fps at 60 and work around that speed. This brings me to my next question. Is it better to fix your fps within your main game loop, or set the refresh rate when you are changing the display?

What I mean is:

DirectDraw.SetDisplayMode 800, 600, 16, 60, DDSDM_DEFAULT

the 60 in there represents the refresh rate you want. This works, and always keeps the game at 60fps. But I'm afraid if someone runs the game with a monitor that only supports say 50hz than they will get an error. So do you guys fix the frame rate within the game loop?

Thanks

Well, the topic of framerate in this post is a bit off topic I realize, since it was about color keys originally. But in relation to the subject of locking framerate. I let my game loop run wild. And I have a MotionScalar object, that you use to set the desired framerate. In this case 60. Motion.SetTargetFPS(60); Then You update it at the top of each run of the game loop. Motion.Update(); Then, treat you game as if it always runs perfectly at 60FPS, and when you want to assign a delta to something, SomeCoordinate.x = Motion.TranslationAdjust(50); The update gets the games current framerate. And creates a scalar value based on target framerate. You just multiply the scalar to all your motion, and your stuff moves appropriately. If the fps drops to 30, then that expect 50 units of movement would be doubled to 100, since it'll take twice as long to traverse the same distance at a lower fps. You'll want to make sure you have something like raycasting in you collision detection for this, cause a horrible even momentary drop in framerate will make an object displace by a large gap, and if you have no means of collision prediction, a bullet or something could completely bypass an object in it's path without consideration. I do realize most of you know this, but I see so many post that ask stuff like this when this subject is raised, I thought I'd speak up.

Originally posted by Mattias
It is true that in 3d, no colorkeying is being used, instead it makes use of alphachannels (though there is a helper function in the D3DX library to create a texture from file, where you can specifiy a colorkey.

Just to clear up on one point, in D3D 8.0 and above the color keying wasn't just a binary 'flag' but actually used the alpha channels in the images and so the color keying was superseded.

In D3D 7.0 and previous versions, there's no reason that you can't use color-keying and alpha channels at the same time.

You might want to make sure all of your textures are fitting in VRAM. Some older cards (dunno about the 82810 in particular) don't support color keying when the source texture is in system RAM. As Mattias mentioned, running DXCapsViewer might shed some light on the problem. Of course, if all your textures aren't in VRAM, you probably have bigger problems than color keying not working. :)

The 810 chip set had integrated graphics of basically a 740. I'm pretty certain that it does support alpha test. As others have said, I would avoid using color key (even if you're using DX7 or before) and opt for alpha test instead. And there are still quite a few of them out there. They sold lots - they were just about the same price as chip sets w/o the graphics down.

If you are already using alpha test instead of color key, you might check that your texture format isn't falling back to something that doesn't have an alpha channel. That was a 16 bit only card, so just a guess, but an ARGB8888 might be falling back to a RGB565 or something.

-Jeff
www.evertt.com (http://www.evertt.com)

During the development of XTM2 we've encountered one colorkeying related issue: at first we used colorkey in text drawing function (and chars were textured quads). Though it worked on my system some other systems just ignored the colorkeys, so we switched to textures with 1-bit alphachannel.
XTM2 uses DirectX7.