new: emulators/mupen64plus

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

new: emulators/mupen64plus

Stefan Sperling-8
New port of mupen64plus, a Nintendo 64 emulator.
http://code.google.com/p/mupen64plus/

Upstream has not made a new release for about a year which is a pity
because the current release has severe problems on OpenBSD.
As shipped, there are issues with the build system, hitting datasize limits,
segmentation faults due to failing allocations not being checked,
a black screen when all this is worked around, and so on...

I've fixed the buidsystem issues myself, only to realise later that upstream
already applied the same or similar Makefile fixes for OpenBSD.

The second challenge was getting the thing to actually run.
After generously applying a lot of patches from the upstream Mercurial
repository it seems quite happy here on amd64 with a radeon card.
Don't be surprised by the amount of backported code patches in this port.
They're all bugfixes upstream made during this year and should mostly
disappear when they finally issue a new release.

Game pad doesn't seem to work but I haven't investigated yet.
But keyboard control works fine. I've added a README that explains
the N64-game-pad to keyboard mapping.

OK to import this? Kill some productivity? You know you want it!

mupen64plus.tar.gz (30K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new: emulators/mupen64plus

stanleylieber
Builds on amd64.

-sl

Reply | Threaded
Open this post in threaded view
|

Re: new: emulators/mupen64plus

Anthony J. Bentley
In reply to this post by Stefan Sperling-8
On 12/18/11, Stefan Sperling <[hidden email]> wrote:
> New port of mupen64plus, a Nintendo 64 emulator.
> http://code.google.com/p/mupen64plus/

Considering the plugin format of mupen64plus, it might be better to
use bsd.port.subdir.mk and have a package for each plugin, and maybe a
meta-package for the standard configuration; tarballs for individual
plugins are at bitbucket.org. (I had a port that did this but I seem
to have lost it.) As a plus, we could use the same makefile for
wahrhaft's plugins, which are well maintained and work better for some
games.

> Upstream has not made a new release for about a year which is a pity
> because the current release has severe problems on OpenBSD.
> As shipped, there are issues with the build system, hitting datasize limits,
> segmentation faults due to failing allocations not being checked,
> a black screen when all this is worked around, and so on...
>
> I've fixed the buidsystem issues myself, only to realise later that upstream
> already applied the same or similar Makefile fixes for OpenBSD.
>
> The second challenge was getting the thing to actually run.
> After generously applying a lot of patches from the upstream Mercurial
> repository it seems quite happy here on amd64 with a radeon card.
> Don't be surprised by the amount of backported code patches in this port.
> They're all bugfixes upstream made during this year and should mostly
> disappear when they finally issue a new release.
>
> Game pad doesn't seem to work but I haven't investigated yet.
> But keyboard control works fine. I've added a README that explains
> the N64-game-pad to keyboard mapping.
>
> OK to import this? Kill some productivity? You know you want it!
>

Reply | Threaded
Open this post in threaded view
|

Re: new: emulators/mupen64plus

Jeremy Evans
In reply to this post by Stefan Sperling-8
On Sun, Dec 18, 2011 at 4:26 PM, Stefan Sperling <[hidden email]> wrote:

> New port of mupen64plus, a Nintendo 64 emulator.
> http://code.google.com/p/mupen64plus/
>
> Upstream has not made a new release for about a year which is a pity
> because the current release has severe problems on OpenBSD.
> As shipped, there are issues with the build system, hitting datasize limits,
> segmentation faults due to failing allocations not being checked,
> a black screen when all this is worked around, and so on...
>
> I've fixed the buidsystem issues myself, only to realise later that upstream
> already applied the same or similar Makefile fixes for OpenBSD.
>
> The second challenge was getting the thing to actually run.
> After generously applying a lot of patches from the upstream Mercurial
> repository it seems quite happy here on amd64 with a radeon card.
> Don't be surprised by the amount of backported code patches in this port.
> They're all bugfixes upstream made during this year and should mostly
> disappear when they finally issue a new release.
>
> Game pad doesn't seem to work but I haven't investigated yet.
> But keyboard control works fine. I've added a README that explains
> the N64-game-pad to keyboard mapping.
>
> OK to import this? Kill some productivity? You know you want it!

Awesome.  Some games are not playable (maybe my box isn't fast
enough), but a couple games are.  OK jeremy@.

Thanks,
Jeremy

Reply | Threaded
Open this post in threaded view
|

Re: new: emulators/mupen64plus

Stefan Sperling-8
In reply to this post by Anthony J. Bentley
On Sun, Dec 18, 2011 at 07:27:39PM -0700, Anthony J. Bentley wrote:

> On 12/18/11, Stefan Sperling <[hidden email]> wrote:
> > New port of mupen64plus, a Nintendo 64 emulator.
> > http://code.google.com/p/mupen64plus/
>
> Considering the plugin format of mupen64plus, it might be better to
> use bsd.port.subdir.mk and have a package for each plugin, and maybe a
> meta-package for the standard configuration; tarballs for individual
> plugins are at bitbucket.org. (I had a port that did this but I seem
> to have lost it.) As a plus, we could use the same makefile for
> wahrhaft's plugins, which are well maintained and work better for some
> games.

I'd prefer using the official release tarballs from code.google.com.
The plugins you're talking about are also available in an extra
packages hosted on code.google.com.

But I'll look into putting each plugin into a separate package.
Either via subdirs or multi-packages, not sure yet.
You're right that this will make adding new plugins easier in the future.

Reply | Threaded
Open this post in threaded view
|

Re: new: emulators/mupen64plus

Stefan Sperling-8
On Tue, Dec 20, 2011 at 10:45:56AM +0100, Stefan Sperling wrote:

> On Sun, Dec 18, 2011 at 07:27:39PM -0700, Anthony J. Bentley wrote:
> > On 12/18/11, Stefan Sperling <[hidden email]> wrote:
> > > New port of mupen64plus, a Nintendo 64 emulator.
> > > http://code.google.com/p/mupen64plus/
> >
> > Considering the plugin format of mupen64plus, it might be better to
> > use bsd.port.subdir.mk and have a package for each plugin, and maybe a
> > meta-package for the standard configuration; tarballs for individual
> > plugins are at bitbucket.org. (I had a port that did this but I seem
> > to have lost it.) As a plus, we could use the same makefile for
> > wahrhaft's plugins, which are well maintained and work better for some
> > games.
>
> I'd prefer using the official release tarballs from code.google.com.
> The plugins you're talking about are also available in an extra
> packages hosted on code.google.com.
>
> But I'll look into putting each plugin into a separate package.
> Either via subdirs or multi-packages, not sure yet.
> You're right that this will make adding new plugins easier in the future.
And here it is, with subdirs and a module infrastructure the plugin
ports can use. There is no meta package yet so all packages need to
be installed manually to get a functional emulator.

Currently all subdir ports compile from the same distfile.
For now they don't depend on one another because they compile without any
other parts of the emulator being installed. That will change when we add
plugins which don't belong to the main distribution. Eventually all plugins
should probably depend on the core being installed to catch issues with API
version mismatches at compile time.

Do people like this better than the previous port I sent?

mupen64plus.tar.gz (33K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new: emulators/mupen64plus

Anthony J. Bentley
In reply to this post by Stefan Sperling-8
Hi Stefan,

On 12/20/11, Stefan Sperling <[hidden email]> wrote:

> On Sun, Dec 18, 2011 at 07:27:39PM -0700, Anthony J. Bentley wrote:
>> On 12/18/11, Stefan Sperling <[hidden email]> wrote:
>> > New port of mupen64plus, a Nintendo 64 emulator.
>> > http://code.google.com/p/mupen64plus/
>>
>> Considering the plugin format of mupen64plus, it might be better to
>> use bsd.port.subdir.mk and have a package for each plugin, and maybe a
>> meta-package for the standard configuration; tarballs for individual
>> plugins are at bitbucket.org. (I had a port that did this but I seem
>> to have lost it.) As a plus, we could use the same makefile for
>> wahrhaft's plugins, which are well maintained and work better for some
>> games.
>
> I'd prefer using the official release tarballs from code.google.com.
> The plugins you're talking about are also available in an extra
> packages hosted on code.google.com.

My understanding is that Google Code is only used for bug tracking and
wiki, and all upstream development is done in Mercurial repos at
https://bitbucket.org/richard42. See
https://code.google.com/p/mupen64plus/wiki/CompilingFromHg

Upstream also suggests getting tarballs for individual plugins from
there, e.g., https://bitbucket.org/richard42/mupen64plus-core/downloads

Note that if you use individual tarballs, you'll need to set
BUILD_DEPENDS += emulators/mupen64plus/core:patch and APIDIR to point
to the right directory.

I don't know the advantages or disadvantages of creating
mupen64plus.port.mk versus just using bsd.port.subdir.mk, so no
comment there.

It looks like the license is GPLv2+, not GPLv2.

The new port builds fine on amd64 (can't test due to lack of OpenGL at
the moment). However, in both the rice-video plugin won't build on
i386 without CFLAGS=-DNO_ASM:

/../../mupen64plus-core/src/api -MD -c ../../src/RenderBase.cpp
../../src/RenderBase.cpp: In function 'void SSEVec3Transform(int)':
../../src/RenderBase.cpp:478: error: unknown register name '%xmm7' in 'asm'
../../src/RenderBase.cpp:478: error: unknown register name '%xmm6' in 'asm'
../../src/RenderBase.cpp:478: error: unknown register name '%xmm5' in 'asm'
../../src/RenderBase.cpp:478: error: unknown register name '%xmm4' in 'asm'
../../src/RenderBase.cpp:478: error: unknown register name '%xmm1' in 'asm'
../../src/RenderBase.cpp:478: error: unknown register name '%xmm0' in 'asm'
../../src/RenderBase.cpp: In function 'void SSEVec3TransformNormal()':
../../src/RenderBase.cpp:617: error: unknown register name '%xmm7' in 'asm'
../../src/RenderBase.cpp:617: error: unknown register name '%xmm6' in 'asm'
../../src/RenderBase.cpp:617: error: unknown register name '%xmm5' in 'asm'
../../src/RenderBase.cpp:617: error: unknown register name '%xmm4' in 'asm'
../../src/RenderBase.cpp:617: error: unknown register name '%xmm1' in 'asm'
../../src/RenderBase.cpp:617: error: unknown register name '%xmm0' in 'asm'
../../src/RenderBase.cpp: In function 'unsigned int SSELightVert()':
../../src/RenderBase.cpp:1266: error: unknown register name '%xmm5' in 'asm'
../../src/RenderBase.cpp:1266: error: unknown register name '%xmm4' in 'asm'
../../src/RenderBase.cpp:1266: error: unknown register name '%xmm3' in 'asm'
../../src/RenderBase.cpp:1266: error: unknown register name '%xmm1' in 'asm'
../../src/RenderBase.cpp:1266: error: unknown register name '%xmm0' in 'asm'

After building without ASM, it seems to run fine.

--
Anthony J. Bentley

Reply | Threaded
Open this post in threaded view
|

Re: new: emulators/mupen64plus

Stefan Sperling-8
On Tue, Dec 20, 2011 at 11:02:36AM -0700, Anthony J. Bentley wrote:
> Upstream also suggests getting tarballs for individual plugins from
> there, e.g., https://bitbucket.org/richard42/mupen64plus-core/downloads

I see. I didn't realise there were tarballs on bitbuckt with proper
version numbers stamped on them. I thought it was only possible to
get a tarball of some revision hash.

Thanks for your input! Attached is a new version that should hopefully
be fine.

mupen64plus.tar.gz (34K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new: emulators/mupen64plus

Stefan Sperling-8
On Wed, Dec 21, 2011 at 08:00:44PM +0100, Stefan Sperling wrote:

> On Tue, Dec 20, 2011 at 11:02:36AM -0700, Anthony J. Bentley wrote:
> > Upstream also suggests getting tarballs for individual plugins from
> > there, e.g., https://bitbucket.org/richard42/mupen64plus-core/downloads
>
> I see. I didn't realise there were tarballs on bitbuckt with proper
> version numbers stamped on them. I thought it was only possible to
> get a tarball of some revision hash.
>
> Thanks for your input! Attached is a new version that should hopefully
> be fine.

BTW, I'm seeing some rendering issues on i386 and amd64 with a NO_ASM-compiled
rice-video plugin (stuff like characters facing the wrong way or text not
being drawn properly when a dialog window is updated).

So I guess we should try the other video plugins, too.
But let's try to get this into CVS first.

Reply | Threaded
Open this post in threaded view
|

Re: new: emulators/mupen64plus

Anthony J. Bentley
In reply to this post by Stefan Sperling-8
On 12/21/11, Stefan Sperling <[hidden email]> wrote:
> Thanks for your input! Attached is a new version that should hopefully
> be fine.

Looks good to me... ok bentley@

On 12/21/11, Stefan Sperling <[hidden email]> wrote:
> BTW, I'm seeing some rendering issues on i386 and amd64 with a
> NO_ASM-compiled
> rice-video plugin (stuff like characters facing the wrong way or text not
> being drawn properly when a dialog window is updated).

Indeed, I see the same. I am also sure that with hg tip on i386 I
never had those artifacts, so NO_ASM was either fixed or not required
at some point. But I agree that this can wait till later. (It would
sure be nice for upstream to make a release...)

--
Anthony J. Bentley