SDL 2.0

233 views
Skip to first unread message

Vinícius dos Santos Oliveira

unread,
Jun 4, 2013, 11:08:43 AM6/4/13
to Mupen64plus
SDL 2.0 Finally In Release Candidate Stage:
http://www.phoronix.com/scan.php?page=news_item&px=MTM4MzU

According to Mupen64plus page on googlecode ( https://code.google.com/p/mupen64plus/ ) rumble support is limited to linux:
"Rumble - Instructions for setting up force-feedback (Linux only)"

One of the additions from SDL 2.0 is a force-feedback API for joysticks.

Are there any plans to support SDL 2.0 in the future of Mupen64plus (maybe version 3.0)?

--
Vinícius dos Santos Oliveira

Richard Goedeken

unread,
Jun 5, 2013, 1:03:27 AM6/5/13
to mupen...@googlegroups.com
Hello Vinícius,

We actually have support for SDL 2.0 which can be enabled at compile time, but I don't think that includes the new rumble functionality.  If someone sends a patch for this feature I would be happy to merge it.  We'll probably stick with SDL 1.2 for the Linux binary releases and leave this as a default in the source makefiles until SDL2 has been in the main distros for a few years, just to keep it easy for users.  We could build against SDL2 to get rumble in Windows and OSX in the near future though; that would be nice.

Richard
--
You received this message because you are subscribed to the Google Groups "mupen64plus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mupen64plus...@googlegroups.com.
To post to this group, send email to mupen...@googlegroups.com.
Visit this group at http://groups.google.com/group/mupen64plus?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Vinícius dos Santos Oliveira

unread,
Jun 6, 2013, 10:19:22 PM6/6/13
to Mupen64plus
2013/6/5 Richard Goedeken <Ric...@fascinationsoftware.com>

We actually have support for SDL 2.0 which can be enabled at compile time, but I don't think that includes the new rumble functionality.  If someone sends a patch for this feature I would be happy to merge it.  We'll probably stick with SDL 1.2 for the Linux binary releases and leave this as a default in the source makefiles until SDL2 has been in the main distros for a few years, just to keep it easy for users.  We could build against SDL2 to get rumble in Windows and OSX in the near future though; that would be nice.

That's good to know.

Thanks.

Sven Eckelmann

unread,
Jun 23, 2013, 5:40:15 AM6/23/13
to mupen...@googlegroups.com, Vinícius dos Santos Oliveira
On Thursday 06 June 2013 23:19:22 Vinícius dos Santos Oliveira wrote:
> 2013/6/5 Richard Goedeken <Ric...@fascinationsoftware.com>
>
> > We actually have support for SDL 2.0 which can be enabled at compile time,
> > but I don't think that includes the new rumble functionality. If someone
> > sends a patch for this feature I would be happy to merge it. We'll
> > probably stick with SDL 1.2 for the Linux binary releases and leave this
> > as
> > a default in the source makefiles until SDL2 has been in the main distros
> > for a few years, just to keep it easy for users. We could build against
> > SDL2 to get rumble in Windows and OSX in the near future though; that
> > would
> > be nice.
>
> That's good to know.

There are many different pull requests [1,2,3,4] available which add the
missing parts for a full SDL2 version of mupen64plus (this includes force
feedback support through SDL2). Mupen64plus was able to run with SDL2 since a
long time because SDL1.3/SDL2 was required by the people doing the Android
ports. The remaining changes were only for corner cases or when people want to
switch from SDL1.2 to SDL2 without changing their config.

Please feel free to test the changes. The SDL2 support can be enabled by
compiling all modules (yes, all modules which interact with SDL have to be
recompiled using SDL2) with the make parameter SDL_CONFIG=sdl2-config

e.g.: make -C projects/unix SDL_CONFIG=sdl2-config all

You can also pass this parameter when using the m64p build scripts.

But I think no graphical frontend for desktop machines (wxmupen64plus,
m64py, ...) currently supports SDL2.

Kind regards,
Sven

[1] https://bitbucket.org/richard42/mupen64plus-core/pull-request/55/use-sdl12-keysym-in-the-config-when-using
[2] https://bitbucket.org/richard42/mupen64plus-input-sdl/pull-request/21/use-sdl12-keysym-in-the-config-when-using
[3] https://bitbucket.org/richard42/mupen64plus-input-sdl/pull-request/22/add-support-for-mouse-based-analog-stick
[4] https://bitbucket.org/richard42/mupen64plus-input-sdl/pull-request/24/use-sdl2-to-play-force-feedback-effects
signature.asc

Richard Goedeken

unread,
Jun 25, 2013, 12:53:12 AM6/25/13
to mupen...@googlegroups.com
This is great Sven, thanks for your work on this. I will merge these after
the 2.0 release, which I'm targeting for the next couple of weeks.

Richard

Milan

unread,
Sep 28, 2013, 7:54:11 PM9/28/13
to mupen...@googlegroups.com, Ric...@fascinationsoftware.com
Hi,

M64Py now has support for SDL2. Windows bundle is packed with mupen64plus for SDL2.

In Linux you can use switch --sdl2 to force it, but it is not needed if core lib is built for SDL2.

Milan

hju...@pichamone.com.br

unread,
Jan 12, 2019, 3:30:43 PM1/12/19
to mupen64plus
I know this is a very old  post, but I could not build mupen64plus with SDL2 for Windows (Visual Studio 2013). Is there instructions to do so in Windows? Something like Sven's example (make -C projects/unix SDL_CONFIG=sdl2-config all )

Thank you for the patience


helvio jr

unread,
Jan 13, 2019, 10:54:58 AM1/13/19
to mupen...@googlegroups.com
Thank you for the fast reply. Congrats on the development, it's being a really great job. 

I've already tried building, but it throw many compiled errors. I'll try harder. I'm kind of amateur in the area.

What I did was:
- change all projects' alternative include path from the 1.2 folder to the 2.0.6 one;
- change dependencies for the link to include SDL2 libraries;
- included manually SDL2.dll after building (I'm sure there is somewhere to tell which files are copied to the final build folder (installed)).

Should be only that? Hope someone that understand details on VS projects could help. 

Helvio

Em sáb, 12 de jan de 2019 19:17, Richard Goedeken <Ric...@fascinationsoftware.com escreveu:
I think we are currently only supporting SDL 1.2 in Windows at the moment. You
could migrate to SDL2 if you like, without too much difficulty. You would need
to update the library in the mupen64plus-win32-deps module to add the header
and static/dynamic libs for SDL2, and then modify the MSVC project files to
build against the new library.

Richard
> --

Richard Goedeken

unread,
Jan 16, 2019, 10:29:43 PM1/16/19
to mupen...@googlegroups.com
Hi,

Your steps to migrate to SDL2 with the visual studio project files sound
correct. Can you pastebin the compiler errors that you get?

Richard

helvio jr

unread,
Jan 17, 2019, 10:39:19 AM1/17/19
to mupen...@googlegroups.com
I'm doing it slowly, as the time permits. I've got to solve some issues. The first one is the project directive to compile .c files as C++ (it's already that way on ui console's project, but some others weren't).

I found some trouble with lack of explicit cast (for example, using int instead of size_t, uint16_t assigned to a enum variable etc.). I solved that in one module. I'll try to fix all and, then, I'll post it, so you can see if it would impact Linux build.

Helvio

Em qui, 17 de jan de 2019 01:29, Richard Goedeken <Ric...@fascinationsoftware.com escreveu:
Hi,

Your steps to migrate to SDL2 with the visual studio project files sound
correct. Can you pastebin the compiler errors that you get?

Richard

-- 

Richard Goedeken

unread,
Jan 21, 2019, 8:48:57 PM1/21/19
to mupen...@googlegroups.com

OK, send us a link if you get any compile/link errors which you cannot resolve.

I think it should not be necessary to compile any additional C files as C++. I know that I had to configure many projects that way with earlier versions of MSVC, because it did not support the C99 feature of defining variables in the middle of a function in a C file. That was really frustrating. But with MSVC 2013 they finally added support for this, so most if not all of the C files should be compilable in C mode.. The problem (as you have discovered) with building them as C++ is that the C++ standard is more strict about type checking and refuses to automatically typecast even very simple things, instead throwing errors. So you have to explicitly typecast everything.

Richard

helvio jr

unread,
Jan 29, 2019, 8:48:55 PM1/29/19
to mupen...@googlegroups.com
Yes, a noticed some projects were like that and some cannot be compiled as C++ at all. Each one has different issue. I'm sorry if I couldn't look at this job last weeks, as I've got busy at the office. I'm planning to restart thisweek.

--
You received this message because you are subscribed to a topic in the Google Groups "mupen64plus" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mupen64plus/KcACa5wJYr4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mupen64plus...@googlegroups.com.

To post to this group, send email to mupen...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages