mupen64plus-libretro-nx
mupen64plus-libretro-nx copied to clipboard
Fix OSX with Angrylion
Not a final version. But we can start discussing some fixes here.
Because of your absence on the last PR, OSX support comes in through https://github.com/libretro/mupen64plus-libretro-nx/pull/286/files which is in staging.
I will consult with ethan
OK I updated this PR with the change on the types.
The changes I see in https://github.com/libretro/mupen64plus-libretro-nx/pull/286/files are not enough to compile the core on my machine.
Please note that this core segfaults in RetroArch on OSX in BufferedDrawer::_updateRectBuffer
.
The only place where I got it to work on OSX was in Ludo by forcing angrylion+cdx4.
OK I updated this PR with the change on the types.
The changes I see in https://github.com/libretro/mupen64plus-libretro-nx/pull/286/files are not enough to compile the core on my machine.
Please note that this core segfaults in RetroArch on OSX in
BufferedDrawer::_updateRectBuffer
. The only place where I got it to work on OSX was in Ludo by forcing angrylion+cdx4.
With all the last changes? Ethan had it functional with Gliden iirc
We will need to ifdef the GL proto change btw, apparently apple is a snowflake and uses a different typedef than khronos states?
@m4xw I think we can merge this, what do you think?
It doesn't allow GL renderers, but at least allows Angrylion. And it doesn't break anything.
The core does not allow for compiling without gliden so I don't want to merge AL only support that still compiles gliden. Its really the min standard. As is users would get crashes on start since you didnt adapt the default either and its already proven to work on osx at least, so find out where its crashing lol.
Oh I was thinking that it would simply default to angrylion on libretro frontends that don't support hardware renderers.
Oh I was thinking that it would simply default to angrylion on libretro frontends that don't support hardware renderers.
I wouldnt mind if we make gliden optional, but thats a bunch of work..
Oh I was thinking that it would simply default to angrylion on libretro frontends that don't support hardware renderers.
I wouldnt mind if we make gliden optional, but thats a bunch of work..
Does OSX currently work with GlideN64 (as opposed to AngryLion)? I've only gotten crashes and assumed it was incompatible.
It used to with simliar minimal changes. Someone needs to take a look...
Any updates on this, or should I just fire up a VM?
EDIT: I incorporated these changes and while it successfully built, the core crashes on launch.
Any updates on this, or should I just fire up a VM?
EDIT: I incorporated these changes and while it successfully built, the core crashes on launch.
yea u need to default to angrylion
It looks like the hardware renderer if working now:

I didn't change anything though. So maybe something changed in RA? I got this running with RA, master branch, compiled with ./configure && make I couldn't get it to run in the RA stable release, it was crashing.
With RA from xcode it segfaults on:
opengl::BufferedDrawer::_updateRectBuffer(graphics::Context::DrawRectParameters const&) + 653
This pull request fixes 1 alert when merging 9aede57264f4d24ad887f26f2b69468e33812db2 into 018ee72b4fe247b38ed161033ad12a19bb936f00 - view on LGTM.com
fixed alerts:
- 1 for Implicit function declaration
was this ever finished?
Yeah id love to know as well
This pull request fixes 1 alert when merging ccc02929095b404522cd1dccedab3a7592a75d23 into c10546e333d57eb2e5a6ccef1e84cb6f9274c526 - view on LGTM.com
fixed alerts:
- 1 for Implicit function declaration
closed in favour of #474