Doom 3 - Linux, Multi-Monitor, DirectX 8 Solutions

nukem996 writes "While the official port of Doom 3 to Linux is still not complete and we still do not know when it is going to be out, other then 'in a few days after the Windows release', Linux users can finally play Doom 3 on Linux with the help of Wine." Elsewhere, an anonymous reader points to a post on the GideonTech forums explaining multi-monitor Doom 3 play, with the caveat: "Doing this with only 2 monitors completely sucks. You want atleast 3, or 5.. or any odd number of monitors (so your center of playing field isn't split between two monitors)." Finally, toasted_calamari explains: "We have written a guide to optimizing Doom 3 for DirectX 8 systems, particularly older ATI Radeon cards. This guide should assist owners of older hardware in running Doom 3 more effectively without upgrading."

Comments

Cmon now.

[ftgow]

Let's hope the Linux port arrives post haste. Rebooting hurts.

Also, it would be nice...

[cyberkreiger]

... if the headline didn't contain both "doom 3" and "linux" unless the linux client was out, so as to not make me jump unnecessarily.

Re:Also, it would be nice...

[tulare]

Well, if you really want to know when it's out, there's a rather useful website, including an option to get automatic email notification when the linux binaries are available.
[/shameless_plug]

what's the point of emulation?

[OleMoudi]

The hardware requirements to play smoothly Doom 3 on a windows machine are high enough to think that the result of a emulation through wine would require even higher computer specs to play D3 the way it was meant to be played.

Doesn't emulation decrease perfomance? So what kind of megacomputer would you need to play that kind of graphically bloated games through emulation?

Maybe I'm missing something

Re:what's the point of emulation?

[cyberkreiger]

You're missing the fact that Wine(X) Is Not an Emulator. Doom3 under Wine(X) runs directly on the hardware.

Re:what's the point of emulation?

[noselasd]

Wine - Wine Is Not an Emulator.
It just implements Windows APIs, no emulation.
All games I've tried runs about equally good on Windows as on
Linux with Wine(x), that is, you must ofcourse have hardware
accelerated drivers installed on linux.

Re:what's the point of emulation?

[Satertek]

Wine Is Not an Emulator

With that said, there is usually only minimal to no decrease in performace when using Wine.

Re:what's the point of emulation?

[Anonymous Coward]

(When it works)

Re:what's the point of emulation?

[Anonymous Coward]

Wine is naturally an emulator. You don't have to emulate hardware to be an emulator. And I wouldn't call having to get every undocumented and obscure nuance correct for software to run a re-implementation. ncurses is a reimplementation, not wine and friends.

Re:what's the point of emulation?

[Anonymous Coward]

Wine is naturally an emulator. Stop thinking in terms of arcade and video game console emulators that you use to play pirated games.

Re:what's the point of emulation?

[Anonymous Coward]

Wine is naturally an emulator. The name tells you nothing. It's like saying a "compassionate conservative" is, well, compassionate because the label the politician gave himself says so. So I guess the wine project meant it to be one of those oxymorons people like to quote, like "military intelligence" and "jumbo shrimp."

At best, the overhead is a few more layers of function calls. At worst, whole chunks of data have to be converted (ex. vertex color formats in Direct3D).

Re:what's the point of emulation?

[RailGunner]

Really? I usually notice a huge performance decrease when using Wine. Blurred vision, slurred speech, light-headedness, a sense of euphoria.

Oh wait - you're talking about the PC, not the player. Never mind.

Re:what's the point of emulation?

[addaon]

Why would there have to be any more layers of function calls? You're assuming a layer of translation - emulation - that's simply not required.

Re:what's the point of emulation?

[Anonymous Coward]

Erm. When a Windows application calls CreateFile(), it still has to go through a bit of massaging before open() finally gets called. Now for CreateFile this isn't much of an issue, but think API calls that are called very often per frame in a game. Still not much of a problem these days ("batch, batch, batch"), but there are still situations that are difficult or annoying to handle, like where vertex colors need to be swizzled to match OpenGL or the application wants write access to the Z Buffer, and so on.

