#151  
Old 19th September 2013, 12:31 PM
tony971 tony971 is offline
Member
 
Join Date: Jul 2013
Posts: 52
Default

Quote:
Originally Posted by tony971 View Post
I'm giving into the idea that the fullscreen issues are with my system specifically, but I can't figure out where the issue is. It exists in every GeForce driver I've reverted to and up through the latest beta. I'm wondering if its because it's being used as an HTPC and the tv it's plugged into has been set to native picture size. (I had to do this do get rid of overdraw on the desktop)
I just tried playing around with the tv picture size and that's definitely where the issue is. When I'm not running a rom, the options are full, theater wide, 4:3, and native. When a rom is running, the options are full, normal, or dot by dot. None of these work correctly, though. When I run fullscreen in PJ64 (which sizes correctly) the picture size options stay the same. So something winmupen does when implementing fullscreen changes the display type for my tv.
Reply With Quote
  #152  
Old 19th September 2013, 03:04 PM
tony971 tony971 is offline
Member
 
Join Date: Jul 2013
Posts: 52
Default

I looked up my tv manual and found what's going wrong. I use an HDMI cable with a 1080p tv. Typically, the screen formats as if it were a standard HDMI input. When winmupen goes fullscreen, it tries to run VGA, SVGA, XGA, WXGA, or SXGA signals through the HDMI cable. The tv can't process them correctly and causes the overdraw. This is why I keep getting problems. It's also why no one else has these problems, since very few people use HDMI with a TV for their monitor.

Last edited by tony971; 19th September 2013 at 03:10 PM. Reason: clarity
Reply With Quote
  #153  
Old 19th September 2013, 03:25 PM
tony971 tony971 is offline
Member
 
Join Date: Jul 2013
Posts: 52
Default

It also explains why only the resolutions matching those signals render for me. Every issue I'm having is because I'm running an HDMI when the fullscreen renders resolutions for VGA/DVI.
Reply With Quote
  #154  
Old 19th September 2013, 03:29 PM
the_randomizer's Avatar
the_randomizer the_randomizer is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Sep 2008
Location: USA
Posts: 1,136
Default

Quote:
Originally Posted by tony971 View Post
It also explains why only the resolutions matching those signals render for me. Every issue I'm having is because I'm running an HDMI when the fullscreen renders resolutions for VGA/DVI.
Interesting that HDMI would cause such rendering issues.
__________________
My rig:
CPU: Intel Core i7 4470 3.4 GHz to 3.9 GHz
Video card:: MSI nVidia GTX 970 4 GB GDDR5
OS: Windows 7 Professional 64-bit
RAM: 16 GB DDR3 SDRAM 10600
HDD: 2 x Western Digital 1 TB HDDs
Monitor: 23" Asus Full HD LED

Oh, and Snes9x > Zsnes in every way
Reply With Quote
  #155  
Old 20th September 2013, 07:40 PM
tony971 tony971 is offline
Member
 
Join Date: Jul 2013
Posts: 52
Default

Right? Well the fix is simple enough (in theory). The fullscreen mode just has to be written in such a way that the monitor resolution doesn't change with the video resolution. It's probably a lot more complicated than it sounds but internet videos are able to do it. That might also fix the menu bar graphics glitch when escaping fullscreen.
Reply With Quote
  #156  
Old 20th September 2013, 09:16 PM
the_randomizer's Avatar
the_randomizer the_randomizer is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Sep 2008
Location: USA
Posts: 1,136
Default

Quote:
Originally Posted by tony971 View Post
Right? Well the fix is simple enough (in theory). The fullscreen mode just has to be written in such a way that the monitor resolution doesn't change with the video resolution. It's probably a lot more complicated than it sounds but internet videos are able to do it. That might also fix the menu bar graphics glitch when escaping fullscreen.
I'd put the blame on the Mupen 64 developers since they wrote it or at least altered the plugin to work with the emulator. The GUI merely uses it, it makes no changes to the plugin's code.
__________________
My rig:
CPU: Intel Core i7 4470 3.4 GHz to 3.9 GHz
Video card:: MSI nVidia GTX 970 4 GB GDDR5
OS: Windows 7 Professional 64-bit
RAM: 16 GB DDR3 SDRAM 10600
HDD: 2 x Western Digital 1 TB HDDs
Monitor: 23" Asus Full HD LED

Oh, and Snes9x > Zsnes in every way
Reply With Quote
  #157  
Old 20th September 2013, 09:40 PM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

Quote:
Originally Posted by nintendo1889 View Post
I'd put the blame on the Mupen 64 developers since they wrote it or at least altered the plugin to work with the emulator. The GUI merely uses it, it makes no changes to the plugin's code.
If it doesn't happen with mupen64plus in general that's not the case (and even if it does happen, SDL is what's doing the resolution switching, it's SDL's fail (supposedly mitigated with SDL2, maybe try out a build built with it?)) and winmupen has its resolution options hardcoded in a few values, if your resolution happens to not be in that range, this screen adjustment must happen thus leading to weird shit happening

@tony can you confirm this does happen as well with a command-line launch of mupen64plus (preferably set to your native res)?
Reply With Quote
  #158  
Old 20th September 2013, 10:38 PM
tony971 tony971 is offline
Member
 
Join Date: Jul 2013
Posts: 52
Default

Quote:
Originally Posted by V1del View Post
If it doesn't happen with mupen64plus in general that's not the case (and even if it does happen, SDL is what's doing the resolution switching, it's SDL's fail (supposedly mitigated with SDL2, maybe try out a build built with it?)) and winmupen has its resolution options hardcoded in a few values, if your resolution happens to not be in that range, this screen adjustment must happen thus leading to weird shit happening

@tony can you confirm this does happen as well with a command-line launch of mupen64plus (preferably set to your native res)?
I'm actually pretty terrible with the command line. What I can confirm is that the frontend wxmupen64plus doesn't have the issue with their internal fullscreen mode. So it's not universal across M64P. Even if it is, a workaround has been found.
Reply With Quote
  #159  
Old 25th September 2013, 10:52 AM
Alajarvi84 Alajarvi84 is offline
Junior Member
 
Join Date: Sep 2013
Posts: 1
Default

How exactly is rice bad ? For me it is the only plugin that runs Conker BFD full speed with maximum resolution and without texture errors of any kind. The other ones are extremely buggy (GLN64+Glide64), i mean the textures (if there is even) stretch to hell with GLN64 and Glide64 misses a lot of textures + 2D objects are missing (like grass). Rice draws everything so good, its like playing N64 except HD The device is Note 10.1 N8020 and CM-10.2 20130209 Nightly (4.3JB)

Settingscwith rice are output:native, scaling:none, flicker:auto, limiter:no, skip:no, fast txt crc:no, fast txt loading:yes, filtering:yes, mipmap:no, screen update method:after drawn, enhancement:scale 2x, hires textures:yes.

Audio resampling:sinc (fastest)

Last edited by Alajarvi84; 25th September 2013 at 11:07 AM.
Reply With Quote
  #160  
Old 25th September 2013, 11:08 AM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 146
Default

You know, the Pokemon Snap red dot issue really makes me wonder how many of the bugs associated with Mupen64Plus actually come down to the core emulation itself or the plugins, seeing as how any plugin based on the Angrylion/MESS RDP code fixes it and makes that game fully playable (very slowly, but technically issue-free). I would love to see Angrylion's plugin ported for use with Mupen64Plus for this reason.
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 04:55 AM.


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