Software Rendering vs Hardware Rendering.

[Cyan]

Well, I have always been a fan of software rendering, especially because I started as a PC gamer in 1996 and back then CPU speed was more important that GPUs because hardware acceleration wasn't that fast.

Hardware acceleration was incredible when it came out but there was a time when Software rendering had some features which weren't possible with hardware rendering.

You can clearly see which features were removed in Quake, the best iD game have ever programmed, imho, which art style remains unique to date, in this great article.

Some differences are really curious.

http://www.quaddicted.com/engines/software_vs_glquake

I can also recall Need for Speed having some exclusive features if you chose the Software renderer in the graphics options, although on the contrary to Quake it looked allegedly better if you had a 3D accelerator graphics card -which I had then, although sometimes I switched to software rendering just to compare-.

Tim Sweeney was a great advocator of software recently until 2008 or so.

http://techreport.com/news/14313/epic-games-founder-discusses-the-pc-as-a-gaming-platform

Btw, I use DirectQ for Quake 1, which keeps the software features of the title and uses Direct3D.

It's very easy on the GPU and laptop friendly, achieving great performance without much effort.

I get 200+ frames per second on Quake at 768p using DirectQ on my i5-2450M processor while I throttle it to 1,7GHz-.

If I don't throttle the CPU it can go up to 3.0GHz max, but I don't let the laptop achieve that speed to avoid unnecessary heat and high frequencies I don't need for the uses I give to this laptop.

 

[Davros]

I use DirectQ as well since the amd drivers at the time didnt like glquake

 

[TheWretched]

Need for Speed 1 had, iirc, no other rendering options than software (full DOS game). Need for Speed 2 on the other hand had a hardware accelerated version. The differences were minute. The smoke emitted by the tires was completely different, though. Not sure if the weather effects are 3DFX only or not, or if it was added with the SE later on.

 

[Davros]

It was nfs 2 se that had voodoo support
the se version also had changeable time of day although I cant imagine that it was'nt possible to have that in the software rendered version

 

[Exophase]

The article you linked seems more like a critique of GLQuake's incompatibilities than a list of things the original software renderer did that couldn't have been done using OpenGL 1.x on hardware of that era. Or at least it seems that way to me:

- Texture filtering can be made nearest neighbor with the appropriate glTexParameteri calls
- Overbright modulation can be enabled with GL_RGB_SCALE set to 2.0
- Fullbrights can be done by setting color manually with glColor
- The non-square texture distortion problem can be handled by padding the texture and properly correcting the texture coordinates instead of scaling it (not sure why this was ever done)
- You can possibly get affine texture mapping with glHint, or if you really need it you could force it with explicit geometry transformation (early cards did it in software anyway) using identity modelview/projection matrices. That way you can pass perspective divided x/y/z and maintain w = 1 to kill perspective correction. Not sure if early OpenGL implementations would have an optimization for passing through vertexes that undergo identity transformations, or if there's some other way to bypass that part of the pipeline. Although I doubt you'd really want to throw out perspective correction.

 

[patsu]

It can be mixed software and hardware rendering too.

 

[eloic]

Do you remember Outcast? It was awesome and it had pretty advanced graphics for its time (some effects and even voxels). It demanded a high specs computer in the time, though.

 

[Davros]

Oh yes we certainly do (and can be bought on cog if anyones interested)
ps: it was all voxels

 

[Sonic]

Oh yes we certainly do (and can be bought on cog if anyones interested)
ps: it was all voxels

Not all voxels. Characters use polygons.

 

[Cyan]

I use DirectQ as well since the amd drivers at the time didnt like glquake

Glquake vanilla should be easy to run except if people use vintage hardware, the game is pretty well optimized. If you add Rysen's textures and stuff like that, then DirectQ is going to help in the case of ATi cards.

On a different note, Quake might seem a hardcore game but to me it isn't at all. The controls are so simple and straightforward -as long as you have the mouse look option active- that even a casual could control it.

Right mouse button to run, left mouse button to use weapons, and Space for jump, that's all you need to know about the game.

Short but beautiful and intelligently designed levels are also one of those things that make the game easy to learn and hard to master.

Need for Speed 1 had, iirc, no other rendering options than software (full DOS game). Need for Speed 2 on the other hand had a hardware accelerated version. The differences were minute. The smoke emitted by the tires was completely different, though. Not sure if the weather effects are 3DFX only or not, or if it was added with the SE later on.

Need for Speed was my first game ever!! :smile: the shop assistants gave it to me as a gift because I bought a 3000€ PC of the time -September 1995, Pentium 100, 32MB of RAM, AWE32 soundcard, HP printer, etc-.

My parents let me buy that PC because I lost my spleen in a car crash -I wasn't at the wheel, somebody else was driving, I had not driving license then- and the insurance company gave me some money as a compensation.

I did sums and my laptop would cost 200.000€ nowadays if prices were the same as in 1995 -I remember 1MB cost 30€ back then...-.

In regards to NFS2, I was so hyped about it but for whatever reason I didn't purchase it. I am glad I didn't as hyped as I was, because when NFS3: Hot Pursuit came out I bought it first day because not having purchased NFS2 was a thorn in my side.

NFS3 was certainly worth the wait, one of my favourite games ever.

The article you linked seems more like a critique of GLQuake's incompatibilities than a list of things the original software renderer did that couldn't have been done using OpenGL 1.x on hardware of that era. Or at least it seems that way to me:

