Software rendering

[EpicBoy]

After James Smith mentioned he switched to software rendering for his games, I'm wondering if anyone here would be willing to give a quick heads up list on how to approach this sort of thing properly on Windows.

DIB sections and Blt commands? Or is there something more to it... ?

[princec]

Use somebody else's library.

Cas :)

[EpicBoy]

More info would be appreciated.

[princec]

Just a general maxim; a lot of folks in here then go off and twiddle their thumbs for 3 months writing half-assed blitting routines when someone's pretty much already done it for you somewhere else... as for explicit advice on what library to use, I dunno :) Doesn't SDL have custom blit routines in it?

Cas :)

[Dan MacDonald]

Mike from blitwise has a pretty slick software engine, both he and mike boeh use it. Maybe you could approach him and see about licensing a copy. I don't think it's packaged up for general consumption but I think a developer should be able to figure it out. Heck maybe James would license his...

I will say this though, James decision to go to a software engine is based on a lot of factors. For one, he has a software engine at his disposal so it's not too much trouble to move to it, for two he's got a big company so he needs to optimize his games to get every possible sale.

Using an OpenGL based library is not a death wish. Little Soldiers has sold over 30 copies this month alone and it's not even half over. It's an OpenGL based puzzle/strategy game. So if you are are like reflexive and you know how to (and are capable of) making top tier games that sell and are looking for a way to optimize them to sell a little more a Software engine might help you eek out a few more sales. But for JoeIndie trying to finish his first game, you would be well advised to not try and write a software engine, that should not be your primary concern. Your primary concern should be trying to make a high quality game that can sell, because honestly the difference in sales between a GL based game and a SW base game is maybe 10-30% depending on the market. The difference between a good game and a crappy game, or an unfinished game is a lot larger. ;)

So focus on what will give you the best ROI, finishing a good game. Once you have that you can worry about SW rendering engines and all that, don't put the cart before the horse and worry about your engine before you start your game.

[EpicBoy]

I agree, I was just curious.

I have shipped games before, BTW, but under a label I'm no longer using. I used BlitzBasic for those games and was just poking around checking my options.

The new game I want to do doesn't sport a lot of graphics - mainly text and UI type stuff with some minimal graphics in one section.

I'll probably move forward with something like C++/PTK but I wanted to check out the software renderer option first to see what it offered...

[Adrian Lopez]

I haven't read it, but Andre LaMothe's "Tricks of the 3D Game Programming Gurus-Advanced 3D Graphics and Rasterization" is all about software rendering.

[James C. Smith]

Dan makes some excellent points. Writing your own blitters is not for everyone. You could use someone else’s or stick to hardware. Also, I would not suggest trying to use software for a 3D game. But when you have pre-rendered art (or 2D painted art) it can be tempting to use hardware for speed or scaling or rotating when it can all be done in software if you want to spend the time to write or acquire to code. The software engine we had at our disposal did not do many of the thinks we needed for Wik such as rotating, scaling, and some kinds of tinting and blending. To get Wik to run is software we used a combination of our existing software engine plus a lot of code from Anti-Grain Geometry ( http://www.antigrain.com/) which we integrated into our engine and then optimized for the specific cases we use it in.

As far as options like GDI and DIB sections, I would recommend you use DirectDraw or a library which abstract DirectDraw (such an SDL).

[Lerc]

So far I have done Fitznik 1 and 2 using 99% Software renderind (and boy did that 1% come back to bite me in little niggly bugs)

Gus the Grey and Drippy use Software Rendering (same engine) also but a slightly different approach to Fitznik.

Fitznik was 16bit with code to handle 565 and 555 bitmaps. I actually took out the 555 support for Fitznik 2 and forced a conversion during the Blit onscreen. I had the luxury of doing this because it had CPU to spare on most systems and 555 displays were increasingly rare. The engine has the choice of having the back buffer in video ram or System RAM. On most newer machines, blending kills perfomance dead if you use a video memory backbuffer. For placing the image onscreen I had the option of PageFlip, Blit with GDI or Blit with DirectDraw. Only Blit with GDI allows for a remap to any odd pixel formats. Pageflip is obviously fastest but requires a video memory backbuffer. GDI and DirectDraw blits varied wildly between graphics cards. Neither GDI or DirectDraw performed consistantly faster accross the board. I encountered a few systems where the Graphics card would suck the image accross the bus letting the blit call return in 26,000 clock cycles. Clock cycle counts in the millions were far more usual. Faster machines just take more clock cycles (ie not faster or slower, just more cpu going to waste)

To get it all working the graphics engine of Fitznik would be best described as a horrible mess of black magic and duct tape. I developed it while figuring out what worked and what didn't. For Gus I started from scratch with an attempt at making something tidier and hopefully more reliable accross systems.

My biggest mistake (again) was that I kept too much system stuff there. I should have done everything possible myself, but I was seduced by having easy fonts. My rendering views still had GDI device contexts attached. I'm tempted to go though and rip it all out still.

The model that Gus and Drippy uses is A block of system memory that gets copied onscreen (using MovQ) each frame. The Bitmaps are DIBs but If I were to start again I'd just use a simple rectangle block of bytes as a base object. MMX is used thoughout (Fitznik avoided it because it wasn't ubiquitous (seems so long ago now)).

