More Carbon Weirdness... 
Author Message
 More Carbon Weirdness...

It has been discussed before on this group how you can play an mp3 using
a movie control while running a sprite surface, but the song won't loop
because the sprite surface hogs all of the system's idle time (except
under OS X, which is another story entirely...).

What I haven't seen discussed, however, is that if you uncheck the
"click to stop" property of said sprite surface and then build a Carbon
app, the music stops after only a few seconds.  Now, I could understand
if the Carbon build behaved this way all the time (ie. regardless of the
"click to stop" setting); I would attribute the fact that the tune gets
cut off to differences between the behaviour of a Carbon app and a
Classic app.  The thing I don't understand is why the "click to stop"
property should make any difference whatsoever.

The main reason I am peeved about this is that I had just come up with
what I thought was a thoroughly brilliant idea to get around the problem
of looping music :)  I set up my app so that every two seconds or so,
the sprite surface is "stopped", and then reactivated by a timer with a
period of one.  That way, the movie control gets enough time to loop the
music and all is well.  This plan works pretty well with both Classic
and Carbon apps, unless the "click to stop" property is off in the
Carbon app, in which case the music stutters unnervingly.  A bit of
testing revealed that I need to provide my "un-click-to-stopped" Carbon
app with an idle period at least three times per second to have the
music play correctly, which rather unfortunately slows down my sprite
surface too much.

I have been able to reproduce this problem in a very small example
project, so I know that it isn't just something weird that the game I am
working on is doing.  I guess what I'm asking is whether or not this is
something I should REALBug.  It doesn't technically cause a crash, I
suppose, but I can't think of any logical explanation for why this is
happening.

It would be really handy, IMHO, if you could use "openAsSound" to open
mp3s, and then use "sound.playLooping" to play them from within a sprite
surface.  Music is an essential part of most games, and it is
unfortunate that there isn't really a way to get it to work in REALBasic
without standing on your head...

--
Greg Gillis

Visit "The Armadillo Games Home Page"
http://www.*-*-*.com/

Home of "Bob's Bricks", "Fawn", and numerous armadillii...



Sun, 02 May 2004 06:33:07 GMT  
 More Carbon Weirdness...

Quote:

> What I haven't seen discussed, however, is that if you uncheck the
> "click to stop" property of said sprite surface and then build a Carbon
> app, the music stops after only a few seconds

This was the behavior previously - i.e. when I wrote the first edition of
my book - regardless of the "click to stop" value. This was why, in the
first edition, I did not recommend a movieplayer as a way of providing
background music in a game.

But now a movie does seem to work fine as background music. When I build
my PacManOnMars game and run it on OS X.1, the music goes on and on
regardless of the "click to stop" value. You might try downloading it from
my site, to see if you get different results.

Perhaps this is something about the difference between a midi file and an
mp3 file? m.

--

  *** REALbasic: The Definitive Guide! The Second Edition! ***
http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt



Sun, 02 May 2004 07:14:10 GMT  
 More Carbon Weirdness...

Quote:



> > What I haven't seen discussed, however, is that if you uncheck the
> > "click to stop" property of said sprite surface and then build a Carbon
> > app, the music stops after only a few seconds

> This was the behavior previously - i.e. when I wrote the first edition of
> my book - regardless of the "click to stop" value. This was why, in the
> first edition, I did not recommend a movieplayer as a way of providing
> background music in a game.

> But now a movie does seem to work fine as background music. When I build
> my PacManOnMars game and run it on OS X.1, the music goes on and on
> regardless of the "click to stop" value. You might try downloading it from
> my site, to see if you get different results.

> Perhaps this is something about the difference between a midi file and an
> mp3 file? m.

Sorry, I should have been more specific.  The music cuts out under OS 9.2.1.
I have no idea what happens under 10.1, but I wouldn't think that it would
suffer from the same problem since I've never had a problem with it before.
I am using RB version 3.5.2, OS 9.2.1, iMac DV SE 500MHz, 192 MB RAM.

Just to be sure, I downloaded PacManOnMars and compiled two versions, one
with "click to stop" on (ie. the way you wrote it) and one with "click to
stop" off.  Sure enough, the MIDI music cuts out prematurely on the "click to
stop" disabled version, but plays on in the "click to stop" enabled version.
The MIDI music lasts a little longer in PMOM than the mp3 music in my game
does, but that might have something to do with differing frame speeds (PMOM
uses 30fps, my game uses 60).

This seems like a bug to me.  I must say that I am surprised at how many
"gotchas" there are when it comes to carbon builds of RB apps.  Cheer me up,
Matt, I'm getting depressed :)

--
Greg Gillis

Visit "The Armadillo Games Home Page"
http://members.home.net/armadillogames

Home of "Bob's Bricks", "Fawn", and numerous armadillii...



Sun, 02 May 2004 10:07:16 GMT  
 More Carbon Weirdness...

Quote:

> Sorry, I should have been more specific.  The music cuts out under OS 9.2.1.

Yes, I apologize, I realized later what you must have meant. The problem
from my end is that I cannot for the life of me imagine wanting to run a
Carbon RB app anywhere but under OS X. Apple's CarbonLib hack is not
working very well, and personally when software requires CarbonLib under
9.x my attitude is not to use that software (although sometimes I have no
choice, I admit). One of the coolest things about RB is that it allows you
to generate, from the very same code, two completely different versions of
your app: a PPC version to run under system 8/9, and a Carbon version to
run under X. It beats the heck out of me why anyone would throw that
advantage completely out the window and build a Carbon app to run under
8/9. m.

