Re: [crossfire] Crossfire server code cleanup/janitorial
Going back to to the original thread - certainly win32 is used, and I also do sun/solaris. I'm not sure if there is any conditional code based on platforms in crossfire - if there is, I would think most could be removed through proper configure checks (that code may predate the conversion to autoconf). I suspect in the case of sgi/irix, vax/ultrix and perhaps a few others, if support disappeared, no one would care. But without knowing specific areas, support for those might also be part of support for other platforms (something like a #if defined(irix) || defined(sun) ) or the like, so just removing irix doesn't do much. I think some of that might be sound code for the client - though even on linux, it seems that the sound 'standard' changes every 5 years or so. Changing C standard is certainly something worth discussing - C99 would be reasonable (in my mind) - C11 may be a bit too recent - while it may be widely supported, it might also mean that certain users would be forced to upgrade their compilers (and perhaps other parts of their system) faster than they really want. But it also really comes down to features - What C11 (or even C99) features are out there that would be of benefit to crossfire? I'm not familiar enough with the different standards to make any assessment on that. C++ has been touched on some. I'd add that there are going to be more C programmers than C++ programmers, just on the basis that to know C++, you need to know C. So by switching to C++, you may very lose some number of current or future potential developers. I'm also suspect that doing a piecemeal conversion wouldn't be at all useful - while there is lots of crufty code in crossfire, you'd really want to look and figure out how all the classes interact and so forth. Otherwise, you may just end up with a C++ version of crossfire which is fundamentally the same, just written in C++. I'm always a bit concerned about rewriting stuff just for the sake of rewriting - while it may find (and fix) some existing bugs in the code, almost certainly more new bugs will be introduced. So echoing some previous comments, I think gameplay should drive more new features. I also think it would be helpful to express what the benefits of the changes are. In terms of roadmap, I think there were some out on the wiki. But like most volunteer based projects, trying to stick to any such roadmap gets difficult - people tend to work on what they want to work on, and it may or may not match something on the roadmap. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
On 04/21/2014 01:23, Mark Wedel wrote: Going back to to the original thread - certainly win32 is used, and I also do sun/solaris. Solaris support seems like a good idea to keep. I think some of that might be sound code for the client - though even on linux, it seems that the sound 'standard' changes every 5 years or so. Sound support is now handled by SDL_Mixer, which works well with OSS, ALSA, PulseAudio, and the myriad of sound systems there are. Most, if not all of the platform-dependent code there has been removed. Changing C standard is certainly something worth discussing - C99 would be reasonable (in my mind) - C11 may be a bit too recent - while it may be widely supported, it might also mean that certain users would be forced to upgrade their compilers (and perhaps other parts of their system) faster than they really want. But it also really comes down to features - What C11 (or even C99) features are out there that would be of benefit to crossfire? I'm not familiar enough with the different standards to make any assessment on that. C99 has many new shiny features that I would really like to use. - Intermingled declarations with better locality of reference - Exact-width integer types (we try to hack around this right now) - New boolean data type (hacked around with our TRUE/FALSE macros) - Variable length arrays (may be useful in future) - Inline functions, to replace some macros in use - New style comments (trivial, but useful) - New library functions like 'snprintf' (used for quite some time) Of course, right now the blocking issue is compiler support, specifically from Microsoft. Both GCC and Clang support C99, except for a few floating point operations, and so do a number of popular compilers (Intel, maybe more). C++ has been touched on some. I'd add that there are going to be more C programmers than C++ programmers, just on the basis that to know C++, you need to know C. So by switching to C++, you may very lose some number of current or future potential developers. Personally, I prefer C simply because I don't know C++ (yet). Aside from greedy selfishness, I don't think a (partial) rewrite in C++ will be useful. C++ has nice features, but our aging code has done fine without so far. So echoing some previous comments, I think gameplay should drive more new features. I also think it would be helpful to express what the benefits of the changes are. Right now there's no pressing feature that requires C++ in order to implement. As far as I can see (which isn't very far) C is fine for the job. Of course, I don't know what job this is, which means... In terms of roadmap, I think there were some out on the wiki. But like most volunteer based projects, trying to stick to any such roadmap gets difficult - people tend to work on what they want to work on, and it may or may not match something on the roadmap. It would be nice to sit down and come up with a roadmap. I've been doing so much 'cleanup' work lately because I didn't have anything specific in mind to work on. Thanks, Kevin Zheng ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
On 04/21/2014 04:20, Tolga Dalman wrote: My impression about crossfire right now is that the development in the server and client code is pretty dormant for the last few years. At the same time, however, I notice some increased activity towards cleanup work. I want to take this impetus as a reason to contribute by myself. More help with Crossfire is always welcome. Two reasons are holding me currently up to contribute, in fact: 1. There is no roadmap or vision. Admittedly, crossfire runs pretty fine for ages now, nevertheless, I do see some open issues. 2. Parts of the code is crufty and even messy. To be honest, I'm scared off fixing issues I find in the code because of this. Having a roadmap or vision is a good idea. Right now mine is to make sure the game works on my operating system and keep it that way. My other vision is to make Crossfire more fun, but without any crystallization that's not very productive. I have many, many open issues with Crossfire, but I haven't considered them important enough to dedicate substantial work to them yet. I'd love to hear your issues so we can start discussing and working on those right now. 1. Define clear requirements for the crossfire server code (this might apply to the client as well). From this thread, I found out that the major platforms are Linux, BSD, MacOS X, Solaris, and Win32. What I'm still missing is the versions. Something like this would be nice: - For Linux I would just define the use of GCC 4.6 or higher, binutils 2.20 or higher, glibc 2.16 or higher. - For Win32 I would require Visual Studio 12 or higher - ... Naturally, these requirements should be testable by the developers. Practically, these items are added in the README file and perhaps published on the crossfire web site. The problem with drawing a bright line is that somebody is inevitably left on the other side. Many working groups have drawn a standard called C99; we do not have to rigidly adhere to it, but instead of requiring specific versions of a specific toolchain, we should write portable code reasonably within a particular standard. 2. With the platform requirements above given, C99 and/or C++11 can be assumed. Even if we decide not to use any C++ at all, I would suggest compile the code with a C++ compiler for reasons of portability. I've seen recommendations to compile C using a C++ compiler. However, if you refer to Bjarne Stroustrup's authoritative book he admits that certain incompatibilities exist. C++ is no more standard than C, and C is just as (maybe even more) portable as C++. 3. With defined platform and compilers, cleanup and janitorial work can start. This includes, e.g., the use of standard types (like bool or uint32_t), standard functions (like calloc), removal of various autoconf checks, etc. I'm in favor of doing this in the mid-term. We already have a nice collection of compatability macros that can serve as a crutch for compilers we do not obey C99. 4. Modernize architecture and replace existing components. I'm not exactly sure what this means. I also see no point in replacing components that have been in service and aren't breaking. I see no harm in rewriting code, but it'd be a lot more productive to focus on making the game more fun than fixing what isn't broken. Thanks, Kevin Zheng ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
