What's new

Preliminary Rice Widescreen support

Tillin9

Mupen64Plus Dev.
Just a heads up since somebody wanted widescreen support. I added some preliminary support in commit 224. I added a 960x600 resolution and adding arbitrary resolution should just be a GUI issue. Once we have something which can resize the output correctly there is no reason not to let the user resize the window or just enter two numbers, etc.

However, it's not 100%. Basically Rice seems to be doing something odd with actually clearing the window, so while the 960x600 resolution I added works perfectly at first, if you move the window the pillerboxes are no longer black but oscillates with the contents of the windows under them.

A simple glClear(GL_COLOR_BUFFER_BIT) doesn't work. I was wondering if I could get some input as to what's going on here.

EDIT: commit 227 fixes these bugs. The only issue left from widescreen fully work is the pixel window border and of course some more testing.
 
Last edited:
OP
T

Tillin9

Mupen64Plus Dev.
Okay... looks like a found a larger bug. This is part of one of my other longstanding issues with Rice, the line during the sunrise in OOT.

Basically the viewport is being passed bad values. However, the bigger issue is that the SDL drawing surface is -1,-2,w+1,h in relation to the the window system. All of the windowsettings.statusBarHeightToUse etc. makes me think this is a longstanding issue that was never properly addressed. However, this might be a multiplatform thing.

Anyone here have an idea of where the problem could be, we seem to be initializing the window okay

SDL_SetVideoMode(windowSetting.uDisplayWidth, windowSetting.uDisplayHeight, colorBufferDepth, videoFlags)

Since ideally we can just fix the initialization and then kill all the extra shim variables since they do nothing anyway...
 
Last edited:

nmn

Mupen64Plus Dev.
I doubt the SDL video mode is wrong. I'd go for something higher up in levels of abstraction.

edit: Try disabling the HW_* SDL video mode flags from being set, just make sure it has no effect.
 
OP
T

Tillin9

