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..

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
                   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

Reply via email to