Am Donnerstag, 25. Januar 2007 00:22 schrieb Dennis Schridde:
> Am Mittwoch, 24. Januar 2007 22:42 schrieb Troman:
> > ----- Original Message -----
> > From: "Dennis Schridde" <[EMAIL PROTECTED]>
> > To: "Development list" <warzone-dev@gna.org>
> > Sent: Wednesday, January 24, 2007 8:43 PM
> > Subject: Re: [Warzone-dev] Music playlists
> >
> > >Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
> > >> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
> > >> > I had some musings about the way this should work. Playlist script
> > >> > interface will be most used by scriptors I assume. I see two main
> > >> > occasions when such an interface might be used:
> > >> >
> > >> > 1) when it is time to interrupt any background music that might be
> > >> > played and kick in some moody piece to create atmosphere, like it is
> > >> > usually done in campaigns.
> > >> >
> > >> > 2) when someone wants to attach a custom playlist to his map, the
> > >> > way it is done with Unreal Tournament maps for example.
> > >>
> > >> Agreed.
> > >>
> > >> > As for the implementation, looks like wz uses 'tracks' to store
> > >> > songs. Track 2 corresponds to menu, track 1 to the in-game music.
> > >>
> > >> I do not think we should let that get in the way of a decent API. We
> > >> can change the way Warzone stores songs, if necessary.
> >
> > Since i'm not the one to program it it's fine with me. ;-)
> >
> > >> > When modder wants his custom playlist to be played when someone is
> > >> > using his map he either loads all songs manually to the user track
> > >> > using scripts, like
> > >> >
> > >> > playlistAddUserSong("mySong1.ogg");
> > >> > playlistAddUserSong("mySong2.ogg");
> > >>
> > >> Sounds good.
> > >>
> > >> > Since this is not the most convenient approach it might be a better
> > >> > idea to load playlist from an external playlist file, which will
> > >> > come with the mod
> > >>
> > >> Well, to me the in-script version above seems more convenient than
> > >> adding yet another file, since the number of songs will probably never
> > >> be high.
> > >>
> > >> > In case of a map with custom playlist it is simple, just call
> > >> > something like playlistPlayUserTrack(); from within the scripts (or
> > >> > again we can make wz start playing user track automatically if a map
> > >> > comes with a user playlist) for wz to switch from player playlist to
> > >> > the custom map playlist.
> > >>
> > >> I think starting the script-supplied playlist automatically seems like
> > >> the simpler and better way.
> >
> > What if the user doesn't want any music to be played at the beginning?
> > It's probably better to let the modder decide this.
>
> I think what Per meant is that there should be an initPlaylist function in
> the scripts, which is called upon mission start. If the modder doesn't want
> that, he must not provide that function.
>
> > >> > In cases when some music must kick in from time to time depending on
> > >> > some in-game conditions it is a bit more complicated.
> > >>
> > >> There are probably two different needs here:
> > >> 1) Scripter wants to play a short song to set the theme of some event,
> > >> then resume the playlist as normal. The new song should then not be in
> > >> the playlist afterwards.
> > >> 2) Scripter wants to change the whole theme of a level by playing a
> > >> new song or songs throughout the remaining time (or until it changes
> > >> again). So we need a way to reset the playlist; then the scripter can
> > >> add the new songs.
> > >>
> > >> So how about an API like this:
> > >> playlistReset() -- deletes existing playlist (eg to remove game
> > >> supplied playlist)
> > >> playlistAdd(song) -- adds song to top of playlist (eg to add to game's
> > >> supplied playlist)
> > >> playlistInterruptWith(song) -- play a song once, then resume playing
> > >> playlist (eg for event)
> >
> > Makes sense to me.
>
> Didn't say that it doesn't to me.
> Just the naming is not my favourite...
> playlistReset -> clearPlaylist
> playlistInteruptWith -> playTrack
> That was my idea... Maybe not ideal, either.
>
> > >My proposal:
> > >
> > >Function to set a playlist.
> > >Function to immediately play one track.
> > >Function to stop playlist playback and one function to resume playback.
> > >Function to set playback-modes, like repeat_all, shuffle, fadein,
> > > fadeout, crossfade.
>
> Those effects (not shuffle, but .*fade.*) would also affect playTrack(). If
> the modder wants something different, he can switch modes before and after
> his custom track. (Reacting to events.)
>
> > This all can surely be usefull to the end user/scriptor. Crossfades for
> > 'insertations' especially in campaigns etc.
> >
> > >Clearing the playlist is simply supplying an empty playlist.
> > >I don't think there is any need to dynamically attach a track to the
> > > playlist, am I correct? Why would one attach a song if he doesn't know
> > > when it will be played...
> >
> > You never know what's going on inside of a modder's head, it doesn't take
> > much affort to provide this functionality, besides I don't see how else
> > we would want to re-fill the list (see below).
>
> If there is technically no other way, yes. In my idea you could re-fill the
> list simply by setting the playlist to a list of different songs...
> But addTrack should have a switch so you can choose whether to append to
> the front or the back... (Or maybe better 2 functions addTrackFront
> addTrackBack, or appendTrack prependTrack, or similarly named.)
>
> I just got the idea of Open*L style functions... OMG... crazy...
> createPlaylist(Playlist*); // New, empty playlist
> deletePlaylist(Playlist*); // Trash it, mark pointer invalid
> bindPlaylist(Playlist*); // Switch to another playlist
> addTrack(Playlist*,Track*); // Append Track
>
> Hmmm... Actually the idea is not that bad...
> Would make it easy to handle multiple playlists, eg. one for the menu and
> for the game, or when The Modder wants to interupt the game with a few
> different songs to acompany his cutscenes or the attack of the clones...
> (And wants to switch back to the usual theme afterwards.)
>
> Implementation for createPlaylist:
> New item of a playlist-linked-list. All pointers NULL. (next, prev,
> thisTrack).
>
> addTrack:
> Walk to the end of Playlist*, check if thisTrack is NULL, yes-> set
> thisTrack to Track*, no-> append another empty item, link it in, set it's
> thisTrack.
>
> bindPlaylist:
> Set sound engine's nextTrack pointer to 1st item of the given list, and
> advise it to skipTrack() so it plays nextTrack.
>
> The linked list would perhaps become a bit unhandy when it comes to
> shuffling and repeating, but it seems very handy when binding, adding or
> switching to the next track...
>
> What do you think about this? Opinions, objections?
>
> > >Stoping and resuming the playlist may be interesting to create moments
> > > of total silence or when cutscenes are played.
> > >
> > >C-Functions:
> > >WZSound_setPlaylist( Song * song1, ... );
> > >WZSound_playTrack( Track interuptionTrack );
> > >WZSound_stopPlaylist();
> > >WZSound_resumePlaylist();
> > >WZSound_setPlaylistMode( PlaylistMode newMode );
> > >
> > >typedef PlaylistMode UInt8;
> > >#define PLAYLIST_SHUFFLE 0x1
> > >#define PLAYLIST_REPEAT_ALL 0x2
> > >#define PLAYLIST_CROSSFADE 0x4
> > >...
> > >
> > >C-Function examples:
> > >WZSound_setPlaylist( song1, song2, song3 );
> > >WZSound_setPlaylist( NULL );
> > >WZSound_setPlaylistMode( PLAYLIST_SHUFFLE | PLAYLIST_CROSSFADE );
> > >
> > >Script-Function examples:
> > >WZSound_setPlaylist( "song1.ogg", "song2.ogg", "song3.ogg" );
> >
> > Variadic functions won't work, we'll have to fall back to something like
> > playlistAddSong(song);
>
> Ok, then I'm fine with Per's playlistAdd and playlistClear functions.
>
> > >WZSound_setPlaylist( "none" );
> > >WZSound_playTrack( "event1.ogg" );
> > >WZSound_setPlaylistMode( "shuffle", "fadein" );
> > >WZSound_setPlaylistMode( "repeat_all", "crossfade", "fadeout" );
> > >WZSound_setPlaylistMode( "none" );
> >
> > Any particular reason not to use playlistSetMode() instead of
> > WZSound_setPlaylistMode()? It's shorter while preserving the same
> > meaning.
>
> For the scripts I don't care.
> For the code I think we should develop some unique and sane naming
> convention to prevent name clashes and provide a clear and consistent API.
> That's why I came up with WZSound_. Other engine (-> lib/) parts might be
> called WZScript, WZIvis (what does ivis actually mean/stand for?) or
> WZGrahics...
>
> > >Additionally I would sent following events to the scripts (and over the
> > >internal event-bus), namings are currently very bad:
> > >playlist_stop
> > >playlist_resume
> > >playlist_nextTrack
> > >playlist_customTrack
> > >playlist_customTrackEnd
> > >playlist_modeChange
> > >playlist_new
> > >playlist_end
> > >
> > >--Dennis
> >
> > Script events would be usefull. Those would end up being named
> > CALL_PLAYLISTEND, CALL_SONGEND etc following wz convention. But those are
> > details, provide me playlist functionality I'll take care of the rest,
> > probably not until mid february though.
>
> 2.1 won't be released in February and probably not in March or anytime
> soon. So this currently doesn't matter that much. ;)
>
> > PS: geez am I the only one having trouble replying to attached files?
>
> Apparently: Yes...
Just for clarification: I got the Open*L idea _after_ I wrote everything else
and then was to lazy to change everthing accordingly...
pgpvgFYiUq1vW.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
