Dev: Custom Conquer Client

[CptSky]

Originally Posted by InfamousNoone

I'm inclined to strongly disagree with this post. It's much easier to achieve cross platform with minimal with C# as opposed to the hoops you have to jump through with C++.

I've not seen best results by using C# with Mono on Mac OS X... The C++, I've seen around ePvP is badly written to be cross-platform. That's not a problem with the language, which is truly easily portable, but with the coders. If people stop writing C++ like Microsoft / TQ and they'll be fine

[.Ocularis]

seriously cool project Angelius. besides the obvious, what are your intentions for development of a custom client for conquer?

Also, how did you learn what you needed to know to reach the current point in the development progress?

[{ Angelius }]

Originally Posted by .Ocularis

seriously cool project Angelius. besides the obvious, what are your intentions for development of a custom client for conquer?

Also, how did you learn what you needed to know to reach the current point in the development progress?

Thank you,

To be honest, this is not about a custom conquer client anymore it's more like making a whole new game .
I thought about it for a while and I was like if I am going to re-create the client from scratch and on my terms then I might as well make my own game and here I started to make huge changes to what I have got so far.

At this moment I am working on loading custom 3D maps that were built/textured using 3ds Max/World Machine instead of using Conquer's cheap low res maps.

This would allow me to load huge open world maps and give me the ability to even build maps dynamically for a limitless world. now it's a lot of work but it's gonna be worth it.

As to how I learned the stuff that got me this far the answer it simple. I Googled it LMAO.

Some screen Shots:

Map in 3Ds Max: This is a big *** map with a single texture mapped across the entire thing and I am already getting good results.

Results:


Extra:

[Yupmoh]

I'm impressed, Keep up the good work

[.Ocularis]

Originally Posted by { Angelius }

As to how I learned the stuff that got me this far the answer it simple. I Googled it LMAO.

*googles developing a custom conquer client*

Wishing I had internet at home right now!
A "whole new game" would be great, but why expand past the resources you already have? It seems a bit rabbit-trailish to me. IF you built a custom client to improve on the current Conquer client, you could upgrade to your stuffy maps later while having a complete working project. A possible upgrade for your users to keep their interest more-so would be more prospective imo.

Another opinion and idea on upgrading to your stuffy maps, why? when your view remains 2d isometric? Visualize with me.. a 3d map, resting on a needle point, and a camera with pan and zoom. As the camera pans, the edge of the map; relative to the center of the camera, is pressed down until the same isometric perspective is reached as in Conquer's 2d isometric view. Transformation matrix?

[{ Angelius }]

Originally Posted by .Ocularis

A "whole new game" would be great, but why expand past the resources you already have? It seems a bit rabbit-trailish to me. IF you built a custom client to improve on the current Conquer client, you could upgrade to your stuffy maps later while having a complete working project. A possible upgrade for your users to keep their interest more-so would be more prospective imo.

I assure you there are plenty of free Assets/Resources online that I can use to build my stuffy maps.
The decision to not use conquer maps did not come out of thin air I am trying to use the least(if any) amount of resources from conquer because I wanna have a leg to stand on (legal-wise) when the time comes, and that ain't gonna happen as long as I am using their maps/ any of their resources.

Yeah its true I could use their maps for now and replace them later but then again the map system is a crucial part of the game and if I don't have that figured out now and by the time the game is in a playable state I am fucked and there is no changing the map system because so much of the game engine depends on it. trust me there is more to it than meets the eye.. Lighting, cameras, elements (rocks, trees, plants, etc), path-finding, 2.5D vs full 3D, etc.

Originally Posted by .Ocularis

Another opinion and idea on upgrading to your stuffy maps, why? when your view remains 2d isometric? Visualize with me.. a 3d map, resting on a needle point, and a camera with pan and zoom. As the camera pans, the edge of the map; relative to the center of the camera, is pressed down until the same isometric perspective is reached as in Conquer's 2d isometric view. Transformation matrix?

My stuffy maps are 3D maps yes, but they are rendered as 2.5D maps, just like in conquer except for one thing, I can scale them as much as I like dynamically and on the fly. That's the only difference. Thanks to Directx 11 and hlsl.

Now to be honest I think I have pushed it too far. for a 2.5D game that is, as I haven't found a single use for this feature yet I mean you venture outside the map boundaries(the official ones that is) and you will find nothing but an empty barren land with some randomly generated vegetation and no body cares for that. Players can actually get lost without the mini map to help them find their way back. there are other major issues of-course but moral of the story is that it would have been a great addition for a 3D game but not for a game like conquer, and I have changed my mind about having a dynamically generated map and I am sticking to what works best a fixed size map.

[{ Angelius }]

Another one of my weird updates

[.Ocularis]

"I don't think there's anything else that you guys ne[end of video]"
NOOOO SHOW ME MORE

AWESOME work Angelius. That's just incredible how careless TQ is with performance.
Knowing from the past, filling a screen on TQ's client full of the plain old simple pheasants. They only contain a solid few vertices in their vertexes, but will totally incapacitate TQ's client. Also enjoyed watching the editing capabilities you've implemented. Looking forward to more of these updates

[pro4never]

Awesome progress and interesting to watch.

I'm not denying for one single moment that TQs client sucks and is a mess in terms of performance but keep in mind that scattering 100 mobs and the client crashing is a server issue, not a client problem (ok... it's both but it's a bug no playable server should have)

