Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Porsche Monty

Most appropriate linux distro for Chocolate Doom

Recommended Posts

Before getting into details, if Chocolate Doom can't go fullscreen and vsync under Linux, don't bother answering anything else.

...so now that I hear it can, what would be the most appropriate linux distro for Chocolate Doom? I don't care how difficult it is to set up, I don't care it completely stinks as a desktop solution, I don't care if it's going to cost me a few hundred, all I care about is that Chocolate Doom runs fast and smooth (on a 3.0ghz with 1024mb ram)

The reason for this is the Alsa drivers which allegedly allow direct access to my CMI8738's OPL hardware, therefore I presume I'd be able to finally enjoy Chocolate Doom's OPL-passthrough solution.

Everytime I tried linux in the past, it turned out to be a complete disaster. I've been told that I shouldn't even bother if I have "WinXP-like expectations", but if I really have to, that I should look no further than Debian.

Ubuntu is completely out of the question for political reasons.

Any help would be greatly appreciated.
Regards.

Share this post


Link to post

I’d like to say any distribution, but chocolate-doom works fine in Debian. Er, no, it messes X’s resolution, but I suspect a driver (nVidia) issue.

Share this post


Link to post

Thanks. This is exactly the reason I ask a thousand times before doing anything I've never done before :)

I really wanted to use my linux modeline paramater from PowerStrip for that perfect 320x200@70hz experience.

Share this post


Link to post

Honestly? I doubt the distro will make any significant amount of difference. You're running essentially the same code on each distro, they might just be newer or older revisions, configured slightly differently or have a few different patches applied.

It sounds like you have very specified requirements for how you want the display to behave. It's almost certainly possible to achieve them, though you'll probably have to invest some time in reading about how to configure X. Don't expect it to be a 5 minute point and click job.

I've had hardware OPL working with a YMF724 in the past. I have a CMI8738 as well but I think I had some problems with it, so you may find it doesn't meet your expectations.

Personally I tend to use Debian nowadays, and it's probably a good fit for what you want to do.

Share this post


Link to post

Thanks.

As long as I can actually accomplish what I have in mind, I'm not discouraged by the learning curve (unless we're talking programming)

I haven't experienced any problems with CMI8738's OPL and vanilla Doom in plain DOS. Everything sounds as expected, so given that YMF724 also works fine, the problem is likely to be related to the sound driver and hopefully not Chocolate Doom.

Debian it is, then.

Share this post


Link to post

Heh, certainly no programming required, but X configuration can be complicated. It's got a lot simpler in recent years so that for most people it isn't a problem any more, but for the kind of control you want, you'll probably have to go beyond what the majority of people have to deal with.

Share this post


Link to post

At the time it takes to configure X, You could just get a 200 MHz computer, load DOS on it and nab a shitty monitor for almost nothing. Hell,it's what I did. I can get that perfect experience just as easily. ;)

