[herbfargus]

I know libcec3 has been requested on that fork for the same reasons with kodi, but I’m not sure how much changes would need to be made to update it.

Im also not sure if you can have both or if one will override the other and cause conflicts, I haven’t looked into it all that much to know one way or the other.

It would be cool though. If I was better at coding I’d do it myself, but I wouldn’t even know where to begin. Perhaps one day when I’m feeling really ambitious I may attempt it.

That recalbox idea is pretty cool too- its very similar to the joy2key thing we have set up now except it would be like a remote2key.

Kodi also has support for gamepads, but unfortunately our current build was compiled without joypad support. I’m also hoping that with the kodi 15 build we can enable the joypad support when we compile it so people can use their gamepads as well.

BTW there’s a ticket on github for these ideas to be implemented:

https://github.com/RetroPie/RetroPie-Setup/issues/879

[herbfargus]

I agree and I think its a great idea but there’s one issue in that the fork listed has support for libcec2 whereas kodi 15 needs libcec3 (which we’ll eventually be upgrading to) and it really just depends on how much petrockblog wants to maintain his fork of emulation station (since it already has the custom settings for controllers) ideally these things should be merged into the master emulationstation but aloshi hasn’t really done much with it since he got a job.

[herbfargus]

Try removing omxplayerin this file

/home/pi/RetroPie-Setup/scriptmodules/supplementary/splashscreen.sh

I added it as a dependency but if you’ve installed it manually that file doesn’t need it.

[herbfargus]

That may be possible. Openelec may have different drivers installed that work with your dongle that maybe retropie doesn’t have by default. It would be the simplest answer if you know it is functioning on the same exact hardware- Occam’s razor says it has to be the software.

[herbfargus]

Have you tried the setting under interfaces wireless-power off? That’s the only thing I can think of short of either your dongle going to pot or not getting enough power and needing a powered USB hub. See method two on this page:

https://github.com/RetroPie/RetroPie-Setup/wiki/Setting-Up-Wifi

[herbfargus]

That’s really odd. Have you tried lr-mgba? It was just moved out of the experimental menu- that’s the one that I use typically.

[herbfargus]

Thanks for your contributions :) I’ll add a link to the compatibility list on the wiki page as well.

[herbfargus]

Its possible its a bad build? You could try reinstalling the emulator from the setup script to see if that makes any difference. Also if your ROMs are zipped that may also explain it- you may need to unzip them first.

[herbfargus]

Just for reference I’ve added a post with the N64 compatibility list:

N64 Compatibility List!

[herbfargus]

This is the only thing I can think of off the top of my head short of hard coding configs without runcommand in emulationstation:

Command Line Access Toggler (for a cleaner look)

[herbfargus]

That’s a good idea on the n64 compatibility list. I might be able to come up with something (I’ll probably leave off regional variants though as it seems redundant to put in 5 versions of the same game.) Maybe once I have time over the weekend.

As far as your psx games being .ecm files- the source you got them from details how to extract them using a program called ecmtools. If you can’t find it Google it. They should be .bin and .cue files after extraction.

[herbfargus]

I’ve had better results with the PlayStation but its also hit and miss. And yes you’ll need a bios- see the wiki

https://github.com/RetroPie/RetroPie-Setup/wiki/Playstation-1

[herbfargus]

here’s a quick video I made just in case there is any confusion:

and yes ronoh55 I will look forward to netplay with you. you’re correct- if you just reinstall from the setup script it should install the latest updates.

[herbfargus]

If you built from RPI 3 beta 2 then in the retropie menu on emulation station there is an option called retropie-setup once you open that a new menu will open up. Near the end is an option to update the setup script. Choose that and then exit out of the script so it can reload the updated script (I just modified the code so in the future you shouldn’t have to restart the setup script) then once you go back into the setup script there is an option called experimental packages (option 4). Once you go into that super Mario war will be near the bottom of the list. Select that and it will compile it on your pi.

[herbfargus]

Update your setup script, don’t forget to restart the setup script. go into the experimental menu and install super Mario war.

[herbfargus]

It should be fixed now. I tested it for an hour with 3 bots and it ran perfectly. Thanks for submitting the request. Once he gets netplay sorted that will be fantastic.

[herbfargus]

The problem isn’t a matter of SD card capacity rather its a matter of how emulation station is coded/ the raspberry pi lacking sufficient CPU. There’s not a whole lot you can do about the issue other than thinning your ROM collection down. I’m not sure how accessing ROMs externally affects it (either USB or NAS).

[herbfargus]

That sounds about right for n64 emulation on the pi. You can try downloading mupen64plus testing from the experimental menu and changing it to your default emulator from x or m menu as the ROM loads but even then it will still be hit and miss. I stick with my PC for n64 emulation since the pi just doesn’t quite cut it yet for me.

