|
|
|
|
|
|
| What is Play! ? |
| 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. |
| Compatibility Status |
|
Fetching compatibility status...
|
| Development Log |
|
Make 'Guilty Gear XX Accent Core Plus' work.
Posted on 2008-10-03 00:00:00 |
|
The goal's pretty simple, I wanna make Guilty Gear work in the emulator. It's a 2D game, so it shouldn't be too much of a problem.
What I mostly want to do with this game is to make the IOP emulation a bit better. Right at the beginning I was faced with some problems since the game requires recent versions of the IOP modules that are currently emulated. The FILEIO module caused me a lot of problems because of the weird communication system it uses for returning its results to the EE. Basically, it involves a custom SIF command handler and some special packets, which took a bit of disassembly work to figure out. I want to be able to support custom IOP modules which are mostly used to provide sound to the games. This game probably streams its music from the disk, so that shouldn't be a problem. Sound effects should be a little trickier and will probably require a more involved SPU support. We'll see when I'll get there... For now I want to be able to play the game properly.  
I got the game to work up to the memory card checking phase (which fails as always). It's asking if we wanna play without a memory card, but unfortunately the controller IOP module doesn't work. So, that's what I'm busy with right now... More screen shots coming soon, hopefully. |
|
Make 'Castlevania: Yami no Juin' work.
Posted on 2008-08-26 00:00:00 |
|
Well, after all this time, I wasn't really able to get the game to work a lot faster, but it did make me realize that threads aren't the way to go to gain speed. This is because of all the synchronization required to make it work properly and also because the threads doing the work are quickly running out of data to process, thus making it wait for the data producers to produce more and negating any speed gain...
I don't really know what else I could do to speed things up while the game is rendering stuff using the VU/VIF. I tried checking which part of the VU/VIF processing was the slowest and I can't really come up with a conclusion. Micro-program execution doesn't seem to be taking a lot of time and so is data decompression. Maybe it's the big amount of data sent to it that's making it choke like that. It seems to be the case with the Atelier Iris world map rendering at least. In Castlevania it seems to be slow because something is keeping the CPU busy. I don't know what exactly, but I'm getting only 15fps if I turn the VIF off. So it might mean that some OS event isn't fired at the right time or that we might be better off working on getting the recompiler to generate faster code. As a temporary measure, I added a frame skip option that will disable GIF and VIF processing for x frames out of (x + 1). If we set the emulator at frame skip 10, Atelier Iris runs at 50 "fps" during the map screen, while Castlevania runs at 10 during the main game screen. That correlates with the 2 types of slowness I've been talking about above. I also revamped the input handler so that the bindings can be configured in the UI and so it can work with joysticks. I also added support for the analog sticks in iop:PADMAN : we can now move the character normally in Castlevania. I'm still not exactly sure about what I'm going to attempt next... I think I'm going to try to make another game work to get more data about what can clog the CPU / VPU and maybe fix more of the broken things. |
|
Make 'Castlevania: Yami no Juin' work.
Posted on 2008-06-23 00:00:00 |
Well, it's been a long time since I've posted here, but it doesn't mean I haven't been working on the emulator. It took me more than 1 month to finally get the game to get past its loading screen and to make it display its game mode.
 
 
I'm kinda happy to see that there isn't too many rendering problems and that the game seems to work correctly (action buttons and menus). We can't move around though, since the analog pad isn't emulated yet. The hardest part in getting the game to load properly was to figure out that my emulation for a game specific IOP module wasn't good. After that, I needed to add support for DMA channels 0 and 8, for VU0 in micro-mode and for a lot of unsupported VU instructions. The next step is going to consist in making the game work at decent frame rates. Currently, while being in the 3D game mode, the game runs maybe at 0.5 fps. The menus and UI also run very slowly (1 or 2 fps), so the speed problem probably isn't related to some "heavy" load the VU1 would have while drawing the scene... |
|
Fix VIF/VU emulation
Posted on 2008-05-15 00:00:00 |
I diverged a lot from the initial goal, but here's where Atelier Iris at now:
  
