Thread: [tuxracer-devel] glTron music
Status: Beta
Brought to you by:
jfpatry
Menu
▾
▴
tuxracer-devel
|
From: Dave M. <dp...@ef...> - 2000-03-27 17:04:41
|
>> I've had a look at gltron >> and it seems to be very easy to use SDL_mixer to play music. The >> quality is excellent too. It uses pthreads so no explicit updates >> are necessary, which should solve the problems reported by Steve with >> libmikmod. > >To the contrary - glTron is the game I have most trouble with. When >the audio is turned on, the frame rate (on even a static scene) jumps >from better-than-60Hz to worse-than-5Hz about once a second - making >the game utterly unplayable. > >It doesn't do this on all machines - which is strange. > Just curious. Are you both talking about the latest glTron with SDL? I think Andreas just recently starting using SDL. |
|
From: Jasmin P. <jf...@mu...> - 2000-03-27 22:40:43
|
On Mon, 27 Mar 2000, Dave McClurg wrote: > >To the contrary - glTron is the game I have most trouble with. When > >the audio is turned on, the frame rate (on even a static scene) jumps > >from better-than-60Hz to worse-than-5Hz about once a second - making > >the game utterly unplayable. > > > >It doesn't do this on all machines - which is strange. > > > > Just curious. Are you both talking about the latest glTron with SDL? > I think Andreas just recently starting using SDL. Yes, I am. My guess from past posts is that Steve has only tried the old version that uses libmikmod -- though I'd be very interested to hear otherwise. Steve, do you mind if I quote portions of your messages on this topic to the SDL/SDL_mixer people? I'd like to hear what they have to see on the topic. Cheers, Jasmin P.S. Btw, I didn't receive a copy of Steve's message that Dave's message is in reply to. It's not in my procmail logs so I know I didn't delete it accidentally. Weird. (It's in the archives, though.) |
|
From: Steve B. <sjb...@ai...> - 2000-03-28 04:22:17
|
Jasmin Patry wrote: > > Just curious. Are you both talking about the latest glTron with SDL? > > I think Andreas just recently starting using SDL. > > Yes, I am. My guess from past posts is that Steve has only tried the > old version that uses libmikmod -- though I'd be very interested to hear > otherwise. Erm - I'm not sure - my son and I played it for a while and then dumped it when the gameplay wore a bit thin. If the SDL version is under a month old then we probably have the pre-SDL version. I presume that since the problem appears to be in MikMod that it would apply just as much to SDL - but since the symptoms don't show up on all CPU speeds, it's kinda touchy. > Steve, do you mind if I quote portions of your messages on this topic to > the SDL/SDL_mixer people? I'd like to hear what they have to see on the > topic. Sure - although I'm sure they are aware of the issues. The bottom line (for me at least) is that you need to have a call into the sound generation/mixing stuff to tell it how much it's allowed to generate ahead of time each time it's called. Only the application can know how long that should be. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jasmin P. <jf...@mu...> - 2000-03-29 04:07:08
|
On Mon, 27 Mar 2000, Steve Baker wrote: > Jasmin Patry wrote: > > Erm - I'm not sure - my son and I played it for a while and then dumped it > when the gameplay wore a bit thin. If the SDL version is under a month > old then we probably have the pre-SDL version. 0.59 beta (the first version to use SDL) was released on 5 March 2000. > The bottom line (for me at least) is that you need to have a call into > the sound generation/mixing stuff to tell it how much it's allowed to > generate ahead of time each time it's called. Only the application can > know how long that should be. Yes, I agree. I did some digging in SDL and SDL_mixer today and it does allow you to specify how much data to buffer. I'm not sure if it allows you to change that amount at run-time, but that seems to be an improvement over the libmikmod mixer. There are potential problems due to the non-determinism of thread scheduling, but my guess is that in practical situations this shouldn't be a problem. One disadvantage of SDL is that it's not as portable as PLIB (Linux is the only fully supported UNIX-type platform). I'll look into integrating the libmikmod code (loaders/players) into SL, if it's something you'd like to see added to PLIB. Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Steve B. <sjb...@ai...> - 2000-03-29 06:03:29
|
Jasmin Patry wrote: > > On Mon, 27 Mar 2000, Steve Baker wrote: > > > Jasmin Patry wrote: > > > > Erm - I'm not sure - my son and I played it for a while and then dumped it > > when the gameplay wore a bit thin. If the SDL version is under a month > > old then we probably have the pre-SDL version. > > 0.59 beta (the first version to use SDL) was released on 5 March 2000. > > > The bottom line (for me at least) is that you need to have a call into > > the sound generation/mixing stuff to tell it how much it's allowed to > > generate ahead of time each time it's called. Only the application can > > know how long that should be. > > Yes, I agree. I did some digging in SDL and SDL_mixer today and it does > allow you to specify how much data to buffer. I'm not sure if it allows > you to change that amount at run-time, but that seems to be an > improvement over the libmikmod mixer. There are potential problems due > to the non-determinism of thread scheduling, but my guess is that in > practical situations this shouldn't be a problem. > > One disadvantage of SDL is that it's not as portable as PLIB (Linux is > the only fully supported UNIX-type platform). I'll look into > integrating the libmikmod code (loaders/players) into SL, if it's > something you'd like to see added to PLIB. I believe that someone looked at that once before. I don't think it's impossible - but it may not be that easy either. SL works with a central mixer that asks the various music sources: "Please make me X milliseconds of audio right now" ...hence the sources have to be able to make a particular amount of sound on-demand. Since MikMod doesn't let you tell it how much to generate, that's not likely to work. However, if we only used MikMod for music, we would probably care much less about latency. Hence we could call MikMod to create however much it feels like - store it in a buffer and just hand 'X' bytes over to SL - keeping what's left for next time. Not very elegant - but it ought to be do-able. Personally, I hate to add dependancies on yet more libraries since that adds so much to support hassles down the line. So, given the choice, I'd prefer to add whatever new music formats to the existing MOD player in SL rather than constructing some elaborate kludge to get MikMod's player to drive SL's mixer. I'm biassed though...and right now, I don't have time to do either modification. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jasmin P. <jf...@mu...> - 2000-03-29 22:51:47
|
On Wed, 29 Mar 2000, Steve Baker wrote: > Jasmin Patry wrote: > > > > One disadvantage of SDL is that it's not as portable as PLIB (Linux is > > the only fully supported UNIX-type platform). I'll look into > > integrating the libmikmod code (loaders/players) into SL, if it's > > something you'd like to see added to PLIB. > > I believe that someone looked at that once before. I don't think > it's impossible - but it may not be that easy either. > > SL works with a central mixer that asks the various music sources: > > "Please make me X milliseconds of audio right now" > > ...hence the sources have to be able to make a particular amount > of sound on-demand. Since MikMod doesn't let you tell it how > much to generate, that's not likely to work. Actually, it does let you tell it how much sound to generate, and that's what SDL_mixer does. SDL_mixer doesn't use any of libmikmod's supplied drivers or mixers (it sets up its own libmikmod driver using mikmod's "virtual channel mixer interface"), and calls mikmod's VC_WriteBytes( buffer, len ) to fill the audio buffer. It looks fairly straightforward. > Hence we could call MikMod to create however much it feels like > - store it in a buffer and just hand 'X' bytes over to SL - keeping > what's left for next time. Not very elegant - but it ought to be > do-able. No, not elegant at all, and that's not what I had in mind. > Personally, I hate to add dependancies on yet more libraries > since that adds so much to support hassles down the line. > So, given the choice, I'd prefer to add whatever new music > formats to the existing MOD player in SL rather than constructing > some elaborate kludge to get MikMod's player to drive SL's mixer. I wouldn't consider this an eleborate kludge. It would use an exposed aspect of libmikmod, without relying on libmikmod's drivers or mixers. It needn't add dependencies to PLIB either, if you include a stripped-down version of libmikmod in PLIB (e.g., the drivers could be left out). SDL_mixer does this too. > I'm biassed though...and right now, I don't have time to do > either modification. Understood (I wasn't asking you to do it, I was offering to look into it and do it myself). Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Steve B. <sjb...@ai...> - 2000-03-31 08:00:26
|
Jasmin Patry wrote: > > ...hence the sources have to be able to make a particular amount > > of sound on-demand. Since MikMod doesn't let you tell it how > > much to generate, that's not likely to work. > > Actually, it does let you tell it how much sound to generate, and that's > what SDL_mixer does. SDL_mixer doesn't use any of libmikmod's supplied > drivers or mixers (it sets up its own libmikmod driver using mikmod's > "virtual channel mixer interface"), and calls mikmod's > VC_WriteBytes( buffer, len ) to fill the audio buffer. It looks fairly > straightforward. OK - you've obviously looked more deeply into this than I have - so I'll bow to your superior knowledge. > > Hence we could call MikMod to create however much it feels like > > - store it in a buffer and just hand 'X' bytes over to SL - keeping > > what's left for next time. Not very elegant - but it ought to be > > do-able. > > No, not elegant at all, and that's not what I had in mind. Excellent - since there is a better way. > It needn't add dependencies to PLIB either, if you include a > stripped-down version of libmikmod in PLIB (e.g., the drivers could be > left out). SDL_mixer does this too. OK - that's certainly possible. Is MikMod pretty stable now - or do new versions still appear regularly? I'd hate for you to hack out a MikMod subset - only to find that you have to keep doing that every few months when MikMod changes. > > I'm biassed though...and right now, I don't have time to do > > either modification. > > Understood (I wasn't asking you to do it, I was offering to look into it > and do it myself). Now that's the kind of thing I like! Let me know if there are changes that you might need in PLIB to make this easier. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jules B. <jm...@he...> - 2000-03-31 11:46:15
|
On Fri, Mar 31, 2000 at 02:57:44AM -0600, Steve Baker wrote:
>
> I'd hate for you to hack out a MikMod subset - only to find that you
> have to keep doing that every few months when MikMod changes.
I know this is the opposite of Steve's feeling, but personally I hate
it when open-source projects gratuitously 'include' a version of
another library instead of linking to it. With a well-known library
(whatever that means) whichever distribution (of whichever OS) you use
should have a handily pre-prepared version.
If the concern is that it makes it harder for *all* PLIB users, then I
would certainly recommend the mikmod support be optional in
PLIB... you'd only need mikmod installed if you wanted to use it's
file loading code in your PLIB game...
Jules
--
Jules Bean | Any sufficiently advanced
jules@{debian.org,jellybean.co.uk} | technology is indistinguishable
jm...@he... | from a perl script
|
|
From: Jasmin P. <jf...@mu...> - 2000-03-31 17:24:21
|
On Fri, 31 Mar 2000, Jules Bean wrote: > I know this is the opposite of Steve's feeling, but personally I hate > it when open-source projects gratuitously 'include' a version of > another library instead of linking to it. With a well-known library > (whatever that means) whichever distribution (of whichever OS) you use > should have a handily pre-prepared version. > > If the concern is that it makes it harder for *all* PLIB users, then I > would certainly recommend the mikmod support be optional in > PLIB... you'd only need mikmod installed if you wanted to use it's > file loading code in your PLIB game... Yes, those are good points. The crucial factor is whether any modifications are required to mikmod (I don't think so, though). The advantages of including the code are convenience for the user, and the fact that you only need to test against one version of the library. I don't have a strong preference either way. Steve, it's your call. :-) Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Steve B. <sjb...@ai...> - 2000-04-01 06:09:07
|
Jasmin Patry wrote: > Yes, those are good points. The crucial factor is whether any > modifications are required to mikmod (I don't think so, though). The > advantages of including the code are convenience for the user, and the > fact that you only need to test against one version of the library. Yep. > I don't have a strong preference either way. Steve, it's your call. :-) Well, to be honest, my preference is to pick a better mod-like format than '.MOD' itself - and just implement that into PLIB once and for all. It's more grief now - but a lot easier to maintain down-the-line. The snag is that I don't personally have the time to do that anytime in the next few months. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jasmin P. <jf...@mu...> - 2000-04-01 17:13:14
|
On Sat, 1 Apr 2000, Steve Baker wrote: > Jasmin Patry wrote: > > I don't have a strong preference either way. Steve, it's your call. :-) > > Well, to be honest, my preference is to pick a better mod-like > format than '.MOD' itself - and just implement that into PLIB > once and for all. It's more grief now - but a lot easier to > maintain down-the-line. Ok. Given that it's not your preferred solution, I think I'll leave PLIB/mikmod integration for now, and go with SDL_mixer for sound support. Joseph (if you're still listening!), this means that I'll be able to play your music. Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Steve B. <sjb...@ai...> - 2000-04-01 06:09:05
|
Jules Bean wrote: > > On Fri, Mar 31, 2000 at 02:57:44AM -0600, Steve Baker wrote: > > > > I'd hate for you to hack out a MikMod subset - only to find that you > > have to keep doing that every few months when MikMod changes. > > I know this is the opposite of Steve's feeling, but personally I hate > it when open-source projects gratuitously 'include' a version of > another library instead of linking to it. With a well-known library > (whatever that means) whichever distribution (of whichever OS) you use > should have a handily pre-prepared version. It's not the opposite of my feeling. I also hate to include part of one library into the distribution of another. However, the alternative is sometimes to require all of our poor users to scour the web and download and install a half-dozen other libraries, some of which will inevitably be the wrong version - or won't install cleanly or something. I only rely on ONE other package (Mesa) in my present code - and even so, the volume of support email I have to answer for people who havn't installed it correctly is more than I like. I *hate* the idea of increasing that number unless it's absolutely necessary. I'm pretty sure that anyone who'se supported a reasonably popular OpenSource application for any amount of time will heartily concur. > If the concern is that it makes it harder for *all* PLIB users, then I > would certainly recommend the mikmod support be optional in > PLIB... you'd only need mikmod installed if you wanted to use it's > file loading code in your PLIB game... Well, yes - that's an option - dynamically link to MikMod. At least that way, games that don't want music don't pay the support price. But nearly all games need music - so I'm not sure it helps in practice. This problem is really putting a serious kink in OpenSource games development - I don't know *what* can be done about it. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jasmin P. <jf...@mu...> - 2000-03-31 17:05:03
|
On Fri, 31 Mar 2000, Steve Baker wrote: > Jasmin Patry wrote: > > It needn't add dependencies to PLIB either, if you include a > > stripped-down version of libmikmod in PLIB (e.g., the drivers could be > > left out). SDL_mixer does this too. > > OK - that's certainly possible. > > Is MikMod pretty stable now - or do new versions still appear regularly? A new version appeared in mid-February, so apparently development continues. I'm not sure if development is concentrated on the drivers or on the loaders/players, though. > I'd hate for you to hack out a MikMod subset - only to find that you > have to keep doing that every few months when MikMod changes. Yes, that could be somewhat of a pain. I'm not sure why SDL_mixer followed that approach. Perhaps some minor changes were required to mikmod itself (though I didn't see any sign of that). > Let me know if there are changes that you might need in PLIB to make > this easier. Ok. Unfortunately the free time I was going to spend this weekend looking into this has been eaten up with other commitments, but I'll get to it as soon as I can. Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
Thanks for helping keep SourceForge clean.
X