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...

Android WIP
Posted on 2015-05-21 22:07:48

Play!'s Android port is getting along well. Some commercial games are now playable (with limited speed) on an actual device!

Compatibility is very low (only a few games have been reported to work), but if you wanna try some games, you can grab the latest build on the weekly build repository. Enjoy!

Play! Weekly Builds - OSX builds
Posted on 2015-03-29 19:33:18

Hi again,

Mac OSX builds are now available on the weekly build repository.

Again, don't hesitate to report any issues you might find on the official GitHub page.

Happy testing!

Play! Weekly Builds
Posted on 2015-03-22 19:30:32

Hello!

Development of the emulator is still going forward and in order to make the latest additions available to everyone, weekly builds will now be available in that space:
http://purei.org/downloads/play/weekly/

Only Windows builds are available at the moment, but OSX and Android builds will follow soon.

Don't hesitate to report any issues on Play!'s GitHub page.

Enjoy!

PsfPlayer v1.02
Posted on 2014-07-03 20:51:02

I've posted an update to PsfPlayer today which puts back in Windows XP support, adds high DPI awareness and fixes some bugs in order to support more PSF sets. It's available on the downloads page.

The downloads page was also updated to include links to the official Play! Git repositories. You can witness the work that's still ongoing on the PS2 emulator over there.

I know I haven't been updating this site much, but I'll try to post a status update soon.

PsfPlayer v1.01 and a bit more
Posted on 2013-08-07 01:00:26

Small update on PsfPlayer today. I fixed a bug that prevented any tracks from the Berwick Saga PSF set from playing. This version also fixes a problem that could occur when reading some ZIP files that had extra information in their directory headers. Warning: PsfPlayer now requires Microsoft Windows Vista and + since it was built using Visual Studio 2012. As usual, you can get the latest version on the downloads page.

In other news, I had a copy of "Final Fantasy XI: Seekers of Adoulin" data disk laying around on my desk, so I decided to see if I could create a PSF set containing the new tracks for the game. The results were positive. Enjoy!

Untamed Arms
Posted on 2013-03-12 22:00:53

So, I've been busy working on various projects including my emulator and I recently got Wild Arms: Alter Code F to run. I ran into lots of problems as always, but I finally got it to work without any patches.

As you can see, the title screen is working perfectly, but that's the easy part.

If we leave the title screen running for a while, it's going to change to an introduction movie, as seen in the second screen shot. I did my best to make movie playback more stable, but it's still problematic. I removed all the threading stuff that was present in my IPU emulation module and made it a bit more error resilient by trapping VLC and bit-stream errors. I also enabled SPU emulation and fixed some problems with what I think is the "streaming mode" because the movie playback engine in the game is trying to keep up with the SPU somehow and requires proper feedback from it. I also improved the movie decoding speed by forcing DMA transfers to the IPU to always execute when the input FIFO is not completely full. The end result is something that kinda works, but still suffers from corrupted macroblocks and other random hiccups. But I don't need to disable movie playback with a patch to go further in the game, which is a good thing.

Before getting to the point of the third screen shot, I had to fix a problem with the instruction cache not being flushed properly. I forced it to be flushed when a recompiled area is being loaded with data directly from the IOP CDVDFSV module. I don't know why, but a lot of games seem to enjoy loading code overlays...

The rest of the screen shots are from actual in-game action. Looks kinda crappy for now, probably because of incorrect flag handling on the VU, but my next goal is to see how I can fix that without breaking other games.

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...)

<< Older Log Entries

Newer Log Entries >>