Alpha blending for 2D games has to be done "by hand" without hardware support,right? Does anyone know a link to a good tutorial for directx?

http://www.gamedev.net/reference/list.asp?categoryid=40

Just scroll down to "Alpha blending".

If you're working for directdraw and are refreshing the screen every frame then there is a work around. You can draw something one frame and not draw it the next. This gives it a very convincing transparency as long as the screen is refreshed at at least sixty frames per second. It's also very CPU efficent in that you only have to do half of the work instead of extra work. However, it doesn't look so good for screenshots.

Or colourkeying every other pixel gives the impression something is transparent.

It's perfectly viable to use hardware acceleration for 2D graphics to take advantage of all the goodies like hardware alpha blending, scaling/rotation and so on. Just render everything with polygons and use orthogonal projection or pre-transformed vertices. I don't have any good links at the moment, but google for tutorials (most introduction tutorial will probably cover 2D triangles before moving on to 3D triangles), or read the documentation that comes with the directx sdk. :)

Just render everything with polygons and use orthogonal projection or pre-transformed vertices.

... and be a lazy future-less programmer

Originally posted by lakibuk
Alpha blending for 2D games has to be done "by hand" without hardware support,right? Does anyone know a link to a good tutorial for directx?

This isn't DirectX, but SDL (http://www.libsdl.org) has built in alpha blending with MMX acceleration. It's as good (or decent) as 2D alpha blending gets. My problem with using 3D acceleration for that kind of stuff is that you're cutting out a portion of your potential customers. My philosophy is: stick to DDraw for 2D games, and use OpenGL/Direct3D for 3D games. Maybe in a few years when everyone has 3D hardware you can use textured quads, but until then if you want maximum compatibility I'd go with DDraw one way or another (SDL or DirectX).

The problem is compounded by the fact that a lot of people don't even have OpenGL drivers, and that you have to use a low version of DirectX for D3D (6 or 7 at most) because you can't count on people to have anything higher. Also, D3D has changed a lot since those days, so you'd be giving yourself an extra headache by having to write for an outdated API. By the way, SDL uses DirectX 5, so even people with Win95 could potentially play your game. :)

Originally posted by gregd
... and be a lazy future-less programmer

Lazy, sure, but I would actually argue that the future lies with hardware-accelerated graphics. To claim that I have no future as a game developer just because I don't write my own alpha-blending routines is a bit harsh. I had fun doing that back in the days when I wrote DOS games, perhaps 6-7 years ago. Think about how much PCs have evolved the last five years and then consider that your game will probably sell for the next five. Sure, you can argue back and forth about hardware rendering, but to dismiss it as if it was pure laziness is to not really a good reason...

Sorry, I don't want to start a discussion about software vs. hardware rendering. Lakibuk was asking if you had to do alpha blending by hand. I replied that you could possibly use hardware. Simple as that.

Originally posted by gregd
... and be a lazy future-less programmer

Greg, your comment could not be more wrong.

