You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't know if it's a bug or not, but I would really appreciate if I could get some help on this one.
First time I tried OJ for Wii I noticed that the video output doesn't run in 240p.
And it doesn't seem to have any predefined support for non-interlaced 320x240 (240p, single field framebuffer, no field flipping).
Neither does ogc-sdl1.2 from what I can see, but libogc does. I play on a crt and the interlacing is at least one part that makes it rather blurry. Which is why I'm here.
As a back story I don't know cmake, c/c++ (I can still follow along and figure out most things)
and I certainly don't know SDL or libogc. Not to mention the OJ src.
Ex Java programmer, but haven't coded since 2017 so it's a lot to take in.
But from a lot of guess work, grep use, testing and "just" reading the source code I think I've been able to piece a bit together so far.
The biggest problem is that every time I want to test something I have to physically move my sd card back/fort to a real Wii w/o a debugger in place so it gets tedious.
At first I thought I would have to create a custom low level framebuffer and copy everything from the SDL_Surface screen/canvas (as it's called when using SDL2). Testing and digging deeper I realized this is not the way I want to go forth considering my dev environment.
ogc-sdl1.2 makes use of said GXRModeObj so I thought I could just change the mode, re-configure and flush the changes.
That works! Doing so I get a 240p single field framebuffer with no interlacing in place.
Instead everything drawn seem to be vertically stretched/scaled/offset and I have no idea how to fix it.
I've tried different combinations of matching the width/height/origin members from above with OJ's definitions and it's call to SDL_SetVideoMode() in Video::reset():
(OJ/video.h)
The fullscreen flags don't seem to be the issue so I'm thinking it's perhaps all draw calls from levels/scenes and menus?
I've built the project with -DSCALE=OFF so it shouldn't be the scaling options available (not available in this case) in that regard that are causing it.
VI_NTSC and VI_NON_INTERLACE are both set to 0 in the same file, but
rmode returned from VIDEO_GetPreferredMode(NULL) has viTVMode set to 20.
If I understand correctly bit shifting to the left by 2 above would result in (fmt * 4) + mode.
That would equal 0? VI_PROGRESSIVE is set to 2 so I'm wondering if the video mode actually set is one from the TVNtsc480Prog definition. If that in turn creates a mismatch somewhere. I am using a component cable after all.
Sorry if this is confusing to read. Just trying to cover everything I've tried and I really am trying.
My set240p() function currently only does this:
I call it in Video::reset() after the SDL_SetVideoMode() function.
EDIT:
Went ahead and installed homebrew channel in Dolphin (can't run the oj.dol otherwise) and interestingly
when I enable the setting below the height is fixed. So it should be a simple mismatch somewhere?
(Realized that if you place the game data at the root of a virtual SD card mounted in Dolphin you can run .elf or .dol files directly w/o HBC to get printf calls in the emu logs.)
EDIT SUCCESS:
Holy sh*t - I think I solved it. I don't fully understand the relationship between the efb, xfb, vi, SDL dimensions and the scaling that occurs, but looking at the libogc example (devkitpro/examples/wii/graphics/gx/neheGX/lesson01) the following function calls caught my interest:
//Sets an appropriate y scale factor based on the actual efb and xfb height
//Needed for proper xfb presentation
yScale = GX_GetYScaleFactor(rmode->efbHeight,rmode->xfbHeight);
//Calculates the xfb height (the final output height presented to/used by the screen) in pixels
xfbHeight = GX_SetDispCopyYScale(yScale);
//Controls the region of the efb that should be copied into the xfb.
//In this case the entire efb
GX_SetDispCopySrc(0,0,rmode->fbWidth,rmode->efbHeight);
//Sets the width and height of the final xfb copy being presented on screen
//Now corrected for efb heights specified in the GXRModeObj presets
GX_SetDispCopyDst(rmode->fbWidth,xfbHeight);
Meaning ogc-sdl1.2 just assumes the height of the efb and xfb is always 480 pixels?
The text was updated successfully, but these errors were encountered:
I don't know if it's a bug or not, but I would really appreciate if I could get some help on this one.
First time I tried OJ for Wii I noticed that the video output doesn't run in 240p.
And it doesn't seem to have any predefined support for non-interlaced 320x240 (240p, single field framebuffer, no field flipping).
Neither does ogc-sdl1.2 from what I can see, but libogc does. I play on a crt and the interlacing is at least one part that makes it rather blurry. Which is why I'm here.
As a back story I don't know cmake, c/c++ (I can still follow along and figure out most things)
and I certainly don't know SDL or libogc. Not to mention the OJ src.
Ex Java programmer, but haven't coded since 2017 so it's a lot to take in.
But from a lot of guess work, grep use, testing and "just" reading the source code I think I've been able to piece a bit together so far.
The biggest problem is that every time I want to test something I have to physically move my sd card back/fort to a real Wii w/o a debugger in place so it gets tedious.
At first I thought I would have to create a custom low level framebuffer and copy everything from the SDL_Surface screen/canvas (as it's called when using SDL2). Testing and digging deeper I realized this is not the way I want to go forth considering my dev environment.
Instead I found that libogc has a predefined struct TVNtsc240Ds:
(https://github.com/devkitPro/libogc/blob/master/libogc/video.c)
ogc-sdl1.2 makes use of said GXRModeObj so I thought I could just change the mode, re-configure and flush the changes.
That works! Doing so I get a 240p single field framebuffer with no interlacing in place.
Instead everything drawn seem to be vertically stretched/scaled/offset and I have no idea how to fix it.
I've tried different combinations of matching the width/height/origin members from above with OJ's definitions and it's call to SDL_SetVideoMode() in Video::reset():
(OJ/video.h)
The fullscreen flags don't seem to be the issue so I'm thinking it's perhaps all draw calls from levels/scenes and menus?
I've built the project with -DSCALE=OFF so it shouldn't be the scaling options available (not available in this case) in that regard that are causing it.
One thing that bothers me currently is the following definitions used for GXRModeObj rmode->viTVMode:
(https://github.com/devkitPro/libogc/blob/master/gc/ogc/gx_struct.h)
VI_NTSC and VI_NON_INTERLACE are both set to 0 in the same file, but
rmode returned from VIDEO_GetPreferredMode(NULL) has viTVMode set to 20.
If I understand correctly bit shifting to the left by 2 above would result in (fmt * 4) + mode.
That would equal 0? VI_PROGRESSIVE is set to 2 so I'm wondering if the video mode actually set is one from the TVNtsc480Prog definition. If that in turn creates a mismatch somewhere. I am using a component cable after all.
Sorry if this is confusing to read. Just trying to cover everything I've tried and I really am trying.
My set240p() function currently only does this:
I call it in Video::reset() after the SDL_SetVideoMode() function.
EDIT:
Went ahead and installed homebrew channel in Dolphin (can't run the oj.dol otherwise) and interestingly
when I enable the setting below the height is fixed. So it should be a simple mismatch somewhere?
(Realized that if you place the game data at the root of a virtual SD card mounted in Dolphin you can run .elf or .dol files directly w/o HBC to get printf calls in the emu logs.)
EDIT SUCCESS:
Holy sh*t - I think I solved it. I don't fully understand the relationship between the efb, xfb, vi, SDL dimensions and the scaling that occurs, but looking at the libogc example (devkitpro/examples/wii/graphics/gx/neheGX/lesson01) the following function calls caught my interest:
Adding all, but the SetScissor call to set240p():
240p (320x240 viewport):
240p (640x480 viewport):
480i:
Meaning ogc-sdl1.2 just assumes the height of the efb and xfb is always 480 pixels?
The text was updated successfully, but these errors were encountered: