Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

KabukiSDK(C# And VB.Net) v1.0 (Open Source)


ArchaicOokami
 Share

Recommended Posts

> Current features:
>
> __________________________
>
> File Features:
>
> CheckDirectory: Checks if a directory exists. If not creates it.
>
> CheckFile: Checks if a file exists. If not creates it.
>
> DirectoryExists: Checks if a directory exists. Returns a boolean without creating anything.
>
> FileExists: Checks if a file exists. Returns a boolean without creating anything.
>
> SaveObject: Saves a serialized class object to a binary file.
>
> LoadObject: Loads a serialized class object from a binary file.
>
> Arent those exact commands available already? How more simplified could they get.
Link to comment
Share on other sites

@ Marsh

Not really, the top few commands are, but handeling saving and loading an object doesnt serialize the object, which youd want for converting to byte arrays to be used in network or streams.

@ Thomas Slusny

This library has the availability for a vb.net coder(no c# experience) to both learn how to convert some stuff to C#, as well as should they want to modify how the functions work or rip the functions directly to their app they have the ability. The C# of course will be slightly more optimized but the VB edition again is mainly for the modifier.
Link to comment
Share on other sites

> And also, why you have your project in both VB and C#? It is enought to have it in C# you can then load compiled library in VB project too.

I think he's referring to the source being written in both VB and C#, which is understandable for anyone who wants to modify it. But yeah, what you said is also true.
Link to comment
Share on other sites

It's not bad code per say, but I do have a few comments on it all.

IO

>! The functions for checking for directories and files are already built into the .Net framework, and the GZip methods are almost nearly copy-and-paste code examples from MSDN.
>! I could be wrong, but from what I saw, you wrote out methods for saving and loading data similarly to the way most Eclipse engines do. If that is the case, I will say that it's not always beneficial to have methods as this. Especially so if you're going to frequently change your class's structure.

Buffer

>! Most of this is stuff you could do in a few lines with a binary writer and memory stream. You go more in depth, which is cool. But if you want to post this as a utility, then eh.

INI

>! Who even uses INI files what with the dynamics of things like XML?

Network

>! It looks good, but it's not asynchronous good in that it's not.
Link to comment
Share on other sites

> I think he's referring to the source being written in both VB and C#, which is understandable for anyone who wants to modify it. But yeah, what you said is also true.

Yes The source was written twice because it is open source for anyone to use modify rip etc.

> It's not bad code per say, but I do have a few comments on it all.
>
>  
>
> IO
>
>
> >! The functions for checking for directories and files are already built into the .Net framework, and the GZip methods are almost nearly copy-and-paste code examples from MSDN.
> >! I could be wrong, but from what I saw, you wrote out methods for saving and loading data similarly to the way most Eclipse engines do. If that is the case, I will say that it's not always beneficial to have methods as this. Especially so if you're going to frequently change your class's structure.
>
>  
>
> Buffer
>
>
> >! Most of this is stuff you could do in a few lines with a binary writer and memory stream. You go more in depth, which is cool. But if you want to post this as a utility, then eh.
>
>  
>
> INI
>
>
> >! Who even uses INI files what with the dynamics of things like XML?
>
>  
>
> Network
>
>
> >! It looks good, but it's not asynchronous good in that it's not.

On the IO, I know those features are built in, if you look at the source u can see what the code in those blocks are, its just a wrapper over a check and perform as a quick to call function(Keeps code looking cleaner, without much of a performance difference) and yes it does handle files like eclipse does using serialization. Of course you dont have to use them, it would be higher performance not to, they are simply there for the lazy as in my network code you have the option to presize it to the max size so you save on REDIM's, but you dont have to(take the slower lazier way out). As for the GZIP, yeah they are copy paste but modified and posted into reusable functions. They arent complete systems, just placeholders for now till i put in the heavy work with my FileStream.

^^^ I should also note, Serialized Objects will make it harder for inexperienced people to break into your files (should u be making a game) and modifying them to hack or stealing them for their own game etc…

The Buffer is work meant to be used with the Network. Im aware you can do that work with memstream and binaryformatter etc... It runs in a structure/module method format for keeping as high performance as possible while using a network buffer.

The Ini isnt a real ini system, General StreamReader/Writer functions are about the same speed if not faster than XML handeling though it is nice for people upgrading projects from vb6\. This code work was inspired for making upgrades to .net from anyones game engines as easy as possible.

(Note I do plan to add XML and SQL handlers in there down the road as well as functions for converting from 1 to another)

The Network isnt even finished either. Its usable but it doesnt have as dynamic of control as Id like. It needs IOCP handler(as an option) with handeling incoming packets, and it does run async on the listener thread. Being that most anyone intending on running these programs will be on a computer with at least the ability for 2 threads(at least for hosting servers) I figured itd be okay to keep the listener on that. If you are talking about Async PacketReceiving(like VB6/JCs.Net engine have broken receive packet systems async) yeah, that is just terrible imo. Slow, performance heavy, and makes it easier for someone to spam packets and slow down a loop.

___________________________________________

Do keep in mind, this is a new SDK I wrote, its being written via C# and translated to VB.net, and I do need suggestions on new features, or changes, testers etc.

I will keep developing onto this trying to keep features as high performance as possible as long as i have fan base willing to work with me on reporting things.
Link to comment
Share on other sites

**Network**

[https://code.google.com/p/lidgren-network-gen3/](https://code.google.com/p/lidgren-network-gen3/)

**IO**

"Binary serialization uses binary encoding to produce compact serialization for uses such as storage or socket-based network streams."

- [https://msdn.microsoft.com/en-us/library/ms233843.aspx](https://msdn.microsoft.com/en-us/library/ms233843.aspx)

**Tips**

Lidgren has built-in serialization as well as cryptography.

I would veer away from wrapping objects and methods that can be called just as easily themselves.  If you think about it you're still having to import your library in order to use those methods; what's the difference between "Kabuki.IO.DirectoryExists()" and "System.IO.Directory.Exists()"?  Using System.IO.Directory you have access to far more methods (an entire namespace devoted to IO with one using statement).  If you really need a method that you can't find anywhere in that namespace then write an extension method.

You mentioned List.  Why not write an extension method that handles IO for List or any other generic class?  I'll assume you know where I'm going with this.

> If you are talking about Async PacketReceiving(like VB6/JCs.Net engine have broken receive packet systems async) yeah, that is just terrible imo. Slow, performance heavy, and makes it easier for someone to spam packets and slow down a loop.

I believe you're mistaken.  Synchronous data transmission is what will inevitably bog your game loop down.  Asynchronous data transmission is received once per loop and sent once per loop; as it comes in, and this is why it's called "asynchronous", it's received on another thread, stored, then a callback is issued to marshal it to the calling thread (in this case the thread your game loop is running on).  

In reference to network and game loop throttling due to channel flooding this is precisely why you relay important game data on a separate channel and sanitize the stream (flood checking, removing duplicate messages, etc).  Lidgren also supports this.

If you're going to add SQL in the future I'd suggest learning Entity Framework (Code First).  Who cares if it's not fully functional on all platforms?  Are you trying to capture the 85% of the market share Windows owns or are you going to beat yourself to death trying to get to that 15% or less?  Give Microsoft another year to produce and expand more of .NET Core.  If you're worried about portability in the first place why in the world are you not using Unity for game development?  No one you know, on this site or any other, has even come close to producing what the Unity3D team has.  No joke.

Best of luck with this.
Link to comment
Share on other sites

> -snip-

Eww…. lidgren

If you're gonna do networking, im gonna save you the hassle and give you some advice.

1.Use Async. Basically when you create Event handlers to handle incoming data in .Net by using the .BeginListen or the .BeginReceive() methods, you're gonna use handlers and the method use is async.

2\. Serialize your data.

3.Do not make responses so your data doesn't get jumbled. Baiscally what this means is. When you want to make sure your data has completely sent before receiving another packet, DO NOT make the client or server reply to the other saying that the data finished reading. This doubles latency and creates lag, often a mistake with those who are new to TCP Socket Programming. John (GerneralAwesome) Showed me how to fix my mistakes here.

4.Use Packet Headers. The first 4 bytes of your incoming data should tell you how big the incoming packet is. THIS is how you split you data to make sure it doesn't get all mixed up in the stream. The next few bytes could be your data type, and every byte after that is the data to handle.

Keeping these four things in mind while programming a network will make it run efficiently.
Link to comment
Share on other sites

> Eww…. lidgren
>
> If you're gonna do networking, im gonna save you the hassle and give you some advice.
>
> 1.Use Async. Basically when you create Event handlers to handle incoming data in .Net by using the .BeginListen or the .BeginReceive() methods, you're gonna use handlers and the method use is async.
>
> 2\. Serialize your data.
>
> 3.Do not make responses so your data doesn't get jumbled. Baiscally what this means is. When you want to make sure your data has completely sent before receiving another packet, DO NOT make the client or server reply to the other saying that the data finished reading. This doubles latency and creates lag, often a mistake with those who are new to TCP Socket Programming. John (GerneralAwesome) Showed me how to fix my mistakes here.
>
> 4.Use Packet Headers. The first 4 bytes of your incoming data should tell you how big the incoming packet is. THIS is how you split you data to make sure it doesn't get all mixed up in the stream. The next few bytes could be your data type, and every byte after that is the data to handle.
>
> Keeping these four things in mind while programming a network will make it run efficiently.

Thanks for the info.
Link to comment
Share on other sites

> To each their own

If only it were a matter of preference.  

> @[member="Budweiser"] we can't be too sure. @[member="Budweiser"] How are your projects going?

Great.  I'm not wasting any time writing boilerplate. :)

PS.  To be perfectly clear I'm not saying what this guy has written is by any means terrible or that it doesn't suit a purpose; worst case scenario it's been a learning experience and it suits his/her purpose.
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...