Some hints to the devteam

[Guest Glen Coe]

Hello folks.

 

First I want to say, that I am impressed by the work you have done so far. It is unbelievable, what you guys have created in such a short time (for ambitious graphical multiplayer games even a year is a minimal time span). Smooth network playing, movable inventory windows, map with automatic path finding and numerous other lovely details - a huge pot of honey for every little pooh out there.

 

So I had a look behind the scenes... and after studying the code I decided to post some (very little) hints... or better to say... personal notes. Even if you do not need my advices, I feel better, if I share my sparse knowledge. Even more because of your hunt for programmers.

 

1) Stony way to the first compile.

Is it a test? To choose only the strongest coders around there? It took me two hours to bring the sources to life. Although I had already some required open source libs on my computer, there were much work necessary to have all things in the right place. Only some notes:

• The libs needed to compile (up to date as necessary) should already packed together. At least the header-files and the libraries. The DLLs are shipped with the actual game (propably also the development directory for the devs). If anyone needs the sources, he can fly around the net, but for the simple compile process this package should already tied up. Not every programmer is willing to go the horrible trip collection all the items needed.
  
• Think, if you could prevent the need for simple c-language. I personally didn't like the style of predeclaring all variables at the beginning of a function (but I have no problem with that 'cause I am coming from Pascal). But for such a big and growing game it makes (perhaps) sense to switch to a language, which supports classes, templates and scoped variables.
  
• If the current CVS is NOT RUNNING CORRECTLY... then make somewhere in the forum a big sign. It costs me an additional hour to verify, that there is also a test server running and that the current CVS is not more compatible with the current playing server (but at least it was running)
  

2) Optimizing the beast.

The code is in general well done and often understandable. But it is undoubtedly necessary to begin to clean, optimize and part the sources. That is by no means a reproach... most of program lines walk directly from brain to editor and nobody can tell me, he writes instantly the neatest code.

 

Let me explain, what I mean on an example.

 

Getting a feeling, how simple changes to the existing code are possible, i searched for the code of the handling and drawing of the inventory window (for I could perhaps change some short cuts for moving items between slots). I found the code (after a long search) in items.c, and already the first function gave me some headaches. Lets have a look at display_items_handler(). What has to be done?

 

First I noticed the three times grid drawing.

   ...
   glColor3f(0.77f,0.57f,0.39f);
   glBegin(GL_LINES);

   //draw the grid
   for(y=1;y<7;y++)
       {
           glVertex3i(0,y*51,0);
           glVertex3i(6*51,y*51,0);
       }
   for(x=1;x<7;x++)
       {
           glVertex3i(x*51,0,0);
           glVertex3i(x*51,6*51,0);
       }

   glColor3f(0.57f,0.67f,0.49f);
   //draw the small grid
   for(y=0;y<5;y++)
       {
           glVertex3i(wear_items_x_offset,wear_items_y_offset+y*33,0);
           glVertex3i(wear_items_x_offset+2*33,wear_items_y_offset+y*33,0);
       }
   for(x=0;x<3;x++)
       {
           glVertex3i(wear_items_x_offset+x*33,wear_items_y_offset,0);
           glVertex3i(wear_items_x_offset+x*33,wear_items_y_offset+4*33,0);
       }

   //now, draw the quantity boxes
   glColor3f(0.3f,0.5f,1.0f);
   for(y=0;y<6;y++)
       {
           glVertex3i(wear_items_x_offset,wear_items_y_offset+160+y*20,0);
           glVertex3i(wear_items_x_offset+2*35,wear_items_y_offset+160+y*20,0);
       }
   for(x=0;x<3;x++)
       {
           glVertex3i(wear_items_x_offset+x*35,wear_items_y_offset+160,0);
           glVertex3i(wear_items_x_offset+x*35,wear_items_y_offset+160+5*20,0);
       }

   glEnd();
   ...

 

I wrote a simple function rendering a grid (which could also used by other modules):

void renderGrid(int columns, int rows, int left, int top, int width, int height)
{
   int x, y;
   int temp;

   glBegin(GL_LINES);
   
   for(y=0; y<=rows; y++)
   {
       temp = top + y * height / rows;
       glVertex2i(left,         temp);
       glVertex2i(left + width, temp);
   }
   
   for (x=0; x<columns+1; x++)
   {
       temp = left + x * width / columns;
       glVertex2i(temp, top);
       glVertex2i(temp, top + height);
   }

   glEnd();
}

 

