Original video mode

[GoogleCodeExporter]

What steps will reproduce the problem?
This is a known problem.  Sorta like the SNES9x GX, when 005 was released, 
the "Original" video mode made the Emulator IDENTICAL to the SNES Console 
itself.  This is exactly what the FCE Ultra GX needs, an "Original" video 
mode, so that it looks identical to the NES console itself.

What version of the product are you using?
FCE Ultra GX 2.0.2

Please provide any additional information below.
The current video modes are talored to a PC obviously.  Like I said, needs 
an "Original" video mode just like the SNES9x GX 005 has, and it will be 
identical to the NES console ifself.  Good Luck!

Original issue reported on code.google.com by b1715...@owlpic.com on 29 Sep 2008 at 7:14

[GoogleCodeExporter]

Original comment by dborth@gmail.com on 29 Sep 2008 at 7:17

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

[GoogleCodeExporter]

Original comment by dborth@gmail.com on 29 Sep 2008 at 7:20

• Changed title: Original video mode

[GoogleCodeExporter]

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 aroun...@adelphia.net on 3 Oct 2008 at 10:29

[GoogleCodeExporter]

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 Dr.M4...@gmail.com on 16 Oct 2008 at 11:03

[GoogleCodeExporter]

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 dborth@gmail.com on 17 Oct 2008 at 1:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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 axe...@gmail.com on 20 Oct 2008 at 3:00

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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 dborth@gmail.com on 20 Oct 2008 at 9:58

[GoogleCodeExporter]

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 axe...@gmail.com on 20 Oct 2008 at 10:14

[GoogleCodeExporter]

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 ekeeke31@gmail.com on 21 Oct 2008 at 8:51

[GoogleCodeExporter]

Done for the next version.

Original comment by dborth@gmail.com on 23 Oct 2008 at 9:30

• Changed state: Completed

[GoogleCodeExporter]

Original comment by dborth@gmail.com on 23 Oct 2008 at 9:31

• Changed state: Fixed

[GoogleCodeExporter]

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 ekeeke31@gmail.com on 24 Oct 2008 at 8:07

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by ekeeke31@gmail.com on 24 Oct 2008 at 8:08

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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 dborth@gmail.com on 25 Oct 2008 at 6:23

[GoogleCodeExporter]

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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 ekeeke31@gmail.com on 27 Oct 2008 at 9:32

[GoogleCodeExporter]

(should be) fixed in r125, please test it

Original comment by ekeeke31@gmail.com on 27 Oct 2008 at 2:33

• Changed state: Started

[GoogleCodeExporter]

Original comment by ekeeke31@gmail.com on 27 Oct 2008 at 2:33

• Changed state: Fixed

[GoogleCodeExporter]

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 dborth@gmail.com on 27 Oct 2008 at 10:38

[GoogleCodeExporter]

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 ekeeke31@gmail.com on 28 Oct 2008 at 8:48

[GoogleCodeExporter]

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 ekeeke31@gmail.com on 28 Oct 2008 at 8:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I just compiled and tested R127, original mode is fantastic.  No more pulsing 
pixels
on my CRT TV :)

Original comment by aroun...@adelphia.net on 29 Oct 2008 at 12:33

[GoogleCodeExporter]

Original comment by dborth@gmail.com on 19 Nov 2008 at 7:20

• Changed state: Completed