PSX core gives low fps, also any chance of frameskip-1/force 30fps?

RetroArch General
#1

I’ve been testing out the PSX implementation on my desktop PC, and I’ve noticed it won’t give me anything higher than 45fps, where other PSX emulators hit 60fps fine. Is there any reason the implementation you guys are using would have trouble pushing past 45fps?

Additionally, I was wondering what the chances are of implementing frameskip-1 to force 30fps for situations like this where a given implementation won’t hit 60fps on certain systems. Any other frameskip value would be totally useless, but frameskip-1 would be a really nice thing to have.

And since I’ve got a thread open, any word on when we’ll be getting that gpSP implementation?

#2

Mednafen PSX is software rendered and interpreted. It’s not exactly screaming fast. Please use PSX-reARMed if it’s too slow (should run on PC too).

Frameskipping interfaces have been discussed, but it’s not decided which approach to take there.

#3

I’m running into a problem configuring pcsx-rearmed in windows:

gcc /tmp/pcsx-conf-17644-1456-26601.c -o /tmp/pcsx-conf-8502-1456-28687 -ldl -lm
c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: cannot find -ldl
collect2.exe: error: ld returned 1 exit status

I haven’t had any luck finding any information regarding -ldl, although I’ve found some regarding ld.exe being unable to find other things. Not sure what to do.

#4

PCSX reARMed will only be fast on ARM architectures.

It’s using a modified version of Ari64’s N64 dynarec (which has been modded by notaz so that it can work as a PSX MIPS dynarec) and the PCSX core has been modified so that it can work with that. That means the old PCSX dynarecs for x86 had to be removed.

I’ve been testing out the PSX implementation on my desktop PC, and I’ve noticed it won’t give me anything higher than 45fps, where other PSX emulators hit 60fps fine. Is there any reason the implementation you guys are using would have trouble pushing past 45fps?

Those other PSX emulators are also inaccurate as hell and totally dependent on plugins for SPU, GPU, and I/O. I’ll gladly take mednafen psx over any of them any day of the week. No offense but ePSXe and all these closed-source PSX emus haven’t cared one bit about the ‘scene’ and the PS1 scene was in a real bad situation until Mednafen PSX and notaz’s PCSX reARMed came around. So we’ll gladly support these emus that try to do it ‘right’.

Also - Mednafen PSX has far superior SPU emulation to any of the other emus you can mention. Really - you’re getting a lot in return for those beefier system requirements that it demands - that not a whole lot of other emus can offer you. System requirements should be ‘just’ a Core i3 CPU.

You will have noticed that ePSXe doesn’t have its source released nor do they have any intent to release it since it would mean they could no longer be making moniez on the Android Store. That and it’s totally dependent on plugins which I feel to be rather patchy to begin with. I’m glad we’re finally moving away from this overreliance on plugins to do most of the actual emulation work in the new generation of PSX emus - even if there’s still a ‘plugin’ behind the scenes at least that plugin is ‘enforced’.

And since I’ve got a thread open, any word on when we’ll be getting that gpSP implementation?

No. It will be made when we feel like it or when we have the time to do it.

Additionally, I was wondering what the chances are of implementing frameskip-1 to force 30fps for situations like this where a given implementation won’t hit 60fps on certain systems. Any other frameskip value would be totally useless, but frameskip-1 would be a really nice thing to have.

What is the point really of frameskipping? If it isn’t fullspeed it’s going to be worthless anyway - trying to play a game that was meant to be played at 60fps at 30fps will just be a huge downgrade.

Really, at the end of the day what it boils down to is that the host system is not fast enough to run the core - period. And no amount of frameskipping will hide away that inconvenient truth.

#5

Interesting information.

Personally, I’m all for accuracy for preservation’s sake, but for actually playing games I’ll stick to what works and runs smoothly. And x86 PC’s don’t work the way I want for gaming. I tried setting up one of my PC’s with XBMC to try to make it somewhat console-ish, but issues with Windows, and the fact that you have to use the underlying OS for managing applications and files, ruined the experience for me. Do you know what the accuracy level of PCSX-ReARMed is though? I’m strongly considering an Ouya (which is ARM-based), so at least I might be able to use that.

Not sure what you mean here. readme.txt here mentions the use of plugins: https://github.com/libretro/pcsx_rearmed Did you remove this from the libretro port? I know that mednafen doesn’t use plugins though.

#6

I haven’t noticed any slowdown, and my laptop is basically a “toaster” from 2008.

#7

Not sure what you mean here. readme.txt here mentions the use of plugins: https://github.com/libretro/pcsx_rearmed Did you remove this from the libretro port? I know that mednafen doesn’t use plugins though.[/quote]

I didn’t remove anything (in fact this was one of the rare cases where the libretro port was not developed by us) - only the right ‘plugin’ gets compiled in for the port in question so essentially there is no ‘plugin’ system - there’s nothing else out there that beats Exophase’s NEON GPU plugin for ARM anyway so there should be no reason to want to use any other GPU plugin. And typical GPU hardware rendering plugins for PSX has always looked rather crap anyway due to the PSX’s inherent limitations (very low-res textures, lack of perspective correction, very low polygon counts) -it has always looked odd to me to see 16x AA 1280x720 graphics and then have to put up with ugly, stretched backgrounds or these ugly cutouts around sprites - the ‘sterile’ look of PSX emus with hardware accelerated graphics has always put me off - it just doesn’t benefit PS1-era graphics at all. Software rendering in combination with shaders is definitely a lot more faithful than I’ve ever seen Pete’s GPU plugin look like, and unlike Pete’s GPU you don’t have to enable/disable a lot of hacks in some GPU config tool to get it to run certain games correctly.