--

  *** REALbasic: The Definitive Guide! The Second Edition! ***
http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt



Sun, 02 May 2004 10:48:21 GMT  
 More Carbon Weirdness...

Quote:



> > Sorry, I should have been more specific.  The music cuts out under OS 9.2.1.

> Yes, I apologize, I realized later what you must have meant. The problem
> from my end is that I cannot for the life of me imagine wanting to run a
> Carbon RB app anywhere but under OS X. Apple's CarbonLib hack is not
> working very well, and personally when software requires CarbonLib under
> 9.x my attitude is not to use that software (although sometimes I have no
> choice, I admit). One of the coolest things about RB is that it allows you
> to generate, from the very same code, two completely different versions of
> your app: a PPC version to run under system 8/9, and a Carbon version to
> run under X. It beats the heck out of me why anyone would throw that
> advantage completely out the window and build a Carbon app to run under
> 8/9. m.

I had considered having two different versions of my game (ie one for OS 9 and
one for OS X), although that will increase the size of the file download by a
couple of megabytes.  Keeping the final size of my game as small as possible is
important to me because I have limited web site space.  I thought the whole
advantage of carbon apps was supposed to be that you could use them under any Mac
OS, but it appears there are still some kinks left to be worked out.

Do I take it then that you don't think this "click to stop" problem is a RB
issue?  Should I just forget about it and have two versions of my game?  The
music code will have to be different under OS 9 anyway (in order to get it to
loop), so I guess it isn't too big a deal to have two versions.  I haven't tried
it yet, but I don't think the "targetCarbon" thingy differentiates between a
carbon app running under OS 9 or OS X...

--
Greg Gillis

Visit "The Armadillo Games Home Page"
http://members.home.net/armadillogames

Home of "Bob's Bricks", "Fawn", and numerous armadillii...



Sun, 02 May 2004 11:46:10 GMT  
 More Carbon Weirdness...

Quote:

> This seems like a bug to me.

Not necessarily -- I don't believe we've ever claimed that you can play
movies while a spriteSurface is Running, so the fact that your attempts
to play them have different results under different circumstances isn't
a bug, it's you trying to peek under the hood.

I wrote the SpriteSurface, and I don't even know why ClickToStop would
have any effect.  Must be some mysterious system-level thing, like
checking the mouse button causing QuickTime to update.  You might try
checking System.MouseDown in your NextFrame event and see if it has the
same effect.  But again, this is peeking under the hood, and is NOT
supported regardless of the outcome.

What you want to do, I think, is make a feature request: please let me
play MP3s reliably while a SpriteSurface is Running.  Submit that with
REALbugs, and we'll see what (if anything) we can do.

Quote:
> I must say that I am surprised at how many
> "gotchas" there are when it comes to carbon builds of RB apps.

You should try a Carbon build of a C++ app!

Cheers,
- Joe

--
,------------------------------------------------------------------.
|    Joseph J. Strout         Check out the Mac Web Directory:     |

`------------------------------------------------------------------'



Sun, 02 May 2004 13:08:29 GMT  
 More Carbon Weirdness...

Quote:

> I haven't tried it yet, but I don't think the "targetCarbon" thingy
> differentiates between a carbon app running under OS 9 or OS X...

What would that mean?  TargetCarbon is a compile-time choice.  OS 9 vs.
OS X is a run-time environment.  There's no way the compiler can
predict where you (or your users) might choose to run the app.  But of
course there are ways (such as System.Gestalt) for your code to check
the environment at runtime.

Cheers,
- Joe

--
,------------------------------------------------------------------.
|    Joseph J. Strout         Check out the Mac Web Directory:     |

`------------------------------------------------------------------'



Sun, 02 May 2004 13:11:00 GMT  
 More Carbon Weirdness...

Quote:



> > This seems like a bug to me.

> Not necessarily -- I don't believe we've ever claimed that you can play
> movies while a spriteSurface is Running, so the fact that your attempts
> to play them have different results under different circumstances isn't
> a bug, it's you trying to peek under the hood.

> I wrote the SpriteSurface, and I don't even know why ClickToStop would
> have any effect.  Must be some mysterious system-level thing, like
> checking the mouse button causing QuickTime to update.  You might try
> checking System.MouseDown in your NextFrame event and see if it has the
> same effect.  But again, this is peeking under the hood, and is NOT
> supported regardless of the outcome.

> What you want to do, I think, is make a feature request: please let me
> play MP3s reliably while a SpriteSurface is Running.  Submit that with
> REALbugs, and we'll see what (if anything) we can do.

An excellent idea :)

--
Greg Gillis

Visit "The Armadillo Games Home Page"
http://members.home.net/armadillogames

Home of "Bob's Bricks", "Fawn", and numerous armadillii...



Mon, 03 May 2004 05:36:51 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. QTVR and Carbon Sloooooow

2. SetMenuIcon under Carbon

3. A Carbon/Apple Event?

4. Carbon HelpTags on Classic

5. Carbon App's in Classic

6. Carbon...

7. AppleScript Toolbox call under Carbon

8. Rainbow colors in Carbon app

9. REALbasic 3.2.1 Carbon

10. Alias Manager for OS X/Carbon?

11. Free disk space in Carbon/OS X apps?

12. Carbon Builds on PPC w/o 10.x

 

 
Powered by phpBB® Forum Software