RiceVideo problem with Mario Kart -- fixed!

[Richard42]

Finally - after ridiculously many hours of debugging, I've found the source of the RiceVideo flashing problem with Mario Kart, and the fix for it. At least along the way I learned a lot about things like homogeneous coordinate systems, polygon clipping, the OpenGL pipeline, and the RiceVideo renderers.

So here is what was happening to cause these artifacts. First, one frame would be rendered to the (blank RGB and Z) hidden frame buffer. Then the problem occurred, because sometimes the UpdateFrame function would not be called and the buffers would not be swapped. So next, another frame was rendered *on top* of the first. The background would first be copied over the entire frame in the RGB space, but the Z buffer would remain untouched. So when the second frame was rendered on top of it, only the new pixels that were *in front* of the pixels from the previous frame would be rendered; otherwise you'd see the background.

While searching for the fix I found that RiceVideo has a mechanism for selecting at what times the UpdateFrame function could be called. So the fix is very simple - by adding the line "ScreenUpdateSetting=1" to the MarioKart section in your '.ini' file, the screen will be properly updated and these artifacts will not occur. Happy Karting!



I think I'm going to rip all of the remaining Win32 code out of my RiceVideo plugin and make it Linux-only, supporting both 32-bit and 64-bit systems. The D3D stuff was already ripped out by Hacktarux, so it's not worth much to Windows users now anyway. And the remaining WIN32 stuff just clutters up the code with all this crap, so I'll probably take some time and get rid of it all so that we can have a clean Linux implementation.

[_Zack_]

Nice work

I will be uploading the 32bit version i made from the svn (the committed changes) soon. Sorry it has taken so long, I am swamped with work at the minute.

[nmn]

Wow. This is great! Now i know the problems that have been occuring everywhere for me when i get the flickering. (Actually, I should've saw this one coming... Especially since the way it appears in K64 where its very obvious that the black area of the flicker is the area where the depth test failed over last frames zbuffer.)

And BTW, before i forget, i think the DirectX mode has more things, (framebuffer maybe?) so if we could locate those and stub them in the OpenGL code we'd probably be better off.

Oh, and for the 32-bit thing: It should "JustBuild" on 32bit PCs. If your on a 64bit machine, open the Makefile and change the
CC=gcc
line to
CC=gcc -m32
and
CXX=g++
line to
CXX=g++ -m32
and it should create 32bit binaries after make cleaning the source.

[Richard42]

And BTW, before i forget, i think the DirectX mode has more things, (framebuffer maybe?) so if we could locate those and stub them in the OpenGL code we'd probably be better off.

Yep, the OpenGL renderer is not as nice as the D3D one in Rice Video. It doesn't support hardware T&L, for one thing, and the clipping modes are also limited. It would be nice to add these features but I'm not too motivated to do it since it runs perfectly at full speed on any 64-bit machine.

Oh, and for the 32-bit thing: It should "JustBuild" on 32bit PCs. If your on a 64bit machine, open the Makefile and change the
CC=gcc
line to
CC=gcc -m32
and
CXX=g++
line to
CXX=g++ -m32
and it should create 32bit binaries after make cleaning the source.

Actually there's a little more to it than that. Those changes will enable it to build 32-bit object files, but they won't link. In order to make it link, you have to add to the LDFLAGS "-m32 -m elf_i386". A couple of years ago when I started working on 64-bit systems it took me hours to find that linker flag.

I'm going to modify the makefiles this weekend to support a command-line argument for making a 32-bit build.

[Richard42]

Wow. This is great! Now i know the problems that have been occuring everywhere for me when i get the flickering. (Actually, I should've saw this one coming... Especially since the way it appears in K64 where its very obvious that the black area of the flicker is the area where the depth test failed over last frames zbuffer.)

NMN, if you find this problem in other games and fix it with a change to the INI file, please also commit that change back to my SVN repository. The Rice Video INI file is in the mupen64-64bit/plugins folder. Thanks.

[nmn]

I went off to find the problem in Kirby 64. While the whole screen redraw fix worked for Mario Kart, It only fixed problems when OpenGL took too much time for each frame (effects did this occasionally) I found that unchecking Show FPS fixed the bug for most of the redraw problem... Very interesting...

[GarulfoLinux]

Good job Richard42

[Richard42]

I went off to find the problem in Kirby 64. While the whole screen redraw fix worked for Mario Kart, It only fixed problems when OpenGL took too much time for each frame (effects did this occasionally) I found that unchecking Show FPS fixed the bug for most of the redraw problem... Very interesting...

I also ran Kirby and saw a few bugs. Sometimes there are black flashes or missing polys, but not often. Sometimes there is what appears to be Z-fighting between 2 different textures on the ground; one of them looks like a leaf, the other a shadow. I played with it a little but didn't get it fixed. Kirby 64 overall looks great, and I had fun running through a couple of levels.

I saw major Z-bias problems in the decal textures in Super Mario 64; I don't know if that was in the original Rice Video or if that got introduced by my other changes, but I fixed that so SM64 looks perfect now.

[nmn]

I didn't go out of my way to find levels in K64 with problems... Couldn't find much when Show FPS was off.

In Super Mario 64 on Rice Video 6.1.2 i remember it having some possible Z-buffer problems in OpenGL mode. I don't remember much though. I could check, but I don't have a Windows box, and its not entirely reliable to use DirectX mode in Wine (Though with the latest GIT versions of Wine the support is pretty damn good)

[Richard42]

In Super Mario 64 on Rice Video 6.1.2 i remember it having some possible Z-buffer problems in OpenGL mode. I don't remember much though. I could check, but I don't have a Windows box, and its not entirely reliable to use DirectX mode in Wine (Though with the latest GIT versions of Wine the support is pretty damn good)

I did do a test to try running SM64 without my changes and it did still show major problems. So probably the bugs were there in RV6.1.0 using OpenGL though it is possible that I missed something when I did my test.

I think I'm going to tag and release soon both my RiceVideo-Linux plugin and the Mupen64-amd64 branch because there is a lot of new stuff that people would like; I've been busy the past couple of weeks. Both of these projects should build perfectly in 32-bit and 64-bit modes. DynaRec should work out of the box now. I can build a 32-bit build on my 64-bit box with 1 command and it works perfectly including dynamic recompilation. I refactored the Mupen64 makefiles to be more modular. I also totally refactored the plugin loading code in the _nogui build of mupen64 so now it actually works like you would expect it to. The original code was sort of a hack; the GUI code must have been written first, and the _nogui build tacked on later, but now it's right. I cleaned up a lot of the top level stuff so now it's a really good base to work from.