Mupen64Plus Dev.
Thanks for the response, but I found something which fixes it! No uncleared pixels and the window decoration / status bar render properly. if I Change the glScissor commands to the viewport (they we're Scissoring out some other part of framebuffer).

I'll now debug why we're doing all this viewport changing, scissoring, etc. I mean the viewport wrapper function and gScissors gets called dozens of times per frame which seems dumb considering that we're not clipping off a good portion of the image.

Initially I though this might have to do with the fact that Rice is a plugin, but all the datastructures used to compute there weird clipping and location positions (some of which I think are wrong) are only found in Rice.

I'm also still trying to figure out why the decision wasn't made to do the simple (and presumably faster) thing and only change the viewport when the window moves/resizes.

Anymore care to chime in? I'm sure things will be clearer, cleaner, and likely faster if I just clear out all this crud but there has to a reason someone put in the 20 or so variables and 200 lines worth of this.
 

okaygo

Mupen64Plus Dev.
I think the real question is, when do we start developing on Rice Video and making it work for ALL games, and fix the errors. :3
 

ebenblues

Mupen64Plus Dev.
I'm also still trying to figure out why the decision wasn't made to do the simple (and presumably faster) thing and only change the viewport when the window moves/resizes.

Anymore care to chime in? I'm sure things will be clearer, cleaner, and likely faster if I just clear out all this crud but there has to a reason someone put in the 20 or so variables and 200 lines worth of this.

I'm not a graphics guy at all, so this is just a blind guess, but rice is the only plugin that supports hires textures. Might those lines be related to that?
 
OP
T

Tillin9

Mupen64Plus Dev.
Well fixing Rice and its bugs is on the todo. Trying to remove some of the unnecessary complication from the plugin should make this easier.

Basically the glViewport defines a box in the window where OpenGL can draw. glScissors is used to avoid repainting the whole frame if only a small thing has changed. Generally it is utilized in the case of a mostly static framebuffer. Think a 1600x1200 window with a computationally intensive 3D and only a small 200x50 button changes state. Basically we were changing these things, but still rerendering the whole screen.

As far as hires textures, they do work with my hacks. If these operations did any optimization, removal makes no difference on my r300. VI/s seems more or less the same or marginally higher than before.

Since we don't properly set different Windowed and FullScreen resultions and other values in this windowSetting struct, I'm leaning towards just doing the cleanup (which will add pillerbox widescreen) and seeing if any issues arise.

I guess my hesitation comes from the fact that I assume whoever wrote the plugin has more OpenGL knowledge than I do and sometimes to use higher-level features you do sometimes have to do odd things.
 
OP
T

Tillin9

Mupen64Plus Dev.
Progress report, the scissors stuff is mainly there as a hack for Mario Tennis. Sadly I don't have this game. My latest commit gives fully working widescreen with normal and hi-res textures (at least for the ROMs I have). I spent an hour trying to figure out why some Zelda hi-res textures for the logo we not loading properly only to find I was loading an older pack without them, arg. I also removed any glViewportWrapper calls that didn't seem to do anything.

I'd highly appreciate some people giving this a test run. It obviously needs code beautification, but should be fully functional. :)

widescreenzelda.png
 
Last edited:

Richard42

Emulator Developer
@Tillin9:

I would suggest lots of testing and staring at the code until you understand what problem the original author was trying to solve in writing the overly complex code that you found. Then if you can re-write the code in a simpler way which will still work in all cases, it's great.

@developers:

I am a graphics guy, and correcting bugs in there video plugins without introducing regressions is very difficult. In most cases you find a problem at one particular point in the code, but you will need to understand a large amount of code, encompassing multiple layers of function calls, before you can rewrite it to fix the bug without causing others..

In the interest of saving all of our time and sanity, we need to follow these three rules for working on the video plugins:

1. Commit only one bugfix at a time. Do not make a commit which fixes more than one bug.
2. When committing a bugfix, give a thorough description of the bug which you fixed, including the game in which it was observed and the steps to reproduce. You may give an issue number referencing the google code issue list if the issue report contains this information.
3. No hacks. I don't want to see anything like "if (thisgame) { hack; hack; hack; }"

#1 is necessary for tracking down regressions when they occur. #2 is necessary so that other developers can test and verify the fix. #3 is just proper engineering practice.

We need to hold off on the video plugin work until after I can establish an automated regression test covering a wide range of games. I have an idea on how to put this together. This type of tool is very important for ensuring that we're always going forward, and can catch regressions as soon as they appear.

Let's focus on perfecting the many features which we've added for v1.4 -- getting them fully tested, consistent, and with GUI support. In a few weeks when things are nearing completion we'll go into pre-release mode with only bugfixes allowed on the trunk and make RCs for wider testing. Then a couple of weeks later we'll make the v1.4 release and we can focus on the video bugs and crashes for v1.5.
 
OP
T

Tillin9

Mupen64Plus Dev.
Okay, since things are more or less working and stable now, any further commits for widescreen support or Rice cleanup will goto a branch.

The viewport offsetting is a logic bug in Rice. I'm still digging through the code, but it looks like originally Rice didn't use OpenGL's matrices to actually transform vertices, everything was done completely manually. Some of the comments still mention this. Such an approach resulted in a number of values being saved to a plugin specific structure to handle these transforms. Originally this intermediate step was designed for 640x480 but later was extended to more resolutions. Some of the math involved, like casting floats into integers, doesn't seem to work correctly all the time. This is the driving force behind a number of bugs in Rice, pretty much anytime a line is 1 pixel off or a texture is shifted a few pixels, etc.

I'm now trying to find out where the N64 sends the project matrix commands. I mean since it does OpenGL itself, we don't need Rice to map the ROM projection transforms to a 640x480 coordinate system (which is does) and then send that to the native OpenGL.

Also, is there any documentation on the technical decisions made in creating the plugin (or an N64 graphics plugin in general)? A nice logic flow diagram for Rice would be very helpful. If not, I'll just have to figure it out myself. However, I think I'll try to put some text together to make it easier for people unfamiliar with the codebase to get up to speed quicker. At the very least, I should help with my understanding.
 

ebenblues

Mupen64Plus Dev.
However, I think I'll try to put some text together to make it easier for people unfamiliar with the codebase to get up to speed quicker. At the very least, I should help with my understanding.
This would be a great document to have. If you do write it up, make it a wiki page.
 

Top