Long term source code goals...

[Tropper]

Hi everbody,

a couple days ago i notice that there is still one Warzone project alive out there - talking about you guys! It seems that the major goal right now is still code clean up. BTW: when i look over the 2.0.5 code release i have to say that the code seem not as bad as i thought i would be - take a look over Ken Silvermans BUILD-Engine if you wanna know how really bad code looks like.

Right know i asking myself about your long terms goal with the source code. I'm not talking about tommorow, next week nor the next couple of months - i really mean _long_ term. I have seen you already kicked out the PS1 support (what i really appreciate) but there are still the old fixed point macros around for example...

So my question is: are there any plans to switch over to C++ at some point in the future, use STL, replace  structs by classes and stuff like that or is the plan to stick with plain C forever and just improve the game itself?

Tropper

[Watermelon]

Hi everbody,

a couple days ago i notice that there is still one Warzone project alive out there - talking about you guys! It seems that the major goal right now is still code clean up. BTW: when i look over the 2.0.5 code release i have to say that the code seem not as bad as i thought i would be - take a look over Ken Silvermans BUILD-Engine if you wanna know how really bad code looks like.

Right know i asking myself about you long terms goal with the source code. I'm not talking about tommorow, next week nor the next couple of months - i really mean _long_ term. I have seen you already kicked out the PS1 support (what i really appreciate) but there are still the old fixed point macros around for example...

So my question is: are there any plans to switch over to C++ at some point in the future, use STL, replace  structs by classes and stuff like that or is the plan to stick with plain C forever and just improve the game itself?

Tropper

switching to C++ from plain old C was discussed on the mailinglist,though most of us didnt find any technical reasons to change it to C++ from C,also the codebase is very big and complicated,so converting the exist code to C++ is not an easy task.

personally I found some of the data structure and algorimth C implementations in wz are pretty brilliant/suitable for such game,and they probably run faster than the STL counterparts,for instance,the linked list is a perfect alternative to C++ class,for its dynamic growing nature.The linked list has less memory footprint and faster traverse compare to vector templates.

C++ abstract data design might help reducing critical bugs/making debugging easier,but that does come at a cost:it will increase the function call overhead when accessing private/protected members.

I am not sure about the long term goals,maybe these can be considered as long term goals for now:

http://wz2100.net/wiki/development:future_ideas

[Tropper]

Arrrgh, i knew the old "there is nothing you can't do in plain C" and "performance comes first" arguments would show up. Btw, i'm aware a switch would not be an easy task. But again, i was talking about the very far future.

Anyway, the future idea page sound fine to me. I was searching for something like that but couldn't find it by myself.

[kage]

yeah, i was one of the c++ switch advocates back in the day, mainly because i was still under the mind control of computer science teachers, however, as i've independently looked into it, i've come to the realization that, while c++ might create better code (this varies *wildly* depending on intended use), c always creates better programs, assuming the code is correct in either implementation, and for approximately 50% of those cases where c++ makes for much better code, a combination of ansi c with an embedded interpereted language (such as python or lua) is much better than the c++ implementation. c++ is good, but it's hardly a general-use language in the same way that c is (granted, this may be due to the far greater maturity of c, combined with the unstable nature of the c++ spec which makes it less "portable").

that said, c++ typically finds an irreplacable niche in gui design (one that ansi c seems to have a really hard time filling), so modularizing warzone's gui system and widgets into a library (probably statically linked, but with g++ as opposed to gcc churning out the object file) might have very positive benefits, at the slight expense of a slightly more strange build environment. for the rest of the game, however, a c struct will do everything a c++ class will when you look at the actually useful semantics, and it'll do it in signifigantly less assembly.

[Tropper]

I think we can stop the C++ vs C discussion at least for the moment. I still would prefer C++, but all in all it doesn't matter right now - even i would convince you. And if you already had that kind of discussion it's a little bit pointless to start a new one.

My main problem right now with the source code is more the lack of documentation. Maybe thats a good start for me where i can help the project; adding doxygen comments to the functions while trying to understand how it works. I pretty sure that it will be not a great help the main coders, but would be a great help to people who are new to the code like me.

[Kamaze]

C++ is used in the sound branch. Lib::Boost too.

[gerard_]