You're getting hardware emulation and emulation confused. They are not the same thing. When winex has to copy Windows's memory allocation layout so that MoH: AA does not crash, well, I think it has gone way beyond a simple API reimplementation.

Re:what's the point of emulation?

[cjpez]

Wine is naturally an emulator.

Actually, no it's not. Wine merely implements the Windows API. Emulation, with relation to computers, generally involves taking machine language instruction-per-instruction and emulating the physical environment, so you can do things like run arcade games a la MAME, x86 envrionments a la Bochs, or other architectures. Wine doesn't do any of that. It merely allows the Windows binary to be executed in a non-windows environment. Prior to Sorenson support in mplayer, I used Crossover to play Quicktime videos, and they ran fine. I don't see any difference in performance between native Windows/Wine on Half-Life, GTA3, or GTA-VC.

I'm sure you could find some examples where performance did noticeably decrease because the Wine implementation of a particular API wasn't optimally, er, implemented. But that's got nothing to do with actual hardware emulation.

Re:what's the point of emulation?

[addaon]

But why are you assuming that open() has to be called? I agree this is the current method for many functions, though not all, and that it is 'emulation', but I disagree that it is an inherent aspect of the WINE project.

Re:what's the point of emulation?

[Minna Kirai]

Actually, no it's not.

Yes it is.

Wine merely implements the Windows API.

Bochs merely implements the Intel 386 opcodes.

Emulation, with relation to computers, generally involves taking machine language instruction-per-instruction and emulating the physical environment

That's not the definition of "emulation". You are referring to "CPU emulation", which is a specific subset of emulation. Software can be emulated too- "emulate" merely means to copy something else; to do what it does. Humans generally have 2 arms and 2 legs; but that doesn't make it OK to say "Max Cleland is not a human"- a statement that is equally as correct as "Wine is not an emulator".

Ask yourself if Wine is just "implementing the Windows API", or imitating Windows. If there's a bug in Windows XP where it doesn't obey it's own API docs, do you think the Wine developers will follow the docs, or the real behavior?

But that's got nothing to do with actual hardware emulation.

No, it has to do with software emulation. Wine emulates Windows, but is not a clone of Windows, because it doesn't have all it's own OS kernel and video drivers (it gets those services from Linux instead). As such, Wine will always have at least one additional layer of function calls beyond what real Windows would have, and that means it will be slower. The only way Wine could meet the speed of Windows is if Microsoft had made a real error in their own implementation.

Re:what's the point of emulation?

[Anonymous Coward]

Sigh. Did you even try to read my posts? I've said it before and I'll have to say it again: emulation does not imply hardware emulation. For example, show me the per-instruction interpretation in "TTY Emulation" (a common phrase).

And nowhere did I say that "Because wine is an emulator, it has to be slow." I checked my posts, and I used the word "overhead." The overhead can be unnoticible (but it still exists), or it can be a killer.

It doesn't even matter whether wine is an emulator or not; it's just annoying every time someone goes and uses that stupid catchphrase name that was a joke in the first place as evidence that somehow wine is not an emulator, and it is amusing how people are always trying to refute my claims.

Re:what's the point of emulation?

[Minna Kirai]

But why are you assuming that open() has to be called?

The only way Wine could get around calling open() would be for them to replace Linux's glibc or kernel and perform the functions they normally provide to it. Then it would no longer be "emulating Windows on top of Unix", but "cloning Windows as an x86 OS". It wouldn't be Wine anymore, but ReactOS.

(Note: Wine is not an x86 emulator. But Wine is a Windows emulator)

Re:what's the point of emulation?

[Anonymous Coward]

Err, what else is CreateFile going to do?

Re:what's the point of emulation?

[bobstevens_took_my_n]

What is even more funny than this debate, is that people think that the phrase "WINE Is Not an Emulator" is some sort of argument in the debate.

Andreas, who started the Wine project, has referred to it as a "Windows emulator" on the Wine mailing list. Also, most dictionary definitions of emulation are broad enough to include Wine. Also, it's completely irrelevant to everything.