[herbfargus]

Press f4 twice. Or any other button after you press f4 otherwise it will just automatically reboot back into emulationstation

[herbfargus]

http://android.stackexchange.com/questions/32663/is-it-technically-possible-to-run-android-on-ms-surface-windows-rt-tablet

I think it may technically be possible but you have to consider that the hardware they built the windows phone on was built to work with their OS (crappy as it was) so even if you were able to get it jailbroken to install Linux its unlikely everything would play nice without a ton of extra programming, kernel work, etc…

[herbfargus]

I think I can help you with the video asplashscreen. I apologise, I need to update the video as some of the paths have changed and I’ve figured a few things out since i first posted it as well that makes setting it up a little easier. I’ve been working with death259 on his PiAssist script and we’re hoping to integrate it that way as its a little easier than manually editing things, but we’re still working on that.

but until then if you’d like to edit it manually, here’s what you do. Ignore the whole old version of omxplayer- I found a workaround to make the new version work without dbus errors.

you need to edit the script here:
/home/pi/RetroPie-Setup/scriptmodules/supplementary/splashscreen.sh
and replace all the asplashscreens with splashscreen like the following

#!/usr/bin/env bash

# This file is part of RetroPie.
# 
# (c) Copyright 2012-2015  Florian Müller ()
# 
# See the LICENSE.md file at the top-level directory of this distribution and 
# at https://raw.githubusercontent.com/RetroPie/RetroPie-Setup/master/LICENSE.md
#

rp_module_id="splashscreen"
rp_module_desc="Configure Splashscreen"
rp_module_menus="3+"
rp_module_flags="nobin"

function depends_splashscreen() {
    getDepends fbi omxplayer
}

function enable_splashscreen()
{
    clear
    printHeading "Enabling custom splashscreen on boot."

    cp "$scriptdir/scriptmodules/$md_type/$md_id/splashscreen" "/etc/init.d/"
    chmod +x "/etc/init.d/splashscreen"

    find $scriptdir/supplementary/splashscreens/retropie2015-blue/ -type f > /etc/splashscreen.list

    # This command installs the init.d script so it automatically starts on boot
    update-rc.d splashscreen defaults

    # not-so-elegant hack for later re-enabling the splashscreen
    update-rc.d splashscreen enable
}

function disable_splashscreen()
{
    clear
    printHeading "Disabling custom splashscreen on boot."

    update-rc.d splashscreen disable
}

function choose_splashscreen() {
    printHeading "Configuring splashscreen"

    local options
    local ctr

    ctr=0
    pushd $scriptdir/supplementary/splashscreens/ > /dev/null
    options=()
    dirlist=()
    for splashdir in $(find . -type d | sort) ; do
        if [[ $splashdir != "." ]]; then
            options+=($ctr "${splashdir:2}")
            dirlist+=(${splashdir:2})
            ((ctr++))
        fi
    done
    popd > /dev/null
    cmd=(dialog --backtitle "$__backtitle" --menu "Choose splashscreen." 22 76 16)
    choices=$("${cmd[@]}" "${options[@]}" 2>&1 >/dev/tty)
    splashdir=${dirlist[$choices]}
    if [[ -n "$choices" ]]; then
        rm /etc/splashscreen.list
        find $scriptdir/supplementary/splashscreens/$splashdir/ -type f | sort | while read line; do
            echo $line >> /etc/splashscreen.list
        done
        printMsgs "dialog" "Splashscreen set to '$splashdir'."
    fi
}

function configure_splashscreen() {
    cmd=(dialog --backtitle "$__backtitle" --menu "Choose the desired boot behaviour." 22 86 16)
    options=(
        1 "Enable custom splashscreen on boot"
        2 "Disable custom splashscreen on boot"
        3 "Choose splashscreen"
    )
    choices=$("${cmd[@]}" "${options[@]}" 2>&1 >/dev/tty)
    if [[ -n "$choices" ]]; then
        case $choices in
            1)
                enable_splashscreen
                printMsgs "dialog" "Enabled custom splashscreen on boot."
                ;;
            2)
                disable_splashscreen
                printMsgs "dialog" "Disabled custom splashscreen on boot."
                ;;
            3)
                choose_splashscreen
                ;;
        esac
    fi
}

And then you’ll want to change this file:
/home/pi/RetroPie-Setup/scriptmodules/supplementary/splashscreen/asplashscreen
and change the filename to splashcreen like the following
/home/pi/RetroPie-Setup/scriptmodules/supplementary/splashscreen/splashscreen
and replace the contents with these:

