Re: [RELEASE] PicoDrive 1.92 - with SVP dynarec
Posted: Thu Feb 15, 2018 12:33 am
I think it's possible to have both memory managers. But the code is very low level and I find it less laborious to optimize the manager that is there. What the manager does is similar to a pc motherboard chipset. For the code you can have an idea and see the historyflamming_python wrote: ↑Wed Feb 14, 2018 9:22 pmWell isn't it possible to have both memory managers (the old one and the new one) and simply switch between them? Or are the changes made to accomodate 32x games too fundamental and have affected everything else?robson.santana wrote: ↑Wed Feb 14, 2018 4:22 pmThe problem with the speed of the Sega CD is that when notaz that by making the Picodrive compatible with 32x, it switched its own memory manager through the memory manager of Genesis Plus GX, which is not an emulator created for portable devices (like Snes 9x). I believe that some optimization is possible, but it will require a lot of effort
What's a memory manager anyhow? You mean something like a garbage collector in the Mega Drive's RAM?
Sure thingThis is possible, this option already exists, in performance analysis mode (profile), please add this request in the github bugs page: https://github.com/robson-alcantara/picodrive/issues
As I understand, the FuSa plugin only outputs to full screen if you have a PSP 2000. In which case yes, every PSP game and homebrew can be set to output to full-screen through the plugin's options - the homebrews themselves require no modification.This is possible if you increase the screen scaling factors in conjunction with the Fusa plugin (one of the plugin options does not consume resources).
From what I heard, the other emulators also do this together with the Fusa
I haven't tried FuSa myself; I have a PSP 3000.
As I understood it's possible for homebrews to be fullscreen with the PSP 3000 too; but it requires inclusion of this FuSa-related code into the homebrew source.
I might be completely wrong on all this though; like I said I haven't tried FuSa, I just heard it has problems on anything other than PSP 2000s.
I can look into this perhaps for you.
Why wouldn't it be? I presume that the homebrew app does have some library call or something else it can make to find out whether or not the PSP is outputing to the TV or using its own display.Did not know this was possible automatically
BTW I have one final request; a bigger one, but this could be very promising:
d). 'overclocking' the rendering of certain games. Some games on the Mega Drive and Mega CD are naturally rendered very choppily and at low FPS. I'm thinking games like Steel Talons, Hard Drivin'.
Wing Commander 1 for the Mega CD has a snail's pace FPS when up close and personal with an enemy ( which is a shame as its otherwise a fantastic and unique port).
A game like Steel Empire - suffers a considerable amount of slowdown when there's a lot of action too.
It would be great if there was inbuilt support in the emulator to recognize certain problematic games, and if one is loaded - overclock their rendering/drawing to give them a faster FPS or avoid slowdown.
https://github.com/robson-alcantara/pic ... o/memory.c
https://github.com/robson-alcantara/pic ... 8757384329
The Fusa plugin has several ways to stretch the screen, those that do not require changes to the homebrews consume a lot of CPU, but there is a way in which it only stretches the width, the height is by the homebrew (or vice-versa) . This option has the best graphics and does not consume CPU
The application is able to know which output device, so POPS works, however Picodrive does not have this code, but studying some open source homebrew with this functionality, if it solves
The developer of Picodrive, notaz has already implemented overclocking in the emulator, but in Retroarch only. I'm expecting version 1.93 of Pandora to port (a code part of PSP version 1.92 still to be done, some code in assembly). I do not do the current version because I do not know if it is stable and also because it would take me longer to spend all the time porting code.