Since the list wasn't doing public replies before...
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:
>
> SDL_GetAppState
> Name
> SDL_GetAppState -- Get the state of the application
> Synopsis
>
> #include "SDL.h"
> Uint8 SDL_GetAppState(void);
>
> Description
> This function returns the current state of the application. The value
> returned is a bitwise combination of:
>
> SDL_APPMOUSEFOCUS The application has mouse focus.
> SDL_APPINPUTFOCUS The application has keyboard focus
> SDL_APPACTIVE The application is visible
>
> See Also
> SDL_ActiveEvent
>
> > 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?
>
> > SDL_AudioInit is one of those intended-for-internal-use functions
> > which happens to let you specify the driver to init. You should
> > only do this of course if you know what driver you need. If we
> > can find a way to figure out what's available, we can specifically
> > try them in the order we want. It's the best we can do for now.
>
> Nasty but could work. Would be better to get SDL improved.
>
> > 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.
>
> > SDL_image.h
> > Not part of SDL, this is SDL_image. I'm not convinced we should
> > use this. If we do, it'll give us support for BMP, pnm, xpm, xcf,
> > pcx, gif, jpg, tif, tga, and png graphics. Probably not all of
> > them, on all systems though. Chances are good that we can't hope
> > for more than gif, jpg, pcx, and png to actually work on all the
> > major platforms. It's also read-only support. Now maybe it's
> > worth using anyway, I'm not convinced. Its tga loader is better
> > than ours, that's for certain.
>
> 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).
>
> BMP is likely to work on all platforms, because SDL is used for porting
> windoze games rather often.
>
> > SDL_main.h
> > This should remove our need for a seperate sys_${OS} on the basis
> > of main/WinMain/WhateverAMacCallsMain functions. We really should
> > investigate this as it'll be one more piece of code we don't have
> > to try and maintain for several different OSes. I am personally
> > aiming to have exactly one set of files that everyone uses when
> > compiling, no exceptions. That means no winquake.h for win32
> > even.
>
> 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.
>
> > 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.
>
> > SDL_net.h
> > Anyone want to investigate this? It's another lib that's not part
> > of SDL. It provides TCP/UDP in a somewhat portable fashion. It
> > seems simple enough, but I guess this factor alone scares people
> > away from the API.
> >
> > SDL_rwops.h
> > !! typedef struct SDL_RWops ... Um, damn, no zip support. We
> > could fix that though, and same for pak support. This is more or
> > less what I was doing before in QuakeForge for the basis of a vfs.
> > They didn't want it then. With this, it would probably be much
> > easier to rewrite (I didn't keep any of my QF stuff, sorry) if we
> > decide to go that direction.
> >
> > 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.
>
> 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.
>
> > SDL_types.h
> > We should probably be using these in most places, especially those
> > that mess with files.
> >
> > I don't know that any of this should be called release critical for our
> > first release, but if we go these directions, it probably should be for
> > our second release.
> >
> > --
> > Joseph Carter <[EMAIL PROTECTED]> Free software developer
> >
> > Steal this tagline. I did.
> >
> > ------------------------------------------------------------------------
> > 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
--
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
