irrNetLite 2.1 [BETA]

Ion Dune · Post by **Ion Dune** » Mon Jun 30, 2008 6:06 am

Yeah, it compiled fine once I added the new library. I'm getting heap corruption errors whenever I call netmanager->update() or netmanager->setupclient(), though. Looks like I will have to wait for the update

D-Eagle · Post by **D-Eagle** » Mon Jul 21, 2008 10:44 am

So... Any news on the update?

BlindSide · Post by **BlindSide** » Tue Jul 22, 2008 2:44 am

Oh my god I feel like such a **** I completely forgot about this. Thanks for reminding me, I'll try to get it done asap.

Ok progress report:

I completely re-wrote the OutPacket/InPacket class implementations, they now use dynamic arrays to allow for any size packets (And less memory consumption), const references for object types for improved performance and sending strings can now be handled through the core::stringc and core::stringw templates, which means sending wide characters is supported now. I am just about to start adding compression support to the packets so you can do something like .compress()/.uncompress() with the help of zLib.

Cheers

D-Eagle · Post by **D-Eagle** » Wed Aug 13, 2008 4:30 pm

*whistles*

BlindSide · Post by **BlindSide** » Thu Aug 14, 2008 4:39 am

Still working on it, I completely separated the interface/implementation and made an independent lib (irrNetLite.lib, For MSVC) that you can link to without having to download Enet/Platform pack (So it includes both Enet and ws2_32.lib object code embedded in the lib).

Lots of other features done/in progress. Get ready for a change in API.

For a release date, I have no idea, hopefully not too far away.

D-Eagle · Post by **D-Eagle** » Fri Sep 12, 2008 12:48 pm

Any news? :)

BlindSide · Post by **BlindSide** » Fri Sep 12, 2008 2:42 pm

Nearly there, infact the it's pretty much done, I just need to compile the documentation and finish adding extra stuff like compression/encryption etc. (Compression is almost done.)

The problem lately is that I've had mid-semester break and I've mostly been working on it on my spare time on the university computers which I don't have access to during the break. The break is over starting next week so hopefully I will have something out by the coming tuesday/wednesday.

Be prepared for a slightly different API, it's more intuitive and provides way better error handling/support, a cleaner code base, and just way better coded in general. Of course testing is still a top priority, I'll try and PM you a beta version earlier than the release so you can have a good look D-Eagle. The static lib for MSVC will include things like ws2_32 and enet linked in so those users won't have to worry about such things. Other platforms/compilers may be supported after release if I have time. (Of course it's not too hard to compile it yourself on linux etc.).

Since this is independent of Irrlicht now maybe I should change the name, any suggestions?

Cheers

Darktib · Post by **Darktib** » Fri Sep 12, 2008 6:49 pm

Wow... very interesting lib!

But I think i will wait for the update^^

PS : and for the net... why not NetLite or something like this ? Or a non-english word (french, german, etc...) ?

D-Eagle · Post by **D-Eagle** » Sat Sep 13, 2008 9:31 am

BlindSide wrote:Of course testing is still a top priority, I'll try and PM you a beta version earlier than the release so you can have a good look D-Eagle.

Cool, i'll be waiting for it!

monkeycracks · Post by **monkeycracks** » Sat Sep 13, 2008 6:34 pm

BlindNet.

ehenkes · Post by **ehenkes** » Mon Sep 15, 2008 10:08 pm

Don't forget a working DEMO.

politicsofgossip · Post by **politicsofgossip** » Sun Oct 19, 2008 9:22 pm

so was the update ever released for this? does the older version still work as long as you comment the lib and use latest version of enet? it worked for visualstudio what if you use devc++? does it matter as long as you link and include everything? do i make any sense?

edit: ok wait rereading it didnt run just compiled i think

BlindSide · Post by **BlindSide** » Sun Oct 19, 2008 10:22 pm

This should work on DevCPP, and pretty much any compiler that supports enet, though I've yet to test this release on linux (If it works on GCC linux it should work on GCC DevCPP). Thanks for reminding me I actually pretty much finished the update (And I sent a beta version to D-Eagle to test which worked pretty well.). I just never got around to documenting and packaging it, that stuff can sometimes be just as important as the code itself, when it comes to a library like this. Also I might want to write a nice example app to go with it.

politicsofgossip · Post by **politicsofgossip** » Sun Oct 19, 2008 10:59 pm

cool. i am eagerly looking forward to it. i just started all of this and its gone past the completely over my head stage to now it is all vaguely starting to make sense. and for some reason i cannot get enough of it its neat figuring out how to get it to work. ive had a few moments where i was like there is no way this is gonna even compile much less run and it works.

an example app would be awesome if i can get my hands on one for whatever i am working on i can usually figure it out. heh after getting a server and client set up in this my next goal will be to somehow integrate newton or physx into it. really have no idea how to do it, i am pretty sure it is possible though right?

BlindSide · Post by **BlindSide** » Mon Oct 20, 2008 1:14 am

Yeah I ran a few Bullet (A good physics library) + the old irrNet tests way back in the past it ran pretty well. You have to remember to send the velocities instead of positions, for smooth movement and physics interaction, and don't forget to update the position every 500ms or so to sync (Non-determinism, inaccurate timers etc contribute very quickly to divergent results.).

Of course IDEALLY this would all be run on a master server and the clients only serve as a transparent workstation that displays the graphics, in this case you should still send velocities (And intermittently update positions.) but the clients won't really need a physics lib running you can just do basic "position = position + velocity * time;" forward reckoning while you are waiting for your position sync and velocity packets to arrive.

Heh look at me I got carried away again, the field of network + physics is one of the most difficult situations modern programmers have to face, but if you keep it simple and robust I'm sure it will all work out.