One late night (or perhaps it was an early morning), during the testing of the ATI Radeon 9800 XT and the NVIDIA GeForce FX 5950 Ultra last Fall, we decided that the only truly "correct" way to test a video card is to test it in every possible situation for which it could be used. Of course, since there is no magic benchmark fairy that brings us numbers while we sleep, testing everything is impossible. We decided to compromise and make the 30 most popular games at any given time our standard GPU benchmark. We are still trying to hit that 30 game mark, but in the delirium of the long nights of testing, we managed to think of a few more ways we could push hardware. Unfortunately, we are all out of rubber pants and whipped cream; we had to go with our second choice: console emulation.

The original idea was to use either an NES or SNES emulator as a real world framebuffer upload benchmark. Emulators of aged consoles can use the CPU to emulate the entire system and just send frames over to the GPU as fast as they are cranked out. Something like this may still be a possibility, but as we delved deeper into the depths of the emulator community, we discovered much more exciting things that we could bring to the table. We finally settled on benchmarking a PlayStation emulator. The N64 and Dreamcast emulators are out there, but nothing is quite as popular as the PlayStation right now. There are PlayStation 2 emulators in development, but nothing that can play games quite yet. We will take a look at a very early Game Cube emulator running "The Legend of Zelda: The Windwaker" as a bit of a preview of things to come. Before getting too excited, it's not really playable yet; we just wanted to include Game Cube emulation to take a look at where we are at this point.

There are a few factors that need careful consideration when looking at PlayStation emulation. First, running a PlayStation game on a PC without upsampling textures, applying a bit of blur, and possibly adding a TV-like scanline filter won't quite deliver the look of the original game. It really is amazing how much the television can hide those jagged edges and make low resolution textures look all right. Of course, the trade off is performance, so it really is a user preference kind of issue. We wanted to make the game look and feel as much like the original as possible with the emulator settings we chose. The added bonus is that our hardware gets pushed a little harder.

And this wouldn't be an article about emulation without mentioning the fact that it is perfectly legal (because of a lovely thing called "fair use") to emulate hardware that you own in order to run software that you own. It is not legal to distribute games (or even the PlayStation BIOS for that matter).

ePSXe: The Emulator of Choice

There are quite a few free PlayStation emulators out there from which to choose. Out of the ones we tested, PCSX and ePSXe were the most compatible and fastest. We decided to go with ePSXe because it was faster than the others, very popular in the community, and still being developed (as far as we can tell).

This is the main ePSXe interface window.

The PSEmu Pro (a discontinued free PlayStation emulator) plugin standard, which ePSXe (and many others) uses, allows the main emulator to separate itself from the very long list of hardware that it would otherwise have to support. The PlayStation emulator is free simply to emulate the core of the PlayStation while offloading sound, graphics, and I/O to different plugins written for different hardware and operating system environments.

Sure, it's possible to get some degree of functionality out of pure software plugins, but why not take advantage of hardware accelerated OpenGL, DirectX, or even Glide based graphics plugins? Smart CDRom plugins can implement aggressive caching and read ahead in order to speed up CD load times; controller plugins can take advantage of all types of joysticks and gamepads. Rather than simply relying on the CPU to emulate an entire system (as was the case with older emulators), we can make use of our entire PC.

Depending on what we want to do with our emulator, the graphics subsystem can be fairly heavily taxed, even making use of some pretty cool pixel shaders. Let's take a look at what goes into PSX emulator graphics.

PlayStation Graphics

There are quite a few aspects to emulating PlayStation graphics, some handled by the PSX emulator and some handled by the graphics plugin. First and foremost, an emulator must take care of all the tasks a normal PlayStation would need to handle. This includes playing movies (emulating the motion decoder: MDEC), handling 2D sprites, rendering 3D scenes and textures, and emulating effects originally produced via a combination of the PSX CPU and GPU (this can result in sometimes expensive uploads to the framebuffer (GPU memory containing the next frame to be displayed) from the CPU when emulating the PSX on a PC). These framebuffer intensive operations show up a lot in the Final Fantasy series of games (e.g. the pre-battle swirl effect, and certain in battle effects).

