Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: From c to c++



On Dec 6, 10:06am, W.E.B wrote:
> Subject: From c to c++
> 	I'm working with a group of students here at the University of
> Nevada Reno who'd like to port crossfire to c++. I realize it's under the
> GNU license but would like to hear from some of the people working on it.
>
> If this becomes a reality it would be an upper divisional class in
> porting using crossfire as an example. With any luck, the class would
> first abstract the code into some general classes and then address the
> issues of static versus dynamic code. There are plenty of topics which
> crossfire implements and is an excellent model to be divided up. Hopefully
> the system would be easier to expand and maintain if we were to do a job
> well done.
>
> If you have some ideas/suggestions we'd be very pleased to hear them.
>
> (Btw, I understand the game is in a state of flux and really would like
> to let you know if we decide to do a rewrite/port anytime soon. I'd
> prefer to work with the others already familiar with the system rather
> than against.)
>
> -web
>


 My main comment on such a project would be the fact that the crossfire source
is very dynamic.  As such, you will either need to be taking in patches that
were written relative to the last version (Ansi C) or need to make frequent
releases (that actually work properly, so that people can develope from that
release)

 I think the other thing you woul need to be careful of is letting the
crossfire programmers as a group know what you are doing, and at least get some
ssort of agreement from them.

 If you effort goes in some direction that the crossfire programmers in general
don't like, there may be a strong push to just keep using the ANSI C version
instead of going to your C++ version.  This may not mean a lot, but it does
carry the chance that your porting effort leads to something that no one wants
to use.

 I will agree with Tyler that the code is pretty messy (inconsisent might be a
better word.)  But I think that problem will always exist in a situation where
numerous people are providing patches/additions to the program.

 I will also agree with Petri in that a good first goal would be to get the
game to compile in both Ansi C and C++ (I believe this is acheivable)

 Also, while the present code is fairly messy, at the same time, at least a
fair number of know it pretty good, such that if we want to change something,
we know what areas of the code it effects and what ramifications it will have
(or other areas that are dependant on it.)  If you do a rewrite, that will not
necesssarly be the case.

 If you are actually looking for something to rewrite, I think a better
candidate would be some other program in which work has ceased.  In that case,
you don't need to worry about merging with peoples changes (since no one else
will be working on it), and you don't need to worry about pleasing the people
who are already using it - you can pretty much do anything you want, without
having to worry about how anyone feels.

 Crossedit is almost such a case of this - know one is actively working on it.
 However, at the same time, I don't necessarily know if it needs a major
rewrite.

 My other concern with such an effort is that it gets started, but never fully
finished, and ends up leaving the game is a state that was really no better
than before.

 This message is not meant to say not to convert crossfire.  But I mentioned
several worries above that I would like to see addressed/how they will be dealt
with.

 Graphical code seperation:  This is really related to William's comments, but
was part of the discussion:

 Right now, I believe all actual display (output) code is contained in xio.c.
 It would not be especially difficult to write substitutions for all those
functions to send it over a pipe or something (ala client.)  The bigger issue
is that there isn't a big reason to do that (so you use some other protocol
instead of X, but what does it gain you?)  The main issue on client server was
to have a reasonably smart client - this partially exists.  Some things this
reasonably smart client does is keep track of items in the players inventory
locally, and sends more abstract commands on what it does to these items.  It
also does stuff like handle keybinding on the client level, and not the server
level.

 One goal of such a system was to make the client lower bandwidth (I don't know
how much it achieved this or not), as well as remove the X11 code from the
server.

 However, the main issue is that in order to do this, it requires much more
than just replacing output routines - input routines also need to be redone, as
well as logic for updating objects on the client side.  At some time, doing
animations locally on the client is a goal (right now, I believe the basic
logic is that it just tells the client that the face has changed, and if you
have lots of animated objects, it ends up sending bunches of those messages.)

 Whether you can do that and keep a client that is usuable for several
different things is very debatable.

 One other issue is that right now, the server keeps track of a lot of
information on what it last sent the client, so that it knows what has changed
and only sends that.  I don't know if all that state information is necessarily
a nice idea, but a lot of it is just from the X11 code, that uses it to know
what needs to be redrawn.



-- 
 --Mark