I've written several software render engines in the past. A quake type, and a terrain engine. Do you think I should restart those engines and make some games out of them? I've done some initial testing, and I can manage about 15-20fps (640x480x16) on an old Pentinum 166 with 2Megs video cards. I have no idea how faster it'd be with optimizations, but I 20fps is smooth enough, considering the slow pc? It's rendering about 3000-5000 textured triangles...

On the surface, it sounds like a fab idea. No reliance on 3d api's and 100% compatibility. But the quality of graphics is not anywhere near today's standards. Do you think it's a good idea?

I'm not sure I see what the point would be. What kind of games would you make with those engines, and what kind of competition would you be facing? Is there an unexpectedly large supply of people with Pentium 166 computers that are starved for 3D games?

If it's just for the fun or nostalgia factor, then knock yourself out. I still play the old Asteroids and Fire Fight clones I wrote every so often just for kicks. But I wouldn't waste my time trying to sell them even if they were complete games.

Just my two cents.

Personally, I'd love to have a software renderer. Miko & Molly is definitely pulling less than 5000 polys a frame. I've thought about making one before. It would be nice, not having to worry about any DirectX/OpenGL/hardware requirements. I started to develop one, just to get a quick idea what I was looking at. Simply transforming the verticies and rending point to the screen only got me about about 10 FPS. I don't know whether that was just because I suck at optimizing code or what. I gave up, figuring it was going to take me months more time than I had if I wanted to get any decent performance.

Just curious...is you renderer pretty generic, or is it very special case (ie: you have to render in a certain method...essentially, your game engine needs to be custom designed around it).

They're both pretty specificly tailored renderes.

The Quake clone is BSP tree based, and draws everything front to back, using edges, and it has perspective corrected pixels and ghouraud shading. It needs a lot of work to finish it. such as portal culling, optimizations to the renderer, etc...

The terrain engine is far simpler. it draws both linear and perspective correct textured triangles for speed. it too needs optimizations...

As for Milo's question, that's the same question I had. What would be the point? the graphics would be far far far below in quality..

You might be able to target Pocket PCs and Palm devices, which have no hardware options at all.

3000-5000 polygons at 640x480x16 on a Pentium 166 with a 2 MB video card is pretty impressive right? That seems to be about the same amount of polys Quake I or II rendered on similar machines at 320x240x8. Maybe they were faster, but 15-20 fps is very good at the resolutions and those specs.

i think it's a good idea if you have it. i'm using a software renderer as a fallback-version for people without DirectX and for addtional effects with DirectDraw. essentially it's just a triangle rasterizer. it's nice to have for rendering rotated bitmaps, for example small rotated particles etc., and for 2D billboarded poly's you don't need any perspective correction, no z-buffer and so on.
BUT,it wouldn't be fast enough for a real 3D game (the engine is only written in C, no mmx/sse yet), i get 10-20 fps with a few hundred medium-sized triangles, and the speed is extremely dependant on resolution (anything beyond 640x480 is killing it :) ).

Most of the triangles are linearly textured, not perspective, so there's no divide necessary. For terrain engines, linear textured triangles are fine since most are so far away.

Quake and QuakeII can render many more triangles than my engines I'm sure!!

I guess I don't understand the worry about different reliences. All the major operating systems come with OpenGL. And you'd be hard pressed to find a computer without some sort of 3D support.

Just my $.02, but if you are planning to build a 3D game, I would bet 99% of your potential audience has 3D support. If that's not your target audience, then stick with 2D.

Originally posted by jih
Most of the triangles are linearly textured, not perspective, so there's no divide necessary. For terrain engines, linear textured triangles are fine since most are so far away.

Quake and QuakeII can render many more triangles than my engines I'm sure!!
If your numbers are accurate, you're getting pretty close to at least Quake I performance. Quake I levels were no more than 10,000 polygons and the character models were about 250 polys each. I'm not sure how much Quake I rendered at once on average, and it ran faster than your engine on lower perfermance machines, but it also ran in 8 bit color at a lower resolution. You seem to be getting pretty good performance.

BTW, the Quake 1 & 2 engine are free under the GPL (i.e. basically, if you make any changes/modifications to the engine, you have to release those changes to the public).

More info here (http://www.idsoftware.com/business/home/technology/techlicense.php).

David

I believe GPL means if you use the engine you have to release the source to your whole game. LGPL is where you can dynamically link with something and not have to release your code.

jih Most of the triangles are linearly textured, not perspective, so there's no divide necessary.

An old trick, you probably know this, but worth mentioning it anyway. You can get almost perspective-correct mapping with almost zero extra cost. While u, v and z aren't linear in space when you project them, u/z and v/z are. So you can calculate 1/z, u/z and v/z at vertexes, interpolate linearly across edges, get the correct u and v at the ends of each scanline (u = (u/z) / (1/z), v = (v/z) / (1/z)) and texture linearly. Or better, interpolate 1/u, 1/v and 1/z linearly across the scanline across the scanline each 16 pixels, for example, and interpolate linearly inside those spans. Looks great and it's relatively cheap.

You can see the 3D engine and a "game" here (http://simbondi.port5.com). There are some screenshots and the full C++ source code. Your engine is probably much more advanced than this, but there it is anyway :)

Garsh!

Why are those GPL , LGPL, etc. licenses so confusing ... and I thought I knew something :)

David

Just to comment on the original posting. Good software renderers have a niche market, I know of only two rendering engines that are available comercially:

Fastgraph, www.fastgraph.com $299USD
Pixomatic, www.radgametools.com/pixomain.htm $10000USD

I know a dozen of comercial projects that would be completely working solutions but are no longer maintained or supported. I would seriously consider it before working on your own engine, Fastgraph is decently priced and you get much more time for your game. The idea of software rendering is good, to be compatible with a much larger range of machines.

[Edit: Fixed link]

The forum parser is broken. The above link to fastgraph has a comma at the end and the forum includes it as part of the URL. It happens too often...