SoftGraphic graphic plugin

[shunyuan]

----------------------------
SoftGraphic HLE plugin v1.5
----------------------------
SoftGraphic is a software rendering HLE graphics plugin that uses MESS rdp core
written originally by MooglyGuy of MESS as rendering engine. No special RSP is
needed. It is slow and you need a fast CPU to get a decent frame rate.

-------
Noteice
-------
This plugin uses uses MESS rdp core written originally by MooglyGuy of MESS and bug fixed by angrylion
to render graphics, the credit of graphics rendering should goto MooglyGuy and thanks for angrylion for his
bug fixes.

source of rdp_interface here

--------
History:
--------
v1.5
* rewrite D3D9 driver with shaders
* support PJ64 save to bitmap
* add 2xSai, Super2xSaI, SuperEagle and TV mode filter

v1.4
* add D3D9 driver support
* add UI to enable/disable D3D9 bilinear filter.

v1.3
* rewrite DirectDraw code to improve frame rate
* add full screen support
* add resolution 1024 x 768

v1.2
* use multi-thread rendering to improve frame rate

v1.1
* add UI to enable/disable filter to improve frame rate

v1.0
* first implementation

--------
Settings:
--------


Preview:







-----------------
my other plugins:
-----------------
ShunyuanDI: Shunyuan's DirectInput8 plugin
HleAudio: Auido plugin with XAudio2 + DirectSound driver support
GfxWrapper: to use Jabo's Direct3D8 v1.7.0.57-ver5 with Project64 1.6

[HatCat]

I wonder why it's still slow if both the RDP and the RSP commands are simulated.
Maybe it's that DirectDraw code.

It doesn't look too sexy when forced to 320x240/640x480/800x600.
The pixels were less blurred/stretched back when I was using SDL.
I was hoping a native port to Windows GDI would blit it less blurred. :S

[Zera]

It's unplayable even on my i7-3770k. Most games are bellow 30Vi/s, while some drop as low as 15Vi/s.

Well, at least it's working

[Lithium]

Great plugin, but very demanding.

[mudlord_]

For DirectDraw, blurriness can come from whether the surface is created in video memory, or system memory. Try to play with the flags on surface creation to fix it.

[HatCat]

Originally Posted by haxatax

For DirectDraw, blurriness can come from whether the surface is created in video memory, or system memory. Try to play with the flags on surface creation to fix it.

ORLY.

That is very interesting to know!

I honestly was guessing that as an instinct, but I'm like, nahh...that doesn't make any sense. H/W blitting just makes it faster.
But I thought closely how software can be considered more "accurate" in some sense.

Hm. Good thing I want to make a plugin that doesn't 100% of the time need modern hardware requirements anyway then. :P

[mudlord_]

Oh yah, ZSNES used to have the same issue :P

[shunyuan]

Originally Posted by FatCat

I wonder why it's still slow if both the RDP and the RSP commands are simulated.
Maybe it's that DirectDraw code.

It doesn't look too sexy when forced to 320x240/640x480/800x600.
The pixels were less blurred/stretched back when I was using SDL.
I was hoping a native port to Windows GDI would blit it less blurred. :S

It is possible, there are several rdp commands need to lock out screen surface to fill the frame buffer with primitive, such as showtile(), and it is very slow to lock and unlock DirectDraw surface.

I wonder it will be faster if I replace the DirectDraw surface with a DIB section.

[the_randomizer]

Originally Posted by Zera

It's unplayable even on my i7-3770k. Most games are bellow 30Vi/s, while some drop as low as 15Vi/s.

Well, at least it's working

The plugin is using software to render as opposed to hardware. It's the first release and over time, I'm sure speed will be improved, but for now, it relies wholly on the CPU as opposed to the GPU. The CPU is doing all the work.

[HatCat]

I believe system memory is the default, so I changed the DirectDraw initializers to create the surface in video memory. It doesn't seem to have fixed certain aspects of the blurring.



I suppose by this point in time the matter could be a little more internal along angrylion's changes to the code.

I'm going to try reverting to the SDL rasterizer temporarily.