Am Freitag, 26. Januar 2007 schrieb Giel van Schijndel: > Dennis Schridde schreef: > > Am Donnerstag, 25. Januar 2007 18:38 schrieb Troman: > >> ----- Original Message ----- > >> From: "Troman" <[EMAIL PROTECTED]> > >> To: "Troman" <[EMAIL PROTECTED]> > >> Sent: Thursday, January 25, 2007 5:57 PM > >> Subject: temp > >> > >>>> Wel the functions on their own look quite good to me. > >>>> Their prototypes however... Let's just say that I don't like the idea > >>>> of passing pointers into the scripting engine. > >> > >> Why not? That's the way most of the scripting stuff works right now. > >> Scripts currently work with a lot of pointers passed from WZ, although > >> from the scriptor's point of view there's no difference between > >> integers/bools or pointers to some internal wz structures. > >> Not that it really matters to me. If we just work with integer ids, that > >> would mean we have less different types to define for scripts (I don't > >> really like the idea of flooding scripts with dozens of new types, > >> unless really needed, but i'm not yet sure what would be optimal for > >> us). > > The fact that that's the currently employed technique hardly makes it be > good. And indeed from the scripter there is no difference between a > regular integer or a pointer. Which makes it all the more dangerous to > pass pointers into scripts. This could easily result in a segfault > beyond our control. I guess the engine provides something like a const keyword... So there is no difference at all between a integer id, where we would have to guard that it doesn't get mixed up with another id in the same range, like Troman said, and a pointer were we would also have to guard, so that it doesn't get confused with another pointer to some other struct.
> >>>> In fact I think dynamic arrays (std::vector or std::list) are probably
> >>>> the
> >>>> best way to solve this. Then once your using C++ anyway you might as
> >>>> well use a smartpointer to hold the `track' object which will fix the
> >>>> problem I
> >>>> mentioned above.
> >>>>
> >>>> Such a small usage of C++ should be rather easy to contain/manage in a
> >>>> single (e.g. `lib/sound/playlist.cpp') source file.
> >>>
> >>> Well, C doesn't have std::vector, so I had no other idea...
> >>> What I just thought about was some selfmade dynamic array:
> >>> struct Playlist { meta-info; Track[]; }
> >>> malloc( sizeof(meta-info) + sizeof(Track*) * playlistSize );
> >>> or realloc( ... );
> >>> Doesn't look nice, but would be an option...
> >>
> >> While surely not as elegant as dynamic arrays we can as well just use
> >> fixed arrays if those are only used to hold pointers to playlists, to be
> >> honest I doubt anyone would want more than, say, 20 playlists at a time
> >> (i'm being rather generous).
>
> Erm, I actually meant to contain the playlist itself (i.e. a list of
> tracks in an order) in a dynamic array, so that dynamic array would _be_
> the playlist.
>
> Oh and 20 playlists? Yes you're being generous, I'd guess 5 would
> already be enough. ;-)
Actually I meant the internal structure of the playlists, not the external.
Means: My problem was not the dynamic number of playlists, but the dynamic
number of tracks in it.
> >>>>>>>>> WZSound_setPlaylist( "none" );
> >>>>>>>>> WZSound_playTrack( "event1.ogg" );
> >>>>>>>>> WZSound_setPlaylistMode( "shuffle", "fadein" );
> >>>>>>>>> WZSound_setPlaylistMode( "repeat_all", "crossfade", "fadeout" );
> >>>>>>>>> WZSound_setPlaylistMode( "none" );
> >>>>
> >>>> Lets not use Cstrings (or any piece of rope for that matter; i.e.
> >>>> strings)
> >>>> to indicate play modes.
> >>>
> >>> This was for the scripting engine. I don't think it supports bitflags,
> >>> does
> >>> it? So the first and possibly easiest option was concatenating strings.
> >>> Maybe we could also provide the C-defines (PLAYLIST_SHUFFLE,...) as
> >>> constants
> >>> to the scripting engine and add them on another...
> >>
> >> Sure, best way to solve this is to provide constants predefined by wz,
> >> works like a charm.
>
> Sounds nice.
>
> >>>>>>>> PS: geez am I the only one having trouble replying to attached
> >>>>>>>> files?
> >>>>>>>
> >>>>>>> Apparently: Yes...
> >>>>>>
> >>>>>> Wouldn't have asked if it was apparent. I was refering to those '>'
> >>>>>> markers actually. Don't see a way how to add them with outlook
> >>>>>> express,
> >>>>>> which forces me to make a small detour.
> >>>>>
> >>>>> Outlook doesn't give you those '>' if you press reply on a mail which
> >>>>> has
> >>>>> an attached file???
> >>>>
> >>>> Of course I can advise you to take and use Thunderbird instead ;-) .
> >>>> It's more powerful than Outlook (e.g. in case of low level access, mem
> >>>> footprint, etc).
> >>
> >> Might as well do this someday, for now I think I'll give Outlook a try
> >> and see if it offers enough functionality (using Outlook Express right
> >> now).
> >>
> >> BTW why don't we just use forums for such discussions? This starts to
> >> look a bit awkward to me. Maybe we can ask Kamaze to set up some
> >> protected area for the developers and those participating in the
> >> mailinglist discussion? Personally i'd also be fine with a public forum,
> >> not sure if this would work well though.
> >
> > I think most of us are going well with a mailinglist and prefer it this
> > way. At least to me it's much simpler to fire up my mail client and watch
> > several threaded discussions. Forums have that flat, time-related style
> > (lost the words... Allready getting late. I mean they only have one
> > direction, you can't split of a discussion as easily) which makes the
> > inconvenient IMO...
>
> Yep, I'm one of them, I really do prefer an email client above a forum.
-DS
pgpQJAltgttyW.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