The client has a max buffer size for single packets. If you send too many targets in a single skill packet (max # of targets changes with client version as they make each target use more and more data), it will cause an unhanded exception and crash the client.

Totally unrelated just irked me cause I've seen that complaint so many times. Generally if you see that on a pserver it's a good sign it's a **** server or at least one that still needs some dev work

[CptSky]

Don't forget the client was developed in the early 2000s and wasn't truly updated since then. A lot of things have changed since they started CO2. Coding practices for games and MMOs too.

[KraHen]

Originally Posted by CptSky

Don't forget the client was developed in the early 2000s and wasn't truly updated since then. A lot of things have changed since they started CO2. Coding practices for games and MMOs too.

^ That. With that said, software/hardware batching was and is available, all their monsters use the same material, so all mobs on the screen can and should be drawn with a single draw call, the fact that they cannot do that proves incompetency. The fact that the client is old is not an excuse for not optimizing/updating it (it wouldn't even change a single thing visually for the end users).

[{ Angelius }]

Originally Posted by .Ocularis

"I don't think there's anything else that you guys ne[end of video]"
NOOOO SHOW ME MORE

Looking forward to more of these updates

Yeah YouTube ate about 35 seconds of the end of the video while trying to edit it on their website, And to add insult to injury it didn't like the size and the bit rate of my video so it converted it from 1.6gb 1080p video to a 250mb god knows what video

However, I am glad you liked it, Thanks for stopping by

Originally Posted by pro4never

Awesome progress and interesting to watch.

I'm not denying for one single moment that TQs client sucks and is a mess in terms of performance but keep in mind that scattering 100 mobs and the client crashing is a server issue, not a client problem (ok... it's both but it's a bug no playable server should have)

The client has a max buffer size for single packets. If you send too many targets in a single skill packet (max # of targets changes with client version as they make each target use more and more data), it will cause an unhanded exception and crash the client.

Totally unrelated just irked me cause I've seen that complaint so many times. Generally if you see that on a pserver it's a good sign it's a shit server or at least one that still needs some dev work

Thanks and I agree, but in my scenario the client doesn't crash because it didn't like the size or the number of packets it received it just couldn't handle the pressure of processing and drawing such a number of monster and their effects on the screen simply because it wasn't coded that way. I mean you could easily have a 100 monster idling on the screen but the moment it involves effects, particles and damage it just couldn't keep up.

Originally Posted by CptSky

Don't forget the client was developed in the early 2000s and wasn't truly updated since then. A lot of things have changed since they started CO2. Coding practices for games and MMOs too.

I would have believed you if we weren't talking about TQ here lol.

I mean this will probably amuse both you and pro4never.

The current Twin-city map has well over 1000 mapcovers, sounds and effects without the server spawning anything, and they are all treated as mapobjects and stored in the same vector and every time a monster/player/effect/etc is spawned by the server it is added to that vector, and how does TQ process them for drawing, well they loop through the entire collection "Every frame" like so.

 Spoiler

vector<> everything;//this is the vector that contains everything 

for (i = 0; i < everything.size(); i++)
{
     everything[i].process();//mapobject
}

mapobject::process()
{
      if(distance <= )
      {
           InteractiveLayer::ApplyShow(this);//determine when to draw this 
      }
}

vector<> finalvector;//cleared every frame 
InteractiveLayer::ApplyShow(mapobject object)
{
     for (i = 0; i < finalvector.size(); i++)
     {
           if (xyz)
	    {
                  int bInsert = i; 
                  for (int n = i - 1; n >= 0; n--)
                  {
                 
                  }
                  finalvector.insert(begin() + bInsert, object);//Draw me after anything < bInsert and before anything > bInsert
            }
            else
            {
                  nOverLayAfter = i;
                  for (int n = i + 1; n < dwSize; n++)
                  {

                  }
                  finalvector.insert(begin() +nOverLayAfter, object);
            }
     }
}

and then when it's time to draw 

for (i = 0; i < finalvector.size(); i++)
{
     finalvector[i].draw();
}

And until this day you could still see that same obnoxious loop running in their assembly code at least in EU demons and they have had well over 10 years to change this but they never did, why? well because it works and that's all that mattered to them.

Originally Posted by KraHen

^ That. With that said, software/hardware batching was and is available, all their monsters use the same material, so all mobs on the screen can and should be drawn with a single draw call, the fact that they cannot do that proves incompetency. The fact that the client is old is not an excuse for not optimizing/updating it (it wouldn't even change a single thing visually for the end users).

Agreed, but why should they? I mean it works the way it is and they are making money and everyone is happy lmfao.

But hey joking aside, I really don't see a problem with that I mean draw calls are cheap and are becoming even cheaper every year, Modern GPU's are designed to handle an insane amount of draw calls per second with little to no effort. so if the CPU is not being burnt out and is able to keep up with the GPU then where is the problem?

I mean if I am not mistaken (correct me if i am wrong) the only time you would benefit from a single draw call is when you have a shit load of low poly objects to draw and by a shit load i mean hundreds if not thousands.

[KraHen]

Originally Posted by { Angelius }

...

Agreed, but why should they? I mean it works the way it is and they are making money and everyone is happy *****.

But hey joking aside, I really don't see a problem with that I mean draw calls are cheap and are becoming even cheaper every year, Modern GPU's are designed to handle an insane amount of draw calls per second with little to no effort. so if the CPU is not being burnt out and is able to keep up with the GPU then where is the problem?

I mean if I am not mistaken (correct me if i am wrong) the only time you would benefit from a single draw call is when you have a **** load of low poly objects to draw and by a **** load i mean hundreds if not thousands.

With the same logic a horse takes you from point A to B just fine, why would you use a car? This is literally a 1-2 hour task to implement, the fact that they are not willing to do it shows incompetence, or worse, plain laziness. I'd call this ADD (******* Driven Development).

[{ Angelius }]

A quick update