Re: [AL] Detecting status of a sample

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On 31 Mar 99 at 18:10, Andrew R. Gillett wrote:

> Is it possible to detect whether a sample has finished playing if I used
> play_sample to start it (as opposed to allocating a specific voice)?

Not really.  It's not too hard to use the voice functions 
directly (see the code for `play_sample'), and you get a lot 
more control this way.

-- 
George
>From <all...@ma...> Wed Mar 31 16:19:56 1999
Received: from post-20.mail.demon.net [194.217.242.27] by mail.canvaslink.com with ESMTP
  (SMTPD32-4.06) id A17883F02E2; Wed, 31 Mar 1999 16:19:52 -0500
Received: from [194.222.103.32] (helo=talula.demon.co.uk)
	by post-20.mail.demon.net with smtp (Exim 2.10 #2)
	id 10SSOX-0005tt-0K
	for al...@ma...; Wed, 31 Mar 1999 21:19:30 +0000
Message-ID: <kv$ddI...@ta...>
Date: Wed, 31 Mar 1999 19:29:28 +0100
To: al...@ma...
From: Shawn Hargreaves <sh...@ta...>
Subject: Re: [AL] learning to program
References: <00ce01bb1ebc$6451fbc0$69ed18d0@u3j3g5>
In-Reply-To: <00ce01bb1ebc$6451fbc0$69ed18d0@u3j3g5>
MIME-Version: 1.0
X-Mailer: Turnpike (32) Version 4.01  <n4LQeHkuIZDKHuEabw2AtDS$Xl>
Precedence: bulk
Sender: all...@ma...
Reply-To: al...@ma...
X-UIDL: 905450761
Status: O
Content-Length: 1206
Lines: 24

casey <sa...@n-...> writes:
>What's the best way to learn how to program?

Books are a good way to get the basic mechanical information about
things like language syntax, but the only real way to learn is just by
doing lots of it, starting simple and going on from there. The best
advice I've ever seen is by Eric Raymond on 
http://www.tuxedo.org/~esr/faqs/hacker-howto.html, when he says:

   I can't give complete instructions on how to learn to program here -- 
   it's a complex skill. But I can tell you that books and courses won't 
   do it (many, maybe most of the best hackers are self-taught). What 
   will do it is (a) reading code and (b) writing code. 

   Learning to program is like learning to write good natural language. 
   The best way to do it is to read some stuff written by masters of the 
   form, write some things yourself, read a lot more, write a little 
   more, read a lot more, write some more ... and repeat until your 
   writing begins to develop the kind of strength and economy you see in 
   your models. 

--
Shawn Hargreaves - sh...@ta... - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."
>From <all...@ma...> Wed Mar 31 16:35:07 1999
Received: from post-20.mail.demon.net [194.217.242.27] by mail.canvaslink.com with ESMTP
  (SMTPD32-4.06) id A17895202BE; Wed, 31 Mar 1999 16:19:52 -0500
Received: from [194.222.103.32] (helo=talula.demon.co.uk)
	by post-20.mail.demon.net with smtp (Exim 2.10 #2)
	id 10SSOY-0005tw-0K
	for al...@ma...; Wed, 31 Mar 1999 21:19:31 +0000
Message-ID: <pfv...@ta...>
Date: Wed, 31 Mar 1999 19:35:55 +0100
To: al...@ma...
From: Shawn Hargreaves <sh...@ta...>
Subject: Re: [AL] TrueColor and Palette (part III)
References: <922835977.2026482.0@[216.47.35.51]>
In-Reply-To: <922835977.2026482.0@[216.47.35.51]>
MIME-Version: 1.0
X-Mailer: Turnpike (32) Version 4.01  <n4LQeHkuIZDKHuEabw2AtDS$Xl>
Precedence: bulk
Sender: all...@ma...
Reply-To: al...@ma...
X-UIDL: 905450762
Status: O
Content-Length: 1086
Lines: 25

George Foot <geo...@me...> writes:
>> Perhaps any bitmap load call without first either setting a graphics
>> mode or calling set_color_conversion() should generate an assert
>> failure?
>
>Maybe this should be in the development library but not the 
>release one?

Asserts are always ignored in release builds.

>Could we set all the shift counts to zero?  That'd be wrong on 
>*all* hardware -- but would it disrupt any of the drawing code 
>significantly?

That would give a non-functional pixel encoding, though, which couldn't
actually load or manipulate graphics. It is perfectly valid to do things
without setting a graphics mode, as long as you aren't planning to later
change modes and display the resulting image (otherwise it would be
impossible to manipulate bitmaps from commandline utilities). So the
default encoding needs to be valid, just not the same as what is likely
to happen in a graphics mode.

--
Shawn Hargreaves - sh...@ta... - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."
>From <all...@ma...> Wed Mar 31 16:59:30 1999
Received: from post-20.mail.demon.net [194.217.242.27] by mail.canvaslink.com with ESMTP
  (SMTPD32-4.06) id A17A13E02DE; Wed, 31 Mar 1999 16:19:54 -0500
Received: from [194.222.103.32] (helo=talula.demon.co.uk)
	by post-20.mail.demon.net with smtp (Exim 2.10 #2)
	id 10SSOa-0005tt-0K
	for al...@ma...; Wed, 31 Mar 1999 21:19:32 +0000
Message-ID: <2vY...@ta...>
Date: Wed, 31 Mar 1999 19:41:24 +0100
To: al...@ma...
From: Shawn Hargreaves <sh...@ta...>
Subject: Re: [AL] TrueColor and Palette (part III)
References: <01J9HGUU2FZ6E2XHK2@KVI.nl>
In-Reply-To: <01J9HGUU2FZ6E2XHK2@KVI.nl>
MIME-Version: 1.0
X-Mailer: Turnpike (32) Version 4.01  <n4LQeHkuIZDKHuEabw2AtDS$Xl>
Precedence: bulk
Sender: all...@ma...
Reply-To: al...@ma...
X-UIDL: 905450763
Status: O
Content-Length: 940
Lines: 22

VERSTEEGH@KVI.nl writes:
>>Trace output functions are part of my most recent unfinished-work
>>upload
>
>I do hope there is a compiler option for them ? 

Of course. Debugging support is only included in debug builds.

>Another idea, in Wham  I have a trace function which takes printf style
>arguments and works in both textmode and graphics mode.
>It just prints a message and waits for a keypres. this function can be extremely 
>usefull in debugging, so you might want to add it to the allegro textout 
>routines.

My trace routine goes to a file by default, but you can easily hook it
to send the messages anywhere you like. So if you want to output to a
graphics screen, or send to a second monitor, or a printer, or whatever,
you can do that with just a couple of lines of code.

--
Shawn Hargreaves - sh...@ta... - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."
>From <all...@ma...> Wed Mar 31 17:11:50 1999
Received: from post-20.mail.demon.net [194.217.242.27] by mail.canvaslink.com with ESMTP
  (SMTPD32-4.06) id A1787B02F4; Wed, 31 Mar 1999 16:19:52 -0500
Received: from [194.222.103.32] (helo=talula.demon.co.uk)
	by post-20.mail.demon.net with smtp (Exim 2.10 #2)
	id 10SSOY-0005tv-0K
	for al...@ma...; Wed, 31 Mar 1999 21:19:30 +0000
Message-ID: <sfyfBTA$omA...@ta...>
Date: Wed, 31 Mar 1999 19:32:31 +0100
To: al...@ma...
From: Shawn Hargreaves <sh...@ta...>
Subject: Re: [AL] Detecting status of a sample
References: <003301be7b99$6560ad80$bb2c883e@arganoid>
In-Reply-To: <003301be7b99$6560ad80$bb2c883e@arganoid>
MIME-Version: 1.0
X-Mailer: Turnpike (32) Version 4.01  <n4LQeHkuIZDKHuEabw2AtDS$Xl>
Precedence: bulk
Sender: all...@ma...
Reply-To: al...@ma...
X-UIDL: 905450764
Status: O
Content-Length: 686
Lines: 13

Andrew R. Gillett <ar...@wh...> writes:
>Is it possible to detect whether a sample has finished playing if I used
>play_sample to start it (as opposed to allocating a specific voice)?

play_sample() returns the voice number, but it isn't really a good idea
to use that for anything important, because the voice is playing in
auto-release mode, so it might be stopped and replaced by something else
at any point. If you need more control than just triggering a sound, it
is much better to use the voice routines.

--
Shawn Hargreaves - sh...@ta... - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."
>From <all...@ma...> Wed Mar 31 17:23:02 1999
Received: from post-20.mail.demon.net [194.217.242.27] by mail.canvaslink.com with ESMTP
  (SMTPD32-4.06) id A18221302D6; Wed, 31 Mar 1999 16:20:02 -0500
Received: from [194.222.103.32] (helo=talula.demon.co.uk)
	by post-20.mail.demon.net with smtp (Exim 2.10 #2)
	id 10SSOg-0005tr-0K
	for al...@ma...; Wed, 31 Mar 1999 21:19:39 +0000
Message-ID: <u6f...@ta...>
Date: Tue, 30 Mar 1999 22:12:42 +0100
To: al...@ma...
From: Shawn Hargreaves <sh...@ta...>
Subject: Re: [AL] Bug in create_light_table function.
References: <199...@sm...>
In-Reply-To: <199...@sm...>
MIME-Version: 1.0
X-Mailer: Turnpike (32) Version 4.01  <n4LQeHkuIZDKHuEabw2AtDS$Xl>
Precedence: bulk
Sender: all...@ma...
Reply-To: al...@ma...
X-UIDL: 905450765
Status: O
Content-Length: 1600
Lines: 32

Grzegorz Adam Hankiewicz <ga...@je...> writes:
>Some time ago someone asked why create_light_table wasn't 
>working as expected. He/she wanted to tint the sprite to white, 
>and thus used 255,255,255 as the rgb parameters of the 
>create_light_table function. Now, if you go to the example 36 
>(goraud sprite) and put values like 255,255,255 or 255,0,0, odd 
>things will be drawn. However, if you put 63,63,63 the sprite will 
>be correctly tinted to white instead of black.
>
>Which means there's either a bug in the documentation or the 
>Allegro function. This test was done with 3.11. Maybe previous 
>versions don't have this bug.

Using 63 is correct. The docs aren't really wrong about this, just very
vague: they don't say what units the r,g,b values are in. I'll add that.

The reason it used to work with 255 is because the top bits were just
ignored, and it wrapped to 63. But this still wouldn't be right if you
tried to produce a gradient, eg. there would be four bands of color
rather than just one in an interpolation from 0 to 255. The current
smarter table generation algorithm handles overflow differently, so you
get very weird results from inputting 255 instead if it just overflowing
and becoming 63.

Logically, I think those parameters ought to be in 0-255 range, in fact
the rational thing would be for all color values to use that format. But
it would be too painful to change the palette units at this point in
time...

--
Shawn Hargreaves - sh...@ta... - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."
>From <all...@ma...> Wed Mar 31 17:30:25 1999
Received: from post-20.mail.demon.net [194.217.242.27] by mail.canvaslink.com with ESMTP
  (SMTPD32-4.06) id A17D35502AC; Wed, 31 Mar 1999 16:19:57 -0500
Received: from [194.222.103.32] (helo=talula.demon.co.uk)
	by post-20.mail.demon.net with smtp (Exim 2.10 #2)
	id 10SSOa-0005tr-0K
	for al...@ma...; Wed, 31 Mar 1999 21:19:32 +0000
Message-ID: <p$neZ...@ta...>
Date: Wed, 31 Mar 1999 19:39:37 +0100
To: al...@ma...
From: Shawn Hargreaves <sh...@ta...>
Subject: Re: [AL] TrueColor and Palette (part III)
References: <922750413.1115931.0@[216.47.35.51]>
 <fIB...@ta...> <199...@sm...>
In-Reply-To: <199...@sm...>
MIME-Version: 1.0
X-Mailer: Turnpike (32) Version 4.01  <n4LQeHkuIZDKHuEabw2AtDS$Xl>
Precedence: bulk
Sender: all...@ma...
Reply-To: al...@ma...
X-UIDL: 905450766
Status: O
Content-Length: 1775
Lines: 41

Grzegorz Adam Hankiewicz <ga...@je...> writes:
>> Perhaps any bitmap load call without first either setting a graphics
>> mode or calling set_color_conversion() should generate an assert
>> failure?
>
>Huh, but wasn't allegro supposed to be in 8 bit mode when you 
>initialized it? I always thought you had a set_color_conversion(8) 
>inside the init routine.

It is in 8 bit mode by default, yes, but it is just initialised that
way, it doesn't have to call any of the mode changing functions.

>Now I have a program which runs in text mode loading/saving 32 
>bit images. If that assert won't tell me anything about "Warning: 
>set_gfx_mode not called", I agree on the change as it won't break 
>my program :-)

You must be calling set_color_conversion(), right? So you are ok :-)

This assert would only be raised in a very specific situation:

- if user has set a graphics mode, that's fine and they can load
anything they like.

- if user has called set_color_conversion(), assume they know what they
are doing, and they can load anything they like.

- if they are loading an 8 bit image in text mode, no default conversion
will happen, so that's ok, and must remain ok to retain compatibility
with old code.

- if they are loading a truecolor image in text mode without calling
set_color_conversion(), it will be auto-reduced to 256 colors. This is
almost certainly not what the programmer meant to do, so Allegro should
bomb out and tell them so. If they really do want that behaviour, a
simple set_color_conversion(COLORCONV_TOTAL) will be enough to tell
Allegro that it really is ok and they did mean to do this.

--
Shawn Hargreaves - sh...@ta... - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."
>From <all...@ma...> Wed Mar 31 17:39:07 1999
Received: from mailc.telia.com [194.22.190.4] by mail.canvaslink.com with ESMTP
  (SMTPD32-4.06) id A408380318; Wed, 31 Mar 1999 17:39:04 -0500
Received: from d1o22.telia.com (ro...@d1... [195.198.248.241])
	by mailc.telia.com (8.8.8/8.8.8) with ESMTP id AAA02803
	for <al...@ma...>; Thu, 1 Apr 1999 00:38:40 +0200 (CEST)
Received: from johans-dator (t7o22p33.telia.com [195.198.249.153])
	by d1o22.telia.com (8.8.8/8.8.5) with SMTP id AAA03105
	for <al...@ma...>; Thu, 1 Apr 1999 00:38:37 +0200 (MET DST)
Message-ID: <004001b9ffb8$85b9a200$99f9c6c3@johans-dator>
From: "Johan Henriksson" <joh...@te...>
To: <al...@ma...>
Subject: Re: [AL] learning to program
X-DT: Sat, 1 Apr 1995 00:41:09 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Precedence: bulk
Sender: all...@ma...
Reply-To: al...@ma...
X-UIDL: 905450767
Status: O
Content-Length: 1138
Lines: 39
Date: Wed, 1 Apr 1999 00:38:37 +0200
X-pi: Got acceptable date - Previous mail Wed, 31 Mar 1999 19:39:37 +0100
from Johan Henriksson, Sweden    HTTP://come.to/jhewok  |
Primary mail: joh...@te...                  #UIN 12035895
Second: jh...@ho...    Third: joh...@ya...
Leadprogrammer and FX-specialist at Real software
http://come.to/real_software
*************************************************************************
-----Original Message-----
From: casey <sa...@n-...>
To: al...@ca... <al...@ca...>
Date: Wednesday, March 31, 1999 4:47 AM
Subject: [AL] learning to program

>What's the best way to learn how to program?
>Using  a C for dummies book and going through it?

What you should start with.

>Thinking up projects and learning the routines and methods to implement the
>projects?

>Reading tutorials?

After a book, this is your best choice

>Modifying/Playing with existing programs?

You mean playing with others sources? FORGET IT! Others have codingstyles
that are hard to read. And bigger games are hard to examine.

After you read the tutorials, you can continue by making som smaller games.

>I'd like to get a few opinions on this if someone wouldn't mind.
>Thanks
>Casey
>
>