Software Rendering Demo

[BRiT]

37fps at starting position -- AMD 2.3Ghz actual [11.5*200], with fps dipping lower at other spots.

Impressive looking, but way too slugish for a FPS game.

 

[Thowllly]

Impressive looking, but way too slugish for a FPS game.

IMO, it was not sluggish at all. It's much less sluggish than HW rendering at the same framerate. Maybe it's just me, but the only thing making it feel sluggish, I think, was the very low mouse sensitivity, but apart from that it was very responsive.

Edit: Just tested it again, and yes, I still think it's the low mouse sensitivity that makes it feel sluggish; it is very responsive to keyboard controls.

 

[BRiT]

Perhaps... but I'm used to 1600x1200@32bit+Max Qual+6xAA+8xAF Qual at over 100fps in Q3A. So to me, it was way too slugish. ie: too low of fps with what little eye-candy it did delivered.

 

[Lezmaka]

17.8 fps on a P3 800

I'm kinda used to sub 30 fps though, playing BF1942 on a 60 player server definately slows things down, lol. But if the server is half full, i get around 30fps, which isn't tooo bad.

 

[Nick]

Impressive looking, but way too slugish for a FPS game.

It's not meant to be a game. It's a tech demo or a proof of concept for soft-wiring technology. People from DivX development are experimenting with it right now and get speedups of 15% from the first attempt.

Also, Quake III does not have a software renderer so it hasn't been build with software rendering in mind. The visibility system 'allows' lots of overdraw because a hardware z-buffer can handle this. I'm planning to implement portal clipping which should reduce overdraw to nearly zero, but this needs total re-processing of the maps...

It's like when the Doom III demo leaked out nobody actually had the hardware to run it at a constant 30 FPS, but it still looked impressive

 

[Nick]

IMO, it was not sluggish at all. It's much less sluggish than HW rendering at the same framerate. Maybe it's just me, but the only thing making it feel sluggish, I think, was the very low mouse sensitivity, but apart from that it was very responsive.

Edit: Just tested it again, and yes, I still think it's the low mouse sensitivity that makes it feel sluggish; it is very responsive to keyboard controls.

Thanks, in the next release I'll make the mouse sensitivity adjustable (didn't have the time to write a config file parser yet).

Because I know I can't reach the same FPS as hardware (except at lower resolutions), I made sure the work is spreaded equally over all frames to get a smoother feeling. Quality is adjusted slightly to keep the frame rendering time around the average. Anyone noticed dithering or point filtering artifacts already? Also the quality of perspective correction and mipmapping is controlled dynamically at no cost thanks to SoftWire.

 

[darkblu]

hey nick,

real nice renderer there! chances you open the source code?

edit: ok, you have the softwire core opensource alright, but it'd be interesting to see your ps->sse translator

 

[Dio]

Yes, my next comment was to mention darkblu's THURP, and also Pixomatic...

The compiled pipeline idea is undoubtedly the way to go forward for software rendering. It's the kind of thing I'd really love to work on but don't have the time...

 

[Nick]

real nice renderer there! chances you open the source code?

This demo won't be open-sourced, mainly because a big part of the code is two years old and a little buggy You might have noticed that after pressing Esc it takes a few seconds to actually terminate the program...

But the good parts will be reused in my ps 2.0 emulator, which will be open-source really soon. By the end of the month I'd like to finish a demo to accompanie my article in the upcoming ShaderX 2 book.