Mirage Source
http://www.miragesource.net/forums/

Optimize Your Packets!
http://www.miragesource.net/forums/viewtopic.php?f=210&t=66		 Page 2 of 3
Author:  pingu [ Sun Sep 17, 2006 7:28 pm ]
Post subject: 
Verrigan wrote:
This artical explains the details of the different data types for VB .Net.. But I think some of it applies to VB 6.0, as well, which could explain why the Fill/ZeroMemory functions don't work well with arrays.. (Especially multi-dimensional ones)

http://msdn2.microsoft.com/en-us/library/47zceaw7.aspx


It's not exactly the same for VB6.

Thank Fal for this:
Image
Author:  Verrigan [ Sun Sep 17, 2006 7:42 pm ]
Post subject: 
pingu wrote:
It's not exactly the same for VB6.


Like I said... some of it applies to VB 6.0.

And you (or Fal) forgot to get the most relevant portion of that MSDN Help Context. :) Here... I'll quote it for ya:

MSDN Help Library for Visual Basic wrote:
Note Arrays of any data type require 20 bytes of memory plus 4 bytes for each array dimension plus the number of bytes occupied by the data itself. The memory occupied by the data can be calculated by multiplying the number of data elements by the size of each element. For example, the data in a single-dimension array consisting of 4 Integer data elements of 2 bytes each occupies 8 bytes. The 8 bytes required for the data plus the 24 bytes of overhead brings the total memory requirement for the array to 32 bytes.

A Variant containing an array requires 12 bytes more than the array alone.


So there ya go. :) I can't tell from the quote how it is stored in memory, so it still leaves a lot of questions as to that.. Which has since led me to stay away from Fill/ZeroMemory unless I allocated the memory with the Windows API. :) (Virtual/GlobalAlloc, for example)
Author:  Lea [ Sun Sep 17, 2006 7:58 pm ]
Post subject: 
I dont know what to say, I have never used your version either.

I am still having problems with Valk, cant connect anymore for some reason. (havent worked on it too recently, TOO BUSY ;--;)
Author:  pingu [ Sun Sep 17, 2006 8:32 pm ]
Post subject: 
Heh, I just bothered reading the title of this topic an realized I had something to contribute...

I happen to be redoing the packet system using Spodi's system, which is just putting data types into a buffer and taking them out in the same order on the other side. I've had to redo everything involved with packets (sending and receiving) and it's taken me quite some time to do that.

The painful twist is that I'm converting Elysium and it's taken me almost three weeks to change the sending of the server and the recieving of the client (aka 50% completion). It hurts, but I've already noticed a difference when I managed to connect to the server one day. Elysium is known for the long "Recieving game data..." screens as it gets all the data from the client, but I swear it took less than a second with these changes.

