Git Product home page Git Product logo

Comments (28)

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024

Original comment by [email protected] on 29 Sep 2008 at 7:17

  • Changed state: Accepted
  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024

Original comment by [email protected] on 29 Sep 2008 at 7:20

  • Changed title: Original video mode

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
I completely agree, the new video modes in snes9x gx 005 are much better. right 
now
it seems as if fceugx is displaying the graphics in a way that looks similar to
snes9x gx 005's unfiltered mode.  I think adding the same video modes that are 
in
snes9x gx 005 would have an amazing effect on the overall feel of the emu.  

Original comment by [email protected] on 3 Oct 2008 at 10:29

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
Just wondering by "Original Video Mode" is this like a palette or some sort of 
video
filter which I haven't heard of before?

If it is a palette, the default one and crashman's are quite accurate but I 
think
that the accurate.pal file included with JNES 1.0.1
(http://jabosoft.com/?categoryid=1) and AspiringSquire's
(http://board.zsnes.com/phpBB2/viewtopic.php?t=3298&postdays=0&postorder=asc&sta
rt=0)
are better (although the comparison I did may not be the best since it was on
different screens but they were closer to an actual NES and the VC).

Original comment by [email protected] on 16 Oct 2008 at 11:03

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
The original video mode would be outputting to the TV at the native NES 
resolution - 
224 x 256 or whatever it is. Right now what we do is output at 640x480 and 
upscale 
the image to this size. Then, anti-aliasing is applied to smooth out the rough 
edges. For my TV, it works great. But some people get a really poor picture 
this 
way. 

Original comment by [email protected] on 17 Oct 2008 at 1:42

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
[deleted comment]

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
The TV sets that suffer more from the upscaling already applied are the CRT 
TVs, as 
much as they suffer from Unfiltered mode in SNESGX. 

I can't tell for sure but this might be related to the use of interlaced scan  
instead of progressive scan. If this were the case, then also the 
non-progressive 
LCD screens would suffer from the same.

For progressive scan LCD screens this original filter could not be required, 
just as 
the unfiltered mode looks good enough on them. I'm assuming you, Tantric, have 
one 
of these TV sets. For non-progressive sets it really is a must though.

Original comment by [email protected] on 20 Oct 2008 at 3:00

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
[deleted comment]

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
Actually I should say that since my TV doesn't support 'original mode', I don't 
think I'll be the one to do this. It's really not that hard to do - but I have 
no 
way to test any implementation I do.

Original comment by [email protected] on 20 Oct 2008 at 9:58

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
Who's the one who helped with original mode on Snes9x GX? The implementation 
should 
be very similar. I don't remember if it was michniewski, but maybe if eke-eke 
has 
the time and wants to, he could help with this...

Original comment by [email protected] on 20 Oct 2008 at 10:14

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
For the record:

1) these are not custom filters, these are custom video mode natively supported 
by
the GC/Wii Video hardware: pretty like 480i,576i or 480p, except that these are
low-resolution video modes used in old console also: 240p and 288p

They look better because the image is output in a progressive way (no 
interlacing),
like 480p but with half the available vertical resolution, resulting in tiny
"scanlines" between active lines.

2) Tne Snes9x "unfiltered mode" does not look good on TV because the deflicker 
filter
(video hardware feature) is also disabled in this mode. This vertical filter 
should
always be enabled when using interlaced video modes, otherwise the screen will
flicker: the reason is that, in 480i(576i), a single line will ALWAYS refresh at
30hz(25Hz) only. Deflicker is not required in low-res "Original" TV mode since a
single line refresh at 60hz(50hz) and there is no interlace.

3) There is absolutely no anti-aliasing applied in ANY of the emulators. What is
applied is bilinear filtering by the GX hardware when rendering the texture 
into the
framebuffer (especially when the originl image need to be upscaled). 
Apparently, this
filter is also disabled in "unfiltered" mode, resulting is cripser graphics. It
should be disabled in "Original" mode for the same reason but this can cause 
some
graphic patterns (letters or group of vertical lines) to be asymetric because 
the
original width (256 pixels) is not a full divider of the resulted width (640 
pixels)
and a filter is required when upscaling. 

4) Anti-aliasing could be implemented (this is natively supported by hardware) 
but it
requires changing the rendering mode and deeper modifications (the EFB height 
and
pixel format need to be changed): you can look at the current SVN code in 
genplus to
see an implementation. However, this is not working great atm (single line 
glitch and
very blurry picture) so I consider removing it, bilinear filtering + deflicker 
is
still the best picture you can get with interlaced video modes.

Original comment by [email protected] on 21 Oct 2008 at 8:51

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
Done for the next version.

