search

libretro / mupen64plus-libretro

Mupen64 Plus libretro core that stays compatible with upstream.
GNU General Public License v2.0
35 stars 34 forks source link

Update M64p + GlideN64 and/or ParaLLEl +GlideN64 to Latest Build #57

Closed Mikau28 closed 5 years ago

Mikau28 commented 6 years ago

Like the Title and referencing here: https://github.com/m64p/mupen64plus-GLideN64

Also referencing here as well: https://github.com/libretro/parallel-n64 https://github.com/libretro/parallel-n64/issues/528

I would personally add 100 dollars to this bounty to update the cores.

Papermanzero commented 6 years ago

This would/should be the reference: https://github.com/m64p/mupen64plus-GLideN64

ghost commented 6 years ago

...just some notes you have to undo the GAWK dependancy you have to wrap around the OpenGL instance factories that are in gliden64 also you also have to wrap around the abstract interfaces in mupen64plus you also have to redo parts of the asm code to fit that part is easy but for gliden64 its a bit tricky because of said C++ instance factories

some current code in this port of mupen is still relevant but there is a vast majority that isn't thanks to said code format changes.

inactive123 commented 6 years ago

Let's link to the bounty here -

https://www.bountysource.com/issues/60020750-update-mupen64-gliden64-bounty

Mikau28 commented 6 years ago

Alright 130!

Are there any devs contemplating the project yet?

Tasosgemah commented 6 years ago

If the parallel core would be easier to port GlideN64 to, we would be happy to apply the bounty towards that as well.

Mikau28 commented 6 years ago

Agreed, if any of the backers so far have objections please state your case. Otherwise, any update to n64 would be welcome.

Mikau28 commented 6 years ago

165!! Looking good!

Tasosgemah commented 6 years ago

Someone in Reddit suggested that instead of an update, porting the latest build from scratch may be a better (or easier) solution. Could this be a better idea then?

Papermanzero commented 6 years ago

It is a better idea. Just use m64p as reference, because maintaining the project would be then easier.

loganmc10 commented 6 years ago

m64p is just a buildbot that pulls the lastest upstream code and puts it all in a zip file, this project was already based purely on the upstream code when I abandoned it, keeping it up to date with upstream is more difficult than it might seem

Papermanzero commented 6 years ago

Well, but you added rumble support, transfer pak and a new audio async feature. So it seems it makes more sense to use this as reference.

Papermanzero commented 5 years ago

405 as bounty =)

Tasosgemah commented 5 years ago

I saw someone has set a goal at 700$

Mikau28 commented 5 years ago

I saw someone has set a goal at 700$

That person needs to come forward and let us know if they can do this. Otherwise, we shouldnt set a target to get people's hopes up.

m4xw commented 5 years ago

https://github.com/libretro/mupen64plus-libretro-nx WIP Repository.

Short breakdown: -HLE RSP: Done -GlideN64: TODO -Mupen64Core: Partially done (runs) --Fix savestates --Fix cheats --Fix configs --Fix dynarecs

It already runs, but currently only with interpreter. For future progress please check the Issue tracker

Tasosgemah commented 5 years ago

Thanks for the report. Finally, some progress!

m4xw commented 5 years ago

Small update:

Currently runs on Android (aarch64), Switch, Windows x64, PS Classic GlideN64 update is on the way, it compiles already, now just need to integrate mupen64plus_DisplayWindow for libretro and change some plugin api stuff

I also plan to port threaded AL (given the new x64 dynarec performs 25-50% better than before)

https://github.com/libretro/mupen64plus-libretro-nx/issues/11

Tasosgemah commented 5 years ago

Can i ask, will the libretro GlideN64 be on sync with the normal one, as it gets updates pretty regularly?

m4xw commented 5 years ago

Yes.

ghost commented 5 years ago

The parallel-n64 part is done.

https://github.com/mudlord/paraLLeXT

Feel free to claim the bounty for that portion. I want zero part of any money that comes from it.

Mikau28 commented 5 years ago

@m4xw can we award the bounty to you?

m4xw commented 5 years ago

@Mikau28 GlideN update isn't finished so I dont think it counts

Tasosgemah commented 5 years ago

Yeah, the graphics plugin is important and needs to be implemented IMO.

Mikau28 commented 5 years ago

How is the progress going on this so far?

m4xw commented 5 years ago

Well it partially works on some games (and crashes eventually). I didn't continue that as I take a short break from mupen currently.

jpsondag commented 5 years ago

How does retroarch do versioning of cores? It seems like mupen64plus had a new version 18 days ago (2.5.9), but the previous version was released in 2015.

https://github.com/mupen64plus/mupen64plus-core/releases

Does retroarch make a "retroarch" version of mupen64plus once per release; or does it make it's own build whenever it wants. (I'm interested in if this is pulling in ~4 years or changes or not...)

m4xw commented 5 years ago

@jpsondag We just rebase our changes whenever we see the need, but the old mupen core was abandoned, so yea we are currently pulling in years of code changes.

m4xw commented 5 years ago

The gliden branch is now functional, heres a preview (win64) with gliden 3.0 https://m4xw.net/nextcloud/index.php/s/2stZjmH5mZo9jZp

Beware of bugs :P

m4xw commented 5 years ago

rebased gliden, fixed more gl stuff, should now run somewhat stable ;) Will need more platform fixes tho before it goes live. I updated the build (same link as above)

Tasosgemah commented 5 years ago