Therefore the code becomes

 

   // item slots
   glColor3f(0.77f,0.57f,0.39f);
   renderGrid(6, 6, 0, 0, 6*51, 6*51);

   // wearing
   glColor3f(0.57f,0.67f,0.49f);
   renderGrid(2, 4, wear_items_x_offset, wear_items_y_offset, 2*33, 4*33);

   // quantity boxes
   glColor3f(0.3f,0.5f,1.0f);
   renderGrid(2, 5, wear_items_x_offset, wear_items_y_offset+160, 2*35, 5*20);

This does not only make code reading easier, but also helps making changes fast. And additional i would advice to make the grid colors global and configurable... add a configurable transparent background picture... and voilá, you are suitable for user modding. UI skinning is one of some things users really like.

 

After the grid code comes the quantity number drawing code:

   //draw the quantity values
   if(item_quantity==1)glColor3f(0.0f,1.0f,0.3f); else glColor3f(0.3f,0.5f,1.0f);
   draw_string_small(wear_items_x_offset+15,wear_items_y_offset+163,"1",1);
   if(item_quantity==5)glColor3f(0.0f,1.0f,0.3f); else glColor3f(0.3f,0.5f,1.0f);
   draw_string_small(wear_items_x_offset+50,wear_items_y_offset+163,"5",1);
   if(item_quantity==10)glColor3f(0.0f,1.0f,0.3f); else glColor3f(0.3f,0.5f,1.0f);
   draw_string_small(wear_items_x_offset+10,wear_items_y_offset+183,"10",1);
   if(item_quantity==20)glColor3f(0.0f,1.0f,0.3f); else glColor3f(0.3f,0.5f,1.0f);
   draw_string_small(wear_items_x_offset+45,wear_items_y_offset+183,"20",1);
   if(item_quantity==50)glColor3f(0.0f,1.0f,0.3f); else glColor3f(0.3f,0.5f,1.0f);
   draw_string_small(wear_items_x_offset+10,wear_items_y_offset+203,"50",1);
   if(item_quantity==100)glColor3f(0.0f,1.0f,0.3f); else glColor3f(0.3f,0.5f,1.0f);
   draw_string_small(wear_items_x_offset+40,wear_items_y_offset+203,"100",1);
   if(item_quantity==200)glColor3f(0.0f,1.0f,0.3f); else glColor3f(0.3f,0.5f,1.0f);
   draw_string_small(wear_items_x_offset+5,wear_items_y_offset+223,"200",1);
   if(item_quantity==500)glColor3f(0.0f,1.0f,0.3f); else glColor3f(0.3f,0.5f,1.0f);
   draw_string_small(wear_items_x_offset+40,wear_items_y_offset+223,"500",1);
   if(item_quantity==1000)glColor3f(0.0f,1.0f,0.3f); else glColor3f(0.3f,0.5f,1.0f);
   draw_string_small(wear_items_x_offset+1,wear_items_y_offset+243,"1000",1);
   if(item_quantity==2000)glColor3f(0.0f,1.0f,0.3f); else glColor3f(0.3f,0.5f,1.0f);
   draw_string_small(wear_items_x_offset+36,wear_items_y_offset+243,"2000",1);

Of course this code was coded in the beginning and runs fine it is horrible to maintain. Think of changing the color for selected number? Or to change the count of numbers? Make some arrays holding the values and build a single function:

void drawQuantities()
{
   // quantities
   int q[10] = {1, 5, 10, 20, 50, 100, 200, 500, 1000, 2000};
   // x-offsets of the numbers in every gridcell
   int o[10] = {15, 50, 10, 45, 10, 40, 5, 40, 1, 36};

   // available colors
   GLfloat selectColor[3] = {0.0f, 1.0f, 0.3f}; // yellow-green
   GLfloat normalColor[3] = {0.3f, 0.5f, 1.0f}; // blue

   int i;
   char number[8];

   for( i=0; i<10; i++ )
   {
       glColor3fv( item_quantity==q[i] ? selectColor : normalColor );

       itoa(q[i], number, 10);

       draw_string_small(wear_items_x_offset+o[i],
           wear_items_y_offset+163+(i/2)*20, number, 1);
   }
}

The quantities are now stored in an array. The x-offsets of the gridcell-numbers too. This was only necessary, because the drawing of the numbers started differently depending on the count of digits. (Here the "optimizer" should introduce a function like drawCenteredString(), which would even more simplify the function). The colors are also predefined to code the glColor-Call only one time. The rest is self explanatory.

 

