What's new

RiceVideo problem with Mario Kart -- fixed!

OP
R

Richard42

Emulator Developer
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

Mupen64Plus Dev.
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

Member
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.
 
OP
R

Richard42

Emulator Developer
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

Member
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 part of the level).
- Items that can spin (like shells) are sometimes deformed (Example with a green shell).
- Intro movie glitches (Example 1, 2).

I'm using the latest sources from SVN.
 

mudlord

Banned
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. :)
 
OP
R

Richard42

Emulator Developer
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!
 
OP
R

Richard42

Emulator Developer
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 part of the level).
- Items that can spin (like shells) are sometimes deformed (Example with a green shell).
- Intro movie glitches (Example 1, 2).

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

Member
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.
 
OP
R

Richard42

Emulator Developer
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

Banned
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

Nintendo Zealot
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.
 
Last edited:
OP
R

Richard42

Emulator Developer
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.
 
OP
R

Richard42

Emulator Developer
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
 
OP
R

Richard42

Emulator Developer
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

Banned
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.
 
OP
R

Richard42

Emulator Developer
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.
 

Top