Thanks Wiimpathy.
I hope you consider an option to use a 240p video mode in the future.
Wiimpathy said:Regarding the video, I know about this problem. The fix for black screen is not good from the beginning. Moreover, I added a stupid code that widen and shift the screen.
It would be better if someone more serious than me, and who can test on new 16:9, do the video part(or maybe everything!).
I"ll do my best waiting for someone that want to help or take this project. Please give me some time cause I'd like to do other things too.
Thanks to eke-eke and tantric too.
I hope all of this doesn't prevent people from playing !
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.
/*** 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;
}
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 ... ?
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 ... ?
/* 240 lines progressive (NTSC or PAL 60Hz) */
static GXRModeObj TV_240p =
{
VI_TVMODE_EURGB60_DS, // viDisplayMode
512, // fbWidth
240, // efbHeight
240, // xfbHeight
(VI_MAX_WIDTH_NTSC - 640)/2, // viXOrigin
(VI_MAX_HEIGHT_NTSC/2 - 478/2)/2, // viYOrigin
640, // viWidth
478, // viHeight
VI_XFBMODE_SF, // xFBmode
GX_FALSE, // field_rendering
GX_FALSE, // aa
/* 224 lines progressive (NTSC or PAL 60Hz) */
/*static GXRModeObj TV_224i =
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.
It seems that the NEOGEO supports two resolution modes, one is 320 x 224 and the other is 304 x 224 (garou?)
61 Raster Vertical Position register . 3C0006H (read, word)
61 Raster Vertical Position register (read only)
Bits 0-2: When the automatic character feature is active, the
character number of the character displayed can be read
from here.
Bit 3: NTSC/PAL mode select *** =PC2 only ***
= 0 : PAL
= 1 : NTSC
Bit 7 : Read lV
Bit 8 : Read 2V
Bit 9 : Read 4V
Bit 10 : Read 8V
Bit 11 : Read 16V
Bit 12 : Read 32V
Bit 13 : Read 64V
Bit 1'4 : Read 128V
Bit 15 : Read 256V (Set. to " 1 " during display.)
251 NEO-GEO mode 380000H, bit 7
0 : NEO-GEO
1 : MULTI-VIDEO SYSTEM
6. When designing for NEO-GEO, important characters should not be placed within
the left most and right most 16-dot areas, nor' in the top and bottom 8-dot areas.
These areas may not be visible on some television monitors.
7. For Multi-Video Systems, 8 dots on both the left and right sides should be
masked by black characters, using the FIX display mode.
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.
Test this if you want :
http://dommagemais.f...eoCD-Wii-ph.zip
Source
http://dommagemais.f...-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.
It's not rocket science. The Virtual Console version of Neogeo games already looks perfect.
Ok, with lovely black border :
/*** 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;
}
The top screen lacks some info that you can see for example on Ninja commando for bosses.
However, viYOrigin should be changed maybe to non academic values.
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 ?
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 !