Linux progress

[Graf Zahl]

Sure. And Hirogen's frame rates aren't really that bad. But it's still a stripped down version of an 8 year old graphics card. Some performance hits must be expected by that. I still think that the system performs as well as the hardware allows.

[Blzut3]

Something must have changed between Kubuntu 8.04 and 8.10 since I'm now able to get ridiculous frame rates using GZDoom's renderer (assuming I have a 32-bit binary made). About 600fps on MAP01, 200fps on E1M1, 1152x648 with a HD3870. OpenGL is still unusable for me since it seems to cause rapid flashing (vsync isn't working), but that is probably an ATI driver problem.

I don't think his graphics card/processor has anything to do with his software renderer frame rates since I get about the same (Core 2 Quad Q6600).

[Hirogen2]

To be blunt, why do you complain that such old hardware has performance problems? Do you really expect it performs as well as something even remotely current? ZDoom still has to transfer the entire screen from main to video RAM and the bottleneck in your setup seems to be precisely there. If you'd repeat your test with at least a Geforce 4 I could take your results more seriously.

Point being that the last time I tried it in a native Windows environment with the same machine and GFX, I got in the excess of 200 fps for the software mode with DirectX, and the GL mode in Windows was of course lower than these 200. I was simply showing that Randy's observation that SDL still sucks.

[Graf Zahl]

What else is new...?

[randi]

But how much of that is SDL's fault, and how much of it is because it's sitting on top of a windowing system that was never really meant for high-performance graphics?

[Blzut3]

Which brings us back to does it really matter if you get 90fps or 600fps? You still only see 75 of them (in my case). Of course I'm wondering if vid_vsync is broken or if it has something to do with my graphics driver since I've been forced to cap it to 35fps.

[Hirogen2]

But how much of that is SDL's fault, and how much of it is because it's sitting on top of a windowing system that was never really meant for high-performance graphics?

You are right. It is not SDL's fault, but X11 — because SDL can use the Xv overlay, and does so under mplayer when Xv is available.

Which brings us back to does it really matter if you get 90fps or 600fps? You still only see 75 of them

Yes it matters. Because once you get in an areas with higher detail or monster count, the framerate will naturally drop. And when that happens, every additional FPS is a good thing—under the assumption that X11 output takes constant amount of CPU to copy one ZDoom-produced frame to the video memory. It would leave more CPU time for in-game action.

[Woolie Wool]

EDIT: Fuck, where did this old thread come from? Never mind...

EDIT Part II: The Sequel: I'm getting even worse FPS than many other people: only 30 FPS at the beginning of MAP01 at 1280x960. To compare, the last time GZDoom actually compiled in Linux (64-bit, I don't know about 32-bit), around r268, I got 440 FPS at 1600x1200. That's a 1450% difference.

In Windows, I get 110 FPS in ZDoom at 1920x1200, and 464 FPS in GZDoom (originally locked at 60 FPS until I set Vertical Sync to "force off" in the nVidia control panel). Running Windows builds of GZDoom under Wine yields around 250 FPS.

EDIT Part III, The Terror Continues. I guess system specs would probabably be in order:
AMD Athlon X2 4300+
nVidia GeForce 8800 GTS
4096 MB RAM
Dual boot Windows Vista SP1 (32-bit)/Kubuntu 8.10 (64-bit)

[Lemonzest]

Just for kicks i ran both gzdoom opengl and zdoom (had to use vid_forceddraw true) in WINE and i got the following

ZDoom E1M1 around 70-80fps
GZDoom E1M1 around 600fps

which is around what i was getting on my old 2Ghz system.

Specs are

Linux Mandriva 2008.1 x86_64

Pentium Dual core E2180 (2Ghz)

4GB Corsair XMS2 DDR2 800Mhz Ram.

[Csonicgo]

But how much of that is SDL's fault, and how much of it is because it's sitting on top of a windowing system that was never really meant for high-performance graphics?

QUOTED FOR TRUTH.

I cannot believe how much X truly sucks. Google realised this and made their own framebuffer for Android as X is everything but fast.

and I can't believe that X uses so much CPU on such mundane tasks that other implementations (like what windows uses) consider effortless. such a shame.

Nvidia has even noticed this: when you load official Nvidia drivers into X, the driver actually replaces the memory manager of X and many other things with their own methods, and up, up, up goes the framerate, down, down, down goes the CPU hog.

[Chris]

I cannot believe how much X truly sucks. Google realised this and made their own framebuffer for Android as X is everything but fast.

Can say the same thing about GDI in Windows, which is also slow as all hell. If you want high-performance graphics, use an API designed for that.

[Graf Zahl]

To be honest, I'd like to see an OpenGL alternative to the current D3D implementation in ZDoom. Then I could re-enable renderer switching in GZDoom but currently when I configure the engine to do so it crashes badly.

[Csonicgo]

I cannot believe how much X truly sucks. Google realised this and made their own framebuffer for Android as X is everything but fast.

Can say the same thing about GDI in Windows, which is also slow as all hell. If you want high-performance graphics, use an API designed for that.

yeah, but openGL isn't for 2D... :[


Also, why is directly accessing hardware that benefits from being accessed directly so fucking difficult in linux? it's not like someone is going to haxxor my boxxor using my damn video card.

[randi]

GDI on Windows

But Windows also has had DirectDraw for 10+ years, which gives you direct access to the video memory and still plays nice with the windowing system, so having to use GDI isn't an issue.

openGL isn't for 2D

It's just as much for 2D as Direct3D is.

[Graf Zahl]

yeah, but openGL isn't for 2D... :[

It still has hardware accelerated 2D drawing to offer so your statement is untrue by default.