From: <cr...@bi...> - 2000-05-16 14:49:54
|
Christopher T. Lansdown wrote: > > Well, since getoptlong isn't standard beyond gnu (i.e. unix), it makes more > sense to just write the functionality that we need. Of course, it's also > possible to support the win32 platform using cygwin rather than VC++ and > thus keep most of the unix functionality. couldn't we just use the gnu code? bzflag is GPL after all. > I haven't intimately looked at the code, but it is very > decentralized right now. it isn't really. sure, it's not a getopt()-like function, but all the command line argument parsing is in a function named parse(), except for a helper function called only by parse(). > Isn't the platform model platform dependent as well? I thought that NT and > win9x has no fork() model the way that unix does (or that it at least > behaves differently). And do you really have platform independent sound? > And what about the windowing code? I didn't see any glut functions being > used either for windowing or input. Things like joystick support will be > hairy to do in a crossplatform way if that's at all possible. you've been taking about bzfs. bzfs doesn't fork, doesn't have sound, doesn't use windows, doesn't use graphics, won't need joystick support, etc. bzfs has very little platform dependent code. bzflag does, but i did try to localize it into just a few classes per system (except for networking, which should've been done in retrospect). > I don't mean to quibble, just to ascertain how much code is really > cross-platform. My (limited) experience with other crossplatform projects > is that win/unix crossplatformability is not easy to maintain as they are > two fairly different worlds. How easy has it been to maintain here? Have > you taken the approach of writing an abstraction layer or lots of #ifdefs? look at platform/*. virtually all the platform dependent code is there, though there are a few scattered #ifdefs and the clock code is elsewhere. it's a small part of the app. cheers, -chris |