Update Mupen+GlideN64 to latest 3.0


#21

Hey!

i’m glad you did thank you, i for one really want this as i mostly play n64.

i updated the git hub issue. is that better?


#22

Yeah, i believe m46p is a better reference since it’s the best setup of Mupen64+GlideN64 there is. But any update will be welcome in my book.


#23

Alright!

We are at 120! Any Devs want to offer feedback on how its looking? Does it seem enticing yet?


#24

Maybe an estimate of how much work that is?


#25

Reached out to Gonetz about the bounty and his thoughts about it. He let me know that with his schedule he has very little time to work on it. "Regarding libretro: unfortunately I have no time for porting tasks. I don’t mind to add support for new platforms or emulators in GLideN64 code, but I can’t work on it myself. If what w4st3d said is true, required amount of work is very large. " He also went on to say that help was asked in the task and no one responded. Here is a link to the thread: https://github.com/gonetz/GLideN64/issues/1544


#26

A and LOT…

/20 characters


#27

Maybe just include GlideN64 to ParallelN64?


#28

That would work too i suppose.

m64p is fine tuned to run every single game but ParaLLel (the core, not the plugin) is supposedly more accurate so maybe with the latest GlideN64 it can reach the same compatibility?


#29

I wouldn’t mind as long as the compatibility is there.


#30

It’s such a shame that we still have to use multiple emulators for N64. We have to use Retroarch cores if we want shaders and rewind (both of which are amazing). We have to use Project64 / GlideN64 for overclocking (only way to run Goldeneye / PD at 60fps) and for compatibility. Probably Mupen64 for some stuff that Project64 doesn’t like.

I honestly would put $100 into a bounty myself, if I didn’t think it was a black hole that would never actually get actioned. The amount of work is too great, and there just aren’t enough people with the required skills.


#31

m64p has a bit higher compatibility than PJ64 from my tests. So if this could be in RetroArch you would have both the highest compatibility possible right now and all the good RetroArch stuff (shaders, rewind, less input lag, etc),

The only thing missing would be the overclocking but hey.


#32

I wonder if it would be the same amount of work to include gliden64 into parallel. It is a fork after all if I’m not mistaken.


#33

Looked a bit at some of the issues and it’s still a porting issue regardless whether its the ParaLLE core or the mupen core. @Twinaphex would it be the same workload if the parallel core was updated instead of Mupen?


#34

ParaLLEL should be easier since it’s a RetroArch exclusive and not a port. Maybe it doesn’t even need to be updated at all. It’s pretty compatible as is when used with Angrylion (not as m64p but very close) with slowness being the only issue. So that means only GlideN64 needs to be worked on in that case. Unless there are incompatibility issues with this particular core and the plugin that need to be sorted out.


#35

That was my thinking as well, would you be ok if the bounty was applied to having gliden64 ported for either?


#36

Well, since you ask, i would be OK with any update at this point.


#37

Ok, I will address it on the github so it shows on the bounty. i might not be able to get to it for a few hours, would you want to post that on the github for me? just that were open to other avenues.


#38

PM me the words and i’ll post it


#39

Parallel N64 is much more of a hard fork.

I would prefer it in Parallel N64 since I don’t really like the idea of having to maintain two codebases that essentially boil down to the same thing (Mupen64plus), however, others liked that it was exclusive to gliden64.

So I dunno. Your choice. It’s not my bounty. You will have to manually cherrypick and backport fixes over anyway, there are multiple things in the mupen64plus codebase that are rather backwards from a libretro core perspective (such as the awk generation of certain files necessary for the dynarec, which is not really portable and not really something we want to do), so this backporting will require some effort anyway, whether it is going to be Parallel N64 or Mupen64plus repo.


#40

Ok i understand, it might be better to change the topic title to the bounty. @GemaH you are the only donation to respond, still ok with this change? i’m going to change the bounty to reflect parallel+gliden64.