----- Original Message -----
From: "Troman" <[EMAIL PROTECTED]>
To: "Troman" <[EMAIL PROTECTED]>
Sent: Friday, January 26, 2007 10:44 PM
Subject: tmp2
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.
Not just because of that, it simply works well, I had no issues with
pointers whatsoever.
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.
The way it is now you can't do anything to a pointer but only access it,
bison would simply not compile script if you tried to manipulate a pointer,
there are no operations that pointers support. You can't even set it to NULL
using scripts, that makes pointers safe. What you can do is pass it to some
internal function for it to mess it up and that's it. So that's not an
issue.
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. ;-)
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.
Well no forum then. It's just when replying you have to count those 'greater
than' signs to find out who you are actually refering to and when you have
more than 10 that looks messy not to mention that all text is cluttered.
--
Giel
_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
