Messages

1

Feature requests / Screen position transforms

« on: September 12, 2011, 05:00:44 pm »

Oh, it's in the RenderWindow class! Most weight of my suggestion was on that part...

The inverse would mainly be used for checking pixels, which is hardly ever done now days. It's a lot more complicated with hardware textures and all the rest.

Can't think of any other use for the inverse... nope.

Thanks for pointing me right.

2

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.

3

Window / Mouse movement, delta position

« on: September 12, 2011, 04:25:46 pm »

Thanks for the reply Laurent.

Don't know if you want to hear it, but maybe SDL got some nice solution for it. It has the delta in its mouse move event, and I reckon it's pretty low level. I don't envy the person who needs to look through SDL source though.

Keep up the good work! Cheers

4

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.

5

Network / How to handle Non-blocking TCP socket returning notready

« on: October 14, 2010, 12:23:47 pm »

Thanks Laurent!
Your support is impeccable!

6

Network / How to handle Non-blocking TCP socket returning notready

« on: October 13, 2010, 11:49:05 pm »

I'm generally nonsensical =D

So when a selector says a socket is ready to receive, does it already have all data or is there still communications in the connection that could possibly delay the blocking?

7

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?

8

Network / Blocking UDP::Receive and threads

« on: August 29, 2010, 08:52:53 pm »

I'll try to reproduce it in a minimal example.

I've changed my code to use a selector, even though I'm only using one socket for the client. But you're saying a UDP socket bound to a port without a selector should receive all packets through the Receive mehod even though it's not blocking?

9

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]

10

General discussions / Should I go from SDL to SFML?

« on: August 28, 2010, 01:36:52 pm »

If you need hardware accelerated graphics then SFML is the way to go. If you want software managed graphics keep going with SDL.
The only use I see for SDL is building old school tile based systems. Actually oldschool games over all, where pixel manipulation is a needed feature. Changing pixels in openGL textures is challenging and kindof messy compared to software loaded surfaces.
If you're using C++, you should use a C++ library like SFML. Using SDL is very clumsy in comparison, mainly since it's a C interface. (atleast the 1.2v I've been using. There's a new 1.3v in the making which seems more organized.)
I didn't change to SFML because of the graphics, event structures or even OO interface though. I had an elaborate library built up around SDL which I was satisfied with already, utilizing openGL through SDL to get the hardware acceleration. What made me switch was the SFML socket support for networking! Trying to use other socket solutions like boost::Asio was way too much effort, so SFML came as a fresh breeze in my bloated, cramped and hot SDL code base. I threw out all my SDL code and re-implement the graphics in just a few hours with SFML, using the already existing sprite class.