max network lib

http://www.truplo.com/TNet/

anyone used it?

Yes, and I ran into a critical bug that would not allow 3 clients to be connected without them losing connection with each other. Until Wave irons out the next release I would suggest BNet instead. I've been using the UDP commands and have yet to run into any problems, though since it's basic, you'll need to write connect routines and things like that yourself.

http://www.blitzbasic.com/Community/posts.php?topic=43533&hl=vertex%20bnet

Infact, I think TNet uses BNet for some of its base code.

Yes, I use it. In fact I ran into a bug when using Flushmem and TNet. The author said that it was something related to BlitzMax, and not TNet. So I am waiting for the next version of BlitzMax to check that...

The next version of BlitzMax ditches the FlushMem command and the garbage collector does it behind the scenes whenever it feels like it - if TNet isn't working now, it's going to be screwed then.

What do you mean, ditches FlushMem?
Do you mean this as in... the FlushMem command no longer exists?!

http://www.blitzbasic.com/Community/posts.php?topic=51481#575151

Thanks :)

And also Mark's last worklog.

He's not ditching it, he's just putting it aside for more advanced users.

Really? Then what's the point of automating it if it can still be usedmanually to some effect? I'm not asking to be argumentative, I'm asking because I don't understand.

I suppose automation doesn't mean perfection, but then what exactly defines perfection relating to garbage collection anyway?

Automation is a big plus for many users, since this has proven to be one of the common stumbling blocks for new users. No flushmem or using it in the wrong places = memory utilization spiraling out of control.

Giving an advanced user the ability to specifically call it at a given time when a lot of things changed and you know you have a little spare time somewhere to clean it up is not a bad thing either...

Although I do wonder if he will give the ability to disable the automated cleanup too for those more advance users...

Personally I think I'd just stick with the automated cleanup, since so far that has always been 'good enough' for me in the past.

My thoughts exactly. A garbage collector is in a better position to know exactly when to delete a dereferenced object from mem than we do. In fact it already does this - calling FlushMem doesn't instantly restore our lost memory - it's completely up to the discretion of the gc. So calling FlushMem manually in an automated system doesn't make any difference.

I could understand if the automated system was switch-offable though.

This is entirely incorrect and I will explain why - in any language.

The problem of an automated garbage collector, is that it really doesn't know when is the best time to flush. It knows WHAT to flush, but not ideally when.

For example you will have a game loop which creates and destroys many things on the fly - perhaps an advanced particle system... or even a physics engine or some AI.

With auto garbage collection it will be stalling your calculations and generally doing it whenever it wants to. Blitz3D kind of side stepped this by doing a lot of it when you flipped/renderworld.

With manual garbage collection, you can do a hell of a lot of stuff, then clean up after all the stuff's done - ideal for setup or other situations where you really don't need it kicking in until the jobs done.

I guess there's pros and cons to both methods and I'll concede that a badly programmed automated system could certainly interfere with your usual program flow. However, I still don't think I'm entirely incorrect.

I don't see much difference between stalling a program during AI calculations, or stalling a program after a loop has finished (and waiting for a VWait, or whatever). So long as the whole loop is still done within one 'frame' (whatever that may represent in any program's case), it really doesn't matter where in the loop the calculations were done.

Automated garbage collection has a much better idea of exactly how hard your computer is being worked at any given moment. If memory were to be freed up during some intense AI/physics calculations, it could well mean the difference between very smooth performance and one more type instance pushing vmem to extend itself. Or, using Mark's own example, for speed ups during load routines. Which I guess isn't so important really, unless streaming is involved.


I'm sorry to have to dispute, but I believe the opposite.

Say the garbage collector realises when the CPU is practically idleing and then does it's work. In fact, the most efficient gc would kick in when the sum of CPU usage for all threads in your program is less than 100%. That kind of accuracy can't be matched by human intervention.

The choice to do it manually, or just stick with the automagical one is great.. Choice is good!!!!