#! /bin/sh
### BEGIN INIT INFO
# Provides:          splashscreen
# Required-Start:
# Required-Stop:
# Default-Start:     S
# Default-Stop:
# Short-Description: Show custom splashscreen
# Description:       Show custom splashscreen
### END INIT INFO

do_start () {

    while read splashline; do
        echo Playing splash video or image $splashline
        isMovie=$(echo $splashline | grep -o ".avi\|.mov\|.mp4\|.mkv\|.3gp\|.mpg")
        if [ -z "$isMovie" ]; then
            /usr/bin/fbi -T 2 -once -t 10 -noverbose -a $splashline
            sleep 12
        else
            omxplayer $splashline
        fi
    done </etc/splashscreen.list
    exit 0
}

case "$1" in
  start|"")
    do_start 
    ;;
  restart|reload|force-reload)
    echo "Error: argument '$1' not supported" >&2
    exit 3
    ;;
  stop)
    # No-op
    ;;
  status)
    exit 0
    ;;
  *)
    echo "Usage: asplashscreen [start|stop]" >&2
    exit 3
    ;;
esac

:

Remove the old asplashscreen with sudo rm /etc/init.d/asplashscreen

Then move your video into a folder like on the youtube video and then open up the setup script-

-choose option 3 setup

-Configure splashscreens

-enable splashcreen

-and then choose your new splashscreen (the folder with your video in it.)

sudo reboot

[herbfargus]

Unfortunately no. I double checked the patches and they all look correct, so outside of the patches I wouldn’t even know where to begin with the code. Hopefully fluffypillow has an idea- who knows, maybe once he finishes his build with netplay enabled we can just use that version instead- he’s made enough changes with the code that its possible the issue will have been fixed.

[herbfargus]

Dreamcast is already an option. You can install it from the experimental menu in the setup script. Its called reicast.

[herbfargus]

You transfer the bios over just like you would a ROM but instead of putting it in the ROMs folder you should put it in the BIOS folder.

[herbfargus]

My guess is it has something to do with these two:

https://github.com/HerbFargus/smw/blob/master/_src/ai.cpp

https://github.com/HerbFargus/smw/blob/master/_src/ai.h

It is possible I may have missed something manually running the patches as that was one of the files I patched but I’ll take another look at it tomorrow and see if I overlooked something.

[herbfargus]

That would be brilliant- if this last issue could be fixed I’d be ecstatic. I’ll peruse the code a bit but its doubtful I’ll come up with anything in my inexperience. Out of all the forks I’ve found this is the only one I’ve seen that has any development going on with it:

https://github.com/mmatyas/supermariowar

But it looks to be more of a netplay thing, idk.

[herbfargus]

according to this issue at the end : https://github.com/dborth/smw-wii/issues/29 its the AI (i.e. Bots) it’s the wii version but its based on the same code and sounds like the same issue. knowing its the bots narrows it down a lot.

[herbfargus]

It finally froze on me. out of curiosity were you playing with bots- and if so, how many? I never had it freeze just with two players but once I added two bots with me and my friend it started to freeze so it has something to do either with the bots, the number of players, or both.

[herbfargus]

Ha well that may be true (minus the glaring black screen bug that isn’t present in kodi 15…) but the package currently in the source code was compiled with the joystick flag disabled. I’m hoping in the next couple months we’ll have something that allows us to provide more convenient options for controls- I know its something I want, and I’m sure many others do as well.

[herbfargus]

There is a way, but it requires recompiling from source with the joystick flag enabled… I’m hoping once kodi 15 stable is released as an official package we can include joystick and cec support so people don’t run into these sort of issues.

[herbfargus]

Correct. You should be fine installing 3.0 rc1 now.

[herbfargus]

I tested it for another hour today on a fresh rpi2 3.0 rc1 build with two SNES USB controllers plugged in- no over clock and default memory split. I played it with a bunch of different game settings and I couldn’t reproduce the issue. It did have the pause menu show up at the beginning of each battle which is annoying but I just press the pause button to make it go away. So idk. Has anyone else had it freeze on them?

[herbfargus]

Mine was just stock straight from a rpi2 3.0 RC1 build. I didn’t over clock it or anything. Perhaps it has something to do with over clocking. I’ll have to test it more today and see if I can get it to freeze.

[herbfargus]

If you’re able to get moonlight sorted out I’m sure it would be appreciated. I don’t have a nvidia graphics card so I’m unable to test it myself.

[herbfargus]

Looks like you’re not the only one: see the compatibility lists:

Mame Rom Compatibility Lists

It just might not be compatible with that emulator. You could try pifba or advmame to see if you get any different results but they aren’t listed as working on either mame4all compatibility lists (I tested them both as well plus a few other people have verified what I’ve tested)

[Author]

Posts