I know a lot of people use Direct3D for 2D engines. The benefits are things like hardware accelerated alpha blending which allows for lots of neat special effects, amongst other things.

Has anyone written a 2D engine using Direct3D or converted an existing 2D engine to 3D low level calls? All my low level stuff is wrapped so it's easy to replace my blt functions with d3D calls and I already have a lot of this working, but I'm looking for advice on the approach to take or any advice that might help from someone who's done it before.

If you read this post (http://www.dexterity.com/forums/showthread.php?s=&postid=612#post612) you'll see an explanation of why I converted my game engine that was using (2D in 3D) dx8.1 to render 2d graphics to using allegro which is based around DirectDraw5. ;)

I would advise against doing it. You are then requiring a 3D accelerator to play a 2D game, which will seriously hurt your sales. Allegro has some nice alpha stuff, but from my tests, it has some nasty compatibility issues too :-(

I understand the potential comaptibility issues, but the fact remains that I can't do in pure 2D what I want to do.

Anyway my engine will be able to use either-or and not one or the other based on some flags, so I'm adding functionality not removing anything. I would never go out of my way to make a pure 2D game, like a card game say, use 3D hardware for no reason. On the other hand, a unique new game that requires a lot of alpha blending and real time lighting will not fly in pure direct draw no matter how clever you are and how much assembler you write because at the end of the day you'll face some hardware bottlenecks that are unsurmountable.

Allegro is ok, but it's a much lower level tool than what I have available to me already. I can already do far more than allegro provides, and as fast etc... I really need to go a step beyond that at this point.

There's an article on Gamasutra that soemone pointed out called "2d programming in a 3d world" that's of interest if anyone wants to read up on the subject.

Originally posted by svero
I understand the potential compatibility issues, but the fact remains that I can't do in pure 2D what I want to do.

Anyway my engine will be able to use either-or and not one or the other based on some flags…

At the risk of sounding argumentative I will say that it seems like your contradicting yourself here. First you say that your game requires 2D in 3D then you say your engine will be able to use either or... I guess I’m not following you.

If your game really does need hardware acceleration then so be it, that's where the things like alpha blending become easier/faster to do. In software mode however the alpha blending is going to be every bit as slow as doing it in direct draw. So basically by saying what you want to do is only possible in D3D you are indirectly saying what you want to do can only be done with hardware acceleration. If you plan for that from the beginning then you might as well go all the way and use all the benefits of hardware acceleration. However if you’re going to toe the line and say “well it doesn’t necessarily need hardware acceleration…” then you should probably be looking at a pure 2D implementation.

I've read the gamasutra article and it was one of the references I used when originally doing my tile engine in DX8.1. I would like to clarify however that Allegro is actually higher level, not lower level then DirectX. You can set up an application and have it blitting an image to the screen in about 10 lines of code. Try doing that using a d3ddevice ;)

>At the risk of sounding argumentative I will say that it seems
>like your contradicting yourself here. First you say that your
>game requires 2D in 3D then you say your engine will be able to
>use either or... I guess I’m not following you.

I guess I wans't really clear. You're correct that it doesn't make sense. What I should have said was that, to achieve the level of quality I want in terms of the number of and quality of special effects in the game I require 3D hardware acceleration. However, the basic gameplay doesn't require it, so if a user has a slower system, or doesn't have directX support they could still play the game, without as many effects and niceties as I would like. For instance I want full antialiasing of in game characters but it's not an absolute necessity.

(edited in : Also I should note that allowing the engine to use either or is a general consideration, not specific to this game. I still have many other titles in the works that would benefit little or not at all by hardware accell so I want them to continue using the directdraw interface that already exists)

>and use all the benefits of hardware acceleration. However if
>you’re going to toe the line and say “well it doesn’t necessarily
>need hardware acceleration…” then you should probably be
>looking at a pure 2D implementation.

Again it comes back to quality. I could drop some effects, but I wouldn't be happy with the game. Better that I allow my vision to come through on more powerful systems. This is a game that will sell for the next 5 years and what's a little high tech today will be commonplace in 2 years.

>I've read the gamasutra article and it was one of the references
>I used when originally doing my tile engine in DX8.1. I would like
>to clarify however that Allegro is actually higher level, not lower
>level then DirectX.
>You can set up an application and have it blitting an image to >the screen in about 10 lines of code. Try doing that using a >d3ddevice ;)

I know it is. It's my internal company engine I was referring to, not DirectX which is basically unusable without a good set of wrappers. I can blt sprites moving all over the screen in a couple of lines of code, but I also have warping, timing, state mechanisms, animation control, realitime lighting, player tracking and many other nice function sets in my lib. My lib is a superset of allegro with some higher level functionality so it doesn't provide anything that I don't have already.

Well for my book I did use d3d8 for 2d graphics.

It may not be needed, but rotation, alpha blending, lighting are a breeze, and superbly fast even on old vcards. I did a couple of per pixel alphablending routines in assembly the other day which were ratehr fast, but compared to D3D8 they ran at about 2% of the speed. Now multiply this with various 500 different things being rendered, and you will see the bottle neck.

Sure you can do anything in 2D/DDraw and not use HW/D3D. But unless you like particles systems being pixels and not full blown alpha textures particles, I wouldn't recommend it. I have some amazing particle systems done in 2d using my engine that would be impossible to do without HW.

About being easy, its farily simple really. I did the engine in about a week includeing input/sound/music/physics/and variosu visual goodies (complete animation system, particle systems, lighting, etc). D3D8 is rather easy to pick up.

Now, if you are doing simple puzzle games (like Dexterity) where the audience is usually of non gamers, its a bad choice using D3D8, but if you are doing action games, where most customers will be people that play games everyday, requireing D3D8 isnt an issue.
Steve's point on most customer not having dx8 installed applied mostly to puzzle gamers. As just about any person that plays commercial games have the latest versions of DX8 and the non puzzle gamers also (do a search for action games on the net and you will see that most will use the latest technology, even freeware/shareware ones.


>I've read the gamasutra article and it was one of the references
>I used when originally doing my tile engine in DX8.1. I would like
>to clarify however that Allegro is actually higher level, not lower
>level then DirectX.
>You can set up an application and have it blitting an image to >the screen in about 10 lines of code. Try doing that using a >d3ddevice


Well allegro is as you said, a high level library that uses DDraw on the low level. about doing it in 10 lines of code, if you use a wrapper for d3d, it can take less (it takes 15 lines of code for me to create a window, setup a device, and render an animated image on the screen, using my wrapper.)

It's true, you can do something’s in 3D that are difficult, and yes sometimes impossible in a pure 2D engine. I do have some counter points I would like to mention however. Not for the purpose of converting you to my perspective or proving yours wrong, but rather to present my own perspective on the topic. Reading this is not likely to change your mind but it will make me feel better because you now know the basis of my perspective and why I see things differently.

The things you can do in 3D-2D game that you can't do in pure 2D game are typically different types of effects, perpixel alpha blending, lighting, bilboarded particle systems etc. I think it's important to shoot for the highest production quality you can with your game, but there are also costs to be evaluated.

When someone says I "need" special effects for my 2D game that only 3D enables me to have. I start to wonder, what is it about the gameplay and pure 2D elements that aren’t enough? It is often possible to "date" your game by using the latest 3D effects. If you look back at quake, when you fire a rocket down the hall and you get a little bit of colored lighting on the wall, a billboarded explosion and some flying particles (that are actually pixels) it looks pretty old. Because a lot of what makes ID's games cool is the latest technology, the majority people don't go buying quake today, they buy what ever the latest technology is. For ID that's Q3A. Essentially quake's shelf life is only as long as there is no technology better then it and once there is new technology quake looks pretty dated.

Compare this to a game like chronotrigger, or secret of manna. That game it timeless, it will still look gorgeous in 10 years from now. Blizzard has a very keen awareness of this and the impact it has on the lifespan of their products. Blizzard finally made a 3D game with WC3 but if you look at it the fanciest hardware trick they use is for their particle system. All the shadows for the buildings are actually textured polys for example. I believe with WC3 blizzard was able to recreate that same timeless quality by having some of the most gorgeous textures I have ever seen while staying away from the currently popular 3D effects. As a result WC3 is probably compatible with older cards and slower machines then any other 3D game released this year.

Aside from that there are also the market considerations. You're reducing the number of people who can play your game when you go to 3D. Weather they are limited by their bandwidth and don't want to download 20MB of dx8.1 or by their video card/processor which is too slow to run your game in software mode. Now I know you said your engine has a 2D mode, but you also said you needed 3D for effects. Chances are your game isn't going to look as good in 2D and people aren’t going to be compelled to buy it.

Since your game is a 2D game, wouldn't it be better from a "selling your game" standpoint to invest all your limited resources into the 2D version, enhancing the appeal of your game to a wider audience as well as sidestepping the "dated" issue that limits the amount of time you can sell your game before it becomes "outdated"? Games like Diablo, secret of manna, older final fantasies all show that you can have wonderfully high production values and a great looking game without relying on 3D gimmicks.

Anyway, that’s my piece. That's why I think staying away from D3D for 2D games is a good idea. For 3D games like 3rd or 1st person, or 3D puzzle games whose game mechanics rely on their being 3 dimensions I think that 3D is definitely the way to go. Just not for games that are inherently 2D to begin with.

Dan was the last topic in reply to my own ? Sorry it just some stuff in there I can't really relate to with my topic :)


Anyway, yes, games should focus on gameplay, but depending on the game, graphics are important. If you do a cool shooter, special effects are necessary (look at StrayFire). I'm currently doing a small shooter which all bullets are done with particles of some sort, why? Because shooter type game users are expecting to. The same way a user that is going to buy a FPS will want a good view, nice models. Same is one if going to buy a 3rd person view wants open/big environments. I don't believe graphics are a major point for games, and I'm an avid gamer, i buy 4-10 games a month (depending on the expenses at home) full blown commercial games (50 bucks) to 5-10 bucks shareware/old games. I've bought StrayFire but haven't bought any of the other older shooters from Dexterity. Why? Because for that kind of game, I like 'pretty thingies'.

The game I'm making is a 2d top down game, and as I said, all bullets are made of particles (tho I do have an option to use prerendered stuff) and they look fantastic. I've been able to do some effects that would take long to code, and much processing time to accomplish on non hw machines. And in case you are wondering, its a variable laser thingy that tracks and subdivides attacks (a sort of lightning thing).


Bruno

The question is, how much will a D3D approach limit your target audience and how many new customers (who dont usually buy 2d games because of the looks) can you reach.

Would be interesting to see a market research about this.

Especially, since you also have the option to target low end 3D cards and DX7 for instance, these are quite common.

And even more interesting is how these numbers will evolve in the next months and years.

One thing to also notice is the fact that old versions of DirectX start to not be supported neither by MS or the card manufactures. If some problems pops, it will be harder and harder with time to start finding whats wrong.

Akura: It wasn't targeted at anyone in paticular, its intention was to elaborate on my own perspective. I gues I used "you" in it somewhere but when I was typing it but I didn't have anyone paticular in mind.

I also purchased Strayfire, but mostly to support indie developers like Kurt Miller. Strayfire is a fun game and nicely implemented. But as a consumer trying the demos of the old "Raptor: Call of the shadows" and Strayfire, I would pick Raptor every single time. I'm not trying to say I represent all consumers, but I think the example is valid. A high production value 2D game that runs on most (all?) machines on the market today has more appeal then a 3D one. Strayfire is a good game, has some innovative shield use game play, but I lacks the depth of game play and the over all game experience that Raptor evokes.

Admittedly Kurt wasn't trying to make a better game then raptor, he was trying to finish a simple shooter on limited resources. But because a lot of those resources were spent making 3D effects, the resulting weapons are fairly un-imaginative and basically rehashing of the same weapon effect. I think if Kurt had spent less time on effects and didn't have to deal with the layer of complexity that 3D adds to a project he could have had more resources to spend on game play elements.

For instance raptor has both air and ground weapons, it has shields, auto tracking/heat seeking, weapons, money to buy upgraded weapons. All nice features that add a lot of fun game play to the game.

Is a game like MetalSlug (http://pixelation.swoo.net/viewtopic.php?t=995) look any worse because it's not in 3D? You can achieve marvelous effects without "needing" alpha-blended-billborded polys.

@Gabor, yes I would like to see some stats like that as well. Unfortunately I have not found any such stats to exist so I'm forced to rely on speculation and critical thinking ;)

@Akrua, I guess I take issue with this on two accounts. One older version of directX are always supported that's inherent in the design of Com. The DX5 interfaces in the DX8.1SDK are just as supported as the 8.1 interfaces. What Microsoft stops supporting is the operating system not the SDK's. So for instance there is no directx8.1 support on windows 95 machines. I guess the only way these old interfaces will die is if the card manufacturers do not correctly/fully support the old interfaces in their drivers. But Microsoft keeps a pretty tight leash on that kind of thing. Secondly when an interface like the DirectX5 interface has been around as long as it has, problems don’t just pop up, unless there's a problem with the manufacturers driver, in that case it would be the manufacturers support problem, not Microsoft’s.

Why not create a 2d engine that's software only, using ddraw to only get it to the screen (software only as in using system memory).

Okay I know people will jump on me for this but here's the thing, DirectDraw is great for blitting sprites to the screen, it's fast because it's hardware accelerated (about the only thing in ddraw that's HW Acceled) BUT you cannot do any cool effects with it because you have to read from video memory (vid mem is where ddraw get's it's blitting speed). The only alternative then is to go 8bit color (palettized - 256 colors) which is fine since in my opinion alot of games don't NEED more than that. You can do cool little palette effects, like fades and what not in 8 bit color. But if you want the effects like alphablending and what not you'll generally want to use 16bit color, and since reading from video memory is horrendously<sp?> slow, you'll want to do it another way.

This is where a software engine comes into play. Sure it *IS* slower than hardware acceleration, I won't deny it. But we have super fast computers nowadays, and software rendering shouldn't be an issue (unless your code is so highly unoptimized). Yes you *CAN* get decent results with effects in reguards to speed in a software engine.

Don't believe me? Just check out Hour 13 Studios game of "Chicken Little" it has all sorts of cool effects, and was done entirely in software. In fact check out a demo here - http://www.hour13.com/cl/ and ask Jake Stine (aka Air) what he did for it after you check it out, it's pretty amazing :-)