Even then, I'm not even close to being finished (I do plan to release the source some time in the future). I'm getting a mysterious bug with this new system that shouldn't happen (of course it shouldn't happen, it's a bug...). I lose focus on the game screen and can't see anything (it's 100% black). I can still type messages and watch as the packets are sent from client to server and back again, but I can't move or even see the map. I'll figure it out soon enough...

Bleh, I just need somebody to feel my pain. If you can feel my pain, say "*feels pingu's pain*" and I'll give you a redeemable coupon for pingu feeling your pain.
Author:  Vans [ Sun Sep 17, 2006 9:24 pm ]
Post subject: 
*feels pingu's pain and its painful >_<*
Author:  grimsk8ter11 [ Sun Sep 17, 2006 9:53 pm ]
Post subject: 
Well, i really cant explain anything amazing about this, because verrigan did it for us in KoC, so it was pretty much perfect, and i learned from looking at that sinc ei knew KoC before he added it like the back of my hand, and more or less, about 150 conversations about it with him :P because I had trouble using it in a base MS when i was working on MSE2.

Really, this is a godly to use if your starting from scratch with netwroking, which is what i did when i made the groundwork for the Moria engine. It makes things alot easier for you. The biggest problem with this in MSE is that MSE uses alot bigger Datatypes then it really needs to for SOOO many things that its not even funny, and over the course of changing them (especially if you tried to copy and paste from verrs example code, which did things mighty different then the best way to do them) you screw alot up. The hardest part was matching up datatypes for adding and removing to/from the buffer.

To Shan:
If you are having problem with the KoC code, talk to me please, because nothing should be wrong with it, since Verr did it (not saying hes perfect :P but he did quite a bit of testing if not more to make sure it worked, trust me, i know).

To Dave:
I had the same problem at first, the buffer seemed to like to overread it client side, check your incomingdata and ahndle data client side. If you want any help, ill be glad to offer assistance.

To Pingu:
Spodi's system IS verrigans system to tell you the truth, what you said PERFECTLY describes what verrigans system does, and there was some controversy over it for a while, untilt hey both decided to drop the argueing, or just got bored of it haha. But I feel your pain, I have done it countless times now, and each time, I get new problems, just takes alot of debuging. And if you need anby help, feel free to ask me too.

To Vans:
loser :P

To Verr:
Got to talk o you on Gtalk sometime, have some questions about Linely and such, also something about KoC.

To Mis:
You didnt post here, and i couldnt forget you just because im bored, but you're still a loser anyway. mwhahahaha :twisted:
Author:  Spodi [ Sun Sep 17, 2006 10:45 pm ]
Post subject: 
Quote:
Spodi's system IS verrigans system to tell you the truth, what you said PERFECTLY describes what verrigans system does


Or the system used for many, many, many online games. I didn't even know about Verrigan doing this until a few months after I made it and wrote that guide, and I did it different then he did. It's a pretty common system to use, though. I didn't know there was "controversy" over it... Verrigan got annoyed with me for a completely different reason. :wink:

Quote:
But I think some of it applies to VB 6.0, as well, which could explain why the Fill/ZeroMemory functions don't work well with arrays..


ZeroMemory/FillMemory works just fine with single-dimension arrays and multi-dimensional arrays... I've never had any problem with it.
Author:  Verrigan [ Sun Sep 17, 2006 11:14 pm ]
Post subject: 
Spodi wrote:
ZeroMemory/FillMemory works just fine with single-dimension arrays and multi-dimensional arrays... I've never had any problem with it.


Does it work just fine in UDTs that have multi-dimensional (or single-dimensional for that matter) arrays defined in them? It may or may not.. Haven't tested it. :) Actually, I hadn't opened up VB for about a month now (until Shannara mentioned this bug..) I've been programming in Visia in my spare time lately, and it's just buggy if I try to declare variables in there, so I try to keep it to long values.. and an occasional string. :)

Also, on the .Net site, it gives me the impression that memory is assigned differently on different systems.. So I dunno. Maybe I'll do some extensive testing to see what is going on. :) If I do, maybe I'll post the results.

I'd imagine I will find that some data (like the actual variable) is stored in memory separate from the actual array data, but I suspect that the different dimensions store a variable close to, or possibly inside the array itself.. But I'll have to test it..

I'll post my results here for anyone who might be interested.
Author:  Misunderstood [ Sun Sep 17, 2006 11:17 pm ]
Post subject: 
Quote:
To Mis:
You didnt post here, and i couldnt forget you just because im bored, but you're still a loser anyway. mwhahahaha :twisted: l


You're awesome too. :P
Author:  Verrigan [ Sun Sep 17, 2006 11:31 pm ]
Post subject: 
Code:
Sub ClearTempTile()
  Dim tTempTileRec As TempTileRec 'Need object to obtain memory size.
  Dim tLen As Long

  tLen = (1 + UBound(TempTile) - LBound(TempTile)) * LenB(tTempTileRec)
  Call FillMemory(ByVal TempTile(1), tLen, 0)
End Sub
Okay... I want you all to look at my coding error here.. You'll see it in ClearClasses() too:
Code:
Sub ClearClasses()
  Dim tClassRec As ClassRec 'Need object to obtain memory size.
  Dim tLen As Long
 
  tLen = (1 + UBound(Class) - LBound(Class)) * LenB(tClassRec)
  Call FillMemory(ByVal Class(0), tLen, 0)