#8

I’m skeptical of the Ouya, but I can recommend PCSX reARMed wholeheartedly - it has a good future ahead of it and the more mainline PC PCSX forks definitely pale by comparison. The SPU emulation is not as good as Mednafen PSX’s by far, but then agan PCSX ReARMed is using Pete’s audio plugin so that is to be expected.

#9

This is, of course, case-specific to begin with. For example, there are all of about 14 games that actually run at 60fps in the entire PSX library, everything else runs at 30fps. Except on those games, you’re effectively losing nothing.

Similarly, in a large majority of games on 2D platforms that run at 60fps (GBA comes to mind), the actual frame count on animations is far lower than 30fps, let alone 60fps. In practice the only thing you’re losing in a situation like this is flicker transparency.

The fact of the matter is there are plenty of good reasons to allow forcing 30fps.

Well in that case I won’t worry about it.

Ouya is actually a really solid piece of hardware. Tegra 3 has a lot of support in the Linux community, not to mention Ouya is android-powered out of the box, so it’s probably the most ideal ARM system for running emulators.

#10

Ouya is actually a really solid piece of hardware. Tegra 3 has a lot of support in the Linux community, not to mention Ouya is android-powered out of the box, so it’s probably the most ideal ARM system for running emulators.[/quote]

Tegra is an overpriced, Madison Avenue hyped-up piece of crap SoC (Tegra 2 being the worst offender with no NEON support) and it’s a legend in Nvidia’s own mind. If you knew anything about Android in general, you’d know why I am skeptical of Ouya as a ‘game console’ - it’s a total failure of an OS (a shitfest of Java services piled on top of a hacked-together Linux kernel) and to make it the central OS for a ‘games console’ is a facepalm-inducing spectacle of idiocy. Every low-level engineer in the world is laughing their ass off at this Android NDK crap, and I’m sorry but somebody has to go ahead and inform you ‘end users’ of exactly how much this platform sucks and get you guys off this ‘Android koolaid’. If I have to do it, then so be it.

While I consider the overall trend of ‘more open’ consoles to be a good thing, let’s make no illusions about Android - it’s a total piece of garbage and Google is probably the worst mockery of a platform holder ever - they make Nintendo, MS, Sony, RIM and Apple’s SDKs look good by comparison. And again, for any startup to base a console around this is enough for them to be discredited in the court of public opinion. It adds so much overhead that you might as well whip out a Windows netbook with SQL Server running in the background and call that a ‘games console’ instead - it rapes the very notion of what a ‘games console’ is.

Valve seems to be sensibly recognizing this and just going with plain vanilla ARM Linux for Steambox. I don’t blame them either - let Nvidia be a pallbearer for Android all it wants to if they want to nail themselves to the cross in doing so - there’s always room for a second 3Dfx at the graphics graveyard.

#11

This is, of course, case-specific to begin with. For example, there are all of about 14 games that actually run at 60fps in the entire PSX library, everything else runs at 30fps. Except on those games, you’re effectively losing nothing.

Similarly, in a large majority of games on 2D platforms that run at 60fps (GBA comes to mind), the actual frame count on animations is far lower than 30fps, let alone 60fps. In practice the only thing you’re losing in a situation like this is flicker transparency.

The fact of the matter is there are plenty of good reasons to allow forcing 30fps.

[/quote]

There are good reasons in that case for avoiding the cost that a frame would incur but it’s surely not ‘frameskipping’ the entire frame - in PCSX reARMed right now, it will send a NULL frame from time to time to video_cb. That is an indication that we want to skip texture upload for that game since the frame has not changed for that specific instant. If we would ‘skip’ the entire frame, post-processing effects (like shaders) would be skipped too - and some of them are dependent on frame count - it would mess them up.

We are simply not going to go down this road where we have to depend on ‘timer code’ to do frameskipping - it will mess up our (superior and simple) syncing model that we have right now, would trigger false positives, and not to mention - frameskipping is just a plain ‘bad hack’ mostly implemented by people who want to maintain the ‘optical illusion’ that something is running at fullspeed when it’s not. Doing syncing at a deterministic refresh rate is preferable.

If a core is running too slow or if your host system is too slow - well guess what, that’s where pluggable cores come into play - write a faster core or do core optimizations to it so that it can run at fullspeed.

#12

I pretty much agree here. Increasing the rendering resolution doesn’t do much for me. The two issues with PS1 graphics for me are the lack of perspective correction, and the almost absent filtering. IMO, If you take a random PS1 game and a random N64 game, these two things are what makes the N64 game look a lot better. edgbla is doing some work on perspective correction for his GPU plugin, but that’s unfortunately not open-source. Some heavy filtering (like on an N64) could still do a lot though, and it probably wouldn’t be too hard for a capable programmer to do.

Well I have no ARM devices (except for my NDS, but that’s crap), but I can’t wait to use it someday then once I get ahold of something.

Yeah, I’m no fan of Linux at all, and Android in general doesn’t really seem like a good OS.

I thought the Steam Box would be x86-based, but if it’s actually ARM-based that certainly makes it even more interesting.

So, while we’re on the subject, is there any other ARM PC/console with a similar size, that is more powerful than the Ouya, has good drivers available, and can be used with a nice controller-based interface (like on a console)? Would the Steam Box be it? Basically, what I want is a modern (powerful enough for HD video and PS1 emulation) replacement for my modded Xbox with XBMC, with the size, quietness and boot times of my Wii. Ouya so far seems to come closer to this than any other system, but if there’s something better out there I’ll buy that instead.