Thanks. I tested F-Zero X and BlastCorps. Both seem to have the later fixes, which is awesome to see in RetroArch.

The only issue is that the core takes a lot of time to load. Like 20 seconds or more. RetroArch looks like is not responding for that time frame but the games load eventually.

m4xw commented 5 years ago

@Tasosgemah yea I assume thats because of shader compiling. Didn't look at that yet.

m4xw commented 5 years ago

Just a heads-up, fixed Android.

So I need to ask every contributor to the bounty, what are expected working platforms? Currently mupen64plus-next supports:

New GLideN64 (with -next) supports

I didn't try the 32bit variants but they should most likely just work. So my plan is to fix all currently supported platforms for -next, before submitting the bounty. So that would mean:

Is that sufficient for all of you? It would be expanded later on either way.

Tasosgemah commented 5 years ago

Fine by me.

m4xw commented 5 years ago

Updated bundle with Win64, Switch and Android aarch64. RE2, RS and others are now fixed, also lots of rendering fixes Got confirmation that Linux x64 works too.

https://twitter.com/m4xwdev/status/1108143295648223232

Tasosgemah commented 5 years ago

Thanks for the update. The fog in Beetle Adventure Racing's snow level is fixed as well.

m4xw commented 5 years ago

@Tasosgemah I have a mitigation for dynarec issues with Indiana jones too (only applied that to the aarch64 build for now tho). So you can ignore that issue (same with KI). Other than that, I need a good pair of 2nd eyes. Feel free to report anything you find here (including feedback in general) https://github.com/libretro/mupen64plus-libretro-nx/issues/4

Tasosgemah commented 5 years ago

Thanks again. I haven't tested many games yet since i know it's still WIP but the few ones i tried (with recent GlideN64 fixes) work nicely. My only complaint so far is the same i reported last time, regarding the loading ROM times, which is not a huge issue i guess, it just doesn't feel as "graceful" as all other cores :p

m4xw commented 5 years ago

It's close to be on par with standalone, so testing is now needed. I know a few things that work in standalone but not here yet, but the list is small.

jpsondag commented 5 years ago

Is there any chance you know what the issue is with dr. mario 64, either the pills are invisible or the graphics are totally scrambled depending on FBEmu options.

The issue is supposedly fixed in understood in Glide:

http://gliden64.blogspot.com/2014/01/frame-buffer-emulation-part-ii.html

There was a fix in 2017 in mupen64plus -core:

https://github.com/mupen64plus/mupen64plus-core/pull/477

but the github issue says it doesn't fix it for dynarec; I'm not sure how your new dynarec interacts (or if it interacts) with the dynarec mentioned in the github issue though.

loganmc10 commented 5 years ago

Dr Mario requires this option:

https://github.com/gonetz/GLideN64/blob/master/ini/GLideN64.custom.ini#L40-L42

If the pills aren't working, either that feature isn't implemented properly, or it doesn't pull in these kind of custom game settings that are needed

Tasosgemah commented 5 years ago

If Indiana Jones doesn't work in Windows i assume the same applies for Battle for Naboo for the same reason? It doesn't work on my end.

m4xw commented 5 years ago

@Tasosgemah Could be, will need to make a test build with stop after jal 1 to test it. Also let's discuss it in the Update GLideN64 Issue, so we don't spam the ppl subscribed here

@loganmc10 I think it's likely a issue with glsm or I borked the parser. Btw do you think exposing copyAuxToRDRAM is worth it? Are there actually a lot of games that use it or are most covered in the ini? Also while you are here, do you know if there will be a alternative for N64DepthCompare without the extension requirements?

loganmc10 commented 5 years ago

I'm not sure what you mean by "exposing", there isn't much use in giving users the option to turn it on or off, but I believe it is needed for Pokemon Snap to work:

https://github.com/gonetz/GLideN64/blob/master/ini/GLideN64.custom.ini#L133

The rest that use it are 64DD games.

GLideN64.custom.ini is an important component of GLideN64, there are a good number of games that need certain options enabled to work properly, I'm not sure if it's incorporated somehow into your port.

Also while you are here, do you know if there will be a alternative for N64DepthCompare without the extension requirements?

I'm not aware of any plans to replace/enhance N64 Depth Compare compared to how it works now (relying on a few OpenGL extensions).

pnkiller78 commented 5 years ago

Hi, I'm sure that the devolopers are aware of this https://gliden64.blogspot.com/2019/04/public-release-40.html, so my question is: Is the Public Release 4.0 code be included in the the final build of this work?

m4xw commented 5 years ago

Its only a bunch of commits away, we use it technically already.

m4xw commented 5 years ago

bob posted a $15 bounty

Guys no need to donate further to the bounty, I am close to done and don't need more.

cubatilles commented 5 years ago

Hi @m4xw , any further progress on this?

m4xw commented 5 years ago

@cubatilles everything is said and done. Only 2 things stopping me from merging rn: Not breaking raspberry (I don't own one, so cumbersome fix) and a regression for Android AArch64 with GLN64 4.0

Problem is also I am on vacation and other projects take far higher prio right now.

Tasosgemah commented 5 years ago

So these issues don't affect windows? If not, could there be a WIP version maybe to test on Windows?

When you are back from vacation ofc.

m4xw commented 5 years ago

@Tasosgemah Correct. https://m4xw.net/nextcloud/index.php/s/gTE8CtqeFKeDKHQ ^Thats GLideN64 4.0 (rebased thrGLN64 branch)