- Texture filtering can be made nearest neighbor with the appropriate glTexParameteri calls
- Overbright modulation can be enabled with GL_RGB_SCALE set to 2.0
- Fullbrights can be done by setting color manually with glColor
- The non-square texture distortion problem can be handled by padding the texture and properly correcting the texture coordinates instead of scaling it (not sure why this was ever done)
- You can possibly get affine texture mapping with glHint, or if you really need it you could force it with explicit geometry transformation (early cards did it in software anyway) using identity modelview/projection matrices. That way you can pass perspective divided x/y/z and maintain w = 1 to kill perspective correction. Not sure if early OpenGL implementations would have an optimization for passing through vertexes that undergo identity transformations, or if there's some other way to bypass that part of the pipeline. Although I doubt you'd really want to throw out perspective correction.

That's a very interesting post.

Learning how to use those parameters certainly needs some knowledge of how the parameters, console and ini, bat, cfg, etc, files work.

Those issues can be overcome but, out of the the box, what most people could see if they were observant enough is that quakegl textures were a lot blurrier -I can't stand blurriness, washed out looks-, and screwed up underwater (distortion, warped up looks) vision didn't help the opengl version either.

glquake was better than 320x240 software quake, he he.

Do you remember Outcast? It was awesome and it had pretty advanced graphics for its time (some effects and even voxels). It demanded a high specs computer in the time, though.

I know that game from PC magazines of the time, but alas, I have never ever played it.

patsu, that approach could give developers some sophisticated results. The more flexibility the merrier.

If software algorithms are translatable directly to hardware and the GPU is powerful enough then it should be fine to just use hardware acceleration.

Sonic, voxels have a very distinguishing look and after watching the video Davros shared it looks like only the character is made of polygons.

 

[Davros]

Need for Speed was my first game ever!!

Ive just had a Need for Speed day - every NFS except :
nfs road and track - cant be bothered setting up dosbox
nfs underground - uninstalled it ages ago when I needed the space, never put it back on because its so similar to underground 2

One thing ive noticed is the forcefeedback has gone downhill since nfs 5 (porsche challenge) although shift 1/2 were decent

 

[Sonic]

Sonic, voxels have a very distinguishing look and after watching the video Davros shared it looks like only the character is made of polygons.

I don't get it.

 

[milk]

All dynamic geometry on that game used rasterized polygons, whith some sort of bump-mapping, though no texture filtering if my memory is correct. Only the huge environments are "voxel" based, and that too actually consisted of mere tiled heightmaped textures, thus it had no support for overhangs or caves.

 

[patsu]

patsu, that approach could give developers some sophisticated results. The more flexibility the merrier.

If software algorithms are translatable directly to hardware and the GPU is powerful enough then it should be fine to just use hardware acceleration.

Modern GPUs are certainly flexible enough, especially if AMD continue to improve the architecture. Their latest presentation about hUMA where the CPU and GPU work seamlessly together in a unified memory pool should open up new possibilities.

 

[jlippo]

All dynamic geometry on that game used rasterized polygons, whith some sort of bump-mapping, though no texture filtering if my memory is correct. Only the huge environments are "voxel" based, and that too actually consisted of mere tiled heightmaped textures, thus it had no support for overhangs or caves.

Also for speed all old good voxel terrain renderers renderer voxels using method called voxel surfing.
Each column of screen is rendered from down-up and when ray hits a voxel the distance is given as start point to next pixel in column. (Gives a nice speedup, but did restrict camera movement.)

Overhangs and caves would have been possible with additional heightfield for ceiling and it's top, but the cost would have been high.

 

[Grall]

Outcast ran slow enough for the day, so caves...out of the question, unfortunately. Only the most brutish of PCs could run that game at playable speed at its highest-to-my-knowledge-supported rez of glorious 640*480, and to even go that high I believe you needed to edit the config file manually, as otherwise you'd get less I seem to recall.

 

[jlippo]

Outcast ran slow enough for the day, so caves...out of the question, unfortunately. Only the most brutish of PCs could run that game at playable speed at its highest-to-my-knowledge-supported rez of glorious 640*480, and to even go that high I believe you needed to edit the config file manually, as otherwise you'd get less I seem to recall.

Yes, it certainly wasn't fastest game when it was released.

 

[Sonic]

All dynamic geometry on that game used rasterized polygons, whith some sort of bump-mapping, though no texture filtering if my memory is correct. Only the huge environments are "voxel" based, and that too actually consisted of mere tiled heightmaped textures, thus it had no support for overhangs or caves.

This is what I remember.

 

[Silent_Buddha]

All, all the talk of voxels makes me think of now defunct Novalogic who made a few games that only used voxels for everything, and later used polygons in addition to voxels.

I still remember being absolutely blown away by the voxel landscape in the original Commanche back in 1992. And then later even more blown away by the original Delta Force back in 1998. Delta Force 2 they started to use polygons for buildings.

Back then it was absolutely amazing to be able to see miles in every direction, no fog on the horizon, no abrupt mountains just suddenly appearing out of nowhere. Something that wasn't possible at the time using polygon based rendering. And still isn't possible with most game engines today. Then again the trade-off was the relatively low level of detail. Voxels were positively huge.

They eventually switched entirely to hardware accelerated 3D rendering however as voxels were just too slow and the fidelity too low at playable speeds to offer any sort of competition to hardware accelerated 3D rendering at the time.

I like to dream sometimes of how incredible things might be if instead of hardware accelerated polygons, we were able to do hardware accelerated voxels.

Oh and that also reminds me of another voxel based game by now defunct Westwood Studios, Command and Conquer: Tiberian Sun back in 1999.

Regards,
SB