SoftGraphic graphic plugin

[shunyuan]

Originally Posted by MarathonMan

Are you using a LLE RSP plugin? Could be the issue if not.

Also, Zera was right in saying that 480p = 640x240 with the vertical resolution doubled. That's how it's supposed to look AFAIK.

Thanks, I have tried both FatCat's LLE RSP, Zilmar's RSP (modified 1.1 spec) and HLE RSP, but without lucks.

I am note sure why on mupen64 0.5.1 the output screen will become 640x480 interlaced, since I am quite sure my plugin stretches the frame buffer from 640x240 to 640x480 to screen. That's why I need a screen shot for reference to trace down this issue.

-Edit-

I always stuck at this screen, the mempak model will rotate but keyboard or gamepad has no response:

[GPDP]

Hmm, I actually had not tried Rogue Squadron itself on Mupen. I can't get past that one screen either. However, Turok 3 does work, and its hi-res mode also showcases the interlacing. Pokemon Stadium's menus also have interlaced output, so that one should be easy to test.

Unfortunately, screenshots cannot capture the interlacing, so screenshots are fairly useless in that regard. The screenshots I took look exactly the same on both emulators, so they don't convey Mupen's interlacing. Nevertheless, here you go, Turok 3 on Mupen64 running in Hi-res mode:



Anyway, I think I may have indeed jumped the gun on the whole "Mupen resolves hi-res properly" thing, since the screenshot looks exactly like on Project64. The thing is, line-doubled doesn't really describe what's going on in that shot. My expectation was that running a game in 480i at 640x480 would produce aliasing that is only a single pixel in height, since it would be mapping 480 lines to a window 480 pixels in height. Yet in that shot, the aliasing is very inconsistent, often going from one pixel in height to three. The same appears to be true horizontally. However, I now refer you to the Rogue Squadron "Expansion Pack" screen:



Check out the aliasing on the Expansion Pack. It's perfectly consistent all around.

However, I think I know what's going on now. It appears Turok 3 doesn't actually render at 640x480, and the inconsistent aliasing is a result of stretching. And indeed, using SoftGraphic 1.3 and turning on the VI filter confirms this:



While looking blurrier than before, the aliasing is far more consistent now due to the added black borders, which are not present without said filter being turned on. Without the filter, the image without borders gets stretched to the window, resulting in nearest neighbor scaling issues. This may be why I was thinking Project64 looked blockier and didn't properly display 480i. It actually does, but the scaling makes it look more jaggy than it should, and I guess the interlacing on Mupen distracted me and made me think it didn't have this issue.

[shunyuan]

Originally Posted by GPDP

Hmm, I actually had not tried Rogue Squadron itself on Mupen. I can't get past that one screen either. However, Turok 3 does work, and its hi-res mode also showcases the interlacing. Pokemon Stadium's menus also have interlaced output, so that one should be easy to test.

Unfortunately, screenshots cannot capture the interlacing, so screenshots are fairly useless in that regard. The screenshots I took look exactly the same on both emulators, so they don't convey Mupen's interlacing. Nevertheless, here you go, Turok 3 on Mupen64 running in Hi-res mode:

Anyway, I think I may have indeed jumped the gun on the whole "Mupen resolves hi-res properly" thing, since the screenshot looks exactly like on Project64. The thing is, line-doubled doesn't really describe what's going on in that shot. My expectation was that running a game in 480i at 640x480 would produce aliasing that is only a single pixel in height, since it would be mapping 480 lines to a window 480 pixels in height. Yet in that shot, the aliasing is very inconsistent, often going from one pixel in height to three. The same appears to be true horizontally. However, I now refer you to the Rogue Squadron "Expansion Pack" screen:

Check out the aliasing on the Expansion Pack. It's perfectly consistent all around.

However, I think I know what's going on now. It appears Turok 3 doesn't actually render at 640x480, and the inconsistent aliasing is a result of stretching. And indeed, using SoftGraphic 1.3 and turning on the VI filter confirms this:

While looking blurrier than before, the aliasing is far more consistent now due to the added black borders, which are not present without said filter being turned on. Without the filter, the image without borders gets stretched to the window, resulting in nearest neighbor scaling issues. This may be why I was thinking Project64 looked blockier and didn't properly display 480i. It actually does, but the scaling makes it look more jaggy than it should, and I guess the interlacing on Mupen distracted me and made me think it didn't have this issue.

