Play! - Development Log

Play! is a PlayStation2 emulator for Windows, macOS, UNIX, Android, iOS & web browser platforms. For more information about this project please visit the "About" section of this site.

Fetching compatibility status...

PsfPlayer v1.00
Posted on 2012-11-28 01:07:49

Hello again, here's a new PsfPlayer version. This utility made it to the glorious stage of being a 1.00 version. Why? Because most of the annoying bugs that was making the player sub-standard are now fixed. There shouldn't be any weird sounding samples in the Final Fantasy PSF sets and sudden slowing down when playing streamed tracks.

Get it now on the downloads page!

PsfPlayer v0.55
Posted on 2012-08-12 15:13:20

I have updated the PsfPlayer utility with some minor bug fixes and additions, such as fixed playback speed for PlayStation2 Square-Enix games such as Final Fantasy 10, 11 and 12 and Kingdom Hearts, better looking playback control buttons and visual feedback for the currently playing item in the playlist.

The fixed playback speed part is a nice side-effect coming from changes I've made to the root counters emulation in Play! when I was working on Unreal Tournament.

In any case, you can grab it on the downloads page.

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.

Grandia Optimizations
Posted on 2012-01-09 23:06:36

I added the missing VU instructions that were needed by Valkyrie Profile 2 and also fixed a problem happening because of I wasn't flushing recompiled blocks spanning a memory area that was being rewritten on by the game code. I couldn't get something to display right away because there was a lot of weird black sprites being drawn on the screen... Probably because they are used to clean some render targets or something like that. But after deactivating the black sprites I was able to see the main character being rendered without too many glitches.

The main issue was now that there wasn't any level in the background... I have no idea what happened there, but there's simply no level being displayed (and probably loaded). The character also seems to be falling down in the void for a moment, hence the trails you see in the screen shot. But, I didn't let that bother me too much because I first wanted to find out why most of the triangles were being generated with a black color (for the clouds in the main menu for example).

I tried to analyze the VU program that was generating the commands to draw the triangles and found out that it was modulating all the input colors of the geometry with some kind of global ambient color. So, I tried to see where that color was being set in the game code and found a function that is supposed to compute that ambient color value, but I found out soon after that it was never called. I looked around, but I couldn't find anything that would give the correct result.

So, I kinda gave up on Valkyrie Profile 2 for the moment and decided to try Grandia 2 instead which is a bit simpler.

There wasn't any major hurdles to get that game running to the point where you can run around in the field. The biggest problem was again the video decoding parts that aren't working at all in this game. I had to patch them out to be able to see the interesting parts of the game... Even then, I had to let the emulator run overnight to get to the first part of the game since the intro movie is unskippable and quite long.

The 3D stuff pretty much worked without any change in the GS handler code which was a bit surprising. I also took the time to fix some problems in my LIBMC emulation that was preventing the game to load and save data to the memory card. The game doesn't run perfectly as there's still weird texture mapping bugs happening when you play for a bit too long but it's not crashing or anything like that.

Seeing that this game was working pretty well, I decided to dive into some optimization related matters to make it work faster. I tackled a few bottlenecks already, one being the need to call a memory read or write routine 4 or 2 times (for quad and double words respectively) in the recompiled code which I could remove by adding memory access routines that can manipulate bigger data sizes. This optimization gave a little boost of 2 fps in Grandia 2, which isn't much, but still nice to have.

I also found out that I could start the execution of a VU microprogram immediately in the MSCAL/MACALF/MSCNT VPU operations to save some time (around 1 or 2 fps). The last thing I did was to get rid of this strange recompiled block addressing scheme I put in place early on in the development of the emulator and replace it with a much simpler 2-level table addressing scheme. This also gave a small fps boost, but not as much as the other 2 optimizations.

The next thing I want to change is the way I emulate the pipeline delays for the Q and MACflags registers. When looking at the recompiled VU code, I saw that there was a register pipeline check generated at every instruction, even for NOPs or blocks that don't even use those registers, which doesn't make much sense since nothing related to them needs to be computed. I'm sure there's a smarter way to deal with this. I don't know if that's going to give a huge fps increment, but I have good hopes that it should help since the VU microprogram execution seems to take a lot of time according to my profiler.

Updates coming soon (or not so soon...)

Valkyrie Menus
Posted on 2011-11-13 14:39:00

As promised, I went back to work on Play!. I continued my work to get Valkyrie Profile 2 to run properly. To make it run a bit better I had to fix a bug in the way interrupts are handled, force basic blocks to be destroyed when the game is writing at their RAM location, make the analog stick work in the DBCMAN IOP module, implement missing system calls in both the EE and on the IOP sides and add support for some more VU instructions.

I also had to implement some hacks to display what's rendered at a specific frame buffer address because this game seems to use the rendering output as a texture to be drawn on a full screen quad, which is something I can't really handle in my OpenGL GS renderer right now. I also had to ignore vertex colors because everything was being drawn with a black color.