I think we can stop the C++ vs C discussion at least for the moment. I still would prefer C++, but all in all it doesn't matter right now - even i would convince you. And if you already had that kind of discussion it's a little bit pointless to start a new one.

My main problem right now with the source code is more the lack of documentation. Maybe thats a good start for me where i can help the project; adding doxygen comments to the functions while trying to understand how it works. I pretty sure that it will be not a great help the main coders, but would be a great help to people who are new to the code like me.

I think that starting with simple "janitorial" tasks like adding doxygen comments is a good idea. Some other things to look into might be fixing warnings (take a look at the --enable-debug flag), declaring functions as static, and all other sorts of code cleanup.

[DevUrandom]

Yup, doxy-comments are nice. Sadly I didn't get to create as much as I wanted.
Also marking stuff const can be of use.

[Per]

The code is starting to shape up. It is not so ugly as it used to be. There are some rather large leftovers, such as the network code (ugh!), but we will get it all into decent shape eventually.

Converting stuff to C++ is just a waste of time which will generate a new bugs and problems, which we really do not need.

If you want to pitch out, there are still warnings left. Try --enable-debug=relaxed to see them.

[tuant20]

My main problem right now with the source code is more the lack of documentation. Maybe thats a good start for me where i can help the project; ...

Hope info in this thread would help: http://wz2100.net/forum/index.php?topic=374.0

[Tropper]

personally I found some of the data structure and algorimth C implementations in wz are pretty brilliant/suitable for such game,and they probably run faster than the STL counterparts,for instance,the linked list is a perfect alternative to C++ class,for its dynamic growing nature.The linked list has less memory footprint and faster traverse compare to vector templates.

No offense Watermelon, but you mean brilliant like storing a "current node" pointer in the list structure itself and use goFirst(), getNext() functions to walk over the list instead of using something like an iterator or a relative getNext(element) function?!

SCNR
Tropper

EDIT: I have to admit that i didn't check if the goFirst(), goNext() functions are used anywhere. I'm still at work and haven't found time to setup the IDE/code/project yet.

[Watermelon]

No offense Watermelon, but you mean brilliant like storing a "current node" pointer in the list structure itself and use goFirst(), getNext() functions to walk over the list instead of using something like an iterator or a relative getNext(element) function?!

SCNR
Tropper

EDIT: I have to admit that i didn't check if the goFirst(), goNext() functions are used anywhere. I'm still at work and haven't found time to setup the IDE/code/project yet.

wz uses C implementation of linked list,unlike C++ ones,it doesnt have to use methods to access first and next element in a singly linked list,instead it stores the pointer to the first element in a global variable and use this->next directly instead of getNext() or sumthing similiar,the wz linked list iteration should be like this:

for (psTemp = psFirst; psTemp = psTemp->Next; psTemp)
{
//do something on psTemp
}

[kage]

actually, iirc, c++ can use the exact same semantics, but unfortunately, c++ programmers often classify it for no reason at all, greatly decreasing the potential performance.

[DevUrandom]

Agree with Kage, even though I don't think it really decreases the performance.
And actually your loop seems wrong to me. Shouldn't it look like following?

Code: Select all

for (psTemp = psFirst; psTemp; psTemp = psTemp->next)

[kage]

Agree with Kage, even though I don't think it really decreases the performance.

an optimizing compiler might inline a function like getNext(), in which case, no, it wouldn't decrease performance. however, if it's not inlined, then you're looking at a lot of stack manipulation that is always implicit with any compiled-in function call, and since linked lists are used by programmers in almost all cases for their performance benefits, it seems shameful for a programmer to put it within a function, even if they knew it was going to get inlined when they compiled it. in general, using functions for that kind of linked-list manipulation is a signature computer-science type thing to do, where the student explored linked lists as an "interesting data structure" rather than the practical applications behind it.

And actually your loop seems wrong to me. Shouldn't it be:

Code: Select all

for (psTemp = psFirst; psTemp; psTemp = psTemp->next)

I have to admit that this looks wrong, too...

i was in complete agreement with you, so the other day i looked that up. it seems that it's actually part of the c spec that nulls be treated as having the reserved address value of 0: anytime a compiler parses something like '*p = 0', it's required that it's treated as null, and since all other pointer values are positive integers (not necessarily that they're int's, though), they can be used directly in conditionals. that said, the for loop is a very concise (and extremely fast) linked-list iterator.