hi,
I hope you don't mind that I reply to the list again, because both, subpatches and trigger could be interesting themes for other newbies...
trigger: In Pd you have the problem that with for example the [+]-object only one inlet is hot (triggers the object). that means you can send any number of floats into the right inlet, but no result will be sent to the outlet. only if you send a message to the left inlet, the object is triggered. the same is with the logical operators. So you need to be sure that a message is is always sent to the right inlet before the left. And there you need the trigger object. It fires its outlets from right to left. [t b f] means "send the float and then send a bang".
to create a subpatch just type "pd" followed by a name of your choice, like [pd collision]. then a new window pops up and with cut and paste you can place objects there, and also work there like in every patch window. it is like an extension to the parent window.
marius.
----- Original Message ----- From: "Just A Drummer" murchisonjames_@hotmail.com To: marius.schebella@chello.at Sent: Wednesday, October 15, 2003 2:10 AM Subject: Re: [PD] Collision detection
Thanks so much, i didn't really understand the trigger object, and still don't really, but they seem to have fixed things up, i know it was pretty messy, i actually cleaned it up from what it was before that! how did you get all the abstractions into their own object boxes and still part of the same .pd file, whenever i try to do that i have to save them as a seperate file within the same directory. anyway thanks again James
From: "marius schebella" marius.schebella@chello.at To: "Just A Drummer" murchisonjames_@hotmail.com Subject: Re: [PD] Collision detection Date: Tue, 14 Oct 2003 01:28:41 +0200
hi, i think it was just a small mistake, that you connected one outlet of [r two] to a wrong inlet of [>=]. i looked into the patch and cleaned it up a little (for my
understanding).
i wrote some hints into the patch, so maybe you want to look into it. feel free to ask further questions (also on the pd-list). i hope this helps. marius.
----- Original Message ----- From: "Just A Drummer" murchisonjames_@hotmail.com To: pd-list@iem.at Sent: Monday, October 13, 2003 10:55 AM Subject: [PD] Collision detection
I know this may be a bit off what anyone has done but i am trying to construct a small shooting game with pd and gem and im having huge
trouble
with the collision detection. i have it working but there are a couple
of
bugs that i have spent hours slaving over. if anyone has any
experience
in
this department it would be very helpful if you could have a look at
my
patch, because i'm losing too much hair over this. thanks James
Chat via SMS. Simply send 'CHAT' to 1889918. More info at http://ninemsn.com.au/mobilemania/MoChat.asp?blipid=6800
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
<< collision.pd >>
ninemsn Premium transforms your e-mail with colours, photos and animated text. Click here http://ninemsn.com.au/premium/landing.asp
Hallo, marius schebella hat gesagt: // marius schebella wrote:
trigger: In Pd you have the problem that with for example the [+]-object only one inlet is hot (triggers the object). that means you can send any number of floats into the right inlet, but no result will be sent to the outlet. only if you send a message to the left inlet, the object is triggered. the same is with the logical operators. So you need to be sure that a message is is always sent to the right inlet before the left. And there you need the trigger object. It fires its outlets from right to left. [t b f] means "send the float and then send a bang".
to create a subpatch just type "pd" followed by a name of your choice, like [pd collision]. then a new window pops up and with cut and paste you can place objects there, and also work there like in every patch window. it is like an extension to the parent window.
I'd like to add that collision detection is a good candidate for making an abstraction instead of a subpatch, because you will need this several times and thus the reusability of an abstraction comes in handy. An abstraction is a pd-file in your path (or the current directory). You need to find out which things in your algorithm will change (like the coordinates of your objects: x1, y1, x2, y2) and then make inlets in your abstraction for them:
inlets: x1 y1 x2 y2 - - - - [collision_detect] - outlet: collision?
Frank Barknecht _ ______footils.org__