[I am assuming this was meant as a public post and have fixed the list so
that public is the default.. Sorry all, I was wondering why nobody was
actually replying ON THE LIST...]
On Sat, Aug 18, 2001 at 09:37:16AM -0700, LordHavoc wrote:
> Some comments:
>
> Joseph Carter wrote:
> >
> > I'd like some opinions on a few things I'm thinking about for the future
> > and want yours. =) I've been looking over the SDL headers and have been
> > thinking that they might help simplify our codebase even further if we
> > start to actually use the API as intended more. SDL supports a lot of
> > stuff we're not using right now, and most of it we have our own version
> > of. Our versions aren't always better.
> >
> > My network connection is screwed, so who knows when you'll read this in
> > relation to me writing it. I may know a little more about some of these
> > things I currently don't by then. If that happens, I'll say so then.
> > Otherwise, grab a copy of the SDL source and feel free to chime in yea or
> > nay on anything that follows.
> >
> > SDL_active.h
> > Includes a function called SDL_GetAppState. Don't know what it
> > does (no manpage) but it might tell us if the app is iconized or
> > something. Could be useful?
>
> According to the SDL HTML docs:
[..]
I've seen it. Useful for stopping sound when you leave the game focus,
etc.
> > SDL_audio.h
> > We already know that SDL audio will make things more portable, but
> > what those of you following who are not Linux people do not know
> > is that SDL defaults to using things like esound on Linux if they
> > are running. This is a problem since esound is not direct to
> > hardware - it's over network connection (usually to localhost..)
> > This is fine for playing mp3s and system sounds, but it sucks for
> > 3D games.
>
> Bug the SDL people about this perhaps?
I have made requests. As it turns out, esound may not be so bad to
localhost once my new sound code is done. That project is on hold though
pending other changes which are higher priority.
> > SDL_endian.h
> > All of this stuff looks like it can replace our LittleLong, etc
> > type functions. It's no more efficient certainly, it just happens
> > to be done by SDL for us and will save us the codespace in
> > common.c ..
>
> Depending on the OS this could add another instruction or something to
> the function call if it is an external library, making it perform worse
> than the id ones, if static linked though it's probably fine.
I think we might need to keep some of the functions anyway since we have
endian functions that SDL does not. I'd like to have us use SDL_RWOps for
file access though, in which case the SDL endian functions would be a good
idea. Only way to know how it will work is to try it I think.
I suspect we may find that we don't want to use it in the network code,
which you and Mercury recently reminded me does happen.
> > SDL_image.h
[..]
>
> Could be a good idea, or not, I'm concerned if not all formats are
> supported on all platforms, as that could result in people making mods
> using formats that don't work on all platforms, and then the burden
> falls on us to support those (ick).
I think I have decided that the Targa loader might be useful, as might the
PNG loader.
> BMP is likely to work on all platforms, because SDL is used for porting
> windoze games rather often.
Yeah, but why the hell do we even want BMP support?
> Heh, the name winquake.h is completely out of place in twilight, at
> least rename the thing, if not merge it into a more appropriate place.
Yes, it's out of place. I do not have a cross-compiler setup or I'd be
making more changes to see that things like it die.
> > SDL_mixer.h
> > This is crap. The SDL guys all know it's crap, and it's not part
> > of SDL proper. MAYBE it's worthwhile to try and grab the code for
> > impulse tracker files out of it for dynamic music. I'm not really
> > convinced it's even good for that, I've been told that the .it
> > code has a few limitations. I haven't actually looked at it to
> > see if it's salvagable.
>
> The less unnecessary features there are, the better, that's my policy.
We do want dynamic music at some point and there is some code for it in
SDL_mixer, I just think we could do better to use our own, that's all.
> > SDL_timer.h
> > Only milisecond accuracy, I think it is possible for us to get
> > much tighter tollerances than that on most OSes, but I don't
> > recall that we actually USE more than that. If we don't, then we
> > should consider using SDL's, one less item in sys_${OS}.c..
>
> On windoze the reliable timer (used in Q3, QF, lhnqserver, and various
> others) is only millisecond accuracy, the other one (PerformanceCounter)
> tends to stray over time (the win98 speed cheat bug with original QW) as
> it is based on the cycle counter in the CPU, which is usually slightly
> misjudged in speed.
*nod* We should probably be using it - I think we are anyway.
> If I didn't need the precision I'd be using the reliable timer in
> DarkPlaces, but I do need the precision for r_speeds2 1 (shows how long
> each rendering stage took), so it's set up as a compile time option...
>
> Millisecond precision tends to make fps counters a bit inaccurate over
> 50fps as well, for obvious reasons.
Yeah, I have noticed a several fps difference between runs and I realize
this is partially to blame. One solution is to rewrite the fps code to
draw a few frames in a given time period before checking framerate. Now
this means the fps counter does not instantly update, but OTOH it means
the fps counter will be readable. You pay a small penalty in that you'll
notice a slight fractional margin of error when a frame happens just fast
enough or just slow enough to make the check happen longer than intended,
it happens with the GLUT gears demo.
Of course gears checks fps every five seconds. That's nowhere near enough
for our purposes. Even once a second is possibly too much. Half second
might make more sense.
--
Joseph Carter <[EMAIL PROTECTED]> Free software developer
We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.
-- Dave Clark
PGP signature