End Sub
See the errors? They're fairly easy to miss..

So, first, I'll say that all that stuff I linked to before, and the note I quoted from the MSDN Help Library, though useful, has nothing to do with the problems in the code. (See? Told ya it wasn't tested 100% :P)

Second... If you haven't already noticed, there is a ByVal before the array we are trying to fill the memory of. Now, for some of you, that probably just lit an amuzement park amount of light-bulbs off in your head..

For the rest, let me explain. FillMemory, like ZeroMemory, and CopyMemory are usually declared with 'Any' as the type for the mem loc arguments.. This allows you to be able to send either a variable which, by default in VB, is sent ByRef (It's memory address is passed), or a memory location's value by prefixing your data with ByVal.. Unfortunately, if you send ByVal <variable here>, to these funtions, you won't get an error.. Cause what's happening is.. the data from your variable is being copied, and the new memloc is being sent to the function.

I'm not so great at explaining stuff so that my 10 yr old can understand, so I won't bother trying to go that deep. So... What I suggest is this: Change those ByVal <varnames> to one of the following:
Code:
<varname>
Or
Code:
ByVal VarPtr(<varname>)

That should resolve any issues with the example.. And for the record, I think Spodi is correct in his statement regarding arrays.
Author:  Dragoons Master [ Thu Jan 04, 2007 12:37 am ]
Post subject: 
Sry to bring this old topic back alive but I'm realy having some problems with the binary packets... I just downloaded the zip file verrigan gave us the link(http://www.verrigan.net/downloads/MSE-Verrigan.zip) and, well, I'm having problems with that! Can anybody download it and just run the server, run the client, create a char, login, and try to drop a gold coin(edit the account.ini). I do this and it just bugs for me... it log me off. I know is something with long values and only with them becouse I added it to my game and it works perfectly but not with any long values. Actualy it works once but when you send a second long values(doesn't mather when) it will bug... I don't know if it's a problem with me but I tried to redownload and it just keep happening... If anybody can help me out with this I would realy apreciate. Tnx in advance and once again, sry for realiving the topic.

EDIT: Omg, I can't beleave it... I found the bug... It was the last thing I would ever thing of... the COMSocketServer.dll DLL changed, I tought it did but then I tought again that it was almost impossible to be the dll... I realy never imagined that the dll would need to change to be able to do this... sry guys, just forget about it xD
Author:  Obsidian [ Thu Jan 04, 2007 3:26 am ]
Post subject: 
Wow that may have been my previous problem as well! I'll have to check that out (and i did have a problem sending any kind of Long Values... but to get around it... i just did a Str$(LONGVAR), and then just did a AddStringToBuffer... then on the recieving end i just got it back as a long and did CLng(W/E). Glad you picked up on it though, i might go back and actually readd byte arrays now). :D
Author:  Lea [ Thu Jan 04, 2007 3:57 am ]
Post subject: 
Hmm... maybe it's a problem with my DLL that would cause my problems. SEems reasonable. Never thought of that. I will need to try later.

What would cause a DLL file to change or stop working? seems a bit fishy.
Author:  Spodi [ Thu Jan 04, 2007 3:58 am ]
Post subject: 
My only guess would be the method used has become obsolete and theres a new method, but you're right, that is odd and fishy.
Author:  Obsidian [ Thu Jan 04, 2007 5:28 am ]
Post subject: 
i dunno, maybe the sub used to control the long variables for the ComSocketServer.dll had changed? I (thought i) remember verrigan saying he had the source and had changed some of it up. If perhaps it was changed and the functions that you're using for mirage had been altered in the DLL... i dunno....
Author:  Dragoons Master [ Thu Jan 04, 2007 12:45 pm ]
Post subject: 
The most weird this is that this working DLL, the ones that work with binary packets, is OLDER than the other one. One is from september/05 and the other one is from august/05... Thats weird...
Author:  Dragoons Master [ Wed Feb 14, 2007 10:59 pm ]
Post subject: 
Ok, I found THE bug and I fixed it!!! Finaly, after a month of useless attempts for fixing this I did it. Well, there realy was a bug. For everybody that downloaded Verrigan's modified MSE with BinPackets, the bug is that when you send the same data to a lot of diferent persons, like SendDataToAll, the Buffer get's messy the first time you send this data. Why? Simple! It was being used as ByRef and that way when, inside SendDataToNew, this code executes:
Code:
    Data = PrefixBuffer(Data, VarPtr(CByte(pType)), 1)
    Data = PrefixBuffer(Data, VarPtr(aLen(Data)), 2)

it will replace the old data with this one already modified... So you need to do this once or don't edit. My fix will only don't change the Data() variable. It will copy the data inside Data() variable to an other variable, DataB.
To fix, inside SendDataToNew, replace:
Code:
    Data = PrefixBuffer(Data, VarPtr(CByte(pType)), 1)
    Data = PrefixBuffer(Data, VarPtr(aLen(Data)), 2)
    GameServer.Sockets(Index).WriteBytes Data
With:
Code:
    Dim DataB() As Byte
    DataB = Data
    DataB = PrefixBuffer(DataB, VarPtr(CByte(pType)), 1)
    DataB = PrefixBuffer(DataB, VarPtr(aLen(DataB)), 2)
    GameServer.Sockets(Index).WriteBytes Data
That shall fix it!
Author:  Bakekitsune [ Sat Feb 24, 2007 11:52 am ]
Post subject: 
Thanks! also how much faster is this?

maybe like,
how many players could you fit?
Author:  Spodi [ Sat Feb 24, 2007 11:37 pm ]
Post subject: 
Binary packets isn't as much about speed as it is lowering bandwidth usage.
Author:  Robin [ Sat Feb 24, 2007 11:43 pm ]
Post subject: 
Spodi wrote:
Binary packets isn't as much about speed as it is lowering bandwidth usage.


Still, having the server sending less data means that it will be able to send to a few more people than it could when it was sending a lot of data.
Author:  Lea [ Sun Feb 25, 2007 3:39 am ]
Post subject: 
Having binary packets also reduces a whole lot of string handling it needs to do. Strings are slow.

Verrigan at one time estimated this change and a few other ones like the binary filesystem would allow about 500 people online.
Author:  Spodi [ Sun Feb 25, 2007 6:12 pm ]
Post subject: 
I wouldn't be surprised if packing strings together holding the same information as the binary is faster (depending on how you do the binary). It really depends how you treat the packets, too. You can easily write crappy binary packets, just like you can string packets. Just like anything else, they're great, if done right. :wink:
Author:  JokeofWeek [ Sun Mar 23, 2008 7:34 pm ]
Post subject:  Re: Optimize Your Packets!
Alright :) So I converted my packets succesfully from Client to Server, without any problems, using a slightly modified version of modBuffer. Now, I converted all the packets from Server sent to client to byte arrays, and it seems to be having alot of problems. The packets are all done good, I checked those over, but it seems to always totally freeze up the client side and crash VB6. I know this is the Server to Client because I did not have this problem when I had only Client to Server. Does anyone know what could possibly be causing this? :S

Edit: Basically, has anyone succesfully converted Server to Client packets? If so, I'd like to talk to you :D
Author:  William [ Tue Mar 25, 2008 8:03 pm ]
Post subject:  Re: Optimize Your Packets!
I suggest you try and reach Grim, he knows what his doing.
Author:  JokeofWeek [ Wed Mar 26, 2008 1:18 am ]
Post subject:  Re: Optimize Your Packets!
Well,I seem to have found where the bug is coming from. It seems that whenever it gets to the MapData packet (in SendMap from server side), it processes the packet and all that, but it prefixes it with the wrong packet length, and that is what is causing the bug.

Does anyone know what could possibly be causing this? o_O It seems to be passing the byte values 34 and 16 (in that order) instead of 34 and 18 for the packet length :S.
Page 2 of 3 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/