If you say Wine isn't an emulator, it doesn't make it work any better than it does for someone who says it is an emulator. No, it's not fricking ZSNES, but that doesn't mean it's not an emulator.

Re:what's the point of emulation?

[LittleBigLui]

The only way Wine could meet the speed of Windows is if Microsoft had made a real error in their own implementation.

That would nevar happen!!

Re:what's the point of emulation?

[cjpez]

Bochs merely implements the Intel 386 opcodes.

There's a huge difference there, though. If you've never run Wine to run any heavier-duty Windows programs, you should try it. Wine enables Windows binaries to run natively on Linux. Yes, Wine will recreate errors in the original Windows API so that it matches the behavior of Windows more completely, but the point remains that all machine code is executed right on the CPU. There's no extra layer to go through. There's no extra layers to go through, either. When a binary makes a call to Windows on Windows, there has to be code running to figure out how to actually do so. Instead of actual Windows code doing so, in this case there's Linux code doing so.

Now, if you're going to split semantic hairs here, I will have to concede that under the general definition of "emulation," Wine is indeed emulating an environment which is generally not present on Linux. However, as I mentioned before, over the course of computing history, the term "emulation" has come to imply that an extra software layer is emulating machine language, which implies a number of extra steps per machine instruction in the emulated binary. Under such a system, the emulated binary will always run significantly slower than it would natively under comparable hardware. That situation is completely non-present in Wine, because, again, the machine code is executed directly on the CPU, with no extra software layer inbetween.

If you don't believe me, try some apps which are supported under Wine. I think in general you'll have really good luck, speedwise. Again, some API implementations may not be as optimized as their Windows counterparts (the menuing system in Half-Life, in particular, suffers from a problem here, or the opening movies on the Half-Life games), but it bears repeating that any slowness is the result of nonoptimal code, not any machine-level emulation.

Re:what's the point of emulation?

[cjpez]

True, but I feel that it's important for the Wine project at least to make an official distinction between what most people think of as "emulation" in a computing environment and what they don't. Emulation in computing has historically meant machine-level emulation of hardware, which is slow. If you say "emulator" to most people who have had experience with them, those people will have images of very, very slow systems which are good enough for running very old programs or testing out whatever kind of software may benefit from being run inside an emulator. Wine doesn't suffer from those limitations because what it's emulating is the more ephemeral software environment in which the windows binaries live, not the underlying hardware. All code happens right on the CPU, not in software-land. It makes a big difference in speed, and from a PR perspective, I think it makes perfect sense to try and distance the Wine project from people's historical perspectives of emulators.

Anyway, I've just spent far too much time talking about it, so I think I'll go do something productive now.

Re:what's the point of emulation?

[addaon]

Or "implementing the Windows API's as a layer on top of the Linux kernel, exactly like (for example) OS X implements the BSD API's as a layer on top of the Mach kernel."

Re:what's the point of emulation?

[Minna Kirai]

but the point remains that all machine code is executed right on the CPU

That's not too meaningful. Yes, if the machine code was executed in software, then it would be impossibly slow, instead of just painfully slow.

