I'm planning the creation of a 2d engine and am considering a few things. I have never used hardware acceleration before so if someone can answer a few questions I have that would help me a lot in deciding whether to use it now.

I have mostly decided I do not want to use hw acceleration - processors these days already have the power to churn out an insane amount of blitting even if it's alpha blended. The only thing I worry about is loosing the ability to do superfast AA-stretching and rotation. Rotation can be precomputed and stretching of pretty images easily kills the sharpness of 2d graphics so I am not too sure I will miss those features either (and by the time I want to add them processors are so mean that it becomes a piece of cake). The big reason I am staying away from HW acceleration is because it allows me to make an engine that REALLY DOES WORK on pretty much any machine. If anyone anyone thinks it is stupid to do a 2d engine without acceleration please feel free to tell me why.

I have discarded pretty much all reasons I know of to use acceleration, but there is one small concern I do have; sub-pixel accuracy of blitting. I know things look a whoooole lot smoother when I can blit bitmap to a fraction of positions (so that I can animate a bitmap's progress from one pixel to another for example). I am sure libraries such as SDL does not support this natively and I have a feeling writing one would be both complicated and expensive in terms of CPU (Exactly how does a bitmap blitted to position 2.5, 10.75 look like? My intuition tells me that the pixels will be quite a bit smeared and that I might not want to treat beautiful 2d art in this way). Does anyone have any insight? :)

If anyone anyone thinks it is stupid to do a 2d engine without acceleration please feel free to tell me why.

One additional reason why you might want to go with a software 2D renderer would be to support mobile devices such as PDAs and smartphones. These devices are at the point where they can handle some neat stuff, (e.g., Manaisoft's Fire Power EX (http://manaisoft.com/00products_sp.htm)).

On the flip side, the accelerator-less desktop/laptop may become a thing of the past soon. Even Gateway's budget notebook line (http://manaisoft.com/00products_sp.htm) includes Intel's Extreme Graphics 2. And while that's a far cry from ATI's X800 line, it's not too shabby for an integrated solution. Judging from its performance when running our upcoming title (http://www.dejobaan.com/inago/gallery.htm), I'd think it could handle some pretty respectable 2d tiling.

My 2D engine is completely software based because I want it to run on just about anything. I don't use DirectX at all, in fact. I have my own 32bit Bitmap surface code that does alpha blending, and I composite to my own framebuffer. The results go straight to the window surface using GDI. With a good dirty rectangle system, you can still get really good framerates with this sort of setup, depending on the type of game you want to do (wouldn't work that great for a shmup with tons of enemies on screen and moving, but I'm not making games like that anyway). Input uses standard windows messages (no DInput). Sound uses Brian Hook's SAL library, with the waveOut driver (no DSound).

I recently just tried running my engine on a base Windows 95 (first release, not OSR1/95B) install on a clean system on an old Thinkpad P2-366, with 32 megs of RAM, and it runs just fine. User doesn't need to worry about DX-Whatever, because DirectX isn't used at all. As long as you have a 32 bit version of Windows (including Windows NT), It Just Works.

I've also started porting the engine to Mac OS X. Sound is taken care of thanks to SAL. Getting my simple framebuffer and input code ported over to OS X shouldn't take very long at all. It would probably be a couples of hours of work if I already knew MacOS X programming. As this is my first dip into those waters, it'll be more like a couple days to a week.

I'm storing all my graphics in vector file formats (SWF, but not using Flash player at all -- using Thatcher Ulrich's gameswf and the Cairo Graphics library to rasterize swf->bitmaps). This lets me easily resize the vector graphics to match the current display resolution, so the game can be played in any resolution from 320x240 up to 2048x1536 (no upper limits, really, but that is the highest I can test with on my current setup!). Obviously, on a low-spec CPU/mem machine, the play experience won't be that great if they try running at very high resolution, but that's ok, they can just stick with 640x480 or even 320x240 and get the same game experience, even if the graphics lose some of their sharpness.

This long winded reply is intended to let you know that, yeah, 2D non-HW accelerated is an option. It has pros (runs on virtually anything) and cons (not suited for all game types), but it is workable.

Some old screenshots of my game/engine can be seen here. (http://www.mischief.com/zblocks)

Like GFM says, it's good if you're not going to be too graphically intensive.

If you are, then any machine capable of software rendering everything at a decent speed will most likely have basic HW acceleration anyway.

I have mostly decided I do not want to use hw acceleration - processors these days already have the power to churn out an insane amount of blitting even if it's alpha blended.

In my experience this is simply not true. First, it's not a question of CPU speed but of memory speed. Second, although computers have gotten faster, screen resolutions have gotten bigger and color depth has increased. Simply put, you cannot blit multiple layers to the screen each frame at 640x480, 16 bit color, and expect 60 fps or higher on any but the fastest computers available.

My recommendation: if you need a lot of performance in 2D, use at least 2D hardware acceleration. It's universally available, you can always fall back to software rendering if it isn't available, and it'll do wonders for performance on older computers.

I have discarded pretty much all reasons I know of to use acceleration, but there is one small concern I do have; sub-pixel accuracy of blitting. I know things look a whoooole lot smoother when I can blit bitmap to a fraction of positions (so that I can animate a bitmap's progress from one pixel to another for example).

Actually subpixel rendering can look really bad if you have a lot of small details. My current project uses OpenGL to provide subpixel accuracy, but I'm seriously considering dropping the subpixel accuracy while keeping the OpenGL. My reason: the game looks better without subpixel accuracy than with.

I am sure libraries such as SDL does not support this natively and I have a feeling writing one would be both complicated and expensive in terms of CPU (Exactly how does a bitmap blitted to position 2.5, 10.75 look like? My intuition tells me that the pixels will be quite a bit smeared and that I might not want to treat beautiful 2d art in this way). Does anyone have any insight? :)

If you cache your bitmaps at subpixel positions, it's only expensive in terms of RAM and CPU cache. But you're probably better off not using subpixel rendering.

One thing you can do is support doubled, tripled, and maybe even quadrupled resolutions. This lets you trade performance for smoothness if you have performance to spare.

@ Karukef: You can nevre new a result of HW AA before you try. Enough to say is that different manufacturers use different AA algorithms. All in all AA usually looks good for modern card, you can control the "amount" of AA (off line, during initialization). If you don't use scaling/rotation you can use some fuzzy alpha edges on your sparites and don't need AA at all. If you use them you will have some smearing, wether it's in SW or HW

@ MiceHead: PC based SW 3d techniques don't port to cell phones easyly (samm staff porting of cause, but with the lot of tweaking). They don't have floating point, their CPU have very different instruction set and timing, small screen change vertex/fill rate ratios relationships. Opposite in the near future game-oriented phones will have HW 3d support, OpenGL ES or J184. So paradoxally you would have more portability with HW renderer for PC->phones.

PC based SW 3d techniques don't port to cell phones easyly (samm staff porting of cause, but with the lot of tweaking).

I was actually referring to 2D blitting; I haven't done any 3D work on Palm or Pocket PC devices, so I can't render (no pun intended!) an opinion on that.