On top of the necessary tasks, it is very desirable to enhance the graphics as much as possible. Because the PlayStation targets television (essentially a 640x480 screen) and texture resolutions are generally low, highly pixilated images can result when playing games on a high resolution computer monitor. Graphics plugins are able to upsample, stretch, filter, and otherwise manipulate textures in order to make images a little more palatable. Beyond texture filtering, full screen filtering can also be implemented in order to assist in making the emulation experience just that much nicer. Standard emulator filters, such as TV scanlines, can be added, and fullscreen blur effects help assuage the lack of antialiasing. One of the coolest trends is the emerging use of pixel shaders to perform these filtering effects (and other parts of the graphics process as well), but more on that later.

Every game is different, and every game will stress different parts of the system in different ways. In order to get the most out of your library, it will be necessary to play with the settings for each game individually and/or use a front end to save your configuration data for each game.

As a final note on console game system graphics, it is important to understand that vsync is a way of life. Since consoles are built for TVs and TVs have fixed refresh rates; every console game out there makes use of the refresh rate as a system timer. It would be wasteful of precious resources to program otherwise. Of course, this adds an interesting dimension to emulation. Running your emulated game at anything other than 59.94 frames per second (in the National Television System Committee (NTSC) parts of the world) will result in your game running either faster or slower than it was intended. Though more of a side effect than a feature, sometimes this is desireable (memory card load/store times are much faster when the frame rate is higher, and for those without the necessary reflexes, slowing the game down can prove useful).

So, how does all this fit together for our PlayStation emulation project? For that, we need only to turn to Pete.

Pete's Plugins to the Rescue

Configuring ePSXe and all the plugins that go along with it is more of an art than a science in some regards. Fortunately, there is a section of the ePSXe help file that has suggestions on where to start with settings for certain games. In the end, though, optimum image quality and performance only come from experimentation.

In choosing the plugins for our system, we wanted only the best. Everywhere we looked, we saw references to Pete Bernert and his PSX plugins. After taking a look at Pete's Homepage and playing around with some of the plugins he had created, we were convinced. Aside from writing high quality plugins, Pete is also a very cool guy and he had a lot of useful advice for us when we let him know that we would be tackling the issue of emulator benchmarking.

These are the settings that we specified in testing using Pete's OpenGL2 Plugin.

When we first took a look at Pete's OpenGL2 graphics plugin, we wanted to turn everything on, set to maximum and see what happened. Honestly, this isn't a good way to get anything useful done when working with an emulator. In fact, if all the different filtering options are enabled at the same time, what comes out is a blurry, fuzzy, nasty mess. In our quest for perfection, we humbly turned everything off and went through all the options one by one, slowly cranking up the settings and checking what effect they had on the two games that we would eventually end up testing with. Happily enough, we discovered that not everything needs to be turned on in order to end up with an indistinguishable rendering of either Final Fantasy IX or Gran Turismo 2. In order to limit the number of variables we were testing, we decided to stick with one list of settings that worked for both games (as shown above).

Here's a brief rundown of what some of the settings in Pete's OpenGL2 plugin do:

Internal X/Y resolution - This setting has the single largest impact on standard image quality that we saw. Native PlayStation resolution is very low and unless this setting is on high, images will be very pixilated and not very detailed. There are also very high settings which don't work on many cards, and really don't add as much as the step up from native resolutions to high resolutions.

Texture filtering - This setting determines what kind of filtering to do on different types textures. Adding texture filtering to 3D textures really helps, but since we are applying a full screen blur filter, the 2D filtering would just make things look fuzzier than we would like.

Hi-Res Textures - We can either choose "none", "2xSaI" or "stretched" here. 2xSaI is a popular filter for SNES emulators and works really well to smooth things out without introducing any blur. Unfortunately, 2xSaI diverges a bit from the original look and feel of the games on a television while incurring a bit more of a performance hit, so we decided to go with stretched and filtered hi-res textures (which does a good job of smoothing out pixilation without overly blurring things).

Use pixel shader for "PSX texture window" emulation - Repeated textures will be handled with a pixel shader rather than palletized textures (which helps with speed).

Off-screen drawing - Some games draw stuff off the screen and then put things back together when they need them. This is how Final Fantasy IX draws its battle system menus. Like the things says: standard should work for most games.

Framebuffer effects - Without setting this option to standard, the pre-battle swirls and some of the battle effects won't work in Final Fantasy IX. Full emulation doesn't seem to be necessary from any of the aspects of the game we tested.