But VMWare and Win4Lin also execute all machine code on the native CPU- and they provide speed almost indistinguishable from running Windows alone. (Because, of course, they are running the actual Windows, and Microsoft's implementation of Windows is far faster than Wine can ever be)

However, as I mentioned before, over the course of computing history, the term "emulation" has come to imply that an extra software layer is emulating machine language

If a large group chooses to use a different meaning for a word, that's their choice- but they have no right to insist that other people using the original meaning are wrong, as "Wine Is Not an Emulator" does.

Under such a system, the emulated binary will always run significantly slower than it would natively under comparable hardware.

No. Not necessarily. You are talking about "realtime emulation", which again is a specific subset (and again, the most common subset). As the program counter moves through each instruction, it is read, and then instructions to an equivalent effect are executed on the host. But there is also pre-execution emulation, exemplified by UltraHLE, which overwrites each instruction with a native one, once only. As you can imagine, this is supremely faster. (But not compatible with all possible programs on all possible hardware)

I think in general you'll have really good luck, speedwise.

No I won't. I've tried heavy-duty Windows apps under Wine, and also the proprietarialy-improved WineX (now called Cedega). Wine sometimes allows a program to run, but it frequently fails due to incomplete features. Cedega provides enough additional features so that many more programs can actually work (in particular, installers can complete), but the performance never comes close to fooling anyone.

In my own video-game tests, a 500mhz Celeron with an NVidia GeForce2MX with WinXP beat an Athlon 1700 with GeForceFX5700 using Cedega on Linux, by sometimes 60% FPS. (Other versions of Wine were even slower)

but it bears repeating that any slowness is the result of nonoptimal code

The code is nonoptimal because of the emulation. I've examined the technical reasons for Wine's sometimes huge slowness, and it comes down to one main thing. Linux systems are split into more different processes than Windows, so an function that a Windows app expects to have serviced immediately instead takes at least 3 process time-slices as we wait first for the separate server to wake up and respond, and then wait again for the app to reactivate and proceed onward.

You can hardly accuse Wine of "nonoptimal code" for that problem- the only way they could avoid it is to integrate Wine, Wineserver, and XFree86 into a single huge process space. And then it's not so much "running Windows applications on Linux", because your system no longer resembles a usual "Linux" desktop environment.

(The other approach that could work would be to dynamically re-write the application's function calls as it loads, replacing Windows/DirectX things with Linux/OpenGL equivalents. I've never heard of it being tried, though... but if it worked, the application would be very fast, after the initial delay is over)

(the menuing system in Half-Life, in particular, suffers from a problem here, or the opening movies on the Half-Life games)

Note that Half-Life isn't new; in fact, it was released six years ago! And it's overwhelming popularity across that time has made it a focus of Wine's developers (featured on their homepage, etc). Yet, as you mention, Half-Life still doesn't work decently. That's a lesson as to how useful Wine is likely to be.

Re:what's the point of emulation?

[cjpez]

Debate continues!

... instead of just painfully slow.

Well, you appear to have had different experiences than I have, because like I said, I haven't noticed any difference in speed.

...but the performance never comes close to fooling anyone.

In my own video-game tests, a 500mhz Celeron with an NVidia GeForce2MX with WinXP beat an Athlon 1700 with GeForceFX5700 using Cedega on Linux, by sometimes 60% FPS. (Other versions of Wine were even slower)

Again, we seem to be having different experiences here. I've never seen any difference in speed on the programs that I've run under Wine. Any program that's sufficiently supported under Wine for me works just as quickly as it does over in Windows-land. I guess there's not much more to be said about that, as there's really no way for me to prove that to you, or vice versa.

Linux systems are split into more different processes than Windows, so an function that a Windows app expects to have serviced immediately instead takes at least 3 process time-slices as we wait first for the separate server to wake up and respond, and then wait again for the app to reactivate and proceed onward.

Sure, of course Linux is more compartmentalized, after all, it's constructed as a multiuser system from the ground up. Perhaps we've been running differently-optimized kernels or glibc versions or something, though, because as I said, I've never noticed a performance hit because of it.

Yet, as you mention, Half-Life still doesn't work decently. That's a lesson as to how useful Wine is likely to be.

Perhaps I overstated the issue with Half-Life. The menus merely run more slowly than they do on Windows. Everything else runs just as well. I think it was a matter of the Winex developers getting it "good enough" and then moving on to make sure that other applications got good enough. I've spent many, many hours playing Half-Life through to conclusion via winex, in addition to (as mentioned) GTA3, GTA-VC, watching Quicktime movies, and as I didn't mention before because I haven't used them in awhile, all of the usual MS Office applications (using Crossover again, here). If you don't consider that useful, then I guess it's just a difference of opinion, because for me it's been immensely useful.

Re:what's the point of emulation?

[gavriels]

What's interesting about performance is that generally, 3D performs much faster on Cedega than 2D does.

Various 2D techniques used in Windows games often perform much more slowly under Linux due to lack of direct access to the framebuffer. Windows games like to both read/write pixels directly to the framebuffer as well as use GDI APIs to draw to them.

The original HL menu system is a good example of this - it combines GDI with direct drawing in all kinds of ways which are difficult for Cedega to do quickly, but once in-game everything is very fast since it's just going direct to OpenGL.

There is a solution to the 2D issue which is for us to implement our own software GDI renderer (to render directly to the virtual framebuffer ourselves, rather than trying to rely on X and synchronizing bitmaps). It's never been voted terribly high by TransGamers so we haven't done much about it recently.

Anyhow, one final data point. Doom 3 on Cedega on an NVidia 5600 runs exactly as fast as it does in Windows when using the 56.72 NVidia drivers. With the released-one-week-ago Windows drivers (61.77), it's much faster on Windows now. Presumably we'll see whatever optimizations NVidia did on the Windows side moving to Linux soon.

Quake 3 engine games on Cedega basically run at par with Windows and Linux Quake engine binaries.

-Gav

Re:what's the point of emulation?

[Minna Kirai]

I guess there's not much more to be said about that, as there's really no way for me to prove that to you, or vice versa.

There's always science to produce undisputable objective facts. But unfortunately, my software budget doesn't permit complete experimentation at this time.

However, using free software, I can provide a few hard numbers for you. The game is "Wolfenstein: Enemy Territory", a $0 FPS on the Quake3 engine, which is available in Windows and Linux versions. I ran it 4 times, in either native Linux or Cedega (WineX 4.0), at quality settings of either Fastest (640x480) or High (1024x768). Each time I loaded the "Siwa Oasis" map and recorded the output of "cg_drawFPS 1".

The data:

1. Cedega Fastest: 33 fps
2. 
   Linux Fastest: 37 fps
   Cedega High: 31 fps
   Linux high: 35 fps

So, the native version is consistently 4fps better than Wine-style emulation. However, that result isn't as extreme as I hoped to show- 4fps is inside the margin of tolerable, not painful. (I'd never tried Wolfenstein under Cedega before, as it seemed pointless).