Okay people go ahead and yell at me now, asking me why would I even think of software (system ram) based systems, and telling me i'm crazy and all of that. And Air go ahead and yell at me for trying to get people to look at Chicken Little ;-)

There are more reasons for using 3D for 2D than just cool effects. For instance, the game I'm currently working on is top-down view. Normally this would mean drawing 36 (at least) directions of every frame of animation, for every sprite. I figured out however, that using OpenGL (same goes for D3D) I can use just ONE direction of every animation, and rotate it using hardware accelerated textured quad rotation.

This would require either pre-generating bit maps for every direction (for pixel perfect collision detection) or generate them at load time (though that might be too slow since each image would have to be rotated, then scanned to make the bit map). For collision detection, the game would look at the current angle of the sprite and find a corresponding bit map in a lookup table. Anyway, the point is that this technique allow me to have at least 36 times less art in the game, making the download size smaller, which means I can use the space for other things like music, or just to make a bigger game.

So what I'm trying to say is that 3D can be used not just because gameplay requires it, but because it could be of great benefit to you just in terms of easing development.

Here's a link to the Allegro Documentation describing how you can rotate (http://www.talula.demon.co.uk/allegro/onlinedocs/en/index014.html#rotate_sprite) sprites with allegro's API very easily. The performance on these rotation functions is very fast, I’m sure the difference between your 3D OpenGL rotated quad and this rotate sprite function would be nearly indistinguishable.

