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 :D

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. :)

[_Zack_]

Keep up the great work Richard :)

Your certainly zappin' those bugs :P

[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!
:D
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.

[Richard42]

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)

NMN, you don't have to worry about that any more; I removed that whole mechanism including the 'configure' and 'config.h' files, because it didn't work. Time to do an SVN update.

Instead, I added a '--configdir' parameter for the _nogui build which allows the user to specify a different config dir if desired, containing the mupen64.conf file. The plugins are also loaded individually in the _nogui build and there is no longer a requirement for them all to be in the same folder. This allows you to have your own .conf file in your home directory which references plugins located in a system dir. I added a 'plugin_scan_file' function in plugin.c to support this. I would suggest taking a look at the changes in the _nogui build and re-working the plugin loading code in the gtk build or your new qt4 build.

[nmn]

Will do ASAP. My internets been slow as hell lately so i've been having trouble getting on to anything at all, however i should have some free time later on today.

[Surkow]

Something I'm wondering about is if I should report graphics glitches like missing textures and stuff. It seems that the Linux port of Rice is behind the windows version of the plugin. I tested a small amount of games and currently SSB is playable but misses textures in the intro and in the levels the backgrounds and non moving objects are glitchy.

[Richard42]

Something I'm wondering about is if I should report graphics glitches like missing textures and stuff. It seems that the Linux port of Rice is behind the windows version of the plugin. I tested a small amount of games and currently SSB is playable but misses textures in the intro and in the levels the backgrounds and non moving objects are glitchy.

I believe that the Rice Video code is up-to-date, and the Linux port was fairly straightforward and shouldn't have caused graphics problems. But there could be big differences between the OpenGL renderer and the D3D renderer. If you can point to problems which appear on my port of RiceVideo but not under windows with the OpenGL renderer, then I would definitely want to fix it because it would be a real bug. If you can find problems which appear on my Linux build but not under Windows with the D3D renderer, it's probably a general OpenGL problem but I'll also try to fix these. At the very least I'll put all graphical glitches on the TODO list.

Please report the game, the nature of the glitch, the Mupen64/RiceVideo build info (binary/source, version), and whether or not the problem appears in Windows with the D3D and OpenGL renderers. That would help me out a lot because I don't have any Windows machines with which I can spend much time testing.

[Surkow]

I only assumed that the Linux version of the Rice plugin was behind because of screenshots I saw from high res projects of SSB. it's probably the difference between D3D and OpenGL (I have to admit that I didn't test it).