Other games hadn't worked at all adequately when I tried them- in particular, Battlefield 1942 was a huge disappointment, considering it had motivated my purchase of a commercial Wine variant.

Note that to continue the sciencetific research, it would be useful to measure the framerate of the same game running in Linux, WinXP, and Wine on the same computer... that would be a useful study for one of those hardware-review websites to publish. (Unfortunately, one such site did just review Cedega, and their insipid results did nothing to answer the obvious question: "How fast is it compared to Windows on the same hardware?")

watching Quicktime movies,

Why use Wine for that? Linux players can load Apple's DLLs well enough- and that way, you aren't stuck with the constrained Quicktime GUI.

Re:what's the point of emulation?

[cjpez]

But unfortunately, my software budget doesn't permit complete experimentation at this time.

Yeah, mine too. I'm also hampered by the fact that I removed my last Windows partition a year ago or so, primarily because of the success that I had in using Winex to play the few games I was interested in playing.

Why use Wine for that?

At the time, the Linux players couldn't load Apple's DLLs, this was before mplayer/xine got sorenson support. 'round the time the Felloship trailers were out, etc. I was playing the fullscreen version via wine without problems.

it would be useful to measure the framerate of the same game running in Linux, WinXP, and Wine on the same computer... that would be a useful study for one of those hardware-review websites to publish.

Indeed, it would...

Re:what's the point of emulation?

[Anonymous Coward]

Maybe it is better to educate people that emulation does not imply hardware emulation or that emulation does not imply large performance penalties, instead of by misleading them by saying "wine is not an emulator." If you want to show that wine doesn't degrade performance to unusable levels, then give them benchmarks or ask them to try it out for themselves. Just don't lie to them.

Re:what's the point of emulation?

[2TecTom]

SYSTEM HALT! Error #1 ~ NUL Inevitable, endless, eternal Wine Is Not Emulator argument

Re:what's the point of emulation?

[Minna Kirai]

Inevitable, endless, eternal Wine

The argument was OVER 5 posts ago until you came in and restarted it, genius.

Re:what's the point of emulation?

[Night Goat]

It still emulates Windows. Hence, it's an emulator, no matter if the creators like to think it's not.

Re:what's the point of emulation?