I don't know about Allegro but generally real time 2D rotations are very slow in software. I know this is a fact for DirectDraw. But if Allegro can do it than that's good. :) Do they have a demo? I guess the only other remark I can make is that if you're making games that you plan to sell for many years, this won't matter much. Eventually everyone will have 3D hardware. That's the last ace up my sleeve. :)

Personally though I can't use Allegro because I invested a lot of work into my current engine. If anything I might try to add SGE (http://www.etek.chalmers.se/~e8cal1/sge/) support (which supposedly has fast rotation in software) to it since that's SDL based (as is my engine). But thanks for the info anyway. :)

I found this (http://www.talula.demon.co.uk/rtl/index.html) demo for real time lighting (in software) in allegro that's pretty impressive. Couldn't find one specifically for rotation however.

Can't download the runtime DLL for some reason, will try again later.

Originally posted by Uhfgood
Okay people go ahead and yell at me now, asking me why would I even think of software (system ram) based systems, and telling me i'm crazy and all of that.

Why would we do that? There are still plenty of uses for pure software systems. In fact, some games don't even need to use DirectDraw at all. Simply drawing to a memory buffer and blitting to a window via the WinAPI is sufficient.

For those of you that have released games using Direct3D, could you elaborate on compatibility and support issues you faced? I see a lot of dire warnings about compatibility and support, but nothing concrete. How difficult has it been to provide a stable app that runs well on the majority of mid-high end vid cards?

Lord Kronos - Because usually people do yell at me, thinking i'm crazy for even thinking about doing games with a software engine.

But I guess that's cool no one yelled at me ;-)

Dan, Raptor was made a long long time ago (heh, I bought it when it was released). It was done before HW, and the most important it was done as a full commercial product made by a full budgeted company.

If you put the average custome against Raptor and StrayFire, and they have no idea of any of the games, never heard about them, don't know the companies, the average customer will probably by StrayFire. I know its sad, but its the truth. I for once prefer Raptor to StrayFire, but thats because I have played Raptor fully. If I only tried out the demo (the only demo I played was the original one, not sure if the new one has anything new) and tried out the demo of StrayFire, I would prefer StrayFire, mostly because its more action frenetic and more visually appealing.

Again, Metal Slug is a fully commercial product, that was designed to run on specialized hardware. And the resources put into it on animation are 30x more than making a 3d spaceship and rotate them a bit. (I suggest you take a look at some of the individual animations on the game, those things are fantastic).

Please don't get me wrong, as I said previously, I like games without HW acceleration, etc. Many of the games I buy are bargain bin games that because they didn't have pretty gfx, didn't really cut it. The thing is, thats a perfect example, the fact they are mroe fun to play, but still are in the bargain bin because of 2d/bad gfx is something we need to consider.

Dan, have you bought Raptor recently (from egames I think were the last one selling it) ? Did they added anything to the game? Did they at least port it to windows ? If they did, I may just buy it again, I miss that game.

Dan, actually, I think I read somewhere in the DX9 sdk (yes, I'm in the beta) that new versions of dx9 will not contains support for dx5 or lower. It was still something in discussion, but basically what they are saying is that dx9 runtimes will be smaller because it will not contain the interfaces for older versions. Also, for all, there is a public beta of DirectX9 runtime on MS site, not sure when they will release a public beta of the SDK.


Uhf: I already told you, but for others to know, 8 bit modes currently are in most cards slower than 16 or 32 bit modes :D My GF2 and GF3 suck badly on 8 bit mode games (maybe its the games fault, but with the lack of 8 bit games nowadays its hard to tell).


Also, for the ones that are really worried about compability, I suggest you make sw only engines. By using GDI to get access to the window buffer, you can make all your engine code work on arrays, and then use the function SetBitmapBits (or something) to copy the buffer to the device context. You lose about 2 ms doing this. Also, old games (Raptor for example) did something familiar but the last copy was directly to video memory, so there is no reason you don't do it also, and it's not that hard either :)

Uhf: I already told you, but for others to know, 8 bit modes currently are in most cards slower than 16 or 32 bit modes My GF2 and GF3 suck badly on 8 bit mode games (maybe its the games fault, but with the lack of 8 bit games nowadays its hard to tell).

Akura - that's not always true. 8 bit mode games work fine on my computer, it's just that with newer cards there's no real slowdown with bit depths higher than 8. However like I said plain 2d (say still using directdraw) you can't do squat for effects because reading from vid mem is way too slow.

And to everyone - I wasn't implying using GDI in a software only engine, I was thinking more along the lines of using DirectDraw just for the frame buffer, you can get exclusive access to the display and a quick way to write to the frame buffer, I just meant not using any other of the capabilities of directdraw, so in a sense if you just used ddraw for a frame buffer it then becomes alot more like old dos programming.

Personally I don't think one should use directx above 6.1 version. This version has everything that a good game engine could use. I have used dx3 and dx5 but the most planned out is v6.1. Even voodoo1 has dx6 drivers. If you want to remain compatible with Nts than use Opengl not dx. Or even better use it too!

Originally posted by Uhfgood
I was thinking more along the lines of using DirectDraw just for the frame buffer, you can get exclusive access to the display and a quick way to write to the frame buffer, I just meant not using any other of the capabilities of directdraw, so in a sense if you just used ddraw for a frame buffer it then becomes alot more like old dos programming.

That is exactly what I do for all my games and it works beautifully. Performance has hardly been a concern at all in 16-bit modes, and most computers these days can handle 32 bit modes without batting an eye as well. And when I say performance, I'm referring to 640x480 and 800x600, full-screen animations, alpha and additive blending, etc (all software, using a system ram video buffer). My stuff runs reasonably fast on a P2/300 (30+ fps 32-bit and 90+fps 16 bit), and obviously most modern PCs don't even bat an eye.

I did a 640x480x16bit performance test a while back on a particle system, and was able to push 3500 additive-blended particles (each 8x8 in size) and a backdrop at 60 fps on a P2/400, and more than 9000 on an Athlon 1ghz. My entire engine is 100% C --I haven't bothered to do any MMX or assmelby optimizations (yet), and I'll probably not bother since I don't have the time and I don't think the increase in framerate would drastically improve the quality of the style of games that we make.

I admit, while the 16 bit performance of my simple little engine is pretty staggering, the 32 bit performance leaves some to be desired. But I make this point: if you're doing a software engine and you just assume all 16 bit gfx, then your resources will be that much smaller over 24 or 32 bit versions-- and while they might not really care one way or the other on 16/32 bit, people here have mentioned time and time again here that gamers do care about file size on download.

- Air

Air:
I did a 640x480x16bit performance test a while back on a particle system, and was able to push 3500 additive-blended particles (each 8x8 in size) and a backdrop at 60 fps on a P2/400, and more than 9000 on an Athlon 1ghz. My entire engine is 100% C --I haven't bothered to do any MMX or assmelby optimizations (yet), and I'll probably not bother since I don't have the time and I don't think the increase in framerate would drastically improve the quality of the style of games that we make.

I don't suppose you have a copy of this that I could try on my machines. My experience was that I could acheive a little over 60fps on a 450 Mhz machine using Rep MovSD to copy a background on and then Drawing one 128*128 sprite.

I think performance tests like this can be hugely dependant on hardware other than CPU. Fitznik ran at 60Fps on a 233Mhz machine while running below 30Fps on my 500Mhz box. This is even more of a factor when you are doing blending where you have to read from video memory if you are doing hardware flipping.

I'm also a bit surprised to hear that 32 bit is slower than 16 for additive rendering. I would have thought the extra data size would have been more than compensated for by each colour component being in a nice place.

As for your comment for side of graphic data, I would say thhat if you are above 256 colours then you should really be looking at jpeg or even mpeg for storing your graphics. I store eveything in Fitznik as jpeg (with a 2 bit bitmap mask if it needs one). You can get very good results this way.

I have a 128*110 (30 frame) explosion animation that comes to 137k, Storing this as even a zipped 16 bit image comes to 300k. (Interestingly, storing as an at 8 bit image with a custom palette gets reasonable visual results and comes to 181k)

[As a sidenote to that, and to add a bit more thread drift. Does anyone know of a Jpeg2000 library that is free for commecial use (or even one that is cheap), the last time I looked into it I found people charching things like 8,000 Euro]

Ok, time for me to get technical. Non-coders beware. :) You make a lot of points which I, too, have heard lots of times over the years. But in practice most of them were dispproved.

