|
|
|
|
|
|
|
A Question of Perspective
Posted on 2012-04-21 14:12:57 |
|
So, after that last update, I got around implementing a better way of simulating the Q register and MAC flags pipeline without updating the status of the pipeline at every instruction. It gave a nice speed boost, but it's going to get trickier to make the MAC flags emulation accurate with that kind of system. But I think I'm going to leave it as is for now since it gives pretty good results nevertheless.
After that, I decided to make Unreal Tournament work on the emulator. It was one of the first games to be released on the PlayStation 2, so I thought it would be rather simple to run. First, I ran into some issues with my high level emulation of the CDVDFSV IOP module because the version used by this game was using a different structure layout than the one I was providing. I also had to implement event flags in the IOP BIOS because the iLink (a.k.a. Firewire) module was using them heavily. I also got rid of the LIBSD high level emulation part because it wasn't complete and also because I thought it would be ok for the games to call their own version directly since the SPU hardware is emulated properly right now.    I also had to implement the "LoadExecPS2" system call because this game uses a strange scheme to switch from the main menu to the game. When you start a new game in Unreal Tournament, the game is completely reloaded from scratch with parameters that tells the program to load a specific map and select specific game options that the player chose in the main menu. I guess they did that because they didn't want to deal with memory leaks or memory fragmentation problems. I then finally took some time to look into the texture perspective correction problem I had for a long time. It wasn't too hard to fix after all and 3D games looks much nicer now, as shown in these screen shots from Half-Life:   But a few fundamental problems persist my emulator that prevents Unreal Tournament from running properly. The first problem is the usage of paletted textures which I handle by converting the index map into an RGBA map that I send to the video card driver. This is a problem for this game because they change the palette many times in the same frame causing the cached texture to be flushed every time they use it with a different palette. The solution to this problem would be to do the index->RGBA conversion in a pixel shader and only upload the index map to the video card. The other problem is that the game also uses a kind of texture caching system that works with a 1024x1024 texture they update every time a new texture is needed for their render. So, each time they update their cache, I have to invalidate mine and upload the new 1024x1024 texture when it's needed. Computing dirty rects and updating only the dirty parts of the textures would probably fix this problem, but it could also be a problem depending on the area where that final texture is stored on PC (either in system or video RAM). I quite happy of the results anyways. This game helped me clean some parts of the emulator which weren't very good. This will surely help when I'll be making other games work. |