Warzone 2100 Forums

I'm new to C and new to WZ dev (though I've played the game since it was released)

Regarding the code:

(1) The constant definitions seem to be sprinkled at random through the code, rather than at the top of each file, or as in some code, in a separate file all together.  Is this a C thing or just WZ?  Is it worth the effort to clean up?

(2) I was trying to find remove the limits on droids... but can;t seem to find where its tied to a uint8/. any help would be appreciated.

(3) I completely understand the reluctance to port/convert the C structs to C++ objects - if it ain't broke... 

------BUT in looking the code it seems that struct definitions are inter mixed with functional code blocks.  Again, is this a C thing or just WZ and is worth cleaning up for readability and organization

------In rewriting sections like formation and when incorporating new code like a physics engine, do you plan to stay with the C structs or start to build C++ objects. Both can coexist, and it seems to me that some thing would be a whole lot easier to do with objects. Plus with recent processors, the performance hit may not be a big deal.

UrbanVoyeur wrote: I'm new to C and new to WZ dev (though I've played the game since it was released)

Regarding the code:

(1) The constant definitions seem to be sprinkled at random through the code, rather than at the top of each file, or as in some code, in a separate file all together.  Is this a C thing or just WZ?  Is it worth the effort to clean up?

(2) I was trying to find remove the limits on droids... but can;t seem to find where its tied to a uint8/. any help would be appreciated.

(3) I completely understand the reluctance to port/convert the C structs to C++ objects - if it ain't broke... 

------BUT in looking the code it seems that struct definitions are inter mixed with functional code blocks.  Again, is this a C thing or just WZ and is worth cleaning up for readability and organization

------In rewriting sections like formation and when incorporating new code like a physics engine, do you plan to stay with the C structs or start to build C++ objects. Both can coexist, and it seems to me that some thing would be a whole lot easier to do with objects. Plus with recent processors, the performance hit may not be a big deal.

1.I think the constants you are refering to the #define's?I think they are distributed sparsely in some files just for readability's sake(making constants definition before relevant function/macro)
2.the droid limits(max number of droids per player in skirmish/mp) is 300,I am pretty sure it's not tied to a uint8(255),it's uint16 iirc but I havent checked the relevant parts for some time now.
3.I think converting to C++ will create some serious issues/bugs like the mixed memory management,like mixing up C-sytle 'malloc' and C++ 'new'...

the functional blocks:if you meant the pointer to another function in a struct,it's the C-style method of a struct 'object'...

actually wz's physics engine is so good that units get stuck alot when bumping into each other and units 'fall off' cliff area sometimes...I admit using C++ will speed up the development speed and attract more attentions from developers,since C is already sort of underdog due to the lack of efficiency(reading/writing code wise,not performance wise) the current bottleneck of overall performance is not gamelogics,so the impact of performance of changing units cap/implementing new feature using C++ objects should be minor/unnoticeable imo.

Watermelon wrote: 1.I think the constants you are refering to the #define's?I think they are distributed sparsely in some files just for readability's sake(making constants definition before relevant function/macro)

I don't think so... Personaly I think it is this way because of lazyness and no one cared till now.
If you find a good way to reorder that (in a way that makes it easier to read through and understand), you could go and do it.

Watermelon wrote: 3.I think converting to C++ will create some serious issues/bugs like the mixed memory management, like mixing up C-sytle 'malloc' and C++ 'new'...

That, increased complexity of the buildsystem and no obvious need for it makes me say: "We don't intend to partialy convert WZ to C++". And a full conversion aka rewrite is not intended either.

Watermelon wrote: I admit using C++ will speed up the development speed

Don't know about this...

Watermelon wrote: and attract more attentions from developers

Possible. Even more would be attracted if we'd jumped on the C# hype...

Watermelon wrote: since C is already sort of underdog due to the lack of efficiency (reading/writing code wise,not performance wise)

In the end it depends on the programer, doesn't it?
And with a bad design you can create worse C++ apps than you could in C...

Watermelon wrote: the current bottleneck of overall performance is not gamelogics, so the impact of performance of changing units cap/implementing new feature using C++ objects should be minor/unnoticeable imo.

Sadly true...

Watermelon wrote:the functional blocks:if you meant the pointer to another function in a struct,it's the C-style method of a struct 'object'...

OIC. I have to wrap my head around this C stuff. So its sorta kinda like an object, just without inheritance, extensions or polymorphs. ok.

Watermelon wrote:the current bottleneck of overall performance is not gamelogics

