|
|
|
|
|
|
| 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 |
|
Castlevania : Yami no Juin - Improve the speed and add memory card support
Posted on 2006-07-19 00:00:00 |
After working all day to make an OpenGL rendering context able to create itself, I was able to finish integrating the existing work for the memory card manager :
It's not yet complete, and here's what I'd like to have done in this development : - Add a 'close' button in the bottom of the window. - Make the memory card switching (from memory card 0 to 1 for example) work. - Fix a speed problem when loading icon data from the disk. - Make a message box appear when the save data already exists when importing. - Add another viewport in the bottom that'll allow to rotate the icon and select which icon to display (there's 3 different ones) - Add an option to export and delete the selected save. - Display the date of last modification. Well, that's pretty much it... I'll be working on adding those points tomorrow. |
|
Castlevania : Yami no Juin - Improve the speed and add memory card support
Posted on 2006-07-18 00:00:00 |
|
Implemented the idea I had yesterday, and it works pretty good. The texture cache isn't invalidated all the time anymore.
I also changed the way the repeat wrapping mode is handled for some specific values because the fragment shader would cause a slowdown when executing the general case algorithm. Everything goes at a nice 10 frames per second now. So I think the "make the thing faster" part is complete for the moment. Next, I'm going to integrate the memory card manager dialog into the emulator. |
|
Castlevania : Yami no Juin - Improve the speed and add memory card support
Posted on 2006-07-17 00:00:00 |
|
After doing some more tests today, I figured out that the multi-threaded thing isn't that much of a good idea... At least, not for the moment.
In Castlevania, the VIF produces way more data than the GIF/GS can handle during an interval of time and the main emulation thread becomes stuck waiting for more space to be available to store more commands. So, unless we make the GIF/GS processing faster, the multi-threaded approach won't give any speed increase. I did some quick profiling to see where most of the time was spend during the emulation, and 80%~90% of the emulation time is spent in the GIF/GS subfunctions, while the VIF1 uses at most 5% and the EE 10% : another argument that says that the GIF/GS is the big problem here. The thing that makes the GIF/GS very slow is all those calls to glTexImage2D in the OpenGL GS handler. If we remove any texture processing, we can get around 10~15 frames per second which is 10~15 times faster than what we got right now. If we disable texture cache invalidation, we get the same speed as if we had disabled any OpenGL texture uploading, without visible problems. So the solution might lie there... If the textures the game uploads end up being the same as the ones we already have in RAM, there is no point in invalidating the cached textures. So, tomorrow I'm going to try adding a check for changes in the GS RAM when we're transfering a texture and invalidate the cache only if there was a change. |
|
Castlevania : Yami no Juin - Improve the speed and add memory card support
Posted on 2006-07-16 00:00:00 |
|
I decided to scrap the first idea I had for implementing an inter-thread communication mechanism, and decided to go with something else that wouldn't have as many problems as the first one.
The current system seems to be stable enough, but it doesn't seem to balance the load very well : the total CPU load still remains at ~50% meaning only one core is in use. I'll try to find out why this is happening tomorrow. |
|
Castlevania : Yami no Juin - Improve the speed and add memory card support
Posted on 2006-07-15 00:00:00 |
| I rearranged some stuff with the OpenGL GS handler and fixed some bugs in the communication mechanism. Even though it's still not stable enough, I could do some tests with some demos, and it seems to give a nice speed boost compared to the single-threaded version. I'll keep working on that tomorrow. |
|
Castlevania : Yami no Juin - Improve the speed and add memory card support
Posted on 2006-07-13 00:00:00 |
|
Well, the title of this one is kinda explicit. I want to improve the speed of the emulator and I want to add basic memory card support.
In the speed improving part, what I mostly want to do is add the ability to move all the execution of the GIF operations into a separate thread. The slowness in this game is caused in great parts by the GS handler and its numerous calls to glTexImage2D. The texture swizzling routines are slow too, but it's nothing compared to the overhead of calling glTexImage2D. There's also the fact that multi-core CPUs are probably going to be the new trend. If we'd keep the design of the emulator single-threaded, we wouldn't be able to take advantage of this. The second core of my CPU is currently unused by the emulator... So by having a second thread doing the rendering job, we should be able to achieve greater speed since the workload will be balanced over the 2 cores. In the memory card support adding part, I just want the game to be able to load a saved game that'll have ripped from my real memory card. I also want to integrate that memory card manager I've been working on these past days. As for today's work, I've started working on giving the GIF its own thread. It won't render anything for now since I haven't found a way to make the GIF thread the "owner" of the created OpenGL context yet. I'll keep working on that tomorrow. |
|
Make 'Castlevania: Yami no Juin' work up to the title screen.
Posted on 2006-07-12 00:00:00 |
|
Cleaned up the SIF/IOP logging stuff.
This is all that had to be done for this development. Something new coming up next. |
|
Make 'Castlevania: Yami no Juin' work up to the title screen.
Posted on 2006-07-11 00:00:00 |
Added support for some few more required alpha blending formulas and fixed some stuff with sprites rendering in the GS handler:
 
The title screen is not rendered without problems, but its fine for the moment as the goal was to just get there. We can go a bit more further and input our name and get to the "Now Loading" screen, but it seems to remain stuck there indefinitely and I wouldn't think the VU emulation in its current state would be able to handle the game... But that's one of my next goals. I also changed the moment our back buffer is flipped to get rid of the "flickering". The change I made seems to work good for this game, but I'm not sure if the exact same thing will do for the other games. We'll have to see... All that remains to do now is to clean up that SIF logging stuff. Pretty much just add a menu item to control the logging and recheck the currently implemented modules for potential missing stuff. |
|
Make 'Castlevania: Yami no Juin' work up to the title screen.
Posted on 2006-07-10 00:00:00 |
Finally completed the changes to the PADMAN module to make the controller work. We can now skip that screen and see the Konami screen and the title screen:
 
The "悪魔城ドラキュラ" on the title screen isn't visible probably due to a problem with alpha blending. I'll be working on fixing that tomorrow. |
|
Make 'Castlevania: Yami no Juin' work up to the title screen.
Posted on 2006-07-09 00:00:00 |
|
The structure I was talking about yesterday is actually the same structure that's used with the extended version of the PADMAN module. But for some reason, the version of PADMAN that comes with the game uses the same method IDs as the older version... I haven't checked the module IDs, so those might be different. But in any case, that makes the problem a bit less complicated since I can use the same stuff I did for Atelier Iris.
I thought it would have worked without any changes, but it doesn't seem like it. It's probably just a matter of setting another one of the values in the structure correctly, so I'll keep looking tomorrow. |
| << Older Log Entries | Newer Log Entries >> |