There are very few reasons any intelligent programmer nowadays would not use pre-transformed vertices and a hardware pipeline to handle 2D graphics. The first and most important would be if you felt that a significant portion of your customer base had insufficent hardware to utilize such technology. The second reason would be if you simply wanted a software fallback to utilize in case the user had buggy video drivers and/or for trouble shooting (see Rad Game Tools' Pixomatic system...that is primarily what they market it for.)

Hardware is far faster and will give you much better visual results (clock for clock) than software rendering. You can scale, rotate, geometrically distort, tint, alpha blend, and many other such things for very little effort and, if you code it correctly, with an almost imperceptible performance hit on any mainstream graphics card made in the last several years.

Would you care to wager how professionally developed games today handle 2D display systems like the user interface and text? Yes, that's right...they use 3D hardware and pre-transformed vertices.

- Roulette

Originally posted by gregd
... and be a lazy future-less programmer
I'm with everyone else saying this is completely untrue. Roulette's post was right on the mark. The only reason to not use 3D acceleration for 2D is if you think your target market won't have good 3D support.

A this point in time, even operating systems (OS X, Longhorn, some Linux window managers) are using 3D acceleration to render their 2D GUIs, largely because 3D cards can do rotation, alpha blending, etc. so fast.

Another added benefit is you get pixel shader support on higher-end hardware. With pixel shaders you can do a lot of very cool 2D effects that may be too slow in software.

I agree BIG-TIME with the comments about having a software fallback to deal with potentialy buggy drivers or very low end video cards. The software fallback does not have to have all the functionality of the hardware version: just enough to make the game playable (example: while the hardware version has transparency levels from 100% - 0%, the software version might have only 50% or use a stipple effect.)

Someone mentioned Pixomatic; while that tool is far too expensive for most of us here ($10,000) their web site does make a compeling argument for the use of a software renderer.

Two interesting cavets in closing:

* Real Arcade, on their developer information site, recommends that game authors NOT assume, or NOT requier 3d hardware. Hmmm, maybe they know something we don't ...

* PopCaps most recent game, DOES support 3d hardware acceleration for 2d effects, but it is OFF by default. Maybe they've choosen to have their game start up in the more stable mode (Real also recommends this) as to have better control over the all important first impression (i.e. a game that looks GOOD and RUNS, as opposed to a game that looks GREAT but CRASHES).

PS. all these comments refer to the use of 3d hardware for 2d effects.

David

Originally posted by BitBoy
Lazy, sure,

I don't get it. How is it lazy? Other points have been made, but it's not lazy when it solves the problem efficiently either technically or in terms of development time. The goal is profitability, not macho-ism.

This post is best read with a glass of beer, wine, your favourite pipe weed, or chill pill. Or not. Nothing profound to read here, but I've allready typed it all up, and pressed preview a few times, and it's the submit buttons turn. It gets jelous if it doesn't get as much text as the preview button.

It(rendering everything with polygons) is lazy because it is not optimal, and it is fairly easy to make many 2D games that support optimized software alpha blitters and hardware accelerated alpha blitters. It is not optimal as not as many people can play your game. Which is why I think not doing so is lazy for certain types of games.

Lazy:
1. Resistant to work or exertion; disposed to idleness.
2. Slow-moving; sluggish: a lazy river.
3. Conducive to idleness or indolence: a lazy summer day.
4. Depicted as reclining or lying on its side. Used of a brand on livestock.


Ok, maybe it is not lazy.

Of course, laziness is a good thing, so even if it was lazy you would still be going well!

Not supporting as many users as possible could mean less profitability, or no profitability. Not all users have sufficiently non buggy video drivers installed, even if lots have perfectly fine accelerated video cards. Or it is not possible, or wanted to install new drivers in places of work, or education. Directx is even buggy on lots of computers. Some only have dx3 etc.

Go 2 color gdi graphics, and ascii!

SDL is nice because it supports using GDI, dx3 on windows. Meaning most people on windows should be able to run your game. As a bonus you get fairly fast mmx alpha blitters, and porting to Mac, linux etc becomes really easy.

For a 3d game, the upcomming mesa3d with opengl should be good for compatibility. If the computer doesn't support accelerated OpenGL, you can use mesa3d. It can use dx 7,8,9 for backup 3d acceleration, with mesa software for backup.

With this new found compatibility, you still have to design your game to run fast enough on the wide range of different speed computers you support. Making the game run, and look nice on all of the different speed computers is lots of work. Some game designs are impossible(or less interesting) without large amounts of graphical ability. eg 5 moving sprites on screen compared to 100, or 50,000 of them.

I use opengl, wrote one of the mmx sdl per pixel alpha blitters, and wrote an opengl backend for sdl(well pygame) so I know it is possible to make a fairly compatible game with alpha blending. It is pretty hard work, unless the game design doesn't call for many moving sprites. Luckily many types of 2D games do not need lots of moving sprites.

ps, try using color keyed graphics. Much faster. It is often 2d hardware accellerated and can run really fast even on the slowest of machines. There are games which use SDL at 640x480 run with many sprites on the screen at once on my lowly p166mmx.

Color keyed graphics are where you have say pink in your image as the transparent color. Gif transparency is an example of this. If you have a constant colored background , you can set the pixels on the edges to the background color; antialiasing them in your image program. Otherwise you have to live with jaggies. Unless you get a pro pixel artist :)


Have fun!

95% of commercial PC game are in 3D with the lastest directx. They sell million of game. How they do this ?

And every computer which have a commercial 3D game for the last 2 years have a recent directX install for our shareware game isn't it ?

Maybe person who play puzzle game don't have a good computer. But for other game, I think people interested in that kind of game have at least geforce 1.

If you make 2D game more people can try your game. But this kind of people which don't invest in their computer for game (a computer with more than 4 year), do they buy game or just donwload and try it ?

I think "2D only" argument is only good for puzzle game, or If people who buy sharewaregames never buy (or get a free copy ;) ) commercial's games.


PS: sorry It's little out topic, but this kind of interrogation was in my mind.

For my games I use 100% software rendering, using SDL. This includes alpha blending effects. I can get away with this because of a dirty-rectangles approach - I only refresh what changes on the screen. If my game is modest enough that little changes at any one time, the performance is excellent.

It's a bit unfortunate that I still haven't properly solved the problems of rotating or scaling images, or even of drawing good looking lines (what year are we in again? ;) ) but then again, I can freely use alpha blending, for things as useless as 3d effects around buttons without shame.

I can live with losing 35% (actual statistic) of my Windows downloaders in the knowledge that I'm not really losing 35% of my sales. If I were using DirectX I'd probably get 90% success rate but I'm also after the Mac and Linux "market" and I don't want to do any extra programming that I don't have to do, nor make irritating technical compromises for trivial performance reasons.

There's no real future in coding alpha blending yourself, or even of using someone else's software renderers. It's very much the same dilemma that FPUs caused in the early 90s. You can stick with fixed point and LUTs but it's a huge pain and nowadays you'd be daft not to use floats and let the compiler take the pain away. Same goes for using an abstraction API and letting the hardware do the blitting.

Cas :)