The next source lines are more difficult to opimize, because there is also data structure optimization needed. But I think, the point, I would show you, was more than visible.

 

Especially now, when you make a bigger change (i count the test server this reason), would be a good time to let some experianced coder do a optimizer/shorter/cleaner-walk. After that you can go on with new motivation, a clean code base, (which would also attract other programmers), and a lot of new ideas possible.

 

Just my 2 cent (ok, ok... there were three ^^)

 

Glen Coe.

[Wytter]

Hi Glen,

 

Thank you for your hints.

 

As for compilation, I do agree that it might be a good idea to have a collective download available. Furthermore we are thinking of using automake/autoconf in the future as well.

 

As you may have seen, many of the newer additions to the client are adopting more object oriented programming techniques (good examples could be Sadez' widgets.[ch] that we sadly aren't using yet, or the elconfig.[ch] that are currently being used for both the client, mapeditor and now also a gtk2-based configuration utility).

 

I do not think that we will be porting the client to C++, even though many of the newer files might not be that hard to port. However, there are many things that could and should be done a lot smarter in the current client, your example with items.c is just one of many. We are slowly moving away from the hard-coding, but it takes a lot of time

 

If you get the time and you wish to help, feel free to submit patches to http://developer.berlios.de/projects/elc/

[roothorick]

I do not think that we will be porting the client to C++, even though many of the newer files might not be that hard to port.

I'm extremely curious -- why? You didn't give any reasons. After reading over the code myself, I can't help but ask why nobody has attempted to port it to C++ yet...

[Wytter]

Well, it's been up for debate many times. Personally I am not against it, but Entropy does not like the idea as he doesn't know C++ (I don't know enough either, but I am quite eager to learn ;-)) and isn't fond of classes etc. - besides, we can do it in C, and we can make it somewhat object oriented, but it is of course harder to do than if it was written in C++.

[roothorick]

Entropy does not like the idea as he doesn't know C++ (I don't know enough either, but I am quite eager to learn ;-))

There's plenty of documentation online, in particular I must recommend The C++ Annotations and especially (although more once you have a grasp of the language) the C++ FAQ LITE. What's nice about C++ is that it's very similar to C, so if you already know C there isn't nearly as much to learn than if you were going to, say, Python.

 

By the way, I just stumbled upon draw_scene.c... is a 304-line function REALLY necessary?

Edited January 26, 2005 by roothorick

[Hammen]

On the note of suggestions to the client, I find it somehow disturbing that you made a file called globals.h that #includes many other files... I highly doubt that every file that #includes globals.h is dependent on all of those files...

[Wytter]

By the way, I just stumbled upon draw_scene.c... is a 304-line function REALLY necessary?

Well, it's been on the TODO list to add the root window to the window manager for some time - currently Adranbach is looking into it AFAIK That would remove that extremely long function and enable a lot more features to be added to the client without being hacks (such as onkeypress support in the WM).

[Leeloo]

I do not think that we will be porting the client to C++, even though many of the newer files might not be that hard to port.

I'm extremely curious -- why? You didn't give any reasons. After reading over the code myself, I can't help but ask why nobody has attempted to port it to C++ yet...

Oh shit, another C++ fanatic that wants everything to be in his language of choice. Hint: If you want to be taken seriously, don't suggest rewriting stuff to a different language that the owner doesn't like.

 

Why is it that C++ and Java programmers want everything done in their language?

[Placid]

I do not think that we will be porting the client to C++, even though many of the newer files might not be that hard to port.

I'm extremely curious -- why? You didn't give any reasons. After reading over the code myself, I can't help but ask why nobody has attempted to port it to C++ yet...

Oh shit, another C++ fanatic that wants everything to be in his language of choice. Hint: If you want to be taken seriously, don't suggest rewriting stuff to a different language that the owner doesn't like.

 

Why is it that C++ and Java programmers want everything done in their language?

Lets not turn this into an off-topic programmers debate.

 

Being a Java programmer, reading C makes it slightly difficult to participate in 'pet' projects like EL, because frankly I dont know C/C++. I'd love to be able to contribute, but I cant, physically. Perhaps that's why us 'fanatics' want things written 'our' way....

[Leeloo]

Think about the other side... You would find it easier if it was written in Java, but the rest of us would have the same problems reading the code.

[Malaclypse]

Hi,

 

