Release PCSX ReARMed, with a new GPU

[Garrett]

Thanks for the explanation Exophase, although most of this is way over my head i do find the minutia fascinating.

 

[Ian J]

Hopefully this will ignite some work on optimising or rewriting a more efficient plug-in.

 

[MarioPandio]

Any chance of screenshots for those of us who don't have the chops to set all this up right now? I'd love to see the differences with Wipeout ..

Sorry to disappoint but I've just spent the last hour trying to capture the differences via various screen grabbing methods and its simply not possible


Gruso's snapsnap PND (timer version) can capture ingame footage using the default GPU plugin for PCSX (except for the menu screens of the emulator itself (which previous screenshot scripts can capture but not any ingame events) and also the game menu screens and intro movies. Which of course show no difference in the rendering quality on either defaultGPU or GlesGPU plugins.


It cannot capture ingame footage of the GlesGPU Plugin however, as all you get is a blank screen from launching PCSX, until you exit.


The older methods of scripts for screenshots by Someguy99 and the timed method by LinuxMaster, can capture the GlesGPU plugin in action but only the PCSX emulator menus and the intro movies of Wipeout upto the splash screen. Once actual demo footage or ingame play is attempted the script is cut off and ceases to take any pictures anymore.


The sole difference in the images of the intro movies of Wipeout is that using the GlesGPU plugin results in a striped grey border to the top and bottom of the displayed image and as it is CGI type footage (I imagine), there is no discernable difference.


Video will be required to see the actual ingame difference but my camera isn't handy and by the time you allow for compression issues by Youtube or whoever its uploaded to, you wont actually see any difference. Except for the main difference that is, which has already been mentioned and which piqued your interest in the first place.


The GlesGPU plugin looks considerably more awesome BUT....you take a 60x performance hit.


Wipeout runs at 60fps on the default plugin at 600 mhz


It runs at about 1 frame every few seconds on the GlesGPU plugin at 1000mhz....but it does look nice.


To be fair, its only the close up shots of the ingame fly bys of the craft that are so slow. The shots of the ships careering around the track are far faster and close to an almost playable speed. With far more power this might be useable but tons of coding tricks would no doubt also be required.


Stick with what works already, which is frankly freakin awesome thanks to Notaz, Exophase and others involved so far.


I'll happily upload a folder of 3 different sets of screenshots from wipeout from these tests for anyone that's that bothered but there is really nothing to see the difference in, except for the grey striped border and lack of a FPS counter on the GlesGPU plugin, as the Pandora cannot keep up with rendering it all and displaying the counter at all, let alone allowing you to play it looking that good and to be fare, it looks bloody good mixed with nostalgia anyway, so who cares


For what its not worth.....Default GPU

GlesGPU

 

[Linux-SWAT]

Waaa ! The plugin double the size of the screen ! ^^

 

[TitanUranus]

As a man, it's not unusual for certain things to double in size if I'm about to use them as a"plug-in". In this case however, I suspect that the screen stretch is simply an illusion due to the vertical resolution being artificially doubled. Would that my own aforemention plugin could create such an impressive illusion...

 

[Linux-SWAT]

When launching the .pnd under Slackware, i can play when logged as root, but when i launch as user, i got those errors :


input: in_name_to_id: no such device: evdev:gpio-keys


input: in_name_to_id: no such device: evdev:nub0


input: in_name_to_id: no such device: evdev:nub1

rearmed wants read access to /dev/input/event*, default firmware has udev rule to make them readable.

Ok, i found the rule for nubs, but not the one for gpio-keys. I copied all /etc/rules.d/* from official rootfs, but still not recognized.

input: in_name_to_id: no such device: evdev:gpio-keys

 

[notaz]

Here are some GLES comparisons:


http://notaz.gp2x.de/img/mess/psx/gles/


Screenshots taken directly from pandora, left is NEON GPU (scaled with nearest neighbor manually, because hardware scaler can't be dumped), GLES on the right. Note how GLES often gets various elements wrong, although it might be good for some games.

 

[gruso]

Thanks for the shots.


Lara's still got it.

 

[Linux-SWAT]

Nope, wasn't in 50-udev-default.rules :/ .

 

[Pickle]

Here are some GLES comparisons:


http://notaz.gp2x.de.../mess/psx/gles/


Screenshots taken directly from pandora, left is NEON GPU (scaled with nearest neighbor manually, because hardware scaler can't be dumped), GLES on the right. Note how GLES often gets various elements wrong, although it might be good for some games.

I think the black borders could be corrected by switching to GL_NEAREST for texture filtering

 

[Garrett]

Thanks for the comparison screens notaz, although the statics are a significant step up from the default plugin they don't really convey how phenomenal they look in motion.. even though it's probably more than a little perverse i encourage those that haven't tried, to fire up some games with the GLES.so plugin enabled (serious overclocking needed) be mindful of drooling on your Pandora screen!

 

[PokeParadox]

Hmm overclocking isn't REALLY needed for the games that can use the plugin well and the CPU is not the limiting factor in the ES plugin, the GPU is.


Basically some games really suffer with the GLES plugin in the current state and others run really nicely.

 

[Linux-SWAT]

Here's my plugin.


/dev/input/event4 was root:root rw rw -- . Shame on me.


Now another mystery .


---EDIT : Haha, no bug when mounting manually the .pnd, then launch manually.

 

[Exophase]

I think the black borders could be corrected by switching to GL_NEAREST for texture filtering

It's most likely caused by partial-transparent edges, which are being shown with full opacity. If you change the alpha reject cutoff to anything less than 1.0 alpha values it should reject them.

 

[notaz]

ok uploaded r14 with working frameskip. Games like Spyro or Tomb Raider run ok with some overclock (if you don't mind glitched loading screens), others still slow or too glitched, as before. The original PEOPS GL plugin has loads of options and hack switches, so those are now available in plugins menu, maybe something can be tweaked there. Get it at the usual place:


http://repo.openpandora.org/?page=detail&app=package.pcsx_rearmed.notaz

 

[Ian J]

Just tried this with a couple of games that were painful to play (Wipeout & G Darius) and they ran really well.


Also messed with some of the new settings in Road Rash and they helped with transparency issues.


This is really cool.


Many thanks for this awesome update.

 

[Linux-SWAT]

Dl soon ^^.


Thx !

 

[asimov-solensan]

I have tried FFVIII and played a while with all the options avalaible. Lot of glitches in the menus, the game runs well on the map, crashes when entering a battle.


The only option that enhanced the behaviour was the "texture garbage collector" which increased stability. At least I could enter the battles, with great slowdowns at this point and lot of glitches in the models.


Still is really promising, when it works games looks really nice.

 

[Ian J]

Should someone start up a Google Spreasheet so that we can compile a list of tweaks for specific games?

 

[Jumpman]

I asked this question awhile ago, but I don't believe anyone ever replied.


Has anyone ever gotten Silhouette Mirage(NTSC/ISO) to run? The opening movie and credits start up, but once you try and run the game.....Nothing. The screen goes black, and it appears to stop running. My copy may be bad, but I don't want to bother looking for another version if there is some kind of compatibilty issue. I've tried differant settings as well, and nothing seems to help.


Chris