Originally posted by Lerc

I don't suppose you have a copy of this that I could try on my machines. My experience was that I could acheive a little over 60fps on a 450 Mhz machine using Rep MovSD to copy a background on and then Drawing one 128*128 sprite.

Chicken Little (http://www.hour13.com/cl) uses my engine, so you could try that. CL doesn't demand a really high framerate to run smoothly, but I've tested it on a couple P/90s and P/133s and it ran at least 20 fps all of them. You can try that.. and remember everything layered on top of the backdrop is dynamic: all additive board-brightening and the layouts and stuff. Plus every gamepiece has an alpha-blended shadow which is the same size as the gamepiece (I was too lazy to crop them to just the visible portions).

Also! There's a ceiling limit to the highest framerate you can achieve, because of the slowness of video ram and sys->vid copies. When I first started working on CL I was using a P2/350. My original blit + 64x64 sprite test did about 60 fps (in 32 bit mode -- it did well over 100 in 16 bit). I was depressed, so I did like 500 sprites. And it was still 60 fps. And I added like 500 more and it went to 54-ish. Now days I can do like 3000 sprites before it affects my framerate any. Again, I stress that most of the CPU time of your game is just doing the sys->vid copy, and that the process of updating that system buffer and doing software blits is so miniscule in comparison that it has little affect on the performance of your game until you get a lot more complex (thousands of sprites, etc).

I think performance tests like this can be hugely dependant on hardware other than CPU. Fitznik ran at 60Fps on a 233Mhz machine while running below 30Fps on my 500Mhz box. This is even more of a factor when you are doing blending where you have to read from video memory if you are doing hardware flipping.
This is very true, however it's much more common to see varients like this when running in 32-bit mode. The reason 32-bit mode is slow in doing software rendering is more because of the slower video bandwidth when copying the offscreen buffer to video ram. Vid memory accesses really show their weakness when dealing with large 32-bit buffers. Hence, if you're on a machine with dated hardware (an older Cirrus video device, perhaps), your 32-bit results will probably be 1/5th or 1/6th your 16 bit results-- while most modern machines it hovers around 1/3rd or so. That's what I found in my tests anyway.

Also-- I'm not sure why you would need to read from video memory to do hardware flipping. I did 100% system ram blending just fine in my double-buffer setup. but I also have a system where I re-render the entire screen from scratch every time even the slightest thing changes. Makes life a lot simpler! :)

I'm also a bit surprised to hear that 32 bit is slower than 16 for additive rendering. I would have thought the extra data size would have been more than compensated for by each colour component being in a nice place.
Two things. a) Pipelining. The shifts don't always equivilate to an extra instruction because often they just fill in gaps in the V-pipe. b) Slow byte-manipulatin in 32-bit protected mode. Accessing each individual byte of memory adds a cycle due to the register-type override. I tried both directly-reading the attributes in 32-bit mode [byte-for-byte], and reading the DWORD and shifting the attributes out. Interestingly, both were almost exactly the same speed.

I mean, software mode is no perfect solution, but it does get the job done, and it tends to be more compatable. It can't get really really smooth framerates on a lot of machines (70+fps). But it will get solid and consistent framerates... well the way I do it does anyways.

- Air