my first compile took only about 10 minutes. After I figured out the cvs host and got the sources, it compiled on the first try, or at most with minor changes to the makefile. I think most of the client is developed on *nix environments, where you have all those libraries pre-installed, at least on desktop and/or developer machines because they are needed by other applications as well. If you use windows, there are some howto's here in forum about this topic.

 

 

[*]Think, if you could prevent the need for simple c-language.

If I'm going to bring myself into a project, I have to accept the different styles (coding styles, languages used, other guidelines) at first. They can be discussed with the team of course, but in the first I will have to accept them. And chosen language is always a big matter of taste anyway. Furthermore it is a large project of its own, to port a given application to a new language. You sometimes are better done, by doing a complete redesign then, after all. Additionally learning new languages is quite easy, once you have figured out some basic principles. The application of several techniques is not dependant on the chosen language. Some languages enforce the use of a particular paradigm, some support it and some just enables it. C enables the use of object oriented patterns, and supports it to some extent, you don't need C++ (or any other OO language) if you just want this. And sticking to the OO paradigm as the only true religion is quite stupid, imho. There's no single programming paradigm that can solve any computational problems in a satisfactory manner (in terms of runtime and memory requirements). I don't like C either, but if I'm going into serious client development, I will have to accept, the use of C or stay off from direct coding and stick to other development related topics. Another topics are that C is incredibly fast and you have the widest support of given APIs available for any single progamming language.

 

 

[*]If the current CVS is NOT RUNNING CORRECTLY... then make somewhere in the forum a big sign. It costs me an additional hour to verify, that there is also a test server running and that the current CVS is not more compatible with the current playing server (but at least it was running)

Errm, cvs is live source, you should always expect possible trouble when dealing with code from any cvs repository. Keep backups of working binaries or create snapshot binaries of known stable releases and keep backups of them to go around this a bit.

[roothorick]

Oh shit, another C++ fanatic that wants everything to be in his language of choice. Hint: If you want to be taken seriously, don't suggest rewriting stuff to a different language that the owner doesn't like.

 

Why is it that C++ and Java programmers want everything done in their language?

I'm not so much suggesting a switch to C++ as I'm suggesting a switch from C. C really has no useful tools for developing complex projects such as MMORPGs. In C, there are no vectors or lists (only arrays, which have no bounds checking whatsoever, making them EXTREMELY bug-prone). There aren't even references (although, given, there are pointers, which are really more like memory addresses than actual references). And all those complex data structures offered by just about every other major language out there, like maps (C++) / dictionaries (Python) / hashes (Perl)? Nowhere to be found. You have to emulate them using arrays if you want that functionality. Oh, and be sure to code in bounds checking too! And guess what? There's no class-based behavior beyond structs, and structs can't contain methods, which dirties your namespace REALLY fast.

 

For all I really care, you can go ahead and switch to Objective C. Or Java. Or Ruby. Or Python. Hell, even Perl would be better. I only suggested C++ because it would be by far the easiest move (as you can reuse pretty much all of the existing code). Just get rid of C. Coding anything this complex in C is a truly painful experience, and maintaining it is close to impossible.

[duran]

you would be surprised how many c++ projects out there looks like a c project with some odd syntax here and there...

[roothorick]

you would be surprised how many c++ projects out there looks like a c project with some odd syntax here and there...

I believe it. It's easy to approach a new language with the same standards and habits that you used with an older, completely different language. Any style switch is difficult, and honestly, if you don't like doing something a certain way, don't do it that way. I really don't care if EL remains in a traditional style. But one thing that really gets on my nerves as I look at making changes to the client is the fact that I have only basic types, arrays, and structs to work with. The suggestion was not so much to drastically change the style of the code, as it was to make the tools available for people with different styles and habits to work on the same codebase provided they're able to understand (but not necessarily agree with) the styles and habits of the other developers, and much more importantly, providing sane complex containers with good error checking that can be used pretty much in place in additions and modifications to the code.

[Leeloo]

I'm not so much suggesting a switch to C++ as I'm suggesting a switch from C. C really has no useful tools for developing complex projects such as MMORPGs.

Ok, an anything but C fanatic then?

 

Entropy picked C for a reason. I would have picked C for the same reason. It's the languange we prefer.

[Grum]

First Fortran was banned. Now C. It's a good thing I'm learning Python, otherwise I wouldn't be able to communicate with a programmer anymore in a couple of years.

 

Personally, I don't like C++. It's an overbloated language which does not solve what it promised to do (i.e. let the programmer make less errors). And yes, I have tried to use it. It's not that I'm against other programming languages, I love Python and Brainf*ck. It's just that C++ is needlessly complicated. And the way it handles those templates...awful

 

