Linux progress
Moderator: GZDoom Developers
Linux progress
Last night, I sat down and spent two hours updating the Linux side of the ZDoom code so that it works with the current version of ZDoom. I'm quite disappointed that XFree86 is basically at the same state it was in the last time I used ZDoom under Linux in 2000: It still sucks for fast action 2D games. Compare the following performance figures. These are all taken on my own computer with an Athlon XP 2400+ and AGP video card running ZDoom at 1024x768. These are the framerates at the very start of Doom's E1M1. The 16-bit and 24-bit times on Windows were obtained by running in a window, and the 8-bit time was fullscreen. On X, running in a window or fullscreen is irrelevant since there is no mechanism for changing the color depth without completely shutting down X, so playing fullscreen offers no performance benefit over playing in a window.<table align="center"><tr><th></th><th>Linux (XFree86)</th><th>Windows (DirectX)</th><th>Linux/Windows</tr>
<tr><th> 8-bit </th><td>133 fps</td><td>150 fps</td><td>89%</td></tr>
<tr><th> 16-bit </th><td>85 fps</td><td>135 fps</td><td>63%</td></tr>
<tr><th> 24-bit </th><td>55 fps</td><td>128 fps</td><td>43%</td></tr></table>
On an 8-bit display, X isn't too bad and is almost as fast as Windows. With 16-bit color, it is barely more than half the speed of Windows. Playing at 24-bit under X is absolutely pathetic compared to Windows. Even compared to an 8-bit X display, a 24-bit X display is abysmal, running 78 fps slower. Windows suffered a performance penalty of only 22 fps for a 24-bit display.
Maybe bypassing X and using OpenGL as a simple framebuffer will get better performance... I know it's not the fault of the compiler, because a GCC-compiled Windows version of ZDoom performs on-par with a Visual C++-compiled version, and I assume SDL doesn't have that much overhead, so I hope there's something I can do to get decent performance out of it short of not using X.
I also miss having a decent integrated development environment under Linux like Visual Studio. KDevelop looked promising until I found out it can't handle projects with files in more than one directory.
Anyway, here is the obligatory screenshot of ZDoom running on Linux:
<tr><th> 8-bit </th><td>133 fps</td><td>150 fps</td><td>89%</td></tr>
<tr><th> 16-bit </th><td>85 fps</td><td>135 fps</td><td>63%</td></tr>
<tr><th> 24-bit </th><td>55 fps</td><td>128 fps</td><td>43%</td></tr></table>
On an 8-bit display, X isn't too bad and is almost as fast as Windows. With 16-bit color, it is barely more than half the speed of Windows. Playing at 24-bit under X is absolutely pathetic compared to Windows. Even compared to an 8-bit X display, a 24-bit X display is abysmal, running 78 fps slower. Windows suffered a performance penalty of only 22 fps for a 24-bit display.
Maybe bypassing X and using OpenGL as a simple framebuffer will get better performance... I know it's not the fault of the compiler, because a GCC-compiled Windows version of ZDoom performs on-par with a Visual C++-compiled version, and I assume SDL doesn't have that much overhead, so I hope there's something I can do to get decent performance out of it short of not using X.
I also miss having a decent integrated development environment under Linux like Visual Studio. KDevelop looked promising until I found out it can't handle projects with files in more than one directory.
Anyway, here is the obligatory screenshot of ZDoom running on Linux:
- Chris
- Posts: 2940
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
I use Linux, actually. Haven't touched Windows in over a month, and I've been dying for a newer version of ZDoom. Does SDL work with SVGALib? You can use that for fullscreen modes (it works under X for me) and it offers pretty good performance (you can switch color depths with it). Unfortunately SVGALib can only be used while under root afaik, but it should be possible alternative. OpenGL as a framebuffer might also work, but my understanding is that uploading/updating video memory textures is fairly slow. I have no idea how it compares with X, though. Might not be that bad.
The development versions of svgalib have a kernel module so the program doesn't need to be run as root. For people that it works for, that might be an option, but I can't seem to get SDL to know about it. (Although the svgalib test programs work fine).
Uploading textures with OpenGL is only slow because writing to video memory is slow. I would be very suprpised if it's any slower than drawing to a window already is. Hopefully by eliminating some of the abstraction offered by X and going closer to the driver, I can get closer to the performance the hardware is actually capable of.
Uploading textures with OpenGL is only slow because writing to video memory is slow. I would be very suprpised if it's any slower than drawing to a window already is. Hopefully by eliminating some of the abstraction offered by X and going closer to the driver, I can get closer to the performance the hardware is actually capable of.
sdl and svgalib
iirc, using svgalib through sdl is as simple as:
$ export SDL_VIDEODRIVER=svgalib
i hope that works for you randy, i can't wait to play the new zdoom out of curiosity, what kind of video card do you have?
$ export SDL_VIDEODRIVER=svgalib
i hope that works for you randy, i can't wait to play the new zdoom out of curiosity, what kind of video card do you have?
Nice! Thanks!randy wrote:Last night, I sat down and spent two hours updating the Linux side of the ZDoom code so that it works with the current version of ZDoom.
XFree86 isn't really designed for that sort of thing. After all, what is Direct Draw (which I understand you use for ZDoom), but a way to bypass Window's windowing system.randy wrote:I'm quite disappointed that XFree86 is basically at the same state it was in the last time I used ZDoom under Linux in 2000: It still sucks for fast action 2D games. Compare the following performance figures.
I understand that X's performance is significantly better with kernel version 2.6.
Hmm... Are you sure? I assume you tried the recently released KDevelop 3.0.randy wrote:I also miss having a decent integrated development environment under Linux like Visual Studio. KDevelop looked promising until I found out it can't handle projects with files in more than one directory.
If you are certain, do you mean a nested or a disjoint directory structure? If you mean multiple unnested directories, then I would suggest simply making some symbolic links to the appropriate directories.
BTW, I don't see what is so great about "integrated development environments" anyway, though. I used to use such things when I was using Windows, but I found that I didn't really care to seek out similar things on Linux once I had worked with simpler setups of syntax-highlighting text editors and some open consoles. (The dos prompt is a joke compared with the excellent bash (Bourne-Again SHell)) and included text-processing utilities.
I now use kate, with its MDI and intergrated console. I simply do my testing in the console. Also, I understand that the version that comes with KDE 3.2 has some sort of support for projects.
I would be running kernel version 2.6 and KDE 3.2 already, if I weren't stuck on a dialup connection. Its too much hassle to upgrade now anyway with my CS Master's program.
- Hirogen2
- Posts: 2033
- Joined: Sat Jul 19, 2003 6:15 am
- Graphics Processor: Intel with Vulkan/Metal Support
- Location: Central Germany
- Contact:
SDL can be instructed to use GL on purpose (IIRC). Also take a look at mplayer, which has about the same problem - presenting 2D pictures in a reasonable performance. You also might look at its "xv"(general) or "xvidix"(ATI specific), "svgalib" and "vesa" VO drivers. (Vesa is actually more performant than svgalib for me.)Maybe bypassing X and using OpenGL as a simple framebuffer will get better performance..
Well you could test the SDL driver on Windows of course and compare FPS then. Or more easier: just compare the performance of prboom-linux with prboom-win32, both use SDL. Maybe have a look at SDL_image.and I assume SDL doesn't have that much overhead,
Last time you said you like RHIDE, it's available for Linux too of course.I also miss having a decent integrated development environment under Linux like Visual Studio. KDevelop looked promising until I found out it can't handle projects with files in more than one directory.
- Chris
- Posts: 2940
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Of course. VESA was at one point the defacto standard for GFX interfacing, back in the DOS days. It had, at least some, time to flourish, unlike SuperVGA which was quickly overtaken by VESA, and never really was much of a standard. In actuallity, you might be able to use VESA with SDL too (I'm not totally sure on this though).Vesa is actually more performant than svgalib for me.
I wouldn't be too sure about that. SDL, from what I've heard, was designed around Linux, whereas Allegro was designed around DOS (and to a lesser degree, Windows). SDL performs better in Linux, just as Allegro performs better in Windows/DOS. The overhead between SDL<->WIndows is most likely bigger than the overhead with SDL<->Linux.Well you could test the SDL driver on Windows of course and compare FPS then.
What?? Where? I loved RHIDE. Too bad it didn't work right in Win2k or with MinGW..Last time you said you like RHIDE, it's available for Linux too of course.
Here: http://www.rhide.com/Chris wrote:What?? Where? I loved RHIDE. Too bad it didn't work right in Win2k or with MinGW..Last time you said you like RHIDE, it's available for Linux too of course.
- Hirogen2
- Posts: 2033
- Joined: Sat Jul 19, 2003 6:15 am
- Graphics Processor: Intel with Vulkan/Metal Support
- Location: Central Germany
- Contact:
Uh setedit (and the enhancement "rhide") work both for me on Linux and Windows (98 though). Though, they are Win32 binaries (yes and thus can use all the memory). However, they use a DOS box. Should not be that hard.
http://setedit.sf.net/
http://rhide.sf.net/
IIRC!
(If you really use them, set "forced ISO-8859-1" mode in Options > Encoding, but only for "application". That way you can use any character above 127 and it will show in Windows and Linux as it should.
http://setedit.sf.net/
http://rhide.sf.net/
IIRC!
(If you really use them, set "forced ISO-8859-1" mode in Options > Encoding, but only for "application". That way you can use any character above 127 and it will show in Windows and Linux as it should.
Where is it?
Where is the archive? Maybe it's not ready?
Well... I think what you compared is like DirectDraw vs. PutPixelExA.
The standard X11 functions just aren't designed for games. They are designed for simple GUIs and the possibility to use GUI programs over a network.
There are many newer and faster ways for things, like that like using xv, opengl, dga, xshm, ...
Maybe you should ask in the SDL newsgroup about this. I bet SDL supports at least some more advanced ways for this.
And BTW: Since XVidModeExtension 2.0, a program can also switch the color depth.
The standard X11 functions just aren't designed for games. They are designed for simple GUIs and the possibility to use GUI programs over a network.
There are many newer and faster ways for things, like that like using xv, opengl, dga, xshm, ...
Maybe you should ask in the SDL newsgroup about this. I bet SDL supports at least some more advanced ways for this.
And BTW: Since XVidModeExtension 2.0, a program can also switch the color depth.