[freespace2] Patches for music and movies

Taylor Richards mtrs at bellsouth.net
Wed Mar 30 12:48:16 EST 2005


On Wed, 2005-03-30 at 18:30 +0200, Pierre Willenbrock wrote:
> The timer code seems to be problematic, though. Sometimes the entire 
> movie or part of it is played too fast.

I thought that had been addressed enough since I don't get it anymore.
The game's timer just isn't good enough then so I'll change it back.

> I experienced audio lag, too. The buffer ring is filled too fast at the 
> beginning. When playing, it always contains about 62 buffers to be 
> played. That equals to about 2 seconds. Reducing the size of the ring to 
> 32 helped that, the lag is near to unnoticeable(but i get some queue 
> full warnings).

Is that timer related or something with my changes to your audio code?
If it's timer related then it should be fixed when I switch back to pure
native code rather than relying on SDL.

> The opengl part looks a bit bloated to me. Expecting w and h to be the 
> width/height of the output area, and g_screenWidth/Height to be the size 
> of the input image, i think this will do the same job:

The OpenGL code has to work on Voodoo cards which means a 256x256 limit
which is why it's divided like it is.  Doing it in one area is a lot
simpler but unless it's a better way to work while supporting the limit
then that code isn't going to be changed.  The current code has already
been well tested and optimized for a variety of cards including the
special problems of the G400 and the limits of the old Voodoo cards.

> When allocating the backbuf it is no longer needed to allocate twice the 
> needed memory(or there is still a bug left after the decoder16-fix - 
> just tell me which movie, i will let valgrind check that). The memset 
> needs to be changed then, too(i forgot to do so).

Ah, didn't look closely enough at that.  I don't want to use realloc at
all though so is that still needed too?   If the decoder16 fix takes
care of the problem then I would guess not but I haven't checked yet.

> src/ui/timer: timer_get_microseconds() wraps around(if we are lucky it 
> simply wraps) after about 1:11h(or half)

Not really concerned about that.  There shouldn't be any
timer_get_microseconds() calls which need to work for more than a few
minutes so having it work for long periods without wrapping isn't a big
deal.  If you find a place where it is an issue though let me know.  As
I understand it it should wrap properly (according to SDL docs that I
looked at once-upon-a-time ago).

> src/mission/missionload.cpp:240: there is still an instance of '\\' left
> src/network/multi_update.cpp:155: here too

Missed those, thanks for the catch.  If you find anymore let me know.
Hmm, it's wrong in fs2_open as well now that I'm looking.

> My code is currently working for my linux. It does handle multiple discs 
> in multiple drives correctly, and ejects the current freespace disc if 
> it does not find the needed one. It relies on (u)mount and eject. It 
> also needs warble_fs2.vp to be on hard disc. Is this file normally 
> installed onto hard disc? if not the cfile-code must be changed to be 
> able to close and reopen file descriptors while the rest of the game 
> thinks it still keeps the files open. This may be problematic in the 
> case of audiostreams, which do their own io(and do read from 
> warble_fs2.vp...). There still may be all kinds of problems with 
> automounters.

Is it OSX friendly?  tigital may be able to get something better that's
OSX specific but I don't want to break anything putting this code in so
we'd need to coordinate the changes so that it all works.  Not sure
about warble_fs2.vp but that's really not a concern anyway since we can
make it a default install requirement.  I don't foresee that (not being
on the HD) as a problem though as long as the CDs are a requirement if
they are used at all.  I believe that I was using an ini setting so that
if CDs were going to be needed then they were required.  We can also do
a VP check in game_init() to make sure that all files are available and
require the CD if they aren't.  The game shouldn't have any problematic
handles open when CDs are going to swapped anyway.  They would get
opened after the swap and existing ones should already be closed before
the swap.  It's been a long time since I went through that code though
so I may not be remembering the procedure that well.  If the only issue
is making sure that all audio streams are closed before we swap CDs then
that's easily doable.

The automounter thing needs to be worked out.  Whether it's work-arounds
specified in the README or better error handling in the code, doesn't
really matter as long as users don't have to fight it endlessly.  Both
main desktops (KDE and GNOME) automount now and we need handle that
properly, disabling that feature in the desktop environment should not
be considered an option.  This a problem I was dealing with too but I
don't remember how far I got with it.

Not sure where the last current code is (few computer change outs since
then) but here is a partial (just freespace.cpp) diff of what I had at
one point.  This is old code and I haven't checked it in a long time so
I wouldn't use it for real until you give it a good going over.  There
was also some header changes and changes to cutscenes.cpp too but those
aren't included.  It supports a user specified mount point as well in
case you want to work off of a removable drive or network drive or
something.  Support for NFS mounts was a request which is why that
network support is there.  The premise is that it would help with LAN
games where you didn't want a full install on every single computer and
so one network location could be relied upon.  It doesn't mount or eject
anything but does work under OSX, I think.


Taylor

-- 
Taylor Richards <taylor at icculus.org>




More information about the freespace2 mailing list