There is one function called 'MoveScreen' in Zilmar gfx plugin spec that allows gfx plugin to adjust window size to match the plugin resolution setting. In this function I follow the code sample of Zilmar's CFB plugin. But mupen64 has the different way to adjust the windows size, so the rendering windows didn't match the plugin resolution setting. This also happens when you use Jabo's D3D plugin or z64gl with mupen64.

In a nutshell, the second picture is stretched to a different resolution other than 640x480 and the rendering rectangle is shifted in client window.

[GPDP]

Originally Posted by shunyuan

There is one function called 'MoveScreen' in Zilmar gfx plugin spec that allows gfx plugin to adjust window size to match the plugin resolution setting. In this function I follow the code sample of Zilmar's CFB plugin. But mupen64 has the different way to adjust the windows size, so the rendering windows didn't match the plugin resolution setting. This also happens when you use Jabo's D3D plugin or z64gl with mupen64.

In a nutshell, the second picture is stretched to a different resolution other than 640x480 and the rendering rectangle is shifted in client window.

Not quite sure I understand. Are you saying Mupen64 is to blame for the scaling artifacts? Because as far as I can tell, other than the interlacing, the picture is identical between it and Project64, meaning they both have the same scaling issue, which goes away when you turn on the VI filter, since doing so shrinks the picture and adds borders. Conker does something similar, in fact.

On that note, on Mupen64, I did notice what looks to me like deinterlacing combing with said VI filter turned on:



As shown on the previous post, Project64 does not have this issue.

I believe it is deinterlacing, because unlike with the filter turned off, the picture is stable and doesn't look like it's bobbing up and down, but you trade that in for nasty combing.

Of course, you may take this with a grain of salt, since you've since removed that filter in the latest version, but I thought I'd point out how it behaves anyway on Mupen64.

[shunyuan]

The rectangle of red line is the rendering rectangle of mupen64.

[GPDP]

Originally Posted by shunyuan

The rectangle of red line is the rendering rectangle of mupen64.

Ah, now I see what you mean. Hmm, that definitely might be an issue. Think that's what might be behind the interlacing?

Since I'm testing all this out anyway, guess I'll go see how 1964 works with this plugin as well.

[HatCat]

Originally Posted by shunyuan

-Edit-

I always stuck at this screen, the mempak model will rotate but keyboard or gamepad has no response:

That's a known bug in the Mupen64 CPU.

Not sure exactly where the problem was, but it's nothing you could control from within plugins.

[daninthemix]

So, any idea when a new version of this plugin might surface? Am particularly looking forward to some speed optimisations

EDIT: is there any way for the plugin to run on its own CPU core? Or will it always run on the same core as project64.exe?

[gamax92]

It would be cool if you could say choose a custom resolution to use while playing or if there was an auto resize option. Not all games use specifically 320x240 or 640x480 and apparently Mario Tennis's start screen runs at 304x224.

Another thing would be if you could create an option to possibly disable dithering on the screen. I know that Zelda OoT (or at least Master Quests Debug version) stores the title screen logo in RGBA 32bpp and frankly its painful to look at.

I'm not sure if bilinear filtering is working for me as turning it on and off doesn't seem to change anything. The filter option worked for me in 1.3.0 and using it makes the dithering much less noticeable. However it does seem to blur sharp things such as fonts.

[GPDP]

Originally Posted by gamax92

It would be cool if you could say choose a custom resolution to use while playing or if there was an auto resize option. Not all games use specifically 320x240 or 640x480 and apparently Mario Tennis's start screen runs at 304x224.

Thing is, everything is supposed to run at 4:3, regardless of whatever resolution is actually being output. Remember, not everything ran with perfectly square pixels back then. CRT TVs had no issues with this since they do not have actual fixed pixels like LCDs do.

Another thing would be if you could create an option to possibly disable dithering on the screen. I know that Zelda OoT (or at least Master Quests Debug version) stores the title screen logo in RGBA 32bpp and frankly its painful to look at. I'm not sure if bilinear filtering is working for me as turning it on and off doesn't seem to change anything.

AFAIK the dithering is meant to be blended by the VI filter featured in older versions of SoftGraphic. I don't know how you would go about removing it without removing detail and shading outright.