[ultranova]

As such, Wine will always have at least one additional layer of function calls beyond what real Windows would have, and that means it will be slower.

No. There are at least two conditions under which Wine-emulated program can be as fast than the same program under Windows:

1. If the underlaying system is faster overall. In my subjective experience, at least Forte Agent is faster under Wine+Linux than under Win98SE. Presumably the reason is that I have a lot of saved messages, and Linux performs better when using lots of memory. Of course it might not be fair to compare Win98SE and Linux 2.6, but I'm not forking money for an XP...
2. If Wine dynamically rewrites the application on load, replacing the Windows system calls with appropriate Linux calls. It is very likely that this isn't quite this simple, but basically I'm talking about recompiling the program to be effectively a native Linux program.

Re:what's the point of emulation?

[ultranova]

No, it's not fricking ZSNES

True - the ZSNES runs everything I've thrown at it, and not said "err:module:import_dll Library MFC42.DLL (which is needed by L"Z:\\mnt\\dosc\\Eudora\\eudora.exe") not found".

Nor does it spit out an obscene amount of error messages for each and every program.

It just works.

Optimizing for Doom3? hardly

[Anonymous Coward]

That article isn't about optimizing, it's about knob-dicking with the readily available settings until it runs smoother. Allow me to summarize the article: "Turning effects off makes the game run faster." Amazing!

Doom3 for linux

[kajoob]

If you're a linux-only user but want to see what doom3 looks like on your system, just simply turn your monitor off.

I keed, I keed!

Re:Doom3 for linux

[Satertek]

Well, if you use Windows you might as well color your monitor blue.

Re:Doom3 for linux

[ftgow]

God that joke is so damn lame. The game is supposed to be scary. Darkness is scary. And if you download the duct tape mod. I hate you.

Re:Doom3 for linux

[Anonymous Coward]

Just shut up and work on the patch, John.

Re:Doom3 for linux

[sharkey]

And if you download the duct tape mod.

Well, that's almost a sentence.

Re:Doom3 for linux

[Chess_the_cat]

If you think BSOD jokes are still relevant you must have spent that the last few years sleeping under a rock. XP doesn't crash. Ever.

Re:Doom3 for linux

[cK-Gunslinger]

Actually, I'm faily certain that was a "Doom III is dark as hell" joke. And you should never say never. Trying to create a network bridge with my LAN and wireless AP makes XP Pro crash hard every single time. It's good, not perfect.

Finally?

[afabbro]

users can finally play Doom 3 on Linux with the help of Wine

Finally? For pity's sake, the game has been out for less than a week...

Re:Finally?

[Anonymous Coward]

A week is a long time when it comes to playing Doom3! TuxGames website still has no information about the game at all!

- NuTTeR

Re:Finally?

[black mariah]

Which isn't surprising at all since Id isn't doing a boxed Linux version.

Re:Finally?

[Sancho]

I thought the same thing, but leaked alphas have been out for much longer, I guess.

Wow

[3Kirt]

Thanks for pointing that out.. I don't think any of us Linux gamers had come across any of this information in the past few days. Bravo!

Re:Wow

[Anonymous Coward]

I'm sure both of you must be thrilled.

While you're waiting...

[ZorinLynx]

Play some classic DOOM! This is a beautiful port of classic DOOM to Linux:

http://prboom.sourceforge.net/

You'll need original WAD files, of course.... But this port can play at high resolutions using OpenGL, has nice sounding music support (something fairly lacking in most DOOM ports) and is fairly accurate to the original.

I've been playing these past few days and have rediscovered what a great game the original DOOM was! And the soundtrack was great too!

-Z

Re:While you're waiting...

[RdsArts]

Feh, prboom. Legacy Doom is the only way to play:

legacy.newdoom.com

Full OpenGL support, keybind support so you don't have to change your finger layout from all the new FPS ;) , improved deathmatch, support for overlapping-area WAD files, tons of nifty stuff. Just enough changes to stay fresh while keeping the old skewl game in place.

multimon must be odd#

[way2trivial]

