Joseph Carter wrote:
>
> [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...]
Oh, I thought all the lists were like that already.
<snip>
> I think I have decided that the Targa loader might be useful, as might the
> PNG loader.
No one is going to throw any weird TGAs at it, that only leaves PNG,
just grab that support from equake or something.
> > 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?
I don't want BMP support, I was only mentioning it :)
> > 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.
Set up a cross-compiler, if only to see what breaks when you change
things... Makes it practical to do large changes :)
> > > 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.
Games seem to be moving toward linear formats like mp3 (Serious Sam and
others) and wav (SiN, Quake3, and probably a few others), and since mp3
is not an option... wav is easy to play back, and they both allow
fading between tracks.
> > > 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.
Here's a thought, use the millisecond counter, combined with the
performance counter, the performance counter would fill in the fraction
below milliseconds, since there would be no highlevel straying, no one
would care.
How to combine them will take a moment's thought however.
Well that moment is over, just multiply the performance counter time by
1000, subtract the integer portion, multiply the millisecond time by
1000 (and since it is already in integer units, that is already the
case), add the fractional milliseconds from the performance counter time
to the millisecond time, and you've got a fraction, which might be total
chaos, or might not... heh.
> 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.
I'm fond of twitchy framerate counters :)
Perhaps every .25 sec.
> --
> Joseph Carter <[EMAIL PROTECTED]> Free software developer
>
> We reject: kings, presidents, and voting.
> We believe in: rough consensus and working code.
> -- Dave Clark
>
> ------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature
--
LordHavoc
Senior Editor for http://www.gamevisions.com
A member of the Brotherhood of The Axe game clan.
Author of DarkPlaces Quake1 engine and mod (
http://darkplaces.gamevisions.com/ )
"War does not prove who is right, it proves who is left." - Unknown
_______________________________________________
twilight-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/twilight-devel