Original comment by [email protected] on 23 Oct 2008 at 9:30

  • Changed state: Completed

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024

Original comment by [email protected] on 23 Oct 2008 at 9:31

  • Changed state: Fixed

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
The video scaling when original mode is selected is not correct (screen is 
somehow
cut in half), I will have a look at it

Original comment by [email protected] on 24 Oct 2008 at 8:07

  • Changed state: Accepted

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024

Original comment by [email protected] on 24 Oct 2008 at 8:08

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
Hi! I'm using last revision, r120, and I have found an issue with the 
preferences and
the video modes.

I'm using a PAL Wii 3.2E 480i with oficial nintendo RGB cable. Timming is set 
to NTSC
and I'm using [U] ROMs

Load FCEUGX with Homebrew Channel b8, go directly to the preferences menu and 
reset
them (also work with a clean installation, without FCEUGX.xml) then load a game 
(I
have tested with Super Mario Bros [U]) the game starts but the game looks thin 
with
two black borders by each side (like 16:9 correction, maybe?), then press home 
on
wiimote and go to the preferences menu again and set the video mode to Original,
press B a few times to go back to gameplay, the video is like hyper-zoomed.

If you press home again and then B again on the wiimote, everything is correct. 
But
in the way the video output can make you crazy with the preferences.

Also one more point, while going to the menu and back to gameplay sound poping 
issue
is there. And the Game Menu option is messed up with the reset system option 
and lead
you back to the wii main menu.

Sorry for my english.

Regards.

Original comment by pakitovic on 25 Oct 2008 at 5:02

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
I can confirm this does happen. Also happens with 'Zoom' function. Sometimes it 
works perfectly. But sometimes it doesn't change the zoom until after you go to 
menu 
and back to game. I'm having the same sorts of issues with VBA GX, although 
currently only with GB games and not GBA games. I've committed a change that 
improves the behavior a bit, but not a total solution - even calling 
UpdateScaling() 
every frame doesn't fix the problem.

Original comment by [email protected] on 25 Oct 2008 at 6:23

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
Hi! I have just compiled r121 and the issue still remains the same :S

Regrads.

Original comment by pakitovic on 25 Oct 2008 at 11:22

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
[deleted comment]

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
I cannot test and commit code atm (I am lurking from work place ;-) ) but you 
will
need to recall draw_init() each time you modify the square[] table or changes to
aspect ratio won't apply.

Also, I am not sure what you wanted to do with updateScaling value set to 5 and
decremented ? Since the NES screen size is constant (contrary to SNES or 
Genesis),
the UpdateScaling() function only need to be called when the user modified 
something
in video options, that is, when leaving the Menu (or when changing the zoom 
level)


Original comment by [email protected] on 27 Oct 2008 at 9:32

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
(should be) fixed in r125, please test it

Original comment by [email protected] on 27 Oct 2008 at 2:33

  • Changed state: Started

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024

Original comment by [email protected] on 27 Oct 2008 at 2:33

  • Changed state: Fixed

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
the updateScaling counter was so that UpdateScaling() was called for the first 
X 
frames rendered after going back to the game. It's strange, but what I've found 
is 
that if you just do it for one frame, scaling doesn't update properly. I tried 
with 
your changes, and the same problem happens. Same thing goes for zoom - I set it 
to 
do it 5 times (for 5 frames), and zooming works better. Set updateScaling = 1 
everywhere, and give it a thorough testing and you should see what I mean. 
Sometimes 
going in/out of the menu, loading a second or third game will cause/fix the 
issue
(s). This issue applies to: 16:9 correction, zooming, reset zoom. 

Basically, it works fine right now being called 5 times. Just not sure why this 
is 
required to be set to > 1 to make it work. In theory, it should only need one 
call 
after exiting the menu, as you suggest.

Original comment by [email protected] on 27 Oct 2008 at 10:38

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
That's indeed very strange, and I didn't find any solid reason in the code :-/

in other emulators, changes happen immediately so either it has something to do 
with
Video Threading which is still not well masterized, or it is side-effect of 
something
worst

Original comment by [email protected] on 28 Oct 2008 at 8:48

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
maybe a stupid idea: try calling GX_Flush() after Update_Scaling(), and in 
ResetEmu,
call it *before* reconfiguring the VIDEO and doing the WaitVSYNC stuff

Original comment by [email protected] on 28 Oct 2008 at 8:52

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
[deleted comment]

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024
I just compiled and tested R127, original mode is fantastic.  No more pulsing 
pixels
on my CRT TV :)

Original comment by [email protected] on 29 Oct 2008 at 12:33

from fceugc.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 13, 2024

Original comment by [email protected] on 19 Nov 2008 at 7:20

  • Changed state: Completed

from fceugc.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.