Just a few of questions
1. Can you be logged into more than one channel
at once?
2. When you leave a channel do you leave the server?
3. I know blast is quicker than text but,
Is SEND number quicker than SEND text?
Is BLAST number quicker than Blast text?
4. I know the stack thing saves bandwidth, but
does that affect the speed as well?
1. Yes.
2. No!
3. Depends. Each number is stored in 4 bytes. Text is stored in one byte per character. Sending "12" as text would therefore be 2 bytes, 1 byte less than a number.
4. Yes... of course.
thx for the response
So stacking is faster even if what is being sent is small?
like ZZ for example.
It looks like stacks is only better if you are using 3 or more characters in a given segment
(EX ab,123,5)
So the only one worth stacking would be the 5 correct?
What I was wondering was if the process of unstacking or the propcess of waiting for the information to stack causes more delay than blasting when the figures are small. Meaning would it improve the overall reaction time for the user recieving the message.
123 would be 3 bytes as a string, 1 byte as a byte pushed onto a stack. Check this.Originally Posted by dascribe
No. Any processing done by Lacewing is negligible. Parsing a text string would be the slowest thing to do, whereas stack messages and number messages are exactly the same.
The bottleneck is the network connection here, not the CPU.
Anywhere except network traffic, I'd recommend the approach that used the fewest events, and least expression code. In general, MMF's event engine is slower than anything an extension can do.
In C (taking calculating distance between objects as an example), doing (object->posx - object2->posx) * (object->posx - object2->posx) is considerably quicker than doing pow(object->posx - object2->posx, 2), because raising a number to a power is one of the slowest operations, by several orders of magnitude. In MMF, (X("object") - X("object2")) pow 2 is considerably faster than the multiply version, simply because it is shorter code.
With network traffic, bytes/second are king.
You definitely don't want to join things together as a string. It was a common piece of advice with Moo (which didn't have stacks), but it generally increased the amount of data being sent and added significant extra complexity to receiving.
I probably didn't need to go into all that detail. Hopefully someone finds it interesting.
Yes, it is interesting!
The great question being posed is AMD vs Intel (just kidding let's not go down that road lol)
Here is the question I'm getting at.
Is it more important to have smaller shipping or less events?
I know both is the ideal, but if one has to be slightly compromised, which factor has a greater impact on user experience/game performance?
It's more important to have fewer bytes transmitted than less processing.
For an online game you have a hard limit on upload data (user to server) of less than 10 kB/second for everyone (except dialup/mobile net users) to be able to play, ideally less than 1 kB/s. That includes lacewing packet overhead (4-6 bytes per send action). 1 kB/s is 20 bytes per frame at 50 fps, and only 10 at 100fps. Subtracting off packet overhead, that's a single 4-byte message! You might just get away with "always" sending X and Y pos as a stack of two 2-byte numbers, but you'd be pushing it.
EDIT: And that's ignoring the overhead of the actual network packets, which is 40 bytes for TCP/IPv4 per packet (but they're automatically combined to reduce overhead) and 28 bytes per packet for UDP (which aren't automatically combined). That eats up your entire per frame allowance before you've even sent anything!
It really is hard work to keep data transmission down.
You shouldn't be sending data every frame anyway, though. 10 FPS sending is fast enough with some decent dead reckoning (try count to 10 in a second).
ok, I'm sold
Just couple of things:
Do you have to use the Zlib?
Is the ACSII case sensitive?
Is it faster for sending chat text as well?
Posting Permissions
Reply With Quote