#501  
Old 27th July 2013, 04:47 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by MarathonMan View Post
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:

__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit

Last edited by shunyuan; 27th July 2013 at 05:17 PM.
Reply With Quote
  #502  
Old 27th July 2013, 07:11 PM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 146
Default

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.
Reply With Quote
  #503  
Old 27th July 2013, 08:19 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by GPDP View Post
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.
__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit

Last edited by shunyuan; 27th July 2013 at 08:25 PM.
Reply With Quote
  #504  
Old 27th July 2013, 09:23 PM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 146
Default

Quote:
Originally Posted by shunyuan View Post
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.

Last edited by GPDP; 27th July 2013 at 09:27 PM.
Reply With Quote
  #505  
Old 27th July 2013, 09:33 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default



The rectangle of red line is the rendering rectangle of mupen64.
__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit
Reply With Quote
  #506  
Old 27th July 2013, 09:37 PM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 146
Default

Quote:
Originally Posted by shunyuan View Post


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.
Reply With Quote
  #507  
Old 28th July 2013, 01:29 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by shunyuan View Post
-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.
Reply With Quote
  #508  
Old 28th July 2013, 01:47 PM
daninthemix daninthemix is offline
Member
 
Join Date: Dec 2012
Posts: 39
Default

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?

Last edited by daninthemix; 28th July 2013 at 01:51 PM.
Reply With Quote
  #509  
Old 30th July 2013, 10:10 PM
gamax92 gamax92 is offline
Junior Member
 
Join Date: Apr 2013
Posts: 26
Default

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.

Last edited by gamax92; 30th July 2013 at 10:36 PM.
Reply With Quote
  #510  
Old 30th July 2013, 10:37 PM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 146
Default

Quote:
Originally Posted by gamax92 View Post
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.

Quote:
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.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 09:19 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.