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.
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.
I have no intent to start a flame war about anything or breaking functionality.
Instead, I'd like you to consider my proposal consisting of these steps:
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.
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.
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.
4. Modernize architecture and replace existing components.
Best regards
Tolga Dalman
On 04/21/2014 08:23 AM, Mark Wedel wrote:
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
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
