Black screen for one player in two player mode in Mario kart 64

[GoogleCodeExporter]

Describe your system:
- Operating System (be specific):
   Raspian wheezy (retropie)
 - Machine type (32-bit or 64-bit):64bit (raspberry pi 2)
 - Mupen64Plus version:ricrpi branch
 - Plugins used:rice

For visual artifacts, give:
- game name and CRC/MD5 hash (printed on console)
- description of the artifact (missing polygons, flashing, wrong colors,
etc)

Describe the problem:

In 2 player mode in Mario kart 64, one screen is always black. On first race, 
bottom screen is always black. If player 2 happens to win with aid of player 
one's screen, player one's screen will be black on next race, and player two's 
screen will then be functional.

Please provide any additional information below.

Original issue reported on code.google.com by clone...@gmail.com on 15 Feb 2015 at 11:47

[GoogleCodeExporter]

libretro is a fork which is currently not part of mupen64plus. Please contact 
the retro maintainers which develop it

I am currently unable to reproduce this problem on PC with the official 
mupen64plus sources

Original comment by conc...@web.de on 15 Feb 2015 at 11:09

[GoogleCodeExporter]

Thanks, but I'm not using the libretro version. This is on linux (raspian), not 
PC.

Original comment by clone...@gmail.com on 15 Feb 2015 at 11:17

[GoogleCodeExporter]

Also, one correction, this is actually not using rice. It's glide.

Original comment by clone...@gmail.com on 15 Feb 2015 at 11:18

[GoogleCodeExporter]

Just googled it and found 
thishttps://github.com/ricrpi/mupen64plus/blob/master/build.sh

This s doesn't seem to use rice or glide64 from upstream. It uses some own 
plugins called gles2n64 and gles2rice. 
https://github.com/ricrpi/mupen64plus/blob/master/RaspbianList

Gles2rice is some kind of fork of rice with own modifications. Gles2n64 is 
something mupen64plus doesn't have at all

Original comment by conc...@web.de on 16 Feb 2015 at 7:35

[GoogleCodeExporter]

And why is linux not a system running on a PC? I am also running Linux and 
still call it pc

Original comment by conc...@web.de on 16 Feb 2015 at 7:37

[GoogleCodeExporter]

I think many people use the word PC to denote a windows machine in this kind of 
context (discussing the environment in which software is being run). I assumed 
that's what you meant.

Anyway, thanks for looking into it. Sounds like I need to contact the 
author/maintainer of these plugins, but for what it's worth, this same issue 
has appeared in ouya, and I doubt they're using the same plugins:

http://www.reddit.com/r/ouya/comments/1g6rq5/emulator_multiplayer/

Original comment by clone...@gmail.com on 16 Feb 2015 at 8:14

[GoogleCodeExporter]

I think the ouya port uses gles2rice and gles2n64. And the thread says that 
gles2rice works. So it is most likely a problem in gles2n64 (which mupen64plus 
doesn't provide). But you can also contact the mupen64plus-ae guys when it also 
happens in their port (android/ouya).

Original comment by conc...@web.de on 16 Feb 2015 at 10:49

[GoogleCodeExporter]

gles2rice is an obsolete plugin from mupen64plus-ae version 2.x.  It evolved 
after the ricrpi branch point and eventually got merged upstream into 
mupen64plus-video-rice.  mupen64plus-ae version 3.x (in alpha phase right now) 
uses vanilla mupen64plus-video-rice.  That is what rpi should try to use going 
forward.

gles2n64 originated in mupen64plus-ae but does not exist upstream.  In 
mupen64plus-ae version 3.x it is called mupen64plus-video-gln64, and is still 
maintained by that project.  I'm not sure how divergent the rpi fork is from 
the ae version.

I recommend the OP search the paulscode forums and github issue tracker for the 
mupen64plus-ae project.  I know this issue has been mentioned before.
http://www.paulscode.com/forum/index.php
https://github.com/mupen64plus-ae/mupen64plus-ae/issues

Original comment by mdlich...@gmail.com on 20 Feb 2015 at 4:03