Page 1 of 2

Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 8:34 am
by invictius
P3-700 slot 1, 512mb ram, geforce 4 agp: 140fps.
P3-1ghz socket 370, 512mb ram, intel onboard: 75.

Vsync off, 320x200, zdoom software mode. Surely the intel onboard video isn't crippling it to this degree. Similar result for an e1m1 timedemo also. And finally, the 700 is running windows me, the 1ghz running xp. Might put me on the 1ghz but it would be a shame because the xp install has all the drivers etc.

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 8:49 am
by Rachael
Yes, older Intel GPU's are very bad with acceleration and processor clocks. Have you tried "r_forceddraw true" on that particular system?

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 9:09 am
by invictius
Rachael wrote:Yes, older Intel GPU's are very bad with acceleration and processor clocks. Have you tried "r_forceddraw true" on that particular system?
2.8.1 doesn't recognize that command. Nor does zdoom le.

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 9:26 am
by wildweasel
Have looked it up: the command's actually vid_forceddraw. That'd explain why it wasn't recognized. =P

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 9:30 am
by Rachael
Oops. :oops:

We definitely need to consolidate the r_ and vid_ namespaces. Having them separate is certainly annoying. :P

I think r_* is meant for the actual rendering code and vid_ is supposed to deal with the hardware code, itself.

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 9:32 am
by wildweasel
Rachael wrote:Oops. :oops:

We definitely need to consolidate the r_ and vid_ namespaces. Having them separate is certainly annoying. :P
Well, I also tend to forget ZDoom doesn't have a cg_ namespace, and keep trying to toggle cg_drawFPS out of habit from Quake 3. =P

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 10:25 am
by invictius
wildweasel wrote:Have looked it up: the command's actually vid_forceddraw. That'd explain why it wasn't recognized. =P
197 on the 1ghz, 343 on the 700. This is on LE, I've been liking the fact that that and CE use the one config file for all systems instead of creating a new one for each pc name, solves a lot of headaches when benchmarking all systems equally. Although the intel drivers appear to be the ones that came with xp, might try hunting down some real ones - would it cause that much of a performance difference though?

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 10:40 am
by Rachael
Yes, it would.

Vendor supplied drivers are almost always better than Microsoft supplied ones - although in Windows 10 that's been changing for the better, thankfully.

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 10:56 am
by invictius
Rachael wrote:Yes, it would.

Vendor supplied drivers are almost always better than Microsoft supplied ones - although in Windows 10 that's been changing for the better, thankfully.
I've got a p4 2ghz with a similarly named intel chipset that gave me about 70fps... putting in a lowly geforce 2 mx gave me 400fps. Unfortunately the 1ghz doesn't have an agp slot, would a lowly pci s3 trio with 2mb ram be any better than the intel?

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 10:57 am
by wildweasel
invictius wrote:would a lowly pci s3 trio with 2mb ram be any better than the intel?
From my experience, an S3 chip of any model would produce worse results than software rendering.

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 11:25 am
by invictius
wildweasel wrote:
invictius wrote:would a lowly pci s3 trio with 2mb ram be any better than the intel?
From my experience, an S3 chip of any model would produce worse results than software rendering.
Might have to start a gofundme for a pci gf 5500 off of ebay. I chucked my pci voodoo banshee in and it wouldn't even POST.

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 1:18 pm
by drfrag
On LE the username is only used on win2k and later. Also there's a setting in display options to switch between d3d and ddraw. The runme cmd file is included just in case you mess things up.

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 1:29 pm
by invictius
drfrag wrote:On LE the username is only used on win2k and later. Also there's a setting in display options to switch between d3d and ddraw. The runme cmd file is included just in case you mess things up.
In what ways is using direct3d as a renderer different from running gzdoom?

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 2:47 pm
by wildweasel
invictius wrote:
drfrag wrote:On LE the username is only used on win2k and later. Also there's a setting in display options to switch between d3d and ddraw. The runme cmd file is included just in case you mess things up.
In what ways is using direct3d as a renderer different from running gzdoom?
Direct3D is used as a rendering surface for the software renderer, not as the renderer itself. The game renders at the usual 8bpp, but draws that to a D3D surface in true color, thus making it effectively immune to Windows 7's palette glitch, as well as enabling smoother window resizes if running windowed. (Oh, and supporting true-color HUD graphics.)

Re: Why is this particular timedemo result so abysmal?

Posted: Thu Jun 01, 2017 4:36 pm
by koverhbarc
Yes, that's the confusing bit. Direct3D is, as this user found, likely to be slower on systems where it matters. Why is DirectDraw not the default for XP and earlier?