All of this allows me to navigate in the title menu without too many problems:

Some notes about the first and the last screen shots:

The actual title screen of Valkyrie Profile 2 has a white background and some moving clouds. I don't know why we don't see any of them, but I can see the mesh used for the clouds if I enable the wireframe mode. There's also something being rendered off screen in the right which also looks like clouds, but I have no idea why it's being drawn there.

The last screen shot shows the prompt used to skip the first movie. I disabled movie playback in the game, so, that's why we see garbage there. If we let it run, we can see the sub-titles and credits being drawn over the video.

After skipping the video, the game starts preparing for the first cutscene. It was using a lot of missing VU instructions that I had to implement and it also triggered a bug with VCALLMS which I fixed. But after that, the emulator crashes because the game feeding some weird data to the GIF through a DIRECTHL command. I'm looking into it and I hope that I'll be able to see some in-game action after this.

PsfPlayer v0.54
Posted on 2011-10-13 21:04:57

Yet another update to PsfPlayer today. I was just feeling like fixing some long standing issues, like the lack of unicode path support. I also had lots of fun adding a themed border for the SPU register view using Windows' Theme APIs (OpenThemeData, DrawThemedBackground, etc.). It looks much nicer now. As a little extra, I added a playlist shuffle mode because randomness is good sometimes.

As usual, you can get it at the downloads page.

I promise I'm going to stop working on PsfPlayer and get back to Play!...

PsfPlayer v0.53
Posted on 2011-09-17 12:41:38

Greetings!

I made an update to PsfPlayer. Most of the changes are cosmetic, but it also fixes small problems that could occur when reading PSF files from ZIP or RAR archives. You can get it at the downloads page.

Encrypted Valkyrie
Posted on 2011-07-24 13:00:09

Hi there,

I merged most of my MPEG-2 stuff in Play! last month with mixed success. It's much more resilient to input stream interruption and so it seems to be a lot more stable. But it's still not working very well. I think there's issues with my DMAC emulation, which makes it crash/hang prone. I fixed a bug related to source chain mode transfer interruption but I think there's other bugs like this one that I'll have to track down eventually. So I decided to leave it as is for now and move to something else...

I've heard from many sources that Valkyrie Profile 2: Silmeria was using a very specific element from the PS2 behavior to decrypt its game data. So I thought it would be fun to check that out. After a few days of tidying things up in my emulator, I finally got to the point where the game was using its decryption scheme.

Basically, it is using a VU micro-subroutine to generate a decryption key which is later used when reading executable data from the DVD. The micro-subroutine in itself is rather simple:

What this does is, multiply each component of an input vector with a constant and add a constant to each component to form an output value that is used as a decryption key. This would easily run on a x86 CPU, but the problem comes from the fact that this piece of code relies on how the PS2 implemented the IEEE 754 standard to obtain a correct value for decrypting the game data. From what I've read, the PS2 doesn't use any round, guard or sticky bit in its floating point operations and also use the truncate rounding mode, which is contrary to what the x86 does. The result is only off by one when we execute this on a x86 CPU, but this one bit is crucial in making the game work properly. So, I had to implement a custom multiply routine which truncates the result of its operation and that seemed to fix the problem. But apparently, the PCSX2 team had to create a special addition routine to work around this problem... So I have no idea if my custom multiply was the appropriate thing to do.

Anyways, the game seems to be able to get a bit further with that custom multiply routine :

I can also get to what I think is the title screen, but it's pretty much gibberish for now. The game heavily uses VCALLMS which is used to call VU micro-subroutines on the VU0. It also uses a lot of VU stuff I haven't implemented yet. I think this game uses the capabilities of the PS2 to the extreme, so I think my emulator is going to break apart once it's going to try to display its main game stuff. We'll see when I get there...

PsfPlayer v0.52
Posted on 2011-06-06 18:30:47

Hello!

Today, I've released an update to the PSF music player. This version only fixes bugs I discovered while trying to listen to some game's music. More specifically, it fixes problems with Vagrant Story, Granstream Saga, Final Fantasy 6 and Chrono Trigger PSF sets (and maybe others I don't know about). As usual, it's available at the downloads page.

Play! v0.30
Posted on 2011-05-31 18:50:28

As promised, here's the latest version of the PlayStation 2 emulator. It's available on the downloads page. This version comes in two flavors : 32-bits and 64-bits. Choose wisely.

It's still way too slow, buggy and incomplete to allow you to actually play a game, but if all you want to do is see the games I've been testing, running on the emulator, then this release is for you. Enjoy!

As for what's coming next... I'm still not sure. I'd like to merge the MPEG-2 decoding stuff I did last year into the emulator, but trying to make another game work would be pretty fun too. I'll think about it and post an update when I'll have something interesting to show.

<< Older Log Entries

Newer Log Entries >>