(you can tell that I HATE X so much that I'd rather use shitty hardware and avoid it entirely)

Share this post


Link to post

If you hate it that much, just play in framebuffer console. You might have to set an SDL env var, but it'll work with FB in Linux, FreeBSD, and maybe even OpenBSD on some arch (like Sparc).

include/SDL/SDL_config.h lists all the env vars.

I mostly used Dave Taylor's linuxsdoom binary (SVGAlib) in Linux before I found out about source ports. It worked fantastic, except for some mods that used DeHackEd. Well it turns out there was also a Linux ports of that (lde), but I didn't know about it...

Share this post


Link to post

Tsk. Using anything less than a REAL Unix IV or V derivative from the mid 80s is just being a poser.

Share this post


Link to post

Honestly you shouldn't have any real issues; these days X.org's autoconfiguration is good enough for almost all cases (aka, no xorg.conf needed), and you'll get a 320x200@70Hz mode just fine so long as your hardware supports it. (Hell, xrandr reveals a bunch of weird modes for me like 416x312... now WTF is that?)

Pretty much any distribution will work equally well for Chocolate Doom.

Share this post


Link to post

I once downloaded a gif animation that was exactly 416x312 and supposedly created with mac software, according to the author. I remember this because I had never heard of such resolution.

It might very well be nothing, though.

Share this post


Link to post
Maes said:

Tsk. Using anything less than a REAL Unix IV or V derivative from the mid 80s is just being a poser.


x2

Share this post


Link to post

Downloading an iso is the hard way.

I always buy the Slackware distribution with 6 CDROM. That set comes with precompiled kernels, can be booted from CDROM, and I can configure it for any machine. It also comes on DVD.
I comes with full source code for everything, so the Linux kernel can be custom compiled to match the machine.

You can also get CDROM attached to a Linux magazine (expensive way).
A few years ago you could get a set of CDROM that includes Red-Hat, and others, so that the buyer can try them all.

Share this post


Link to post

Depends on your Internet connection, really. Most urban connections are well suited to downloading an ISO within a day (often even within an hour). There is obviously a market for selling CD-ROMs with them still, however, otherwise the businesses selling them wouldn't be.

Share this post


Link to post

I don't understand the question.

Pretty much any distro with python, X and SDL will offer the exact same experience... won't it?

Share this post


Link to post
Porsche Monty said:

I don't care if it's going to cost me a few hundred, all I care about is that Chocolate Doom runs fast and smooth (on a 3.0ghz with 1024mb ram)


WTF @ system specs if the expectation is simply running Chocolate Doom. I do not know how "heavy" it can actually be, down to the point of having smoothness issues with a machine of that class.

While some backyard benchmarks I did with various ports (including my own, Mocha Doom) showed me that Chocolate Doom is indeed not the most optimized of ports (my ranking was prBoom+ > Mocha Doom (yes, it beats the old unoptimized prBoom in stuff like nuts.wad) > prBoom > Chocolate Doom, the latter by a big margin), I'd have a hard time picturing it to be unplayable.

Hell, I can run Mocha Doom at 960 x 600 resolution on a Celeron 1200 and it's running around vanilla framerate, I suppose (?) Chocolate Doom would be at least as good, even with screen doubling? Then again that's on Windows XP, but Mocha Doom works just as well on a similar system even under Debian/Ubuntu, so what's there that "gets" at Chocolate Doom in particular?

Share this post


Link to post
Maes said:

While some backyard benchmarks I did with various ports (including my own, Mocha Doom) showed me that Chocolate Doom is indeed not the most optimized of ports (my ranking was prBoom+ > Mocha Doom (yes, it beats the old unoptimized prBoom in stuff like nuts.wad) > prBoom > Chocolate Doom, the latter by a big margin), I'd have a hard time picturing it to be unplayable.

Software prboom+ should not be much faster than prboom. I do not remember any improvements I made for software renderer except "try_to_reduce_cpu_cache_misses" config variable (sometimes it helps much, sunder map10 as example). But in some places prboom+ is more precise and requires more calculations because of that. Also, prboom+ is compiled by Intel Compiler (with IPO and PGO optimizations) and it should give 10-20%. On nuts.wad I have 100 fps in prboom+ vs 83 fps in prboom (both with screen wiping, because it is impossible to disable it in vanilla prboom)

GL renderer is much faster (glboom even does not sort walls, flats and sprites by texture). Just tested on my Core2 E6750 @ 2.66GHz:

epic map05:   301 fps vs 67 fps  (4.5x)
nuts map01:   146 fps vs 38 fps  (3.8x)
sunder map10: 140 fps vs 36 fps  (3.8x)
dv map01:     933 fps vs 102 fps (9x lol)
My test set:
http://prboom-plus.sourceforge.net/test_demos.zip

P.S. Did you test chocolate doom in 'windib' mode? IIRC, 'directx' is default mode in chocolate-doom and it is slower than 'windib'

Share this post


Link to post
Maes said:

While some backyard benchmarks I did with various ports (including my own, Mocha Doom) showed me that Chocolate Doom is indeed not the most optimized of ports

Yep. I've never put very much effort into optimizing it at all. The biggest bottleneck is the screen resizing, and for the rest of it, optimization is unlikely to have any significant effect on modern machines. Throughout the history of the project I've never bothered with optimized assembler drawing functions, for example.

Share this post


Link to post

I never changed default settings for Chocolate, so I guess it's DirectX mode.

I remember distinctly that at least in terms of map code Mocha could smoke the old prboom in nuts.wad on a Celeron 1200. Mocha Doom: a slideshow, but at least playable, and recouped normal speed in automap mode. PrBoom: more of a slideshow, not playable, and even automap mode didn't recoup any speed ;-)

As that map didn't actually become playable until prBoom+ to the best of my knowledge (perhaps to blame to the default prBoom settings), that was kind of expected.

Then again that was on an XP machine with little RAM (384 MB). My theory is that Java's GC mechanism might give it an advantage in such maps where a lot of stuff is being created and destroyed continuously, since memory for dead mobj_t's is not freed immediately, and so the associated overhead does not occur right "there and then". Of course, such mechanisms could be hacked into the Zone subsystem.

I also made some tests in the built-in E2M2/E3M5/E4M2 demos of Ultimate Doom on a Core 2 T8300, in software mode (OpenGL mode for prBoom just didn't pump out enough FPS to be competitive), and Mocha still beat normal prBoom by a measurable margin, or at least was practically head-to-head (gotta dig those benchmarks out...).

BTW, these are the only demos I know of that run OK in all four ports, so I use them as timedemo benchmarks. Sadly I still have some issues syncing the other built-in demos due to some vexing desync issues I still can't pinpoint.

Share this post


Link to post
Maes said:

WTF @ system specs if the expectation is simply running Chocolate Doom


I'm not worried about Chocolate Doom's performance on my computer but Linux being so much of a bottleneck.

My last experience with Linux went like this: most apps that were supposed to run in fullscreen, couldn't do so. The few that did wouldn't even vsync, and if miraculously any managed to pull that off, it was slow as hell.

At this point I'm just expecting everything to screw up or not work at all...but hey, anything for decent OPL.

Share this post


Link to post
Porsche Monty said:

I'm not worried about Chocolate Doom's performance on my computer but Linux being so much of a bottleneck.


Linux + performance?

The answer is obvious: become a Gentoo ricer and compile EVERYTHING with the proper flags for your machine.

Share this post


Link to post
Porsche Monty said:

I'm not worried about Chocolate Doom's performance on my computer but Linux being so much of a bottleneck.

My last experience with Linux went like this: most apps that were supposed to run in fullscreen, couldn't do so. The few that did wouldn't even vsync, and if miraculously any managed to pull that off, it was slow as hell.

Could have any number of causes. I'd suspect video driver issues - for example, you might have been using X in VESA mode instead of an optimized driver for your video card. You'll get similar poor performance if you run Windows with its generic VESA drivers. If that was the case then the kernel itself (Linux) wouldn't really have had anything to do with your problem.

Maes said:

Linux + performance?

The answer is obvious: become a Gentoo ricer and compile EVERYTHING with the proper flags for your machine.

And make sure you compile Chocolate Doom with --enable-penis-extension.

Share this post


Link to post

@Maes: not a bad idea if I actually cared for Linux.

@Fraggle: I'm pretty sure I got the drivers working as I tried some Utah teapot OpenGL test app (I think it came bundled with the distro) and I was getting like 220fps, in windowed mode, that is.

Share this post


Link to post

Chocolate Doom runs fine on my old dumpster laptop (IBM ThinkPad T30). And that's in OpenBSD (not a "ricer" OS), with these deliberately de-optimized sysctl settings:
hw.setperf=0
hw.cpuspeed=1197 (a result of the above)
machdep.allowaperture=1 (X security workaround, see xf86 manpage)

dmesg excerpt:

cpu0: Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz ("GenuineIntel" 686-class) 1.20 GHz
real mem = 535851008 (511MB)
avail mem = 510480384 (486MB)
vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility M7" rev 0x00


I run chocolate-doom in fullscreen mode, with aspect correction, at 640x480 (the lowest my LCD will go).

Share this post


Link to post

You can pretty much discredit Maes on the topic of Linux; he's trying to mock his idea of a "typical" Linux user that doesn't really exist (well, to be fair, it probably does in some corner somewhere).

Share this post


Link to post

Maes is being facetious for comedic effect.

Gentoo ricers used to be really prevalent, around the time that Gentoo's GCC fork was faster than mainstream GCC. However, those changes got ported back upstream so now all distros are as fast as Gentoo used to be.

I'm sure there are still people who insist on running Gentoo and compiling their whole OS with some obscure CPU flags to eke milliseconds more speed from their bootup but they'd have to be a minority, even amongst otherwise-rational Gentoo users.

Porsche Monty said:

My last experience with Linux went like this: most apps that were supposed to run in fullscreen, couldn't do so. The few that did wouldn't even vsync, and if miraculously any managed to pull that off, it was slow as hell.

So to answer your original question: The most appropriate Linux distro for Chocolate Doom is one where the video drivers work properly.

Share this post


Link to post
chungy said:

You can pretty much discredit Maes on the topic of Linux; he's trying to mock his idea of a "typical" Linux user that doesn't really exist (well, to be fair, it probably does in some corner somewhere).


Did you remember to compile your humor kernel module?

fraggle said:

Yep. I've never put very much effort into optimizing it at all. The biggest bottleneck is the screen resizing, and for the rest of it, optimization is unlikely to have any significant effect on modern machines. Throughout the history of the project I've never bothered with optimized assembler drawing functions, for example.


This pays off though in portability, correct? That's one of the chocodoom project pie-in-the-sky ideas are, anyway.

Share this post


Link to post
fraggle said:

Yep. I've never put very much effort into optimizing it at all. The biggest bottleneck is the screen resizing, and for the rest of it, optimization is unlikely to have any significant effect on modern machines. Throughout the history of the project I've never bothered with optimized assembler drawing functions, for example.


For what it's worth, Chocolate Doom runs smoothly on my computer no matter the resolution. From 320x200 up to 1600x1200 with the scanline thing on, all exactly as smooth.

I'm guessing it would only make sense to optimize for PIII's with integrated gpu's and below?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×