Closed joolswills closed 8 years ago
Also your repo is forked from gizmo98 repo rather than upstream - in terms of the github git gui etc, would it be better to fork from the actual upstream and re merge your changes, so then github will give useful information in regards to how far ./ behind you are from the main repo, rather than gizmo98's one ?
Sorry more questions - upstream seems to have alsa support too - would be good to use that rather than oss.
Here's the fix for the shm_open failing -
Oh, awesome! I haven't looked at it in a bit, but yeah I hadn't gotten any feedback from my pull request to reicast upstream... seems like more fixes were merged in so maybe its time to refork and rebase.
Thanks!
The patch is now upstream, plus they have merged their rapi2 branch back in I think. Would be nice to at least get this in your github so we can remove the tmpfs stuff from the module, even if you don't have time currently to rebase your stuff over upstream.
Very nice - I'll take a look at merging these changes into my reicast retropie branch once I get half a chance, I'd like to get rid of the tmpfs as well.
Any news ? I am keen to ditch the tmpfs stuff, so I'll add a patch to the script, or fork your repo if you don't have the time (I realise rebasing against upstream is some work, but in the meantime I'd like to include the small fix for the shm_open).
That might be faster; I've been swamped at work lately and am not sure when I'll get a chance to get back on this. Feel free to fork and apply the fix, and I can pick up from there later when I've got a little free time again.
Thanks!
Push. Any update here?
well, there is one patchset that still could be applied regarding the shm_open fix, but tbh we should revisit using the upstream release again. It may still lack some of @free5ty1e 's features but it's in development and his fork is dead (and is going to be problematic to maintain since upstream did not accept the patchsets and went another route - so they may have implemented some of the functionality, but not necessarily in the same way)
Ok. I will take a look if it upstream is working now. I think they use another joypad configuration know. If this cannot be sorted out fast is there any reason to keep this module experimental? Joypad config should be easy now with this input script https://github.com/RetroPie/RetroPie-Setup/issues/1100. I did not experience any crash.
I would prefer it to stay in experimental at least until the things I mentioned have been sorted/looked into.
But input script can be merged so the interested user can test reicast easily?!
if it works (not throwing errors) without reicast being installed sure
Upstream seems to work: https://github.com/gizmo98/RetroPie-Setup/blob/reicast-update/scriptmodules/emulators/reicast.sh
Supports OSS and ALSA. Keyboard can be used as input device. There is a new joypad mapping style which is not compatible with our current repo. Input script has to be modified.
I'm happy to test any new changes :)
I can confirm that it builds but yes definitely needs controller updates.
There is a joypad setup script under /opt/retropie/emulators/reicast/bin. Joypad config must be stored in "a" file (*.cfg with any name) under /opt/retropie/configs/dreamcast/mappings. Finally i think open /opt/retropie/configs/dreamcast/emu.cfg and select evdev device you are using for player1-4 (I have a setup with controllers and joypads. /dev/input/js0 is /dev/input/event2 device. /dev/input/event0-1 device is keyboard).
I don't know why we use tmpfs. What was the reason?
@HerbFargus You can try this out if you like: https://github.com/gizmo98/RetroPie-Setup/commit/292d0443991c07357265a3d881abaffbd037d0e3
I'm in the middle of exams but ill try to give it a go when I can find a spare moment
looking good - thanks for the efforts!
@HerbFargus Do your exams. If you have some spare moments time relax or do something else. It's not that important. ;-)
@joolswills I will test some more before doing a PR. I'm still not certain why tmpfs was used. ALSA audio backend has some crackle. OSS seems to be a little bit better.
tmpfs was originally used due to a problem with https://github.com/reicast/reicast-emulator/issues/601#issuecomment-74723710
once that was fixed some code was reverted, but incorrectly which I fixed with:
https://github.com/reicast/reicast-emulator/pull/680
so any tmpfs stuff can be nuked in the module
Cheers!
OSS on the rpi requires the alsa OSS emulation layer, so sounds like a bug in their alsa code (or yet another bug in rpi alsa). we can dig into that i'm sure.
I think both plugins have sometimes short audio interruptions. If OSS backend is used there is no sound at all. If ALSA backend is used you can hear an audible "clonk". I will keep OSS because "clonk" sound is more irritating.
@joolswills @HerbFargus Reicast seems to run quite well and it did not crash anytime. Some games do not run full speed but other emulators have the same problem. We use upstream "with tweaks" now. These tweaks are not necessary to build and run successfully. We can switch to upstream anytime if necessary. Is there still a reason to keep this module experimental any longer?
It runs better than the n64 (for some games) so I don't see any reason to keep it in experimental. Same could be said for psp probably as well.
If they run fine we could do this as well.
I will do this before the next release
I think this can be closed now.
@free5ty1e I have made some minor changes to the reicast.sh launch script. I am planning to look into not having to use the tmpfs stuff - just was wondering about the state of your repo vs upstream - I see you did submit some stuff upstream - did it get manually squashed/merged etc ?