Originally posted by: smithpd
I don't understand the statements that emulators are the answer. Maybe I just don't understand how they would work. Could someone explain it? See my questions below.
OK...the term
emulator is used to mean a variety of different things. And it generally causes a great deal of confusion!
People traditionally take the word
emulator to mean a set of software functions mimicing a set of hardware routines; however, this usually has a very negative performance connotation: the host machine must be orders of magnitude more powerful than the emulated hardware. It make take, on average, 20 instructions on the host machine to emulate one instruction of the emulated hardware.
Dynamic recompilation (and caching of such recompilations) were created to enable emulators to overcome some of these performance problems. Instead of just mimicing the emulated hardware, a dynamic recompiler will
translate the emulated hardware routines to the host's hardware routines. The translated code can then run at
near native speed. The translated code can also be stored and then simply reused for subsequent runs of the same application (but this last technique is not often used AFAIK).
Hardware virtualization is faster still, but it is not machine emulation
per se. In this case, both the emulated machine and the host machine have the same CPU instruction sets (or some common subset). The machine code executes at near native speed without requiring any translation. [Some machine code is handled differently, so that the guest OS (and some other apps) does not interfere with the host OS.] AMD and Intel have both included hardware acceleration for this in modern CPUs, which is a really good thing!
What I meant by the term
emulator is a conglomerate of
machine virtualization (for the CPU and guest OS, which will run the games) + virtualized drivers allowing the guest OS's virtual video adapter (which is just a dummy software device) to route game APIs such as DirectX and OpenGL back to the host OS's GPU (for hardware acceleration).
This approach has been done and done effectively enough by Parallels on the Mac...
http://www.parallels.com/en/pr...s/desktop/features/3d/
...so why not use a similar approach to run old PC games on a modern PC?
First, I have some doubt that a software emulation of 3D cards would perform well enough to run middle of the road games like Thief 2, which still place heavy demands on the 3-D graphics system. Of course, with enough horsepower, I suppose this could change in the future.
Ah, see, I meant hardware-accelerated 3D.
Specially-written drivers for the guest OS in a VM could pass the guest OS's DirectX, Glide, and OpenGL calls to the host OS, which would do the work on the GPU, and the results could easily be passed back to the guest OS for output in a window.
More important, what would such an emulator look like, and how would it work? Would it look to the OS like a second graphics card, so you could make it your primary display? Would the emulator render 3-D in software and route 2-D images to the 3-D card you are bypassing? I suppose you might have some hardware to plug into a spare slot so the OS would recognize the hardware as a second graphics card. How else could you get your game to access it? Games just look for hardware. Or do you fool the OS into thinking that a piece of software is actually hardware?
Well, that's the cool thing. A driver can do just about anything in software (including passing input and output back and forth from another hardware device), and still appear to the OS as real hardware. So a special driver written in the guest OS of a VM could pass data back and forth to the hardware-accelerated video driver in the host OS. This would be called
driver virtualization.
No special hardware would be required for this technique. For example, VMWare has provided virtualized video drivers (2D only) for quite a few years now. No one has thought of also routing the 3D calls until recently, when advances in CPU virtualization have made feasible the idea of running high-performance code in a VM.
Virtual PC is a replacement for the OS. Wouldn't it just run the game in its virtual OS environment? Then wouldn't the game still be faced with sending Direct3D commands to your faulty graphics card and drivers? Wouldn't the incompatibility still be there?
Yes, exactly, but the Direct3D commands would not necessarily be routed as-is to the faulty card. The community project would have to write a driver to route those commands. Now, if the community also maintains a database, as I suggested, then the driver could contain a set of hacks for specific games. For example, if Thief 2 was detected, a software dithering routine might be used, but the rest of the Direct3D commands could be routed mostly unchanged.
Make no mistake: designing and writing such a driver would take a fair bit of work by dedicated and (reasonably) talented developers. The database and driver design would have to be flexible enough to contain and properly implement hacks/workarounds for hundreds, perhaps thousands of games. This is NOT the kind of project that one could just write in a month and forget about it.
The user interface could simply be a "Games and 3D Applications" window, a front end if you will, containing icon launchers for the games. Or a completely transparent technique similar to the one nVidia employs (for its automatically-activating 3D profiles) could be used so that the right workarounds get applied for whatever game the user starts to run. Yes, that would probably be best.
VMWare seems like an interesting idea that might create both a virtual OS and virtual hardware. I looked around and I could not any specific information on how it would emulate a different graphics environment than the one already in the computer. How does that work? Does it have a list of virtual graphics cards? If I had an Nvidia 8000 that messed up my game, could VMWare make it look like I had an ATI x1950 instead?
No, that's why I said that NOT all the tools to get this up an running are just lying around, waiting to be used. A community project, nonetheless, could be created to develop the virtualized drivers and create a complete package (or a set of step-by-step instructions), database for the game workarounds, a user forum for user-to-user support, FAQs, etc. In short, this would be a major undertaking, the scope of which would have to apply to old PC gaming in general (and not just the Dark engine games, or any other specific community) because that's the only way to get enough support to keep the project relevant and useful.
I have been operating under the theory that compatibility with various versions of Direct Draw was the main problem, yet I think RTCW is pure OpenGL, is it not? I would have thought OpenGL would be stable. I think that is why id uses it - to be independent of Microsoft. Good decision!
Facebook
Twitter