Long term source code goals...
Long term source code goals...
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
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
Last edited by Tropper on 15 Mar 2007, 13:35, edited 1 time in total.
- Watermelon
- Code contributor
- Posts: 551
- Joined: 08 Oct 2006, 09:37
Re: Long term source code goals...
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.Tropper wrote: 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
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
tasks postponed until the trunk is relatively stable again.
Re: Long term source code goals...
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.
Anyway, the future idea page sound fine to me. I was searching for something like that but couldn't find it by myself.
Re: Long term source code goals...
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.
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.
Re: Long term source code goals...
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.
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.
Re: Long term source code goals...
C++ is used in the sound branch. Lib::Boost too.
We all have the same heaven, but not the same horizon.
Re: Long term source code goals...
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.Tropper wrote: 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.
- DevUrandom
- Regular
- Posts: 1690
- Joined: 31 Jul 2006, 23:14
Re: Long term source code goals...
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.
Also marking stuff const can be of use.
Re: Long term source code goals...
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.
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.
"Make a man a fire, you keep him warm for a day. Set a man on fire, you keep him warm for the rest of his life."
Re: Long term source code goals...
Hope info in this thread would help: http://wz2100.net/forum/index.php?topic=374.0Tropper wrote: 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; ...
Re: Long term source code goals...
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?!Watermelon wrote: 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.
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.
Last edited by Tropper on 16 Mar 2007, 15:33, edited 1 time in total.
- Watermelon
- Code contributor
- Posts: 551
- Joined: 08 Oct 2006, 09:37
Re: Long term source code goals...
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:Tropper wrote: 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.
for (psTemp = psFirst; psTemp = psTemp->Next; psTemp)
{
//do something on psTemp
}
tasks postponed until the trunk is relatively stable again.
Re: Long term source code goals...
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
- Regular
- Posts: 1690
- Joined: 31 Jul 2006, 23:14
Re: Long term source code goals...
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?
And actually your loop seems wrong to me. Shouldn't it look like following?
Code: Select all
for (psTemp = psFirst; psTemp; psTemp = psTemp->next)
Last edited by DevUrandom on 17 Mar 2007, 21:35, edited 1 time in total.
Re: Long term source code goals...
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.DevUrandom wrote: Agree with Kage, even though I don't think it really decreases the performance.
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.DevUrandom wrote: And actually your loop seems wrong to me. Shouldn't it be:I have to admit that this looks wrong, too...Code: Select all
for (psTemp = psFirst; psTemp; psTemp = psTemp->next)