Thread: MechCommander 2 Source code project looking for programmers

Hi all,

My name is Karl

I am a member of a small team of people who are working on making some source code and content changes to Microsoft's mechcommander 2.

Our brand new moddb entry: MechCommander Omnitech mod - Mod DB
Our forum thread: MechCommander OmniTech

MechCommander 2 Background:

MechCommander 2 (MC2) was released in 2003 and the source was released in 2006. MC2 is based in the battletech universe. The stars of the battletech universe are called battlemechs and they are basically large walking tanks.

Now the reason I have visited your forum is because I am on the hunt for people who have some spare time and would like a fun side project to work on.

Basically our small group need help with the graphics code of MC2. Currently it is very limiting, no bump mapping, no LOD system, has a low polygon limit per frame which causes some of the in-game objects to be only partially drawn if the screen has many objects on it (e.g. a large battle, lots of trees, a city).
We have some code already, provided by another coder which should create a LOD system and bump mapping, but its a code fragment and needs to be implemented into the main MC2 source code package.

If someone is interested in having a play with the source code and maybe joining the team our current "list" of tasks that we would like help with are...
1. Remove the polygon limit
2. Implement the existing new rendering features present in our code chunk
3. Other (what I believe to be) smaller tasks around improving how the graphics of MC2 are handled and implementing a better memory managment system (currently the game uses statically allocated memory pools, possibly this is the source of the polygon limit?)

If interested please post or PM

Cheers

Karl (by the way I am in New Zealand so I apologize to anyone who posts and doesn't get a response until the next day)

I really hope it's in C++!

We're talking about a full game here, right?

Why it even has a polygon limit?

I was looking for a thing to do these days, so why not!

Originally Posted by Sipher

I really hope it's in C++!

We're talking about a full game here, right?

Why it even has a polygon limit?

I was looking for a thing to do these days, so why not!

Hello Sipher and thank-you for your reply

To answer your questions....

1. Yes the game is in C++ (or at least to my very limited coding knowledge it appears to be a C type language)

2. Yes MC2 is a full game, and the wiki is... MechCommander 2 - Wikipedia, the free encyclopedia

3. Yeah the engine has a very strange limit, it has a total number of polygons that it can display at any one time on screen, if you exceed this limit, the game just doesn't draw the extra polygons, so as I said you cant make forests or citys or have massive battles
Here is an example from our editor or this poly limit (in game is the same but it was easier for me to create this example in the editor)
I believe (I am a non coder so I could be wrong) that at least some of the problem revolves around the way memory is allocated, the game has code like this..
.
[code] TG_Shape::tglHeap = new UserHeap;
TG_Shape::tglHeap->init(tglHeapSize,"TinyGeom");

//Start up the TGL RAM pools.
colorPool = new TG_VertexPool;
colorPool->init(30000);

vertexPool = new TG_GOSVertexPool;
vertexPool->init(30000);

facePool = new TG_DWORDPool;
facePool->init(40000);

shadowPool = new TG_ShadowPool;
shadowPool->init(30000);

trianglePool = new TG_TrianglePool;
trianglePool->init(20000); [code]

To me it would seem that these are memory pools and once they game has filled them the overflow just never gets drawn

Someone who has already looked at the MC2 source code has commented that this sort of static allocation is now a very out dated way of doing things and that it is more common to have some sort of dynamic memory allocation.

As I said I believe this code to be some of the problem but I cant say its all the problem.

Anyway after a very long post I will point out that I have updated the first post with some links to sites about us as a team, our project is MechCommander OmniTech

Cheers

Karl

They are using 1 vertex buffer to draw everything so they pre-allocate 30000 vertices and then use those vertex 'slots' at runtime for various pieces. I imagine they have code to patch into and remove vertices from the buffer. The 20000 triangle limit should theoretically mean the vertex limit is 60000. That really isn't much considering terrain can easily swallow 60000 vertices in a few patches and main game models are now in the range of 10000 to 25000 triangles a piece.

The engine obviously does not sort objects by texture and is making the concession that SetTexture() calls are less expensive than calling DrawIndexedPrimitive on several different objects. It appears they are using a pool allocation scheme to allocate memory but without the source that is only a guess.

The vertex limit should be removed for all modern hardware but the batching should be preserved for optimal performance. Much of this can be altered to use SetVertexStreamFrequency() to take advantage of instancing. It looks like this game was done in 2000 which makes it 11 years old. A lot changes in 11 years in the graphics world and I'm not sure this engine is up to par to do anything noteworthy on current hardware. It needs to be moved to the programmable pipeline and away from the fixed function pipeline.

Best of luck but you will run into serious issues with code that is this out of date with respect to modern hardware and techniques. 2000 is getting into the DirectX 7/8 time frame so the engine needs re-factored for DirectX 9.0c and possibly DirectX 10. If the code is well written the re-factor shouldn't be all that difficult but it depends on the design and the requirements the original dev team set forth to fulfill as to how much re-design and re-factor is needed to bring it into the current era of computer graphics.

From the screenshots some very important items I see that need addressed:

• The terrain texture splatting is poor - appears to be about 3 to 4 textures per terrain - cannot tell if the terrain is one huge terrain or if it is restrictive - could be a simple static vertex buffer
• The terrain is most likely light-mapped via static lightmaps
• The models it renders are extremely blocky - could be a result of the restrictions placed on modellers at the time
• Textures lack resolution - again could be due to restrictions on artists
• No bump mapping
• Terrain lacks detail close up - terrain textures lack detail
• Decals lack resolution - burnt spots on the ground near the mechs are most likely decals
• The default levels look bleak and barren
• The overall presentation of the engine is extremely dated

Wow... You definitely sound like you know what you are talking about Bubba and I will not dispute anything you have posted

I think that as a team we realise that 10 years in anything is along time and graphics programming is no exception.

As such we are not looking for an engine upgrade that will put id5 to shame, just some extensions here and there (if there can ever be such a thing ) to not really extend the visuals of MC2 so much as allow other moders to take our package and be free to create content and mods they way they want (ie with bump maps for extra detail, high polycount models)

MC2 is what I call DX7.5 it is basically written with DX7 but at the time DX8 was coming out so there are some DX8 features tacked on the side (according to MC2 project lead frank savage), and again I guess dragging MC2 kicking an screaming to a DX9ish state would require know-how and time. On the positive side I can say that the code fragment we already have was written very quickly by our coder (who is now inactive) and is exclusively DX9 code which at the time it was written believed to be working to some extent with the MC2 engine. I am hoping that this means that the existing code in MC2 is written well and logically, and as you said good base code will ease the inevitable growing pains

Again thanks Bubba for your contribution and hopefully with Siphers help and anyone else who wishes to join (and hopefully our original coder will also become active again to help) we can get the changes made and improve MC2. You never know maybe we will see you again in the graphics coding thread hopefully discussing our teams progress

Bubba's much more experienced than me, so i really can't disagree with anything he says!
Of course i will help!

EDIT: Hey, it says that his inbox is full!!!
EDIT^2: Still full!!

It's 'GReaper'. I'll help you as much as I can.

Access granted

Here is the private forum login page

Login

Great!