Release Preview: Mupen64Plus 2.0 Video


Ok, I'll check and try to integrate their core update.
If you could structure it as a git fork of their repo, you can then get their future core updates "for free" by just doing "git pull". If you can put it on a public git so I can clone and build it for pandora, I could probably take a stab at some dynarec bugs too (eventually, not right now as I'm busy).

I just hope it doesn't end up with what we had with 1.x, with lots of tarbals all over the net, and where the source more or less got lost over time..
I'll be working the Open Pandora project into our repository once it is public.  This will probably prompt some restructuring of our folders (that is one of the reasons I've been wanting to incorporate an Open Pandora port - to help keep our repository more in-line with upstream Mupen64Plus).  I'll be releasing updates along with the Android updates when the logistics are worked out, and pull in fixes from these other projects when there is anything useful.
That's great. But how should I structure my sources? For now, they have the mupen64plus structure, and I planned to create a git with that structure. Will it be ok for you?
 
Ok, I'll check and try to integrate their core update.
If you could structure it as a git fork of their repo, you can then get their future core updates "for free" by just doing "git pull". If you can put it on a public git so I can clone and build it for pandora, I could probably take a stab at some dynarec bugs too (eventually, not right now as I'm busy).

I just hope it doesn't end up with what we had with 1.x, with lots of tarbals all over the net, and where the source more or less got lost over time..
I'll be working the Open Pandora project into our repository once it is public.  This will probably prompt some restructuring of our folders (that is one of the reasons I've been wanting to incorporate an Open Pandora port - to help keep our repository more in-line with upstream Mupen64Plus).  I'll be releasing updates along with the Android updates when the logistics are worked out, and pull in fixes from these other projects when there is anything useful.
Hey, the man who gave me hope is back.

Maybe we'll see something from you now.

:)
 
Please stop asking ptitSeb whether x or y is working well with the emulator. You'll experience soon enough once the emulator is released.
 
That's great. But how should I structure my sources? For now, they have the mupen64plus structure, and I planned to create a git with that structure. Will it be ok for you?
I believe he wants it as close to the original mupen64plus structure as possible.
 
@ptitseb: dont try to make everyone happy. if you've kept the original structure it's the way to go to put on github. if another fork changed the structure, it's not your fault, and the forks author is responsible to adapt
 
That's great. But how should I structure my sources? For now, they have the mupen64plus structure, and I planned to create a git with that structure. Will it be ok for you?
I believe he wants it as close to the original mupen64plus structure as possible.
Xperia64 is correct, I would prefer to have the code as close to the original folder structure as possible, with the Android project in its proper place (wish I would have done so from the start).  If it were just me working on the source, I would just scrap it and do the restructure now, but in order not to step on everyones toes, I think it will have to be done incrementally.  So just release it in whatever folder structure you prefer, and I'll work it in.  My hope is that having more than just an Android project will provide the momentum needed to prompt a folder restructuring to bring our repository more in-line with Richard's.
 
Ok, I'll create a git with a vanilla structure. I'll probably start slowly this week end....
Woo! I guess you finally worked git out :)


Best thing about Retrode integration is it works on all mupen builds :D
 
Last edited by a moderator:
We are actually gearing up for the big "3.0" Android UI overhaul, so the timing might be perfect for rearranging the folders as well..
 
Ok, I'll create a git with a vanilla structure. I'll probably start slowly this week end....
Perfect!  Not sure if you prefer github or bitbucket, but if you go with github, I'll add you to our repository too in case you want to make any edits when you come across them -- just a friendly gesture, not meant to be any kind of obligation :)
 
Last edited by a moderator:
Ok, I'll create a git with a vanilla structure. I'll probably start slowly this week end....
Perfect!  Not sure if you prefer github or bitbucket, but if you go with github, I'll add you to our repository too in case you want to make any edits when you come across them -- just a friendly gesture, not meant to be any kind of obligation :)
I prefer github. I already have a few repo there, under my nickname.

Thanks :)
 
Just a few screenshots more.

With Rice and GLES2 (mipmapping off)

Stacarft64:  starcraft64.png (playable, speed looks good).

F-Zero X:fzerox-4p.png (very fluid, even with 4 player on screen).

Perfect Dark:perfectdark.png (looks ok, a few graphical artefact here and there, but freeze after a few minutes).

With Glide

StarWars Ep1. Racers:swep1racer.png (need many frameskip, still playable).

Monster Truck Madness 64: monstertruck.png (need frameskip, a bit jerky for now).

I still have to refine the Frameskip code on Glide, have a hard time finding the right formula, but things keeps going on the right direction :) .
 
Last edited by a moderator:
Just a few screenshots more.

With Rice and GLES2 (mipmapping off)

Stacarft64: 
attachicon.gif
starcraft64.png (playable, speed looks good).

F-Zero X:
attachicon.gif
fzerox-4p.png (very fluid, even with 4 player on screen).

Perfect Dark:
attachicon.gif
perfectdark.png (looks ok, a few graphical artefact here and there, but freeze after a few minutes).

With Glide

StarWars Ep1. Racers:
attachicon.gif
swep1racer.png (need many frameskip, still playable).

Monster Truck Madness 64: 
attachicon.gif
monstertruck.png (need frameskip, a bit jerky for now).

I still have to refine the Frameskip code on Glide, have a hard time finding the right formula, but things keeps going on the right direction :) .
With perfect dark, I believe last time I tested it, it wasn't a dynarec or gfx plugin issue. It was an issue with the mupen64plus core or something, as it also froze using both of the interpreter types.
 
Last edited by a moderator:
AFAIR, ptitseb planned to have it in a few weeks.

But that heavily depends on how optimizations are coming along.

Often in coding, when you think something doesn't need much time, it takes a lot longer.
Thanks for the answer, ED.

Carry on testing, guys, I will check back in "a few weeks" and see if there is progress.

I find it exciting to know there will (hopefully) be an awesome N64 emu available, thanks to ptitseb for his hard work, and the testers who are ironing out any bugs right now before a public release!

Now, see how nice I can be when people are nice to me?
 
Back
Top