sukhi2011
Active Member
Ok yes i can huge difference and looks fantastic on wipeout 3.
Is it good to overclock if the games are running slow and some games do flicker,does the hi-res work on every game.
Release PCSX ReARMed, with a new GPU
- Thread starter notaz
- Start date
Is it good to overclock if the games are running slow and some games do flicker,does the hi-res work on every game.
bagmouse7
Member
- Joined
- Oct 25, 2004
- Messages
- 299
It looks AWESOME on Wipeout but is slower than the other drivers. On games like Hot Shots Golf it has some graphical errors, so I think each game will have a different level of success.
Ian J
Advanced Member
- Joined
- Aug 27, 2010
- Messages
- 1,880
I don't normally use the GLES plug-in but I just tried Wipeout 3 and have to agree it looks stunning.
Last edited by a moderator:
sukhi2011
Active Member
To be honest most games are running really slow or they show graphics gliches.
It's very few games work with this plugin.
If only the games worked normal,we would have hi-res graphics,in games like ridge racer type 4 and tekken 3 look amazing but are unplayable.
It's very few games work with this plugin.
If only the games worked normal,we would have hi-res graphics,in games like ridge racer type 4 and tekken 3 look amazing but are unplayable.
Last edited by a moderator:
- Joined
- Dec 8, 2005
- Messages
- 6,603
- Age
- 40
- Location
- UK
- Website
- pokeparadox.itch.io
- WEBSITE
- https://github.com/pokeparadox
- YOUTUBE
- pokeparadox
Last edited by a moderator:
Garrett
Advanced Member
Can i suggest that we get a GLES compatibility list going: games that run at playable speeds (with overclocking) with little or no graphical glitches.
notaz
Certified Guru
I have frameskip mostly working here on GLES plugin which helps many games, have to finish it up and release.
CAZMIESTER
Active Member
- Joined
- May 30, 2010
- Messages
- 966
Any chance ray crisis space shot and raystorm can be supported.
Garrett
Advanced Member
I could be wrong (and most probably am) but i think the DSP is vital for things like this, and as yet it's not an option.
Exophase
Nothing good will ever come of Exophase.
The DSP has nothing to do with the performance of an OpenGL ES renderer.
BaDToaD
"Very" Old Timer
Garrett
Advanced Member
Ah OK, any chance you could educate me where the bottleneck lies as far as it's performance in ReARMed is concerned.
Pickle
Mega GP Mania
The silicon
Linux-SWAT
Forum Addict!
- Joined
- Feb 13, 2010
- Messages
- 9,187
^^
Exophase
Nothing good will ever come of Exophase.
I looked at the OGL ES plugin a bit and it isn't surprising that its performance is very poor. It's basically doing a draw call for every triangle or quad, which will result in tens of thousands per second for a typical game. That's never going to perform well. Note that this is largely because it is based on old code meant for OGL 1.x, with triangles drawn using "immediate mode".. the way graphics are done has changed a lot since then.
Getting fast and reasonably correct (forget perfection) emulation with hardware acceleration/enhancement is challenging mainly due to two things: supporting PS1's texture formats and supporting reading back previously rendered-to VRAM as a texture for a later primitive. The texture format problem is usually solved by converting all PS1 textures to some standard format like 15bpp RGB. This requires a lot of careful tracking because the same texture data in VRAM can result in different textures if different palettes are used. So you have to match palettes with texture regions (which are defined by triangles) and cache every new combination that's used. Uploading new textures is expensive and this can end up using a lot more memory than the PS1's textures did.
The other problem is harder. You have to be able to merge the emulated display - which is a different format from the emulated VRAM, or at least that's the main point of using hardware, to enhance the original - with the original display. Reading back the screen output is very expensive. And since this happens a triangle at a time it can be expensive to determine exactly which parts to update. Usually games will render an entire large rectangular region (in the backbuffer in VRAM), but not always. Sometimes they will render "off the screen." Emulators like peops OGL1 handled this through a complex set of checks, heuristics, and hacks, and invoked software rendering over trying to get back the rendered display. But these old emulation techniques didn't have access to a lot of more advanced features like render to texture.
There may be other solutions possible with more complex caching strategies or utilizing fragment shading more to emulate things. But Pandora doesn't have a lot of fragment shading capability so who knows how much you can get on them..
Getting fast and reasonably correct (forget perfection) emulation with hardware acceleration/enhancement is challenging mainly due to two things: supporting PS1's texture formats and supporting reading back previously rendered-to VRAM as a texture for a later primitive. The texture format problem is usually solved by converting all PS1 textures to some standard format like 15bpp RGB. This requires a lot of careful tracking because the same texture data in VRAM can result in different textures if different palettes are used. So you have to match palettes with texture regions (which are defined by triangles) and cache every new combination that's used. Uploading new textures is expensive and this can end up using a lot more memory than the PS1's textures did.
The other problem is harder. You have to be able to merge the emulated display - which is a different format from the emulated VRAM, or at least that's the main point of using hardware, to enhance the original - with the original display. Reading back the screen output is very expensive. And since this happens a triangle at a time it can be expensive to determine exactly which parts to update. Usually games will render an entire large rectangular region (in the backbuffer in VRAM), but not always. Sometimes they will render "off the screen." Emulators like peops OGL1 handled this through a complex set of checks, heuristics, and hacks, and invoked software rendering over trying to get back the rendered display. But these old emulation techniques didn't have access to a lot of more advanced features like render to texture.
There may be other solutions possible with more complex caching strategies or utilizing fragment shading more to emulate things. But Pandora doesn't have a lot of fragment shading capability so who knows how much you can get on them..
