well, it should be already there, set the Video Mode to progressive, though the choice of naming is a little bit confusing, it's not 480p but 240p.
maybe it should be renamed to "ORIGINAL" or "NON-INTERLACED" like on other emulators.
Wiimpathy said:
, I took a look at the video code and a few things seemed odd to me, while comparing with other emus:
1) you force EURGB_60 TV modes when using interlaced/progressive but I am not sure if PAL60 is fully compatible with NTSC displays (should be but I think it's better to use the mode returned by VIDEO_GetPreferedMode then apply _DS, _INT or _PROG on it)
2) neogeo always output 320x224 pixels but your render modes seem to use odd values like 512 pixels for the EFB width (upscaled to 640 at output), 240 lines for FB height in "progressive" mode, upscaled to 478 lines at output, also 478 lines in interlaced mode. It seems to me this is going to introduce unneeded scaling and blurry filtering, using 640x224 with VI_HEIGHT=448 for "progressive" and 640x448 with VI_HEIGHT=448 for "interlaced" should be better. Off course, you must also change the "YOrigin" values as well according to the new VI_HEIGHT, and change the HASPECT/VASPECT values to keep the original aspect ratio unscaled.
3) i don't get all these stuff with projection mode, camera view and matrix transformations, seems utterly complicated to me to display a simple 2D texture, though I a not sure to understand this part of GX very well anyway and all emus seem to use different methods. If someone understaInd how this works (probably use similar concepts as OpenGL btw), I'd appreciate a quick lesson
Thank you Jacobeian for looking at the video code.
The video options are called this way because I thought it was closer to reality, I'm not sure it's a real original mode.
To be honest, I tried my best to understand GX by myself, and of course looked at the other emulators.
After some tests(and headache too!), I erased some parts and didn't check well last source. Therefore, the video part is some kind of a draft(a mess?).
1) The TVMODE_EURGB60 should be the same for NTSC and PAL60(which is my case). The problem would be more for PAL50 and bad sync with sound and framerate.
2) Here, the headache starts again. Well, neogeo cd isn't always 320x224 but it's sometimes at 304x224.
But yes, you're surely right about these values I made some mistakes and forgot to change some(EFB for ex.)
I'll try it again later. I'm not sure how to change haspect/vaspect correctly and to have a good aspect ratio though.
3) I might need some lessons too! For example the GX_InitTexObjLOD which is used for the Level Of Details and allows clearer textures. When activated (in the emu with Filter on/off) in progressive mode it produces some waves when moving in y axis.
What is causing this ? A bad video mode, bad values for viHeight etc ... ?
To sum up, I"ll take your advices and see if I"ll have the patience to understand more GX video to improve this(before Wii 3!). I repeat myself but would be better that someone who already know this part do it, that would be faster.
I hope all of this doesn't prevent people from playing !
The video options are called this way because I thought it was closer to reality, I'm not sure it's a real original mode.
To be honest, I tried my best to understand GX by myself, and of course looked at the other emulators.
After some tests(and headache too!), I erased some parts and didn't check well last source. Therefore, the video part is some kind of a draft(a mess?).
1) The TVMODE_EURGB60 should be the same for NTSC and PAL60(which is my case). The problem would be more for PAL50 and bad sync with sound and framerate.
2) Here, the headache starts again. Well, neogeo cd isn't always 320x224 but it's sometimes at 304x224.
But yes, you're surely right about these values I made some mistakes and forgot to change some(EFB for ex.)
I'll try it again later. I'm not sure how to change haspect/vaspect correctly and to have a good aspect ratio though.
3) I might need some lessons too! For example the GX_InitTexObjLOD which is used for the Level Of Details and allows clearer textures. When activated (in the emu with Filter on/off) in progressive mode it produces some waves when moving in y axis.
What is causing this ? A bad video mode, bad values for viHeight etc ... ?
To sum up, I"ll take your advices and see if I"ll have the patience to understand more GX video to improve this(before Wii 3!). I repeat myself but would be better that someone who already know this part do it, that would be faster.
I hope all of this doesn't prevent people from playing !
I don't think slightly jacked-up video is going to stop anyone from using it, so don't sweat it.
And thanks again
Where do you got that idea from ? No, I think the resolution is always 320x224 and anyway, "update_video" function is always called with these values for vwidth and vheight , which is what counts for GX.
It might be possible that Neo Geo Video chip has a feature that games can use to mask the two 8-pixels column on the left and on the right of the screen, this was very common at that time (I think NES and SMSion (which define th do this as well) to hide objects coming from outer screen space, but no the resolution is fixed and this masked column is part of the screen.
EDIT: Seems like there is a some confusion on many websites. The resolution (which also defines the aspect ratio) is constant in the emu (320x240), it's just that the 8-pixels columns on left and right sides are always blanked so you got some kind of letter-boxed aspect on TV unless you stretch the display with GX. See this code in video.c:
Code:
/*** Do clipping ***/
for (count = 0; count < 224; count++)
{
for (sx = 0; sx < 8; sx++)
video_line_ptr[count][sx] = video_line_ptr[count][sx + 311] = 0;
}Now the strange thing is that the emulator do this for ALL games, and I would have thought it's a switchable feature of Neo Geo hardware.
Maybe some games do not mask these pixels ?
Are Neo Geo games letter-boxed on a TV ? I don't think so, which mean those 304 pixels occupy all the screen. To be accurate, we should therefore upscale those 304 pixels to full screen on Wii, so 84 for HASPECT is fine (320/304*80 = 84) and for VASPECT values, try with 56 (224/4).
generally the cause is scaling artefacts (for example when scaling 224 lines to 478, the ratio is not an integer) when filtering is disabled, so you better use integer ratio for scaling (320->640, 224->448).
I was about to report this exactly same issue. Like Jacobeian already said, it's a scaling problem. You need to upscale the horizontal resolution using an interger value (scaling the horizontal resolution by a factor of 2).
Also, like Jacobeian said before, the values used to tweak the resolution are wrong (see below).
There is also this part of the code that seems odd.
224 lines progressive doesnt make sense. The Wii is only capable of 240p (not 224p) and there is already a section of the code to handle 240p.
I also need to mention there is a big overscan area in the horizontal resolution, eating a considerable amount of the screen. I adjusted my TV, using others emulators as a reference, to eliminate the overscan area, but with this NeogeoCD emu the overscan is still there.
In the end, the vertical resolution that needs to be used is definitely 240p (without any scaling). I know that games use x224 - but the resolution of the game itself and how the console output this resolution to the screen are two different things. When displaying the picture on TV, the x224 pixels will occupy the entire height of the screen, and the difference between 240 and 224 will be 8 black pixels on the top and botton of the screen.
Now, the horizontal resolution is a bit trick. Neo-Geo games were made with 2 different resolutions - 320x224 and 304x224, but the console itself always display the picture using 320x240. So, if a game is using 320 pixels, it will fill all the screen, but if it's using only 304 pixels, it will show 8 black pixels on each side of the screen.
So, I think the best is to configure the Wii's active width to 640 and let the GPU upscale the picture using an integer value of 2.
Then, some games will fill all the screen, and others will not - but it's something very minor. I don't think it's worth to stretch the screen and mess with the aspect ratio just to fill a small gap.
Exactly.
However, you can define a vertical height of 448 lines (224 in non-interlaced mode) and got the Wii video chip centers it for you. No need to render all 240 lines.
224 (non-interlaced) / 448 (interlaced) lines is generally the height of visible area on CRT TV, i.e full screen. This applies to Neo Geo but Wii as well, there should not be any upscaling in the vertical direction.
Are you sure about that ? I found a tech document that says the internal screen dimension (in Video RAM) is 320 pixels wide but the Neo Geo only outputs the 304 middle ones.
Now, most games (if not all, since the emulator itself does that by default, with no way to change it) seem to use a 304x224 resolution anyway and I don't think I remember seeing any Neo Geo games with black bar on screen sides, which means Neo Geo pixels are a little wider than twice a Wii pixel, i.e 304 "Neo Geo" pixels = approx. 640 "Wii" pixels (it might be a little wider, since 640 Wii pixels is not exactly full-screen)
Here is the document I found (check Video section):
http://furrtek.free....eo/NeoGeoPM.pdf
You can notice there is mention about resolution:
but then there is no indication how the game can switch between the 2 modes, and the emulator does not emulate that either. So I assume this was just a rumor or a confusion with the size of the internal screen where tiles/sprites are placed.
EDIT:
Or maybe the emulator is just wrong and some games (?) use the whole area and these pixels are meant to be displayed.
I found that more official document that indeed seems to imply 320x224 is the display area:
http://www.hardmvs.c...ammersGuide.pdf
Also seems like there is a PAL mode where the size of display is 320x256 (I guess this is to reduce the size of vertical borders since PAL TV signal has more lines than NTSC one)
and finally this:
So my first idea was right then, the resolution is 320 pixels and games can choose to hide 8 pixels on both side by selecting the FIX display mode (?).
Seems like this emulator is always forcing this mode, I don't think this is accurate and the code I showed before probably need to be conditional and not automatic.
Anyway, that means the 320x224 neogeo screen needs to be upscaled on Wii to 640x224 (non-interlaced) or 640x448 interlaced)
And HASPECT/VASPECT should be 80/56.
The resolution is 320 pixels, but due to a different dot clock, I guess 304 pixels in a real console occupy the whole screen.
Anyway, I think 99% of the games uses only 304 pixels. So, the fact that this emulator is always hiding 8 pixels on each side is not a big deal. I just don't know if the emulator is actually rendering these 16 black pixels or not. If it's, then upscaling to 640 pixels is fine, but if it isn't, wouldn't 608 pixels be a more correct value?
Anyway, I think 99% of the games uses only 304 pixels. So, the fact that this emulator is always hiding 8 pixels on each side is not a big deal. I just don't know if the emulator is actually rendering these 16 black pixels or not. If it's, then upscaling to 640 pixels is fine, but if it isn't, wouldn't 608 pixels be a more correct value?
Actually, it seems that games are supposed to put black tiles themselves, it's apparently not done by hardware automatically like with other consoles .
And so it should not be forced black by the emulator as it is actually (and yes it seems it renders all pixels and THEN it writes $00 i.e black to the borders)
You might be right about the pixel clock, maybe 304 pixels is what is supposed to be fullscreen and the 320 pixels are only meant to be used with special display with wider viewable area, hence why most games don't use it.
Is that verified btw ? I really don't know what to to think about that, we should check if there is something meant to be displayed in those borders, when the emulator does not force them black.
No, the emulator renders 320 pixels, with 8 pixels on the left and on the right blacked.
The output buffer is then passed to GX for Wii rendering and its size is always 320x224.
So if those 304 middle pixels are supposed to be fullscreen, it means the 320 pixels wide output buffer shouldn't either be upscaled to 608 or 640 pixels but wider, approx. 320x640/304 = 674 pixels so that the 8-pixels borders does not even appear on screen (if we consider 640 Wii pixels is fullscreen). In this case, a value of 84 (~674/8) for HASPECT is correct then.
And so it should not be forced black by the emulator as it is actually (and yes it seems it renders all pixels and THEN it writes $00 i.e black to the borders)
You might be right about the pixel clock, maybe 304 pixels is what is supposed to be fullscreen and the 320 pixels are only meant to be used with special display with wider viewable area, hence why most games don't use it.
Is that verified btw ? I really don't know what to to think about that, we should check if there is something meant to be displayed in those borders, when the emulator does not force them black.
No, the emulator renders 320 pixels, with 8 pixels on the left and on the right blacked.
The output buffer is then passed to GX for Wii rendering and its size is always 320x224.
So if those 304 middle pixels are supposed to be fullscreen, it means the 320 pixels wide output buffer shouldn't either be upscaled to 608 or 640 pixels but wider, approx. 320x640/304 = 674 pixels so that the 8-pixels borders does not even appear on screen (if we consider 640 Wii pixels is fullscreen). In this case, a value of 84 (~674/8) for HASPECT is correct then.
Test this if you want :
http://dommagemais.free.fr/progs/wii/NeoGeoCD/Tests/NeoCD-Wii-ph.zip
Source
http://dommagemais.free.fr/progs/wii/NeoGeoCD/Tests/NeoCD-Wii-ph-src.zip
Thank you for theory, that's interesting. The progressive mode doesn't suffer anymore of "beach" effect but the acceptable VASPECT is 58. However, viYOrigin should be changed maybe to non academic values.
The top screen lacks some info that you can see for example on Ninja commando for bosses.
Anyway, this is just a test. And as always if you feel comfortable with GX video and Neo hardware, feel free to take the code improve/correct/complete it and release it for players.
Vigi__lante, when the code is between /* and */ it is commented and not really used, that was just for testing and I didn't erase it.
http://dommagemais.free.fr/progs/wii/NeoGeoCD/Tests/NeoCD-Wii-ph.zip
Source
http://dommagemais.free.fr/progs/wii/NeoGeoCD/Tests/NeoCD-Wii-ph-src.zip
Thank you for theory, that's interesting. The progressive mode doesn't suffer anymore of "beach" effect but the acceptable VASPECT is 58. However, viYOrigin should be changed maybe to non academic values.
The top screen lacks some info that you can see for example on Ninja commando for bosses.
Anyway, this is just a test. And as always if you feel comfortable with GX video and Neo hardware, feel free to take the code improve/correct/complete it and release it for players.
Vigi__lante, when the code is between /* and */ it is commented and not really used, that was just for testing and I didn't erase it.
Well, Neogeo games was meant to be used with an arcade monitor, which you can easily adjust the vertical and horizontal size of the screen (unlike a regular TV). So, for the few games that use 320 pixels, the arcade operator can resize the screen in order to display all the pixels.
MAME is very accurate about this kind of stuff. This is how Baseball Star looks:
Metal Slug displays garbage pixels in that area (see botton right):
Picture from Metal Slug running from the original hardware (arcade monitor) displaying the same area:
http://imageshack.us...16/img4149.jpg/
While this could be correct, there is no point to use a 240p video mode if the horizontal resolution is been upscaled using a non-integer value. Unless you use bilinear filtering, it will display artefacts - but if you turn on the filtering it will blurry the picture, negating all the good aspects of using 240p.
So, the 240p mode should use 640 pixels, and not 674.
It's not rocket science. The Virtual Console version of Neogeo games already looks perfect.
Thanks!
But it still shows lots of artefacts due to the non-integer scaling. It would be great if you could upload another version using 640 pixels on the viWidth, instead of 678.
Thanks for the clarification (and for screenshots). Just to be sure, do we have capture of the same game running on TV (not arcade monitor ?). Maybe this MVS/NEOGEO mode setting is changing the dot clock ?
I admit I never tried a Neo geo game on VC. So you mean Metal SLug on VC has these black border displayed but not Baseball Stars 2, right ?
That was expected, using 640 (320 x 2) was going to show all 320 pixels and therefore those black pixels.
But it seems that's correct and proper aspect ratio, according to Vigilante screenshots so better leave it that way.
Well, to be even more accurate, you should remove that part from video_drawscreen1 in video.c:
Code:
/*** Do clipping ***/
for (count = 0; count < 224; count++)
{
for (sx = 0; sx < 8; sx++)
video_line_ptr[count][sx] = video_line_ptr[count][sx + 311] = 0;
}According to the above screenshots, clipping is done by game, not automatically done by the video hardware, see how the bottom left tile is still displayed in Metal Slug ?
Anyway, you can keep fullscreen as an option for games that clip those columns, keep with fb_width=640 and vi_width=678, the filtering effect seems less noticeable than bilinear filtering done by GX when fb_width/HASPECT/vwidth is non-integer. According to docs I've read, the video hardware is also able to apply horizontal upscaling, but the filter is different (and might be configurable ?) Off course, HASPECT must keep in side with fb_width (fb_width / 8 i.e 80)
That's because you are using 58 for VASPECT. Try keeping it equal to 448/8 i.e 56, otherwise GX is going to upscale the original image with non-integer ratio and applies bilinear filtering in vertical direction this time.
If that does not work with this value, then maybe it's because of the perspective/matrix projection used, I admit I have some trouble understanding these and this might change the way the 320x224 texture is rendered to GX buffer (zoomed ?). According to the same docs I've read (hum), you can use "orthogonal" projection instead of perspective, which seems a better choice for 2D flat images. But I really don't know how to use this, maybe looking at some other homebrew code would help ?
There isn't any "academic" value, unless you don't want the image to be centered on screen:
viYOrigin should always be set to (VI_MAX_HEIGHT - viHeight) / 2 in interlaced mode and (VI_MAX_HEIGHT/2 - viHeight/2) / 2 in non-interlaced mode
viXOrigin should always be set to (VI_MAX_WIDTH - viWidth) /2
So in the previous code you posted (with viWidth=678), you should fix viXOrigin as well.
Last thing, the horizontal scaling should be the same in non-interlaced or interlaced mode, there is no point in having 640 for one and 678 for the other, it's just vertical timings that change between those modes (fb_height =vi_height /2 in non-interlaced mode)
I'm sorry, I have no mean to test code on Wii right now so I would not post updated sourcecode/version but changes should not be difficult to make ;-)
The problem is when GX_InitTexObjLOD applied on progressive mode with a vaspect other than 58, waves effect is back.
I don't know why, try it and you'll see the difference.
I see what doc you're talking about... Not sure if there's a huge difference with guOrtho and GX_LoadProjectionMtx.
That comfirms one thing, it will take a long time to understand. Maybe, you're motivated to do it...
I don't know why, try it and you'll see the difference.
I see what doc you're talking about... Not sure if there's a huge difference with guOrtho and GX_LoadProjectionMtx.
That comfirms one thing, it will take a long time to understand. Maybe, you're motivated to do it...
I don't see any black borders on my TV. Unfortunately, I still see video artefacts. The GPU is still upscaling the picture using a non-integer value, but with my limited knowledge I can't point exactly what is wrong.
In fact, the version before this one, that was using a viWidth of 678, was cutting a good amount of the picture even for games that have 304 pixels as the horizontal resolution.
So, with this last version, using a viWidth of 640, playing games that use 304 pixels, I see no black bars, there are no cuts and the picture fill all the screen.
There are a few others bugs with the video code, for example:
- if you select to turn on the filter, you are actually turning it off (it's inverted).
- when you first start the game with the filter "turned off", the filter will be turned on unless you bring the menu and return to the game. If you load a new game, the new game will be started in interlaced mode unless you bring the menu and return to the game.
For Metal Slug, there are no visible black borders been displayed on the VC version, just like Neo-CD Wii when using a viWidth of 640.
I also tested an injected rom of Baseball Stars 1 and you can't see all 320 pixels , but they are there, hidden by the overscan. That's probably what happens on the real console.
BUT, when playing Baseball Stars 1 on Neo-CD Wii these pixels are completely cuted, they are not there, not even covered by the overscan area. They are not displayed at all.
That sure is a wrong behaviour of the emu.
Alright, then, I made the changes you suggested (and others) that I actually tested on wii and it seems at the moment nothing's perfect.
Right now, for me it's "plein le cul" that you might translate in "a little fed up with it" more politely.
Meanwhile, I"ll let you elaborate theories and hopefully we"ll have something good in the future.
I just want to remind that the black screen issue was "fixed" in video.c and it surely affects the accuracy of emulation. I hope someday someone will find the cause of this, I'm curious to know what it is.
Have fun and good luck !
Right now, for me it's "plein le cul" that you might translate in "a little fed up with it" more politely.
Meanwhile, I"ll let you elaborate theories and hopefully we"ll have something good in the future.
I just want to remind that the black screen issue was "fixed" in video.c and it surely affects the accuracy of emulation. I hope someday someone will find the cause of this, I'm curious to know what it is.
Have fun and good luck !
If I have to guess, I would say the problem is with the vertical resolution itself.
Why the efbHeight and xfbHeight are using 224 instead of 240? Why the viHeight is using 448 instead of 480? I don't know.
The 240p code of Mednafen-Wii is using 240 pixels, not 224, and it's working fine.
http://code.google.com/p/wii-mednafen/source/browse/trunk/SDL/src/video/wii/SDL_wiivideo.c?spec=svn35&r=35
I also see a lot of screenshots from Neo Geo emulators, like the one below, where you can see it's using 320x240 with borders around the picture. In that case, using 224 would be wrong.
Let me know what you guys think.
-
Xdqwerty
what are you looking at?
-
@
AncientBoi:
And a part of my immediate family passed also. Sending my good suit to the cleaners for the funeral Saturday -
-
-
-
-
-
@
Xdqwerty:
@SylverReZ, may I ask you something? What are your favorite animes? (Aside of serial code lain)
-
-
@
Xdqwerty:
Mines are all the dragon ball animes. Im also enjoying Fullmetal alchemist and my hero academia+1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