For those of you complaining about me sticking with 8 bit. I have made builds of Gus in 16 and 24 bit, Performance wise I'm tempted to stick with 16 bit.
Additive blending in 16 bit using MMX is a bit of a pain but It's still way faster than standard instructions. Alpha multiply blending is easier because you can contrive things to not overflow the bitfield (can't go whiter than white).
For simple mask transparancy style sprites you have a couple of options. RLE encoded Whitespace, which can be great for speed but annoying to clip, or standard Rectangle with mask color. MMX can speed up Mask colour blitting if you read source and dest then mix the two together based upon a comparason. This is something that is only viable if you have a system memory backbuffer since you are reading every location prior to writing.

All of this takes as given that you can build a sprite framework with rectangles and clipping etc. that side of things is only really a good days work away though.

When It comes down to it. If everthing is optimised the real speed comes from what you don't draw rather than drawing it really fast. Commenting out a single MoveQ instruction in the core of Gus Now makes the game run much much faster (only with most of the screen not there :) ).

Not sure if any of this this helps.

[Ryan Clark]

I've managed to create some high performing software rendering routines using SDL... if your game doesn't involve heavy screen updates you can probably get away with per-pixel alpha blending by employing a dirty rectangles algorithm.

My game is a puzzle game, and requires fairly few screen updates. The alpha blending enables us to have anti-aliased edges on all of our sprites, which makes them look 10x better :) And, thanks to SDL, it runs well on Windows, MacOS, and Linux (all tested).

If you have any specific questions I'd be glad to help.

[MirekCz]

I haven't read all the post, just a fast go-thru, so here are few points:

1.If you don't know if you should use dibs or anything else.. don't even come near software rendering... to do it propertly you need a hell lot of knowledge and without it you're 10x better off using a prepared engine
(the other way is to spend at least few months learning about software rendering... find some tutorials on google on ddraw and start with it..a good book might come handy as well)

2.Lerc:yes, dropping 15bpp (ie 555) support is a good idea but instead forcing the bitblt transformation it's much faster to do the transformation by yourself. Usually windows takes some time to convert all the data and it can be done much faster with a well optimized function.. and that's just one function to optimize, so no real effort and you can gain noticeable amount of performace.
Another thing is to do similar 16->32bpp transformation if some vidcards don't support 16bpp mode (no idea if there are any actually)

[EpicBoy]

Would it really take several months to do a simple 2D renderer for a puzzle game? I'm not talking about a 3D engine, sorry, I should have been clear. I'm talking about something that will draw graphics and pieces of graphics. That should be simple loops with some alpha blending thrown in to make it look pretty.

Or am I so naive that it's frightening? :)

[wazoo]

Why not just let the hardware do that for you though EpicBoy?

Any Direct3D and/or OpenGL simple setup will do the trick. Even just sticking the pipeline into an Orthographic projection will emulate a typical 2d scene pretty decently....plus you don't have to worry about the gayness of 565 vs. 555.;)

[Momor]

If you need help, I've writen a bunch of software renderers (but in Delphi & Java only for now). What is your programming language ?

In any case you could use SDL or Allegro, which already support native software blitters.

Otherwise, you can still go the GDI way ... If you need to support alpha blending, then I suggest you to use DIB & direct pixel access (RGBA 8888 is fine). This way you'll get rid of the display pixel format. The only concern with DIBs is that the Blit() function used to display the DIB on the screen has become a lot slower since the arrival of DirectX ... dunno why ! :o

[Lerc]