on the VERY ORIGINAL port of doom... you could do multiple monitors with multiple computers driving the second/third views... I did this once, (mostly to see if I could) for a side view.. it worked/rocked!

However, I had my main monitor as straight ahead, and my side monitor as 'to the side' it did not function as 'split view' down the middle.. is it not possible to have two monitors, with the center of focus being one monitor? must it divide the view down the middle?

Re:multimon must be odd#

[Harald74]

On Doom 3 a rear monitor would probably be more useful, for those times when you can hear noises behind you. Just glance over your shoulder... :)

Anyways, wouldn't four monitors (north, south, east, west) also be useful? Then you don't have to split the view.

Re:multimon must be odd#

[cK-Gunslinger]

Wouldn't spinning the mouse around 180 be a lot easier and more convenient than physically looing behind you? There's probably even a "turn 180" action you can bind to a key.

Doom3 on Wine experiences

[pp]

I've played it that way on my athlon 2000+geforce 4 ti4200. It's quite playable, most notable problems are that it's _SLOW_ for about 15-20 secs
after loading a game. Going to the menus and using the PDA for a while and it goes back to a reasonable 20-25fps or so. Also I end up having to restart the game completely after dying, trying to load a game at that point just gives a black screen.

After a hardware upgrade and a native client it should be great, hardware upgrade for the speed
and native client to get rid of those glitches ;-)

Eh

[Anonymous Coward]

A lot of the Doom soundtrack is just ripoffs of groups like Slayer, Pantera, Metallica and Alice in Chains.

Re:Eh

[ZorinLynx]

Ripped off? Or inspired by?

I'd love to hear some of the tracks that the Doom music was "ripped off" from. Just because you draw inspiration from another kind of music doesn't mean you ripped it off.

Name some titles? I want to hear this for myself and decide. }:)

-Z

Re:Eh

[Anonymous Coward]

Here is a thread of some people discussing it: http://forums.newdoom.com/archive/index.php/t-1239 6.html

http://www.mazedude.com/remixdescriptions/barrel s. htm has a clip of the Alice in Chains song. Listen to the AiC album, Dirt, and see if Doom ever pops into your mind.

Maybe John Romero's own testimony would serve well: http://www.zone.ee/estdoom/download/romero.txt

Bobby Prince was inspired by Heavy Metal and Grunge just as much as Jogeir Liljedahl was inspired by Commodore 64 music, Jochen Hippel, Vangelis, et al.

Re:Eh

[Anonymous Coward]

Also, this is probably unrelated but,

