Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Zoomulator

Pages: [1]
1
Feature requests / Screen position transforms
« on: September 12, 2011, 04:37:38 pm »
I figured that the window class could keep two functions for transforming between the screen and the current view setting.
In the case that you set up a view that's not aligned to the pixels of the screen, the window could have a ScreenToView and ViewToScreen transform function so you could easily get the mouse position in the active view.

It's fairly straightforward to do it yourself, but it's easy to get wrong a few times before it's right. Another of those convenience things, but I think it'd make sense with the Window - View feature that's already in.

2
Window / Mouse movement, delta position
« on: September 12, 2011, 01:13:21 pm »
I can't really see the point in not having the delta information kept in the mouse move event. Sure, you can calculate the delta yourself by comparing the new position with the old, but this doesn't work when the mouse position is limited by the screen/window border.

There's a lot of instances where you use the mouse for movement rather than being a cursor. First person look around views, as one example, and there's a few many more.

Besides being limiting by not having it, it's also a question of convenience and clarity. The mouse move event is usually a single instance, and hardly performance intensive, so why not just include the deltas with the mouse move event instead of letting the user hassle with that detail?

I saw an earlier post on the subject, but it had no replies for some reason. Hope this defines the question more clearly.

3
Network / How to handle Non-blocking TCP socket returning notready
« on: October 13, 2010, 11:14:44 pm »
I've set up a selector in the fashion stated in the tutorial though with non-blocking sockets. Occasionally, the receiving TCP socket will return "not ready" and then simply drop the packet.
It tries to read the socket twice and returns "Not ready" both times, and then it just stops trying so the packet is never received. The next packet may arrive properly as this only happens rarely.

What should I do when a TCP socket returns "not ready"? Should I put it in a special buffer that tries to read it again each iteration until it succeeds? What then if it doesn't succeed before another message arrives and is successfully received by the selector algorithm?

4
Network / Blocking UDP::Receive and threads
« on: August 29, 2010, 07:59:17 pm »
Maybe I designed my UDP listener thread the wrong way, but here goes.
I've made a thread for the client side that listens for incoming data from the server. Quite logical. It occured to me that the UDP socket must be set to blocking, or it misses a ton of packets. It's fine leaving the socket as blocking in the dedicated thread for as long as it's running, but when I need to close the thread while the socket is blocking I don't really know any way of unblocking it while the SocketUDP::Receive method is running.
I'm using a bool for a loop in the Run method of the thread to shut it down safely. Am I forced to kill the thread with Terminate()?

It seems like the TCP socket can be in a non-blocking state and still receive all packets. Is this true?[/b]

Pages: [1]