Where is the current bottleneck?

UrbanVoyeur wrote: OIC. I have to wrap my head around this C stuff. So its sorta kinda like an object, just without inheritance, extensions or polymorphs. ok.

Oh, WZ even got inheritance.
I just fear that it is not officially supported by the C spec...
Have a look at the BASE_ELEMENTS definition.

UrbanVoyeur wrote: Where is the current bottleneck?

The graphics engine is one of them.

DevUrandom wrote: Oh, WZ even got inheritance.
I just fear that it is not officially supported by the C spec...
Have a look at the BASE_ELEMENTS definition.

Structures of structures.... of structures.. of pointers  Oww. That made my head hurt.  But I guess that's one way to do it. Extends and interface are such a beautiful words.  :'(

Hmm. Well it looks like messing with these structures is like playing in traffic.

UrbanVoyeur wrote: Structures of structures.... of structures.. of pointers  Oww. That made my head hurt.  But I guess that's one way to do it. Extends and interface are such a beautiful words.  :'(

Hmm. Well it looks like messing with these structures is like playing in traffic.

"interface" can be an extremely beautiful word. however, for the occasional good that "extends" brings, it so often leads to abuse that it's often best for "no one else but you" to handle that form of object orientation (and since you must replace "you" with every single dev, you'll find that, mathematically, the chance that any given dev should be using extends is inversely proportional to the size of the development group. at any rate, there are many good books, dating well back into the 1980's, that explain the grave deficits of classical inheritance (especially when applied in a collaborative environment), and there are even more books that explain the problems with multiple inheritence (a language feature that's supposed to fix some of the limitations of inheritance), and certain c++ semantics such as the "friend" keyword (the usage of which is indicative of an underlying design flaw). in the end, many resources will point out that an interface can, in regards to group relationships between classes, achieve everything that classic inheritance can, and with much greater flexibility. on the small scale, every once in a while you'll find a problem for which extends is obviously the only clean solution (in which case you use extends), but for just about everything else requiring a class, an interface is the better choice (and interfaces are always a much much "cleaner" approach than c++ multiple inheritance).

the above is certainly something of a mini-rant, but is based on hard research by many other people (i can look up some old sources if people want); i won't even talk about the evils associated with the tendency of oo programmers to needlessly "overclassify".

at any rate, a "class relationship" in c++ is simply a compiler-imposed convention -- if we start to write up a virtual "interface/inheritance tree" diagram (if it's not apparent whether a struct is "extending" or "using" another struct, then it may need to be cleaned up), then the system in place might be much more usable to any developers new to the project, and it shouldn't be extremely difficult to maintain developer-imposed struct relationships.

i believe there's no inherent problem with us rewriting certain sections, or certain new sections in c++, but i'll always be there to point out that there are things that will always be more cleanly implemented when written in ansi c, and that, for all the "wonders of object oriented programming", it's vary easy to make it worse.

I have no doubt that you are right - my thinking is more along Java lines, where everything is a class, and yes, interface is cleaner in teams and large code bases. In my java experience (which is not wide), extends is mostly used in private methods/sub classes within the overall public facing class. 

Getting back to this C, an interface/inheritance tree sounds like a good idea. Were there any docs like this with the source code from Edios?

nope.  just what was released with the source on dec 6 2004.

all the docs that i was able to obtain over the years are in a quite large file - if you want all this just let me know.


71.4 MB (74,932,224 bytes) = this also includes the files that ms frontpage puts in... i use frontpage only.

too old and forgetfull to try and learn new stuff... ;D

They are on the server already. I don't know if DevUrandom already did the diff/patch.

Kamaze wrote: They are on the server already. I don't know if DevUrandom already did the diff/patch.

link??

link: http://wz2100.net/files/docs/wzdocsprj50.7z
This is with the FrontPage stuff stripped out of it and thus ~20MB smaller.

DevUrandom wrote: link: http://wz2100.net/files/docs/wzdocsprj50.7z
This is with the FrontPage stuff stripped out of it and thus ~20MB smaller.

How do you want to make these docs available on this site?

A imo temporary solution would be to have it uploaded here by Coyote (I'd suggest /wzdocsproject or similar).
In the long term the idea is to have it in the wiki. That needs someone to move it there, though...

DevUrandom wrote: That needs someone to move it there, though...

Sound like something I can do - move it to the wiki.  I'll try to follow the same basic organization of the old docs, unless anyone has other ideas.