@stumcbill
The only two things I can think of are

Drive is full File permissions issue

#1 is easy enough to check, #2 shouldn't be an issue as long as your USB drive is using the FAT32 file system.

When you say you manually save, if you mean through the game's normal save feature, you could try using a save state as an alternative. If a save state worked then it likely would mean that none of the above applies and it is something else.

@ashpool Ok thank you! I was worried there

@lostless OK, so I updated all packages, and now it's fixed.

@mitu оООО!
Oh thank you! on the hundredth attempt, it still worked itself

-magic!?))

@saku00 Sadly, I don't think it is. The only emulator I know of that even supports the DS-i is melonDS, which even then is still a WIP and not available on RetroPie at the moment.

@dankcushions Thanks. I prefer shaders, as the zFast gives you a nice touch of bilinear with scanlines. I found the curved version was slowing things down, but when I went with standard, it was fine. I guess that little extra processing step to warp the edges was just a little too much. When I remove that, things work pretty well (and look great).

@sleve_mcdichael thanks for taking the time to explain this :)

@sleve_mcdichael That seems to have sorted it, thanks very much :)

@mitu Okay sorry for wasting your time, I reinstalled it and it fixed the major issue that the diagonals were really slow. I didn't think it was a game profile issue cause it worked fine on dolphin 5.0. I'm not sure how it fixed it though.

@drdave79
You've already enabled OMX player, right? First guess then would be the videos have downloaded, but are in another format like yuv444p while they need to be in yuv420p (or at least that is one that is known to work.) If so, there's a simple script that can convert them for you when downloaded.

Check first: locate a game that doesn't show a video. Navigate to where the video should be, at:

/home/pi/.emulationstation/downloaded_media/<platform>/videos/<romname>.mp4

If the file exists, check it out with ffprobe (may require sudo apt install ffmpeg first):

ffprobe "filename.mp4" 2>&1 | grep Stream

Output will look something like:

Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv444p, 360x480 [SAR 1:1 DAR 3:4], 349 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default) Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 24000 Hz, stereo, fltp, 64 kb/s (default)

See in the Video stream where it says yuv444p, 360x480? That's bad, we want it to say yuv420p instead.

Sounds like you? Good. This post on GitHub discusses the solution. TL;DR version after:

https://github.com/muldjord/skyscraper/issues/222

The quick version:

Edit your /home/pi/.skyscraper/config.ini to include the line:

videoConvertCommand="videoconvert.sh %i %o"

Script provided by jgcobra on the GitHub thread:

#! /bin/bash # Script provided by jgcobra echo Converting video... echo Source: $1 echo Dest: $2 # Check if the video is already in 420p format c=$(ffprobe "$1" 2>&1 | grep -c yuv420p) if [ "$c" -eq 0 ] then echo Incorrect source video format detected. Converting video to 420p format... ffmpeg -i "$1" -y -pix_fmt yuv420p -acodec copy -strict experimental "$2" else echo Video is in correct 420p format. Copying as is... cp "$1" "$2" fi

Place the script in your system path or in /home/pi/.skyscraper and make it executable with chmod +x videoconvert.sh. If you want to see the script's output when run by Skyscraper, I think you need to put verbosity="3" in your config.ini.

I think this check/conversion only happens on initial caching of the video, so re-scrape your roms with --cache refresh to force a re-download and, for maximum efficiency, you can use --flags skipexistingcovers and similar to avoid unnecessarily redownloading those media.

This solved probably 90% of my problem videos. There were a handful that didn't take and I had to do a little extra fiddling, but this should get you started.

Don't forget to rebuild your gamelist.

Take a look at https://retropie.org.uk/docs/Keyboard-Controllers/#configuration-example-ipac.

Thank you @mitu, will get to that later :)

@shadyaw

I would like to know this also!

Sorry for providing hints into wrong direction. I must admit I did not follow the portable devices section of Nintendo HW well.

@bio_hazard1282 said in draStic on Raspberry Pi 400:

Turns out that I couldn't install it, is there a build of it for arm64?

No, there isn't. The binary provided by the developer(s) of DraStic is only for 32 bit ARM. Also note that we don't support Ubuntu on the Pi, so some things might not work correctly.