On Wed, 12 Jan 2000, Andreas Beck wrote:
> > I've been playing a 'wee' bit with ggiplay (the quicktime movie player).
>
> Ah - good. Nice to see someone uses/enhances it.
>
> > - smooth scaling (bad habit for me :)
>
> *grin* - how about finally writing a scale target ?
I still say I don't know how to do it. Now it's for a simpler reason - I
don't really know what method I want to use for it. Gotta admit the code
is -fast-! :) [I get faster performance from the scaling code onto
directbuffer than I do from a crossblit... or maybe the same. It's
pretty close anyways :]
Update: now multithreaded: Primary reader; secondary renderer. Renderer
is designed to toss frames if it's falling behind too far (but still needs
a little work to really handle RT-type stuff). Audio is next after that..
*grin*.
Note that inter-thread messaging is -evil- and requires lots of
lock-management prone to lockups. Debug this under X using printfs as
anything else crashes. ***stupid gdb*** that's supposed to handle threads
still complains of "unknown signals".
Ummm... Should I just go directbuffer and build a renderer-target
fallback that uses crossblit? Oh, I guess so...
> > - What do I do for sound? I could use GSI (which does -not- work
> > for me... the daemon -never- starts)... Maybe I should look
> > at a GGI-style sound management library?
>
> Hmm - last time I looked, GSI was geared towards action style games.
> I.e. free running midi/CD plus 3D positioned sound-effects.
>
> This is quite a bit different from your current needs which are pretty much
> streaming large amounts of PCM data in a synchronized way.
>
> Yes - a GGI-like Lib would be interesting, as there are at least:
> OSS, Kernel native drivers, ALSA, network audio servers, dumb /dev/audios,
> the Win stuff ...
>
> Unifying this would be great ... but it will need quite some effort and
> study of all possible targets to get it right.
Got it. I will take a peek but more below.
Anyone have any ideas?
Current todo:
-> Allow PCM transmit/streamed with synchronization
-> Allow PCM receive/streamed also with synchronization
-> allow sharing with ViaVoice so voice-recognition
can be mixed with music playing.... I picked the beta
up of this package and it's -cool-! (IBM's dev section)
-> Allow multiple transmit streams | mixing
-> 3D streamed data, possibly more. Doesn't really make a
lot of sense unless you have something like background
music being mixed with, say, incoming voice transmissions
*grin*
Or with MIDI-emu or MOD/XM/S3M/... players...
-> Maybe a MIDI handler? Maybe later... Or could spawn TiMiDiTy
into one (or two) of the data-streams to handle this.
I realize this is a little off-topic for GGI but I thought I'd approach it
here as there's gamer-types :)
> > -> Sound-management -requires- threads! (or at least
> > processes ie: fork() + SYSV semaphores && shared mem,
> > though most sound can be done with just fork() and a pipe)
>
> I see. Yes - at least in the way OSS supports stuff now. With ALSA style
> access to DMA pointers and stuff, I can see single-threaded versions, but it
> would still be a bit clumsy.
It's a -lot- easier to do it message-based/multithreaded. I've just
finished testing/running a very primitive messaging system :)
> > - Also threading and portability. Linux threads are not
> > compatible with Windows threading. And not with any other Unix's
> > AFAIK. Maybe another idea? I really don't know. Linux's
> > threading model is -very- efficient. Do you know if there's a
> > pthread-lib for Windows?
>
> Well - there is always one - forgot the name -, but IIRC it is not preemptive.
preemptive only. Now it -can- be done cooperative but I haven't really
designed this system for that. Generally cooperatively-threaded systems
have to be pretty custom-designed. Now a GTK or X program can get away
with it, but not something that's not message-based to begin with.
Ummm.. Folks, let me know if I should post this anywhere... I've still
got my geocities account (www.geocities.com/Tokyo/Spa/1076/index.html or
for that matter http://www.geocities.com/winterlion/ :)
There's my patch for abuse to run under GGI there. It's also got my
original scaling-toys in that code IIRC...
[I also have a scaling patch for d1x and snes9x if anyone wants... should
I? :]
That scaling target -could- be made smart and told "go to this resolution
if [x..y] resolutions are selected and go to that resolution if [a..b]
resolutions are selected"... Any ideas? :) I'm still not sure how to
approach this...
G'day, eh? :)
- Teunis
