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.

 

[Danny]

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.

 

[nmn]

In addition, i have slowly been working on a Qt4 GUI (I'm also learning Qt4 at the same time so it may be a while), so the modularness couldn't have came at a better time.

But very nice progress. I hope to try it but right now i got about 8 minutes so it might not be worth it.

 

[Richard42]

That's cool; I've seen Qt code in projects but never written any myself. I have written a bit of wxWindows code - it's very portable and pretty easy to use. Sort of reminds me of MFC but with function-based positioning code instead of the dialog builder.

You will have to integrate qmake to do a Qt gui. Right now all of the plugins are built as sub-modules, but the r4300 core, the X86 dynamic recompiler, and the main apps for the _nogui and gtk-gui builds are still built together in a single makefile. It might be worthwhile to split it up further if you're going to add another gui target.

 

[Richard42]

I'm chasing down a major bug in Rice Video. The symptom is a crash when running around on the first area of Banjo Kazooie. Last night I ran it in GDB and did some examination. At first I thought it was a texture blitter/combiner writing into the wrong memory space due to a negative coordinate or something. But this morning I ran it under Valgrind and saw that it's actually due to a texture struct being used after it has been free'd. It should be a fairly easy fix, and this is a bad bug too - I bet it causes crashes in other games as well. Valgrind is such a great debugging tool, if you have the patience to reproduce the bug while playing the game at 2fps.

 

[Danny]

Keep up the great work Richard

Your certainly zappin' those bugs

 

[nmn]

Holy crap dude, Your just beating the crap out of these bugs...

 

[Richard42]

Holy crap dude, Your just beating the crap out of these bugs...

Yep, I fixed that Rice Video crash last night and a couple of other small issues as well. The SVN repository is almost up to rev 50, and it's about time to make a release.

 

[kdubya]

Dude you're awesome. I may get to retexturing mario kart now that it works.

I have another bug for you that is probably really easy to fix. It effects the pod racer game and star wars rogue squadron (neither is playable). It is supposedly related to the implementation of the n64 expansion pack. I think Hacktarus was saying that if you turn off the expansion pack then these games work fine, but as of right now you have to do this in the code and compile it either on or off. A command line argument that turns the expansion pack on or off would be nice.

 

[Tillmann]

In addition, i have slowly been working on a Qt4 GUI (I'm also learning Qt4 at the same time so it may be a while), so the modularness couldn't have came at a better time.

But very nice progress. I hope to try it but right now i got about 8 minutes so it might not be worth it.

Hi!

I'm a little embarrassed to request this, but as a GNOME user, i'd like to ask if you could at least maintain the gtk2 gui.

Could it be some kind of alternative to do a command line parameter to compile the gui with gtk or qt

 

[Richard42]

Dude you're awesome. I may get to retexturing mario kart now that it works.

I have another bug for you that is probably really easy to fix. It effects the pod racer game and star wars rogue squadron (neither is playable). It is supposedly related to the implementation of the n64 expansion pack. I think Hacktarus was saying that if you turn off the expansion pack then these games work fine, but as of right now you have to do this in the code and compile it either on or off. A command line argument that turns the expansion pack on or off would be nice.

I tried playing those games last night. Rogue Squadron wouldn't play at all - nothing on the screen. Ep 1 Racer would play but the screen was shifted down by about 1/4 of the height and everything on the bottom was cut off.

I looked in the code but there is no obvious control for enabling/disabling the extra 4M of RDRAM in the Mupen source. There is a place in memory.c which initializes the hash tables, and it appears as though you could decrease the available memory there, but I tried it many different ways and none of them worked. The game would still detect the expansion pack memory.

I also d/l'ed and looked at the source for 1964 to see how it was implemented there. 1964 appears to also modify a TLB page table in addition to the RAM hash table when it enables/disables the expansion pak. But the TLB implementation in Mupen64 is totally different and I couldn't immediately see how it even works. I'd have to seriously dig through the r4300 manuals to verify its operation, and that's not too high on my list of fun things to do.

So unless Hacktarux can offer some guidance on the necessary steps to correctly disable the extra ram, it probably won't get done any time soon.

 

[nmn]

The qt4 GUI is a side project, GNOME users may use it if they dislike the GTK one as it will still work great, and I'm also not going to cease work on the GTK2 version. Infact, I have implemented PNG icons that are dynamically loaded and made better icons for the GTK version, so i hope to release that as soon as i make it work when the cd is not the application folder (I'll probably copy off of the methods used to locate plugins and such since that will also respond to the compile settings that tell it where to look, in a special folder or the directory of the app)

More about the qt4 gui:

- It will probably resemble the Windows one more, i dislike the way the GTK2 one looks anyways
- It will not effect the plugins, unless i decide to port them too, but thats for another day
- It won't make the graphics plugin appear inside the window

I'm still thinking about ways to make the graphics appear in the window, right now my thoughts are still on an optional OpenGL context manager that plugins can use via a special Mupen64 Linux version extension of the plugin API. Its probably not all that hard to do and it would definitally help to make Mupen64 for Linux a bit more user friendly.