Would it really take several months to do a simple 2D renderer for a puzzle game? I'm not talking about a 3D engine, sorry, I should have been clear. I'm talking about something that will draw graphics and pieces of graphics. That should be simple loops with some alpha blending thrown in to make it look pretty.

Or am I so naive that it's frightening? :)Making a renderer do all the basics is actually quite quick and relativly easy if you know your stuff. I'd be fairly confident in being able to throw something together in a few days. To make things a layer up will take longer, Making animation entities with animation rates, cycling/pingpong, that sort of stuff. That's stuff that would have to be done at some point regardless whether the graphics card or the CPU is putting the pixels on the screen.

Adding scaling and rotation (especially nice scaling and rotation) are harder issues but James pointing to Anti Grain Geometry looks like a good option to find bits to help out. [thanks for the pointer James, there's some good stuff there]

It's all in the doable box. Getting something premade would be quicker. The main issue there is A) how long will it take to find the right library and B) how long will it take to find that you've picked the wrong library.
On one previous game I was bitten by B and ended up having to have some nasty sprite stitching code to put together sprites that were greater than 256 pixels wide. It's the reinventing the wheel that ensures that your wheel is going to be round.

Sticking around a forum like this is a good place to get a handle on the good Off the shelf libraries though.

[MirekCz]

EpicBoy:the question is... how fast should it work?

Potentially you could get one done in a few weeks... but it might be slow or buggy like hell. It's not an easy task.

It would be most time/effective to either find someone that uses a good engine and can you help a bit with all the "possible" problems or pay someone for a nice library.

[Tom Cain]

You could look at the FastGraph library. It has been around a while and is supposed to be quick, written in assembly. I think it can use hardware or fall back to software. http://www.fastgraph.com/

[PoV]

Yeah, I'll also vouch for Allegro as a software rendering choice. Being *super* free, and it does more than just blits (unlike SDL), not to mention it gives you easy to use input, audio, and cross platformness as well. Combined with AllegroGL, an addon that integrates OpenGL in to the mix as an acceleration option, you should be able to write a game that uses GL if supported or falls back on Allegro polygon functions if not.

[Nutter2000]

I'm currently evaluating the Kyra Sprite engine
http://kyra.sourceforge.net/

Seems pretty good so far, a quick, and by no means complete, list of features (in no particular order)

it sits on top of SDL,
uses OpenGL or Software Rendering automatically depending on the switch used to create SDL
supports sprites, tiles, and canvases. Canvases let you write directly to a portion of the screen.
Seems pretty fully featured, supports alpha blending, colour keying, text, etc
it's released under the GPL licence or LGPL licence provided you display their splash screen
It's C++
seems quick enough. I haven't run my own stress test yet but the demos don't run badly.
supports layering through a Z coordinate
Has built in maths for isometric
supports scaling, rotating, dirty rectangle updating, collision detection and so on
All in all seems a reasonable sprite library so far

perhaps my only issue is that it is very integrated, all the resources are contained in it's own resource management system, which isn't a bad thing it just doesn't quite fit in with my own game framework, but I can live with that if it suits my requirements.

Anyway, enough of this tirade, hope it helps

[DangerCode]

I'm currently evaluating the Kyra Sprite engine
http://kyra.sourceforge.net/

How's it holding out now that you've had some time with it?

[Nutter2000]

How's it holding out now that you've had some time with it?
Not bad, I haven't had chance to stress test it as much as I'd like but it's definately looking to be the lib that I'll be using.

Couple of issues I've found so far;

The library is statically linked as default which renders the LGPL licence pretty much useless. However, I spoke with the guy who wrote it, Lee Tomason, and he pretty much doesn't care how it's linked so long as if you use it commercially then the Kyra splash screen is displayed. So a bit of work is needed to make it a dll, but being open source the code is there to do that myself rather than having to wait for someone to do it.

There's currently no Mac version and I'm not sure what issues need to be resoved to create one. I think there is a group who are working on one but I don't know how far along they are.

All Kyra assets, eg. fonts, sprites, tiles, etc, are compiled into a dat file, you can have multiple dat files and page them in and out of memory as you need them. I've tried compiling and displaying some of my own sprites and it was very easy to do.
However, having all the assets in dat files makes it difficult to update individual assets without updating the whole dat file.
On the other hand this means that the kyra engine itself doesn't need to link with any image decoding lib or provide code for different image types, this reduces the size of the kyra lib. The image decoding stuff is done in the seperate dat file encoding program.


Apart from all that it's a very good library, and it's pretty much complete, unlike a lot of open source stuff out there.