Anyway, noone's oing to rewrite the game in C++. Not only because they don't want to, but also because there's no real advantage to it.

[Wytter]

rootherick: Fortunately you still have function pointers ;-) Think of it as a challenge - it is definately possible to write good object oriented code in C.

 

So far we've sticked to being almost valid C89/C90, as Leeloo has been very strict whenever we made a C99 reference (as in one that can't be compiled with GCC 2.95) - so I think you should stick to that standard as well ;-)

 

And duran does have a point - there's really not that many C++ projects out there that really use (and understand) the capabilities of C++, hence they end up being ~similiar to C - but in a language that the compiler might not be able to optimize as well as if it had been written in plain C.

 

And yes - the problem is that there's no real advantage in porting the client to C++; and if someone even took the time to do that, would the code be faster or slower? My estimate would be the latter and the code would start looking even more as a hack ;-)

[mikeman]

And yes - the problem is that there's no real advantage in porting the client to C++; and if someone even took the time to do that, would the code be faster or slower? My estimate would be the latter and the code would start looking even more as a hack ;-)

Well, of course there is an advantage, but I don't think "porting" would do it.

I see the reason of porting the game to D3D for instance, in addition to OpenGL, but C++? Unless you can write a real C++ program, why bother? Porting the client code to C++ would mean,at most, substitute arrays with lists or vectors, structs with classes, and some functions with methods. Big deal. Better spend your time optimizing your existent C code, after all, good programming is all that matters, regardless of the languange. For instance, I saw that the rendering pipeline tests *each object* in the map for visibility, before drawing it, and there are a lot of objects in one map. It wouldn't take too much to implement a space partitioning technique(like quadtrees) to speed things up.

 

Now, if one would want to take real advantage of C++, he would have to pretty much redesign the whole thing. One poster said that C++ is an overbloted languange, well, C++ is a superset of C. Writing a C++ program doesn't mean you have to do *everything* using C++ features. You can still use C where it is more simple to do so, and use C++ where again is more appropriate to.

For example, it would have a huge benefit if you managed all the game entities through a scene graph. You would spend a little more time designing, but the advantages would show later, when you constantly need to add many new characters,weapons, gameplay options... Of course, everything can be done in C too, but let's face it, C++ is more "natural" environment for these kinds of things.

Edited January 26, 2005 by mikeman

[Malaclypse]

Of course, everything can be done in C too, but let's face it, C++ is more "natural" environment for these kinds of things.

This not only applies to C++ but to any object orient approach, because people are used to think in terms of objects rather than in terms of functions and data.

[Leeloo]

Well, of course there is an advantage, but I don't think "porting" would do it. I see the reason of porting the game to D3D for instance, in addition to OpenGL, but C++?

 

D3D? Are you nuts? Why on earth would you want to lock the game to Microsoft, while at the same time lose half the developers and a good part of the players?

 

Of course,

everything can be done in C too, but let's face it, C++ is more "natural" environment for these kinds of things.

This not only applies to C++ but to any object orient approach, because people are used to think in terms of objects rather than in terms of functions and data.

 

You forgot something... "OO-people are". Those of use who weren't forced to think in terms of objects by some restrictive language think of programming in the same way as we think about everything else... eating, sleeping, cleaning, cooking, working, playing, swimming - none of those are objects.

[Placid]

Well, of course there is an advantage, but I don't think "porting" would do it. I see the reason of porting the game to D3D for instance, in addition to OpenGL, but C++?

 

D3D? Are you nuts? Why on earth would you want to lock the game to Microsoft, while at the same time lose half the developers and a good part of the players?

 

Of course,

everything can be done in C too, but let's face it, C++ is more "natural" environment for these kinds of things.

This not only applies to C++ but to any object orient approach, because people are used to think in terms of objects rather than in terms of functions and data.

 

You forgot something... "OO-people are". Those of use who weren't forced to think in terms of objects by some restrictive language think of programming in the same way as we think about everything else... eating, sleeping, cleaning, cooking, working, playing, swimming - none of those are objects.

Your gonna hate me Leeloo.

 

Correct; none of those are objects. They are sets of behaviour defined by objects.

[roothorick]

Entropy picked C for a reason. I would have picked C for the same reason. It's the languange we prefer.