So, to sum it up, the 3D map rendering works again, the game works on the MacOSX port and memory card emulation is working for the game. I would have loved to show you the other parts of the games that use the VU, but most of these still don't work properly. The map rendering also still requires the patch to work properly... I decided to stop looking for the causes of the bugs because I had no idea where the causes might lie (no, they aren't related to the lack of DIV pipeline emulation). The bugs aren't major anyways and you can still play the game even if you encounter them. I'll probably stumble on something while working on other games that'll make me think of something that could fix the problems... As for this development, I think I'll leave it as done for now. I need to start working on something fresh... |
|
Fix VIF/VU emulation
Posted on 2008-04-27 00:00:00 |
|
After almost 3 weeks, the state of the VU emulation got a bit better. For Atelier Iris, all the required VU instructions are emulated and we can execute the microprograms the game needs. It's far from perfect though...
There's one problem that occurs while the game tries to show the animation that appears when Klein absorbs mana elements from props in the map that I don't know how to fix. The VU program feeds some negative coordinates to the GS and I have no idea how to deal with those without breaking other stuff... So I think I'll leave that problem as it is for the moment. Instead, I'll try to concentrate my energies to get the overworld map rendering to work properly again : right now, it works with a patch, but I wanna get rid of it, and I think proper DIV pipeline emulation will do the trick... |
|
Fix VIF/VU emulation
Posted on 2008-04-09 00:00:00 |
Both demo #2 and #3 work as before now:
 
What took me a lot of time was to get rid of the global variables that were used all over the place in the compiler. They were causing some trouble since it's possible for the compilation code to be ran by two threads (EE thread and VIF thread) simultaneously. I also took the occasion to remove heaps of old code. The frame rate on both demos isn't too bad and it's a lot better compared to the previous version of the emulator. Also, demo #3 doesn't work quite well on MacOSX... I haven't investigated much, but I'll try to make sure it works for the next release. Next challenge : the VU stuff in Atelier Iris. The previous version couldn't make the overworld map rendering code work properly without a patch in the game code. I don't wanna rely to that patch this time... |
|
Fix VIF/VU emulation
Posted on 2008-04-01 00:00:00 |
After a little bit more than a week of work, I finally got the first scene of the demo to work again.
The frame rate is a bit better than the previous version, but it's nothing groundbreaking. Next step: make the second scene of the demo functional. |
|
Fix VIF/VU emulation
Posted on 2008-03-21 00:00:00 |
|
In this development, I wanna get the VIF/VU stuff back to a working state. I'm gonna use the "Slave of the VU" demo to do that since it's not doing very complicated stuff. I also want to add proper pipeline emulation for the instructions that store their result in the Q or P registers.
Currently, all I've got done is getting the old VIF module to compile again and linking the VIF stuff to the other modules that access it (DMAC, VM). I can now step through a VU microprogram once again, but I'm running into a lot of unconverted instructions. The next steps will involve creating functions that splits the microprogram into proper basic blocks for its execution because the current execution logic (the one that's used by the EE) doesn't apply to the VU execution logic. After that, I'll have to convert all the required instructions for the execution of the first microprogram in "Slave of the VU" to the new compilation system. |
|
Put the project back in its tracks (part 2)
Posted on 2008-03-18 00:00:00 |
|
I finally decided to base my idle loop skipper on the number of times a basic block is executed in a row: once a specific threshold is met for that value a V-Blank start (or end) interrupt is forced. It works well for Atelier Iris (runs at 45 fps+ on my computer), but it'll probably work less well on other games that have a more esoteric synchronization method. But since I'm not supporting a lot of games at the moment, I think I'll leave it as is for now.
Logically, the next part would be to fix the VU support, but I wanna do that on a demo first. That's what I'm gonna to work on tomorrow. There's also an annoying texture loading lag bug present when playing the game that kills all the pleasure of having high frame rates, but I'm gonna leave fixing that in another development (probably in the one after VU fixing). |
|
Put the project back in its tracks (part 2)
Posted on 2008-03-16 00:00:00 |
|
I've completed the conversion to the current recompilation system of all instructions needed for the normal "2D" (no VIF/VU) operation of the game.
I've also been checking into the idle loop skipping thing. I still don't really know how I'm gonna do that as there's many different V-syncing schemes used in the games which use different parts of the PS2 hardware:
Maybe the key lies in the detection of an "idle" state and the forcing a V-blank start interrupt when that state is detected... |
| << Older Log Entries | Newer Log Entries >> |