Support SDL_mixer as an alternative to SDL_sound

fdelapena commented

2015-06-10 19:16:20 +00:00

(Migrated from github.com)

Because SDL_sound needs patching to works properly with SDL2, this makes packaging hard to achieve for existing GNU/Linux distributions.

Though SDL_mixer may not fit all SDL_sound features, I believe it is worth yet to consider. I could prepare an Autotools project to support SDL_mixer if available.

Because SDL_sound needs patching to works properly with SDL2, this makes packaging hard to achieve for existing GNU/Linux distributions. Though SDL_mixer may not fit all SDL_sound features, I believe it is worth yet to consider. I could prepare an Autotools project to support SDL_mixer if available.

cremno commented

2015-06-10 19:33:32 +00:00

(Migrated from github.com)

Did you read #36?

Ancurio commented

2015-06-10 20:55:40 +00:00

(Migrated from github.com)

Why would a distribution want to package mkxp?

fdelapena commented

2015-06-10 22:58:56 +00:00

(Migrated from github.com)

@cremno oops, didn't find the issue, thanks. Well, SDL_mixer mixing features can be managed from OpenAL. The useful remaining part could be the higher level loaders and without having to deal with every file format decoder before, but in this case I suggest libsndfile instead (except for MP3). The motivation of this issue is to get rid of SDL_sound due to its tricky setup.

@Ancurio not for distributions, however developers would have a easy way to try the interpreter. I believe this is good for the project development itself.

@cremno oops, didn't find the issue, thanks. Well, SDL_mixer mixing features can be managed from OpenAL. The useful remaining part could be the higher level loaders and without having to deal with every file format decoder before, but in this case I suggest [libsndfile](http://www.mega-nerd.com/libsndfile/) instead (except for MP3). The motivation of this issue is to get rid of SDL_sound due to its tricky setup. @Ancurio not for distributions, however developers would have a easy way to try the interpreter. I believe this is good for the project development itself.

Ancurio commented

2015-06-10 23:30:31 +00:00

(Migrated from github.com)

@fdelapena I still don't understand. There are the prebuilt binaries (even 32/64 bit on Linux), and I even recently added a kit of all dependencies so one can easily hack and compile custom versions of mkxp (on Linux).

What are you trying to achieve by cutting out SDL_Sound? It's not the only dependency where you cannot straight up use distribution provided dev packages. The new PhysFS is still not being packaged (as it still hasn't made a new release), libruby needs a small hack to embed the zlib module, and upstream SDL2 still has the one bug.

@fdelapena I still don't understand. There are the prebuilt binaries (even 32/64 bit on Linux), and I even recently added a kit of all dependencies so one can easily hack and compile custom versions of mkxp (on Linux). What are you trying to achieve by cutting out SDL_Sound? It's not the only dependency where you cannot straight up use distribution provided dev packages. The new PhysFS is still not being packaged (as it still hasn't made a new release), libruby needs a small hack to embed the zlib module, and upstream SDL2 still has the one bug.

fdelapena commented

2015-06-11 00:34:39 +00:00

(Migrated from github.com)

Oh, I didn't remember about the PhysFS issue too (missing pkg-config and such). Despite the existing upstream bugs, I still believe maintaining dependency kits or binaries from the project side takes time too, and having code workarounds to make it work with existing buggy upstream may be still worth.

Would you accept patches to make mkxp work with upstream packages if proposed?

Oh, I didn't remember about the PhysFS issue too (missing pkg-config and such). Despite the existing upstream bugs, I still believe maintaining dependency kits or binaries from the project side takes time too, and having code workarounds to make it work with existing buggy upstream may be still worth. Would you accept patches to make mkxp work with upstream packages if proposed?

Ancurio commented

2015-06-11 11:40:16 +00:00

(Migrated from github.com)

The PhysFS issue is not about pkg-config, it's about an entirely new feature (custom archive readers) which is missing from 2.0.

I still believe maintaining dependency kits or binaries from the project side takes time too, and having code workarounds to make it work with existing buggy upstream may be still worth.

The dep kit I probably won't have to update for a long time. Binaries are an easy automated process and don't really take long. All in all it's a lot saner than accommodating 3rd party software distributors in my own code.

Don't you remember when we talked on irc and we rigorously went through the SDL_mixer API up and down, and I showed you how it simply doesn't allow for streamed decoding?

The PhysFS issue is not about pkg-config, it's about an entirely new feature (custom archive readers) which is missing from 2.0. > I still believe maintaining dependency kits or binaries from the project side takes time too, and having code workarounds to make it work with existing buggy upstream may be still worth. The dep kit I probably won't have to update for a long time. Binaries are an easy automated process and don't really take long. All in all it's a lot saner than accommodating 3rd party software distributors in my own code. Don't you remember when we talked on irc and we rigorously went through the SDL_mixer API up and down, and I showed you how it simply doesn't allow for streamed decoding?

fdelapena commented

2015-06-12 05:18:48 +00:00

(Migrated from github.com)

Don't you remember when we talked on irc and we rigorously went through the SDL_mixer API up and down, and I showed you how it simply doesn't allow for streamed decoding?

Yeah, you're right. By the way, I hope PhysFS will release a new version soon, as SDL2 is preparing the 2.0.4.
Let's close the issue.

> Don't you remember when we talked on irc and we rigorously went through the SDL_mixer API up and down, and I showed you how it simply doesn't allow for streamed decoding? Yeah, you're right. By the way, I hope PhysFS will release a new version soon, as SDL2 is preparing the 2.0.4. Let's close the issue.

Rows
Columns

Support SDL_mixer as an alternative to SDL_sound #109