While entering random searches in PACER (https://pacer.psc.uscourts.gov), I did see a court case that was something like "id Software vs. Bobby Prince" that was either a breech of contract or copyright infringement. Unfortunately there were no court documents from that case that you could download so I have no idea what it is actually about, but it's still interesting. Maybe this is one reason why he isn't doing the music?

Re:Eh

[Moderator]

The original MIDIs for DOOM sound a lot like vintage Hetfield/Mustaine riffing. I don't think DOOM ripped them off any more than later bands ripped off early Metallica.

On a related note, Mustaine wrote the modern Duke Nukem theme.

Re:Eh

[Anonymous Coward]

Do you mean the theme song for Duke Nukem 3D? The song, Grabbag, was written by Lee Jackson, the sound/music guy at 3D Realms. Megadeath did do a cover version of the song (I think there is a link to it on the 3drealms website somewhere).

Re:Eh

[Anonymous Coward]

I remember when id used to claim "Music by Prince"... Bobby Prince that is.

Uh

[Anonymous Coward]

How about no.

Linux solution didn't work for me...

[DoktorSeven]

I saw this a few days back and gave it a try, but no such luck - the game refused to run at all, giving me an "unhandled exception" right away. Strange thing though, is that plain wine (20040615) ran the thing fine... well, if you call "fine" looking very washed out, textures missing/wrong, etc. However, everything was very bright and you could actually see where you're going without a flashlight! :)

Re:Linux solution didn't work for me...

[Ycros]

You know, it ran quite fine on my FX5950 ultra under plain wine. However, that video card unfortunatly died. (I blame the windows machine I stuck it into temporarily) :(

What's really interesting, is that I have successfully run Doom3 on a Geforce 2 GTS 32mb in wine, this time experiencing the same overbright problems.

Re:Linux solution didn't work for me...

[Anonymous Coward]

You need to run it with a depth of 24, not 16. That will fix the washout/static on monitors problem.

So let me get this straight

[SynapseLapse]

While I can only dream of playing doom ]I[, since my tired old computer with it's sinfully old Voodoo board (Hey, I have student loans) has no chance of hell of ever running, other people out there get to run the game with FIVE monitors?!? Don't get me wrong, I think it's great that ID is thinking forward that far to allow for computers five-ten years from now to have an extra graphical benefit... but still. *sighs* Oh well, someday I'll have a new computer with enough hutzpah to play doom 3... Someday when the economy doesn't suck and I get a real job. /end whiny rant.

Alternate Universe?

[Anonymous Coward]

I can't wait for Delight 3, the alternatve universe game to Doom 3 where the Mars base opens up a portal to heaven. Friendly angels and cute cherbim come through, but in full pixel transparencies and realistic pixel shading. None of this 2d angelic crap.

Dual

[Gamefreak99]

Has anyone tried it with only two monitors? I'm not about to go and grab another card and monitor to play on three but I could do it on two. Of course if it sucks so bad as to not warrent the effort then I simply won't.

Related note...

[ajservo]

There's an ATI fix floating around on a board somewhere... It's mixed as it working for people. Although it seems to work for many, on my system, when I applied the fix to the code, rebooting to the game, I had lost all textures on ALL surfaces, and could only see lighting sources and my weapon's indicator readout. BACK UP YOUR FILES before attempting... I'm glad I did.

Re:Related note...

[luugi]

You're probably talking about this

Comment removed

[account_deleted]

Comment removed based on user account deletion

performance increase

[DiniZuli]

You have propaply allready seen this, but anyway here goes (don't know if it works on Linux though - but cannot see why it shouldn't):

The following commands control the image cache, which if enabled and set correctly can help smooth FPS and may also boost performance:

image_useCache [0,1] - If set to 1, uses background loading to cache image information. This may not necessarily improve framerate performance, but it does assist in smoothing out frame rates and reducing loading pauses. Note that the image_cacheMinK (see below) size must be raised from its default otherwise the game will crash when using this setting. Once this setting is enabled, the actual cache value is set in the image_cacheMegs setting below.

image_cacheMegs [Megabytes] - Determines the maximum amount of system memory to allocate to temporary loading of full-sized precompressed images if the cache is enabled by setting image_useCache to 1. Note that since this caching only applies to precompressed images, using the Ultra Quality setting will render this setting useless, since at Ultra quality no texture compression is used. Since a cache is only a temporary holding area, and not the place where the entire game is meant to reside, do not raise this value to something extremely high as that will simply reduce the available memory for the rest of Doom 3. Try a value of 128MB for those with 512MB of system RAM, and if you have more than 1GB of RAM, you can try a higher value like 196MB or 256MB for example. Do not set this to half your system RAM or some other monstrous amount.

image_cacheMinK [KiloBytes] - This setting determines the minimum size in KB for precompressed image files to be loaded into the cache. To make sure most image files can be loaded, and to also prevent a system crash when enabling caching, select a value like 3072 to start with. Raising this setting may improve caching, but it may also hinder caching if most textures are below the size you specify, so don't just raise this value for the hell of it.

got this from here

and if you have some extra space on your hard-drive go look here

Re:performance increase

[DiniZuli]

Oups! forgot to say that it is in the 'DoomConfig.cfg'-file you should make the changes - sorry :)

Game over, man, game over!

[Anonymous Coward]

Please learn what "emulator" means and try again.

Wine(X) Is Naturally an Emulator.

Re: It's the usage, not the wine

[guybarr]

Really? I usually notice a huge performance decrease when using Wine. Blurred vision, slurred speech, light-headedness, a sense of euphoria.

Performance decrease for men, but increase for women : You've been utilising wine on the wrong client.

-- Premature optimization is the root of all evil.