ddboarm

Members
  • Content count

    57
  • Joined

  • Last visited

Community Reputation

100 Neutral

About ddboarm

  • Rank
    Member
  1. Nullable struct in c#

    Quote:Original post by Nik02 ...value type to a Nullable templated class in order to inject nullable traits to structs. This has a bit of overhead because the underlying values of nullable struct instances are effectively forced out of the stack. Inclined to disagree...unless you can produce an actual resource that supports your claim. When a value type is made nullable, a reference type is created on the heap to reference the struct on the stack. Overhead? Really? Quite negligible I'm sure.
  2. Nullable struct in c#

    You can't create a nullable struct directly. However, you can create a nullable reference to the struct: private Vector2D? point1; It makes perfect sense to create your Vector2D as a struct to mirror exactly the way the Point class works. Go for it... Now, when you create a nullable reference you will have 2 properties to be concerned with: HasValue Value You can check HasValue (bool) to determine whether the struct has been initialized. Obviously, Value will reference the actual struct.
  3. Threading Multi Client Server

    I don't know about Java really, but before you jump off into the threading, check out the asynchronous methods (Begin/End). I started with the threading model and quickly became annoyed at the issues with threading sockets. Do yourself a favor... :)
  4. When I read the OP, I had to give this a shot and see if I could do it. So, here is a link to a simple console application and winform source that I threw together. It's probably not perfect, but it will certainly give you enough to work with and a place to start learning. Enjoy!!!
  5. c# set/get problems

    Quote:Original post by Tct Hi, a quick question, suppose we have a code like that *** Source Snippet Removed *** The problem is that when I'm changing Position or Scale through X accessor, Position.set or Scale.set isn't called due to obvious reasons and thus OnChangePosition and OnChangeScale also aren't called, my question would be what would be the best way to invoke Position/Scale set accessor from Vector2 accessors? Delegates, Events? or maybe there is a better way, I am still green in C#, so maybe I am missing something here. Thanks maybe: public class Vector2 { private float _x; private float _y; public float X { set { //ToDo OnChangePosition(); OnChangeScale(); _x = value; } get { return _x; } } public float Y { set { //ToDo OnChangePosition(); OnChangeScale(); _y = value; } get { return _y; } } }; I dunno...but the only thing I see that is apparent about why OnPositionChange/OnScaleChange isn't firing is because you aren't calling it when an X or Y value changes? I'd probably use a function with a return value instead. Also, there may be some logic that you can implement that will determine if one or both of those events need to be triggered. Hope that helps some...
  6. What did you get for Christmas?

    Quote:Original post by Lode The "Dirkjan Scheurkalender"! You must probably live in Belgium or Holland to know what that is :) I was able to find "Dirk Jan Supercalendar"...but nothing beyond that. Google doesn't even know what it is...
  7. What did you get for Christmas?

    Quote:Original post by szecs Nothing. Awww...that's like Christmas purgatory - neither naughty nor nice. At least if you'd gotten a lump of coal you could figure out how to apply enough pressure to make a diamond.
  8. What did you get for Christmas?

    My 2 front teeth
  9. I have found remarkable success with whatever my questions were at http://www.stackoverflow.com. With a little code I might be able to help you out. I am gaining experience rapidly with reflection and delegates in C# with an interface I am developing.
  10. Game related Multi-threading

    A previous post is correct in that you don't want to create threads left and right. Any many scenarios where I have thought I needed a thread, I have been able to replace with asynchronous method implementation (Delegates, BeginInvoke, etc.). Just thought that I would throw that idea out there for possible consideration.
  11. Quote:Original post by taz0010 Catch the WM_MOUSEMOVE event. The coordinates of the mouse are accessed via LOWORD(lParam) and HIWORD(lParam) respectively. For the square, you can check if the mouse is over it with 4 'if' statements. For the circle you can use the distance formula; if((mX-cX)^2 + (mY-cY)^2 <= circleRadius^2) // Mouse in circle A little OT, but: How well do the WM_MOUSEMOVE, ~DOWN, etc. port to other platforms?
  12. One thing I was experimenting with using GDI+ and drawing to a panel control (C#) was how to catch the MouseDown, ~Move, etc. No matter which way I looked, all the suggestions pointed towards using a 'foreach' loop to determine the mouse coordinates. Only problem is that the foreach cannot keep up with fast movement of the mouse. I published static events in the panel that each GDI+ object (Rectangle, etc.) then subscribed to (if it cared). Then, each of my GDI+ objects were made aware of mouse events. I was even told that this was effectively no different than a 'foreach' loop, but performance differences between the two implementations tells a different story. I know there may be some differences between Direct2D and GDI+, but this solution shouldn't be affected by those differences - at least I wouldn't think so. I, admittedly, am not experienced with any graphics other than GDI+ (yet).
  13. Quote:Original post by Antheus Quote:Original post by ddboarm Really, to fully manage TCP (and offset the extra overhead), you must ensure that your send buffer is fully used. We've been experimenting with ways to get the most out of TCP as we can with strict adherence to filling buffers as much as possible, and not splitting messages up over multiple send/receives. Except that no API I'm aware of exposes this information, thereby making it impossible to know how full the buffer actually is. The only way this can happen is to keep send buffer fully congested at all times (WOULDBLOCK or block on send), but that is counter-productive for low-latency applications, since the data is actually delayed due to flooded connection. Unless you are stuck with TCP for whichever reason, sending messages over UDP using one of established concepts would make this type of tuning considerably easier as well as more deterministic. Each network stack is free to implement its sending heuristics and still remain standard compliant. OP: Relevant background. From what I understand about the Socket class, you set a buffer size: from MSDN - Socket.SendBufferSize Property Gets or sets a value that specifies the size of the send buffer of the Socket. - Socket.ReceiveBufferSize Property Gets or sets a value that specifies the size of the receive buffer of the Socket. - public IAsyncResult BeginReceive( byte[] buffer, int offset, int size, SocketFlags socketFlags, AsyncCallback callback, Object state ) where size Type: System.Int32 The number of bytes to receive. - public IAsyncResult BeginSend( byte[] buffer, int offset, int size, SocketFlags socketFlags, AsyncCallback callback, Object state ) where size Type: System.Int32 The number of bytes to send. I realize that TCP is a Stream - and always 'on' - and therefore nearly improbable that you could keep the 'stream' full without rigorous looping. However, you make the most of each Send/Receive by getting as close to filling the buffer as you can. Maintain message lengths to within the bounds of the buffer sizes. Maintain a developmental adherence to complying with the buffer sizes. I provided the information above simply to convey that I don't feel I'm going off half-cocked. :) There are many more sites I researched as I progressed in creating our network server project. I will include UDP - I'm not going to deny our game dev customers the choice of protocols by any means. Frankly, actual implementation of our product, and the methods chosen, are completely left up to the developer. I am simply providing tools for creating a client/server game that don't require programming the actual sockets through the async processes - and is developed to be fully integrated into the game engine.
  14. Quote:Original post by Codeka ... TCP is a stream-based protocol - there is no such thing as "packets" (at an application-level anyway). I referred to it as a packet instead of a message. But I do see what you are saying. In reference to receiving a partial packet, rather than wait (or loop) for the rest of the message, if I receive a message that doesn't have a 2byte length I ignore it. At least that is the process right now. But this is mostly to experiment with inbound traffic and get an idea about how well it works. Really, to fully manage TCP (and offset the extra overhead), you must ensure that your send buffer is fully used. We've been experimenting with ways to get the most out of TCP as we can with strict adherence to filling buffers as much as possible, and not splitting messages up over multiple send/receives.
  15. It seems there are 2 completely different schools of thought on whether TCP or UDP should be used. TCP: a reliable connection based protocol - can remain connected, but requires a little more overhead, thus a little slower. UDP: an unreliable connectionless protocol - faster and less overhead. Okay, so using UDP means that you have to check message IDs because you are working with a fast, yet unreliable protocol. Compare that method to using TCP. Because TCP is a reliable protocol, you don't need to double check to ensure you aren't receiving a duplicate message. What I have implemented is that the first 2 bytes of my message give me a length of the incoming message (inclusive of the first 2 bytes ;P). Compare that with the size of the message. We are planning on optimizing data packets to the send/receive buffer size so no packet would ever be larger than the buffer (requiring multiple sends to complete a data packet). So, if the first 2 bytes represent an 800 byte message and all the socket received was 750, I throw it away. I don't bother telling the client or server to resend - if a request is not fulfilled within a given timeframe, it will simply request again. There can be discussions that go on forever over the advantages/disadvantages of the protocols. I'd actually like to be able to have a reliable, connectionless frickin' protocol :) Comments welcome...