Forum Replies Created

Viewing 16 posts - 1 through 16 (of 16 total)
  • Author
    Posts
  • in reply to: Mupen64plus (ricrpi branch) #90485
    clone206
    Participant

    Technically it’s one emulator with 2 different plugins but I know what you mean. I envision some way to add into the main mupen64plus config file a list of roms and which plugin each uses.

    in reply to: Mupen64plus (ricrpi branch) #89870
    clone206
    Participant

    I use the select button myself.

    in reply to: Mupen64plus (ricrpi branch) #89615
    clone206
    Participant

    Ok, thanks. I’m still on 2.5, so do I just update the setup script from within the setup script, or do a pull, or is that step not even necessary?

    in reply to: Mupen64plus (ricrpi branch) #89607
    clone206
    Participant

    @gizmo98 – Nice, can’t wait to try this! Thank you!

    Edit: can you walk me through enabling neon optimizations while using the packages (as opposed to setup) script?

    in reply to: N64 glitch #89320
    clone206
    Participant

    ScreenUpdateSetting=7 seems to work better in general for me, including the Zelda games. I may have also had to tweak the frame skip settings to get it to work right as well.

    Both OOT and MM run great now, including the annoying unskippable intros.

    in reply to: Rpi 2 potential power? #89318
    clone206
    Participant

    Thanks, here you go. It looks like they’re starting to do some of what I describe below with a new experimental package for mupen64plus that ends in “-testing”. You would have to install that from the retropie setup script. This makes an n64 folder in the roms directory for each video plugin. Then you put the rom in one of the folders to see which plugin works best. Not sure if they’ve included all the rice video plugin settings I changed, though.

    Mupen64plus (ricrpi branch)

    in reply to: Rpi 2 potential power? #89225
    clone206
    Participant

    Here’s my setup on a pi2, showing n64, psx, and ports.

    I can get multiplayer mariokart 64 to work as well, but that took a lot of tweaking. Can cross post to the other thread where I explain how if you want.

    https://www.youtube.com/watch?v=ogTrMtM9TEk

    in reply to: Retropie 2.6 Rom Compatibility List?? #89222
    clone206
    Participant

    Some info about getting the most roms for n64 to work (without using retroarch). Also a video link to show how they run on the pi2.

    https://www.petrockblock.com/forums/topic/mupen64plus-ricrpi-branch/page/2/#post-87770

    https://www.youtube.com/watch?v=ogTrMtM9TEk

    in reply to: Mupen64plus (ricrpi branch) #89218
    clone206
    Participant

    Thanks, @gizmo98

    Note that without ScreenUpdateSetting=7 I can’t get two player to work in mario kart 64. So I guess for me getting that to work was the bigger priority since I just use the other plugin for mario 64.

    in reply to: mupen64 and mupen64plus #89209
    clone206
    Participant

    You can also setup mupen64plus to use one of two available video plug ins on a per game basis. Note that using retroarch mupen64plus isn’t what I’m talking about here. You can setup the non-retroarch mupen64plus to use both the default video plugin and the rice video plugin that come with retropie.

    The rice plugin works with a lot more roms than the default plugin, and you still get better performance than with retroarch.

    See the following:

    https://www.petrockblock.com/forums/topic/mupen64plus-ricrpi-branch/page/2/#post-87770

    in reply to: Mupen64plus (ricrpi branch) #89197
    clone206
    Participant

    The below settings were used for banjo kazooie in the below video. I use these settings globally with gles2rice, and have had a lot of games run just fine that way, though gles2n64 still feels more responsive, so I use it when I can. Games which also use the below rice settings on my system include Mario Kart 64 (for multiplayer), Banjo Tooie, Paper Mario, Perfect Dark, Castlevania, OOT, Majora’s Mask, Pilotwings 64, and Mario Tennis.

    When gles2n64 was used (Mario Kart 64, Super Mario 64) in the below video, the default config was used.

    Click here for video

    [Video-Rice]
    
    # Frame Buffer Emulation (0=ROM default, 1=disable)
    FrameBufferSetting = 0
    # Frequency to write back the frame buffer (0=every frame, 1=every other frame, etc)
    FrameBufferWriteBackControl = 1
    # Render-to-texture emulation (0=none, 1=ignore, 2=normal, 3=write back, 4=write back and reload)
    RenderToTexture = 0
    # Control when the screen will be updated (0=ROM default, 1=VI origin update, 2=VI origin change, 3=CI change, 4=first CI change, 5=first primitive draw, 6=before screen clear, 7=after screen drawn)
    ScreenUpdateSetting = 7
    # Force to use normal alpha blender
    NormalAlphaBlender = False
    # Use a faster algorithm to speed up texture loading and CRC computation
    FastTextureLoading = False
    # Use different texture coordinate clamping code
    AccurateTextureMapping = True
    # Force emulated frame buffers to be in N64 native resolution
    InN64Resolution = False
    # Try to reduce Video RAM usage (should never be used)
    SaveVRAM = False
    # Enable this option to have better render-to-texture quality
    DoubleSizeForSmallTxtrBuf = False
    # Force to use normal color combiner
    DefaultCombinerDisable = False
    # Enable game-specific settings from INI file
    EnableHacks = True
    # If enabled, graphics will be drawn in WinFrame mode instead of solid and texture mode
    WinFrameMode = False
    # N64 Texture Memory Full Emulation (may fix some games, may break others)
    FullTMEMEmulation = False
    # Enable vertex clipper for fog operations
    OpenGLVertexClipper = False
    # Enable/Disable SSE optimizations for capable CPUs
    EnableSSE = False
    # Use GPU vertex shader
    EnableVertexShader = True
    # If this option is enabled, the plugin will skip every other frame
    SkipFrame = False
    # If this option is enabled, the plugin will only draw every other screen update
    SkipScreenUpdate = True
    # If enabled, texture enhancement will be done only for TxtRect ucode
    TexRectOnly = False
    # If enabled, texture enhancement will be done only for textures width+height<=128
    SmallTextureOnly = False
    # Select hi-resolution textures based only on the CRC and ignore format+size information (Glide64 compatibility)
    LoadHiResCRCOnly = True
    # Enable hi-resolution texture file loading
    LoadHiResTextures = False
    # Enable texture dumping
    DumpTexturesToFiles = False
    # Display On-screen FPS
    ShowFPS = True
    # Use Mipmapping? 0=no, 1=nearest, 2=bilinear, 3=trilinear
    Mipmapping = 2
    # Enable, Disable or Force fog generation (0=Disable, 1=Enable n64 choose, 2=Force Fog)
    FogMethod = 0
    # Force to use texture filtering or not (0=auto: n64 choose, 1=force no filtering, 2=force filtering)
    ForceTextureFilter = 2
    # Primary texture enhancement filter (0=None, 1=2X, 2=2XSAI, 3=HQ2X, 4=LQ2X, 5=HQ4X, 6=Sharpen, 7=Sharpen More, 8=External, 9=Mirrored)
    TextureEnhancement = 6
    # Secondary texture enhancement filter (0 = none, 1-4 = filtered)
    TextureEnhancementControl = 0
    # Color bit depth to use for textures (0=default, 1=32 bits, 2=16 bits)
    TextureQuality = 0
    # Z-buffer depth (only 16 or 32)
    OpenGLDepthBufferSetting = 32
    # Enable/Disable MultiSampling (0=off, 2,4,8,16=quality)
    MultiSampling = 0
    # Color bit depth for rendering window (0=32 bits, 1=16 bits)
    ColorQuality = 0
    # OpenGL level to support (0=auto, 1=OGL_1.1, 2=OGL_1.2, 3=OGL_1.3, 4=OGL_1.4, 5=OGL_1.4_V2, 6=OGL_TNT2, 7=NVIDIA_OGL, 8=OGL_FRAGMENT_PROGRAM)
    OpenGLRenderSetting = 0
    # Enable/Disable Anisotropic Filtering for Mipmapping (0=no filtering, 2-16=quality). This is uneffective if Mipmapping is 0. If the given value is to high to be supported by your graphic card, the value will
    be the highest value your graphic card can support. Better result with Trilinear filtering
    AnisotropicFiltering = 0
    in reply to: Mupen64plus (ricrpi branch) #88392
    clone206
    Participant

    As I was first looking into the mario kart 64 two player issue I submitted an issue for mupen64plus. Just today I got a reply that might be useful to the ricrpi maintainer(s). See the reply from today (Feb 20) at the below link.

    I wonder if the rpi 2 is powerful enough to handle the vanilla mupen64plus-video-rice and mupen64plus-video-gln64 plugins. I get the sense they’d be compatible with more roms.

    https://code.google.com/p/mupen64plus/issues/detail?id=641

    in reply to: Mupen64plus (ricrpi branch) #88078
    clone206
    Participant

    @chdez77076 – Looks like the beginnings of one are here:

    https://github.com/ricrpi/mupen64plus/wiki/Game-Compatibility-List

    I’ve gotten a ton of roms to be very playable now between the default plugin and rice with these updated settings. I’m seriously neglecting important things in my life because of this!

    Also, I’ve gotten the default plugin to show both players’ screens in 2 player Mario kart 64 by setting “update mode=3” in gles2n64.conf, but the screen flickers so much it’s not really a workable solution. It’s a shame because it’s noticeably laggier with the rice plugin, to say nothing of the textures frequently being rendered incorrectly as black squares. There doesn’t seem to be much documentation out there on configuring the gles2n64 plugin. At least with the rice configs there’s heavy commenting.

    I have no idea what the numbers for “update mode” even correspond to!

    UPDATE: I figured out how to make the vast majority of the black boxes go away in mario kart 64 when using the rice plugin. This, in combination with the earlier changes to the settings I made, have got the rice plugin running pretty much on par with gles2n64 on the rpi 2. The trick was turning on texture filtering and using the “Sharpen” filter in /opt/retropie/configs/n64/mupen64plus.cfg under the Rice settings. So all of the relevant settings from that file are:

    [Video-Rice]
    ...
    # Frequency to write back the frame buffer (0=every frame, 1=every other frame, etc)
    FrameBufferWriteBackControl = 1
    ...
    # Control when the screen will be updated (0=ROM default, 1=VI origin update, 2=VI origin change, 3=CI change, 4=first CI change, 5=first primitive draw, 6=before screen clear, 7=after screen drawn)
    ScreenUpdateSetting = 7
    ...
    # If this option is enabled, the plugin will skip every other frame
    SkipFrame = False
    # If this option is enabled, the plugin will only draw every other screen update
    SkipScreenUpdate = False
    ...
    # Force to use texture filtering or not (0=auto: n64 choose, 1=force no filtering, 2=force filtering)
    ForceTextureFilter = 2
    # Primary texture enhancement filter (0=None, 1=2X, 2=2XSAI, 3=HQ2X, 4=LQ2X, 5=HQ4X, 6=Sharpen, 7=Sharpen More, 8=External, 9=Mirrored)
    TextureEnhancement = 6
    # Secondary texture enhancement filter (0 = none, 1-4 = filtered)
    TextureEnhancementControl = 0

    I am one happy camper :)

    in reply to: Mupen64plus (ricrpi branch) #87876
    clone206
    Participant

    Thanks, @gizmo98!

    In the past I’ve preferred to use the retropie packages script for source based installs, so I can catch any errors that come up. The setup script frustratingly goes back to the splash screen after any errors and then you can’t see what they were.

    I take it I can use that variable at some point during usage of the packages script too?

    in reply to: Mupen64plus (ricrpi branch) #87770
    clone206
    Participant

    In case anybody is interested, I figured out that it’s actually quite easy to switch video plugins. mupen64plus has a –gfx switch that allows you to specify which plugin to use. Retropie 2.5 comes with two customized plugins, which happen to also be the plugins used in ouya, which is why ouya users also face the mario kart 64 issue. These plugins are named gles2n64 and gles2rice.

    In retropie 2.5 gles2n64 is the default plugin used by mupen64plus. It actually looks quite a bit nicer – at least for composite video out – than gles2rice, which I believe used to be the default in previous versions. The problem is that gles2n64 tends to lock up on a lot of roms, and in the case of mario kart 64, it can only display one of the players’ screens.

    In order to use the gles2rice plugin only for certain n64 roms, I created a separate folder in the roms directory. Then I created a new system in es_systems.cfg, and specified that plugin using the –gfx switch within the command tags. Note that you also have to explicitly set the gles2n64 plugin using the –gfx switch within the command tags of the original system, or the other system will cause gles2rice to be written into the main mupen config file as the default plugin. I’m guessing there’s a more elegant way to accomplish this, so sorry if I’m leading anybody astray, but it was the best I could do with the knowledge I have. I know you can also edit plugin settings on a per-game basis via config files too.

    Below is the relevant config code for using my method. The path to the roms directory has also been changed from the default because I keep all my roms on a usb stick, so you can’t just copy and paste this into your /etc/emulationstation/es_systems.cfg file. Also, I added a “sudo” before the commands as I also store save data on the usb stick, and if the commands aren’t run as root, mupen can’t write to the fat32 formatted usb stick. I’ve also read that running as root can give performance gains.

      <system>
        <fullname>Nintendo 64</fullname>
        <name>n64-mupen64plus</name>
        <path>/media/usb0/r0ms/n64-mupen64plus</path>
        <extension>.z64 .Z64 .n64 .N64 .v64 .V64</extension>
        <command>sudo /opt/retropie/supplementary/runcommand/runcommand.sh 1 "/opt/retropie/emulators/mupen64plus/bin/mupen64plus --gfx mupen64plus-video-n64 --configdir /opt/retropie/configs/n64 --datadir /opt/retropie/configs/n64 %ROM%" "mupen64plus"</command>
        <platform>n64</platform>
        <theme>n64</theme>
      </system>
      <system>
        <fullname>Nintendo 64</fullname>
        <name>n64-mupen64plus</name>
        <path>/media/usb0/r0ms/n64-mupen-rice</path>
        <extension>.z64 .Z64 .n64 .N64 .v64 .V64</extension>
        <command>sudo /opt/retropie/supplementary/runcommand/runcommand.sh 1 "/opt/retropie/emulators/mupen64plus/bin/mupen64plus --gfx mupen64plus-video-rice --configdir /opt/retropie/configs/n64 --datadir /opt/retropie/configs/n64 %ROM%" "mupen64plus"</command>
        <platform>n64</platform>
        <theme>n64</theme>
      </system>

    Now I’m going through all my roms, and when I find one that doesn’t work with the default plugin, I simply move it over into the alternate folder (specified with the above config code) and relaunch emulationstation. Now there are two nintendo 64’s listed in emulation station, one for the default plugin, and one for the rice plugin. Of course, some roms don’t work with either plugin, but sometimes I get lucky. Majora’s Mask and Banjo Kazooie are two notable examples of roms that only work with the rice plugin for me.

    I haven’t been able to test 2 player mario kart 64 with the rice plugin as I need my friend to come back over with his controller (unless I can figure out how to specify player two as using the keyboard), but I’m hopeful it’ll work, as it seems to work for ouya users based on the reddit thread in my previous post.

    All in all, n64 games run much better on my raspberry pi 2 than they did on my b+. And I finally have working doom, duke nukem 3d, and quake III arena. I’ll post my overclock and memory split settings as well. It’s been pretty stable at these settings, but if I try to go up to 1140 the pi seems to freeze up and I get locked out. And I believe it was also the cause of sd card corruption, which is why I store roms, save data, and backups of config files on a usb stick now.

    gpu_mem=64
    arm_freq=1100
    core_freq=500
    sdram_freq=500
    over_voltage=6

    UPDATE: I got two player mario kart 64 to work with the rice plugin! I had to tweak some settings in /opt/retropie/configs/n64/mupen64plus.cfg to get it to work. With the default config both players’ screens just freeze before the race even starts. This seems to have to do with when the screen is redrawn. Under the “[Video-Rice]” section of the file I changed the following parameters. This also had the effect of making things look nicer too (smoother frame rate)

    ScreenUpdateSetting = 7
    ...
    SkipFrame = False
    SkipScreenUpdate = False

    Edit: Lowered gpu memory to 64 for better performance.

    in reply to: Mupen64plus (ricrpi branch) #87532
    clone206
    Participant

    Got the 2.5 image running on my raspberry pi 2. It was a breeze to get up and running, so thanks for the great work! The problem I’m now having is I can’t get 2 player to work in Mario kart 64 with mupen64plus. The bottom screen is blacked out so player 2 can’t see what they’re doing.

    Here’s the interesting part. The 2nd player can still control their character. For fun, I (as player 1) followed closely behind player 2 for an entire race so they could use me as a camera man and so they finished in 1st place. Then, when the next race started my (the top) screen was blacked out and theirs was now functional. We tried this scenario again with roles reversed (camera man vs lead player) and whoever came in 1st would always have the functional screen on the next race.

    To me, multiplayer Mario kart 64 is the holy grail of raspberry pi game emulation, so I’m really hoping to find a workaround. I suppose I could give the libretro version another shot, but the performance was horrible on the rpi 1.

    According to the below thread, ouya users were able to get around this by using a different video plugin in mupen64plus. Is there a straightforward way to change plugins in retropie? Does it require recompiling mupen?

    Emulator multiplayer?
    byu/duracellchris inouya

Viewing 16 posts - 1 through 16 (of 16 total)