Currently SSB suffers from the following glitches:
- Some levels have background problems. For example the background of the Hyrule Castle level vibrates (it can be seen in this (http://img248.imageshack.us/img248/7173/backgroundissuericevidewi6.png) part of the level).
- Items that can spin (like shells) are sometimes deformed (Example (http://img254.imageshack.us/img254/1558/itemglitchesricevideolivq3.png) with a green shell).
- Intro movie glitches (Example 1 (http://img254.imageshack.us/img254/2944/schermafdrukricevideolihg6.png), 2 (http://img156.imageshack.us/img156/3213/schermafdrukricevideolidq6.png)).

I'm using the latest sources from SVN.

[mudlord]

But there could be big differences between the OpenGL renderer and the D3D renderer. If you can point to problems which appear on my port of RiceVideo but not under windows with the OpenGL renderer, then I would definitely want to fix it because it would be a real bug. If you can find problems which appear on my Linux build but not under Windows with the D3D renderer, it's probably a general OpenGL problem but I'll also try to fix these. At the very least I'll put all graphical glitches on the TODO list.


Just wondering though, is it okay if I port over your OpenGL fixes to my Rice Video builds? :) I'll credit you with the OpenGL fixes of course though. Currently the OGL renderer is very lacking compared to the D3D renderer and I would love to help improve the renderer in my plugin. And hopefully, I can then fix the OGL problems in my plugin based on the Linux fixes for yours. :)

[Richard42]

Just wondering though, is it okay if I port over your OpenGL fixes to my Rice Video builds? :) I'll credit you with the OpenGL fixes of course though. Currently the OGL renderer is very lacking compared to the D3D renderer and I would love to help improve the renderer in my plugin. And hopefully, I can then fix the OGL problems in my plugin based on the Linux fixes for yours. :)

Mudlord, go for it - port away. Last night I fixed 2 problems in TextureFilters.cpp, so hi-res textures are now working on RiceVideoLinux!

[Richard42]

Currently SSB suffers from the following glitches:
- Some levels have background problems. For example the background of the Hyrule Castle level vibrates (it can be seen in this (http://img248.imageshack.us/img248/7173/backgroundissuericevidewi6.png) part of the level).
- Items that can spin (like shells) are sometimes deformed (Example (http://img254.imageshack.us/img254/1558/itemglitchesricevideolivq3.png) with a green shell).
- Intro movie glitches (Example 1 (http://img254.imageshack.us/img254/2944/schermafdrukricevideolihg6.png), 2 (http://img156.imageshack.us/img156/3213/schermafdrukricevideolidq6.png)).


Thanks for the screen shots - that should help. The screen flashes are probably a result of the screen update issue. If you set ScreenUpdateSetting=1 for the SSB ROM in RiceVideoLinux.ini, this should be resolved. I'll try to reproduce the others and see what's going wrong.

[Surkow]

Thanks for the screen shots - that should help. The screen flashes are probably a result of the screen update issue. If you set ScreenUpdateSetting=1 for the SSB ROM in RiceVideoLinux.ini, this should be resolved. I'll try to reproduce the others and see what's going wrong.

I added the update setting but it didn't make a difference. What should it solve again? I also noticed that the donkey kong level had the same glitches as in the intro.

[Richard42]

I added the update setting but it didn't make a difference. What should it solve again? I also noticed that the donkey kong level had the same glitches as in the intro.

There is a technical description of the problem at the beginning of this thread. Basically it looks like several polygons or pieces of polygons 'disappear' and reveal the background image or color underneath. It kind of flashes - doesn't happen on every frame but maybe every few seconds you'll see several flashes.

In order for the .ini setting to take effect, I believe you need to have 'EnableHacks' set to 1 in the RiceVideo.cfg. Also, there may be several different rom dumps of the same game, so check the CRC printed on the console when you run SSB, and make sure it matches the CRC in the RiceVideoLinux.ini file for the game. The ScreenUpdateSetting=1 should be placed at the end of the list underneath the CRC.

[mudlord]

Mudlord, go for it - port away. Last night I fixed 2 problems in TextureFilters.cpp, so hi-res textures are now working on RiceVideoLinux!

Brilliant!

Also, have you got a SVN of sorts? Is the link public or is it private? Just wondering so I could port your latest OpenGL improvements to the Windows port.

[cooliscool]

Off topic (sincerest apologies) - speaking of Z-fighting, I'm having the same trouble in my Zelda 64 model viewer. The only solution I could come up with was to increase the topmost coplanar surface on the y-axis by 1, effectively making the two surfaces non-coplanar, eliminating the problem. The issue with that is, I really don't know how the heck I'm going to be able to detect coplanarness, especially when the mesh data in display lists is scattered about.

Any GPU plugin authors have any clues? API is OpenGL.

[Richard42]

Off topic (sincerest apologies) - speaking of Z-fighting, I'm having the same trouble in my Zelda 64 model viewer.

Any GPU plugin authors have any clues? API is OpenGL.

There is an opengl command called glPolygonOffset which is design to remedy this problem. It adjusts the Z coordinate of the polygon's vertices in the clipping coordinate space by a variable amount depending upon the fixed value that you specify and the maximum z-slope of the polygon. In order to use this, you must know which polygon(s) should be 'on top' of the others. You can set a 'decal' flag for each polygon or texture and activate the glPolygonOffset whenever this flag is set.

There are mathematical methods of determining coplanarity by the coordinates alone but in order for this to look right you must also know *which* texture needs to be on top, so you can't make it work without having some extra info, ie the decal flag.

[Richard42]

Brilliant!

Also, have you got a SVN of sorts? Is the link public or is it private? Just wondering so I could port your latest OpenGL improvements to the Windows port.

I do have an SVN server. There is a public read-only account, username is 'mupen64' and password is 'Dyson5632-kart'. The URL is:

svn://fascination.homelinux.net/mupen64-amd64/trunk

[Sirmatto]

Richard42, have you and mudlord considered consolidating your SVN trees into a single one one?

[mudlord]

Not a bad idea. I'm more than happy to do this and give Richard42 write access to my SVN tree. :)

[Richard42]

Not a bad idea. I'm more than happy to do this and give Richard42 write access to my SVN tree. :)

My personal feeling about merging the Linux and Win32 builds of RiceVideo is that it's more work than I'm willing to take on right now, and for little benefit. Not to imply that it's a bad idea - I think if anyone feels passionate about it and wants to do it, they should go ahead - but there are better things that we could be working on, and other ways of sharing our work together.

To understand why I feel this way, let me give a little history about how RiceVideoLinux came to be. The original RiceVideo plugin was developed as a windows-only project. Hacktarux took the source for v6.1.0 and ported it to Linux. This involved a boatload of GTK code for the config dialog and a some OS-specific tweaks for things like directory list traversal. He sort-of tried to keep it buildable in Win32 by adding a bunch of #defines for the OS-specific stuff, but he also removed the D3D renderer (obviously wont build in Linux) and used some typedef hacks for D3D-derived objects like vectors. Hacktarux really made a lot of changes. Next, I started with a vanilla copy of Hacktarux's 6.1.0 port and modified it to build and run on the 64-bit architecture - mostly changing 'long' to 'int' and re-writing the inline assembly code. I decided that the code really needed to be cleaned up, since the Linux port left all this junk lying around that was unmaintainable. I know that no-one is going to run the Linux port of RV on Win32 without the D3D renderer, so there's no point in having all this #defined stuff: it will never be tested and is sure to break sooner or later. So I removed all of the "platform-independent" stuff to make it Linux-only: all the #defines, all the D3D-derived stuff, is now gone from my build. It is much cleaner and more maintainable this way. Then I made a bunch of fixes: most of them to the OpenGL renderer, but some of them to the base code as well.

So here's what we're left with: a good Win32-only build of RiceVideo maintained by Mudlord, with an excellent D3D renderer and a mediocre OpenGL renderer. And a good Linux-only build, for 32-bit and 64-bit architectures, maintained by myself, with a pretty good OpenGL renderer. Merging these two together without introducing any regressions for the individual platforms would require a very large amount of work. Someone would need to build an OS-independent layer to avoid #define hacks. Someone would have to add the missing functionality (like the Debugger window) to the GTK GUI. Someone would have to come up with a proper solution for using non-D3D derived data types in the base classes but still be compatible with D3D in the Win32 build.

The primary motivation that I can see for merging the RiceVideo projects is to make sure that fixes and improvements get applied to both systems. As an alternative solution, I think it would be easier if we did the following: I can add Mudlord to the commit email notification list for the RiceVideo project on my SVN server, and he can do the same for me on his SVN server. This way we will each receive a diff through email when a change is applied, and can choose to merge this change into our own repository if applicable. Unless one of us goes on a hacking spree and introduces many changes into the platform-independent core, this will be much less work than merging the two projects together.

I have already merged all of the changes from Mudlord's SVN server up until about r28 into my build - a lot of it was Win32 or D3D-specific stuff, but there were a lot of hi-res texture loading changes which made it in.

[mudlord]

The primary motivation that I can see for merging the RiceVideo projects is to make sure that fixes and improvements get applied to both systems. As an alternative solution, I think it would be easier if we did the following: I can add Mudlord to the commit email notification list for the RiceVideo project on my SVN server, and he can do the same for me on his SVN server. This way we will each receive a diff through email when a change is applied, and can choose to merge this change into our own repository if applicable. Unless one of us goes on a hacking spree and introduces many changes into the platform-independent core, this will be much less work than merging the two projects together.

I have already merged all of the changes from Mudlord's SVN server up until about r28 into my build - a lot of it was Win32 or D3D-specific stuff, but there were a lot of hi-res texture loading changes which made it in.

I see a possible alternative. I can give you a seperate "linux" directory on my SVN server that can contain your Linux port. That way, it does not affect both ports and both ports are inert. Since they will be on the same server, but in different directories, there is zero issues of code mixing. Plus, due to them being on the same server, code reusage in the OpenGL renderer is easier to manage.

[Richard42]

I see a possible alternative. I can give you a seperate "linux" directory on my SVN server that can contain your Linux port. That way, it does not affect both ports and both ports are inert. Since they will be on the same server, but in different directories, there is zero issues of code mixing. Plus, due to them being on the same server, code reusage in the OpenGL renderer is easier to manage.

That may be what we'll have to do in the future, because there are big changes coming up in my life and I may not have much time to work on this. But I won't cross that bridge until it's here. In the short-term I would actually prefer to keep RiceVideoLinux on my SVN server, the reason being that I have created an automated release building system. Both RVL and Mupen64-amd64 are in the trunk of the same repository, and with my new release system I am able to check out a tag and build the release zip files that I posted to this forum with a single makefile command. I spent quite a few hours on it last weekend, because it will save time in the future and improve the quality of the software by ensuring that what was delivered was what was intended to be delivered, and no mistakes were made. It could still be done if RiceVideo was moved to your SVN server, but tagging and releasing would take more work.

I believe that merging should be the same regardless of whether the changes being merged are from the same repo as the project being modified or not, so hopefully this will not be an issue.