Framebuffer uploads - This setting specifies how much direct uploading to the framebuffer the CPU can do. Setting this to full is useful for the Final Fantasy series, unless you don't mind missing some of the effects or minor details. This does have an impact emulator speed though.

Shader Effects - We chose to use an OpenGL ARB pixel shader that implements a full screen blur rather than the standard full screen filter (which is just a blur as well). Changing the level will increase or decrease the blur effect, but we find level one to work just fine. There are other shader options, but we stuck with the ARB option since the other useful shaders Pete provides are written in GLSlang (which only runs on ATI cards). Of course, it is important to note that since all the generic shaders that Pete writes are ARB shaders, ATI cards will have theoretically an easier time with them (though NVIDIA's unified compiler technology has improved a great deal since anyone really looked at ARB performance difference on the two architectures).

This brings us to my final point about Pete's plugins. Since Pete has an ATI Radeon 9700 card, Pete tests his programs on his ATI Radeon 9700 card. He is cool enough to write his generic stuff following ARB specifications, but this kind of setup is not optimal for NVIDIA GeForce FX cards. In this case, since the developer of the software isn't trying to sell something, Pete is not obliged commercially to support NVIDIA products as well as he supports ATI products. It also follows that NVIDIA wouldn't invest large amounts of time and energy in helping Pete support NVIDIA products. Where programmability issues are somewhat excusable on a commercial level (since NVIDIA invests time and money in game companies to help them write better code for the GeForce FX line), the sore spot is in independent development such as this. Here's to hoping that NVIDIA's upcoming line of cards will be easier from which to extract speed.

The Testing Setup

Performance Test Configuration
Processor(s):	AMD Athlon 64 3000+ AMD Athlon 64 3400+ Intel Pentium 4 3.4GHz EE Intel Pentium 4 3.2GHz Intel Pentium 4 3.2EGHz
RAM:	2 x 512Mb OCZ 3500 Platinum Ltd
Hard Drive(s):	Seagate 120GB 7200 RPM (8MB Buffer)
Video AGP & IDE Bus Master Drivers:	VIA Hyperion 4.51 (12/02/03) Intel Chipset Drivers
Video Card(s):	Sapphire ATI Radeon 9800 PRO 128MB ATI Radeon 9800 XT ATI Radeon 9600 XT NVIDIA GeForce FX 5950 NVIDIA GeForce FX 5700
Video Drivers:	ATI Catalyst 4.2 NVIDIA ForceWare 56.56 (WHQL)
Operating System(s):	Windows XP Professional SP1
Motherboards:	Intel D875PBZ (Intel 875P Chipset) FIC K8-800T (VIA K8T800 Chipset)

The games that we tested are Final Fantasy IX and Gran Turismo 2 (along with a preview of things to come in The Legend of Zelda: The Windwaker).

The only important issue to note when looking at the performance data is that FRAPS reports sometimes framerates that are between 50% and 25% of what the plugin reports. From what we understand, the game sees between two and four vblank interrupts before it draws one screen (meaning the game doesn't update the screen on every vblank). For Final Fantasy IX, we generally see a 25% framerate during MDEC playback, 30% while traveling the world map, 50% when walking around off the world map, and 100% when in a battle scene or menu system. Please keep this in mind as FRAPS might be reporting 30fps at points, but the game could still be running at full speed. We will point out these differences again on the test pages.

Final Fantasy IX Performance - MDEC

The title screen for Final Fantasy IX.

CPU scaling shows the P4 EE and its beefy cache on top of the heap. Also interesting to note here is that Prescott leads Northwood in performance here.

Final Fantasy IX Performance - Exploring Locations

The scene used to benchmark walking around.

This benchmark tests limited 3D rendered over a 2D background that is the town, city or dungeon.


For all intents and purposes, the P4 EE and the Athlon 64 3400+ perform the same. This time, though, we see Prescott and Northwood swap places. The 3000+ also creeps up from the bottom here. Again, these framerates are all way beyond playable with the emulator pushing about 300 vblanks per second.

Final Fantasy IX Performance - The World Map

The location benched on the World Map.

This is a full 3D landscape environment with some framebuffer effects (in this case, rain). The FRAPS reported frame rate is about 33% of the emulator reported framerate.


Here, we see both the AMD Athlon 64 processors leading the Intel bunch. With all the Intel processors essentially pushing 66 frames per second (almost 200fps in the emulator), this seems like it could be a platform limitation. The added speed and cache of the 3.4GHz EE not adding any benefit at all indicates that there is a bottleneck somewhere else in the system. All we can do right now is to give a sidelong glance at the motherboard and wonder, but we don't have any conclusive evidence of what is going on here yet.

Final Fantasy IX Performance - Frame Buffer Effects

Benchmark battle scene

Either fortunately or unfortunately (depending on your preferences), this is where most of the playing time in Final Fantasy games is spent. Welcome to the battle system. Here, we see offscreen drawing, framebuffer uploads and framebuffer effects in full swing. This portion of the game is also rendered at full framerate.


CPU speed doesn't quite affect battle system performance as much as the GPU. It is good to see that Intel processors aren't still bottlenecked for this benchmark. The Prescott, Northwood and Newcastle processors all deliver about the same performance here, while the P4 EE and Athlon 64 3400+ lead the way.

Final Fantasy IX Performance - 2D Performance

The menu after the battle.

There are plenty of menus in Final Fantasy games, and not a little time is spent dealing with items and characters from the menu system. This is a pure 2D sprite test and it runs at full framerate.


Here again, it looks like we have hit a platform architecture limit on both the AMD and Intel fronts. The VIA based AMD platform has a little more than a 5.5% lead over the Intel 875P platform.

Gran Turismo 2 Performance - Race Replay

Grindelwald race replay benchmark

Of course, we had to include GT2, as it is one of the most awesome games of all time. This benchmark is a replay of a race ran at Grindelwald (the second race of the Clubman Cup). Again, here we see FRAPS reporting the game drawing screens at somewhere around half the internal PSX framerate.


The P4 EE and Athlon 64 3400+ are on equal footing here, while the other three processors share the second place trophy once again. All these processors make easy work of whatever game we throw at them.

Just for Fun - The Legend of Zelda: The Windwaker

Zelda title screen as emulated

This is a pretty cool emulator called Dolphin. It isn't quite (read: any where near) finished yet and there are plenty of things that still aren't being emulated correctly. Of course, getting 4 frames per second of something kind of close to what we see on the Game Cube is still pretty exciting. Here are the numbers even though they really don't mean anything.

Final Words

From our benchmarks, it is obvious that ATI Radeon cards are better suited for emulating the games that we tested under ePSXe and Pete's plugins with the settings we chose. The NVIDIA cards did hold their own and can take care of some tasks very well, so it isn't really fair to say that they aren't good enough to emulate a PlayStation game. We were a bit shocked to see the kind of performance drop from the 5950 Ultra the 5700 Ultra took in some of the tests; we will be looking into the issue further as our experience with emulator benchmarking progresses. There are some settings that can be tweaked in order to get more performance out of the emulator than we did, but we were going beyond simply high quality emulation of the actual PlayStation experience. Of course, if you want to play the Final Fantasy series in all its glory, ATI GPUs are the way to go.

Future graphics and CPU tests here at AnandTech will include a console emulation benchmark. We wanted to introduce the topic with a smaller scope of hardware to take a look at what we might expect to see in future reviews while focusing on the concepts and technology behind the benchmarks. Whether we do the same thing we did here or try something different remains to be seen (and will be based on response and practicality).

As soon as a Game Cube, PlayStation2, or Xbox emulator is able to run retail games, we will be looking to adopt a new emulator, but until then, ePSXe and Pete's plugins will be our standard. We may still end up exploring NES, SNES, or arcade emulators as more specific hardware tests, but we are still trying to finalize our testing methodology. Suggestions are always welcome.

Hopefully, this has been a useful excursion into the unknown of benchmarking. We were certainly surprised to learn about the amount of technology that goes into emulating a PlayStation and we look forward to following further developments in game system emulation. With the addition of this type of benchmark to our future test suites, the emulation community will no longer need to rely on word of mouth and/or guess work in order to determine what kind of hardware they will want for their system. It is our hope that we will start to see ATI, NVIDIA, AMD and Intel take notice of the popularity of console emulators and start lending a little more assistance to the community as well.