For that one reason and that one reason alone, you should deny everyone working on it of the features provided by C++? Most notably, inlining, which allows you to optimize code in ways that you would otherwise have to sacrifice a massive amount of readability for. The complex data types like vectors, maps, etc. provide a significant advantage for readability too, providing much more readable syntax for such structures. Do you really want to sacrifice such large advantages just because you're stuck in your ways? Maybe you should reconsider your philosophies here, it's this kind of stubborn conservatism that turns peaceful large-scale disagreements into civil wars.

 

You forgot something... "OO-people are". Those of use who weren't forced to think in terms of objects by some restrictive language think of programming in the same way as we think about everything else... eating, sleeping, cleaning, cooking, working, playing, swimming - none of those are objects.

 

And you decisively missed something completely. _ALL_ natural languages (English, Spanish, French, etc.), regardless of their character sets, regardless of their originating cultures, regardless of their syntax, are object-oriented -- what's a noun? It's a variable referring to a class, or an instance thereof. And out of the 30+ natural speaking languages that have ever existed, the concept of noun has prevailed in each and every one of them. The rest is obvious. Since we already communicate with each other in an OO format, wouldn't it make sense to communicate to a computer in an OO format? It's less to learn, and we're conditioned to think in an OO sense straight from Day 1 out of the womb! In fact, since it's so universal, it's by no means a stretch to say that the human brain is specifically designed to think in an OO fashion.

 

However, it's all really irrelevant, as no OO (programming) language requires you to write OO code. If you don't want to, don't. It's that simple.

[Wytter]

C99 supports inlining as well.

[crusadingknight]

Well, as far as I'm concerned I use C because it's fast, and a low-level language. C++ just adds extra complexity. Class substituting using structs can be done, with few problems; what's the point of having to write huge declarations for a simple function? If I can interface a Small-Controlled GUI in C, why do I need C++? I can use src files to do the same as a C++ class anyway, and with less typing, so what is the point?

[mikeman]

Well, of course there is an advantage, but I don't think "porting" would do it. I see the reason of porting the game to D3D for instance, in addition to OpenGL, but C++?

 

D3D? Are you nuts? Why on earth would you want to lock the game to Microsoft, while at the same time lose half the developers and a good part of the players?

 

Of course,

everything can be done in C too, but let's face it, C++ is more "natural" environment for these kinds of things.

This not only applies to C++ but to any object orient approach, because people are used to think in terms of objects rather than in terms of functions and data.

 

You forgot something... "OO-people are". Those of use who weren't forced to think in terms of objects by some restrictive language think of programming in the same way as we think about everything else... eating, sleeping, cleaning, cooking, working, playing, swimming - none of those are objects.

I said "D3D *in addition* to OpenGL". That is, the game to run using D3D or OpenGL, let the user choose. I didn't say it should be done, I said I could understand it if someone would want to do it. It's always the best choise to support both APIs.

 

As for OO, first of all, everyone thinks in terms of objects. "swimming" is not an object, but it just can't stand alone. It only has meaning if you say "Leeloo is swimming", "Leeloo" is an object, and the implementation for "swimming" is possibly different from "swimming" method of the object "Malaclypse", even though they have the same interface. Even in a procedural languange, functions(procedures) always operate on data(objects). OO programming just encapsulates the functions and data in the same entity.

 

 

For example: I'm now working in adding Cal3D support. Say we wanted to also keep MD2 support. The thing is, an MD2 and a Cal3D model have the same interface. They both have to be loaded, placed,animated,rendered. It's just the implementation for those that differs. I could have a CModel object as a parent, with virtual functions for those methods, and CMD2Model and CCal3DModel to actually implement those different types, by overriding the virtual functions.

 

Now, the renderer wouldn't care whether it's an MD2 or Cal3D model. We could have this:

 

void RenderAllModels()

{

 

for (i=0;i<models_num;++i)

{

CModel *model;

//retrieve model from a list of CModels here...

model->Render();

}

 

}

 

Same for animation, the animation loop would just call model->Animate() for all models,without caring whether it's bone animation or not. If at a later point we would want support for Doom3 models, no problem: Just derive a new CMD5Model class for CModel, and implement its virtual methods. The RenderAllModels() function wouldn't need to be touched. It would work as it is, having the ability to render Doom3 models.

 

You can imagine in how many cases in the game this example applies to.

 

You can also do this in C by using structs and function pointers, but that's basically OO again. But how could you do this by sticking to the procedural paradigm? You would basically need to make multiple case statements, and call the proper functions according to the model type.

Edited January 26, 2005 by mikeman