VB6 versus VB.net performance comparrison?

[UnGod]

I happened to recently find out that eclipse engines written in vb6 have a hard time with more than 70ish people online at a time and i was really hoping to have room for many more people and more accurate location for players…

My question is, how many players could i potentially host using an engine programmed in VB.Net rather than vb6? what are the benifits of vb.net that would relate to server performance? lets assume this is all happening on a external dedicated server.

secondly, how hard would it be to convert vb6 to vb.net? i understand there are programs to help but how much effort would it be to go back behind the program and tidy things up?

assuming im working starting off with an engine written in vb6 what are my options for other languages i could convert into?

[Growlith1223]

It's not the language that doesn't support 70+ players, it's how the engine was made.. again, to answer your question, it varies, especially since how optimized said engine.benefits of moving to vb.net would be the fact you're using a new language, but also because it opens more powerful APIs you can use. Converting to vb.net takes a while and takes a lot of time rewriting some things. There's hundreds of languages you can use, the more populars are C++, C#, Java, and vb.net. C would be considered but i hardly ever see it used.

[Mal]

VB6 is a COM language compiled to native; Wikipedia states that new external third-party functions that utilize part VB6 source code and part machine code make it faster than C++.

Bottom line: VB6 is faster than .NET depending on how its used/written. Growlith was correct when he did that performance issues were due to how EO was written. He was also correct in saying that there is a significant list if pro's for moving to newer technology; one of those being the fact that .NET applications run far more efficiently across just about every CPU architecture because that's exactly what it was designed to do (JIT, IL).

[Vince]

> secondly, how hard would it be to convert vb6 to vb.net? i understand there are programs to help but how much effort would it be to go back behind the program and tidy things up?

These program are bull****.

EO was written poorly, and its architecture leads you to problem of limitation you may have encounter.

Therefore, if EO is built that bad it is not due to its dev but it is rather because of VB6.

Right now, VB6 is a quite old(it uses COM which is outdated), the needs of users and developpers evolved a lot since VB6.

Converting as it is to VB.Net, it's possible but you won't get any advantages…

Firstly, because convert an outdated architecture to a brand new language won't make the architecture modern and able to host more thant 70, even if the language is "more powerful".

On the other hand, because programming techniques change, the way of managing data change a lot between languages, even more when you compare VB6 to new langages.

And upgrading the current architecture to a modern one is suicidal undertaking...

If you want to getting started with a new language, you would have to set up a completely new engines, with its own features and its own architecture.

But it would take several years to get something really interesting and to be able to develop your game.

If not, you won't gain any performance, just by migrating to another language.

However, there are different way in order to improve the perf of EO, you could for instance use C++ DLL to extend the VB6 possibilities or use it for complex algorithm with a lot of calculation(like A* pathfinding), but we could discuss about their long-term sustainability.

Anyway, one day if your project grow up, you would have to move on something new.

[UnGod]

thank you guys for your replys if you would i have more questions though.

> VB6 is a COM language compiled to native; Wikipedia states that new external third-party functions that utilize part VB6 source code and part machine code make it faster than C++.
>
> Bottom line: VB6 is faster than .NET depending on how its used/written. Growlith was correct when he did that performance issues were due to how EO was written. He was also correct in saying that there is a significant list if pro's for moving to newer technology; one of those being the fact that .NET applications run far more efficiently across just about every CPU architecture because that's exactly what it was designed to do (JIT, IL).

now about cpu structure would vb6 be able to utilize multiple core processors or would that even come up as an issue? a lot of server hosting im seeing is advertising 2,4,8,16, even 32 core processors.

> However, there are different way in order to improve the perf of EO, you could for instance use C++ DLL to extend the VB6 possibilities or use it for complex algorithm with a lot of calculation(like A* pathfinding), but we could discuss about their long-term sustainability.

 I really appriciate you bringing this up i had absolutely no idea this was possible, I would like my players location to be as accurate as possible.. is this something a c++ DLL could possibly do?

 I dont quite understand what you mean by long term sustainability though Il research it as best i can but if you would explain i would appriciate it

[Vince]

It's depends on how much player you want in your game.

By long term sustainability , I mean it's not a long term solution, one day if you game goes well, you'll have to think to move on something new.

Concerning VB6, it's not able to use multiple core processors.

But there's many things you can improve in EO.

For exemple, the packet system is based on byte array which allow you to workaround the string packets' system.

But in EO, when you set up a packet and you use Write method such as :

```

Buffer.WriteLong m_Var
```
If you didn't use the PreAllocate method (used in MS4), each time you call a Write method, the byte array will be resized.

(if you look into the clsBuffer if i'm right, in the write method you'll find Redim Preserve), which an awful way of building packets.

In fact building byte array packets using Redim preserve in certain circumstances could be slower than using string concatenation(in string packet).

And it'll slow down all your application.

The first thing to do is to avoid as much as possible the use of Redim Preserve not only in packets…

C++ or C could handle many and various problem of speed execution, and in fine allow you to host a bit more of player(if found the correct way of using it).