Topics

1

Network / 8 bit bools in packets instead of 1 bit

« on: July 17, 2014, 10:19:39 pm »

Why does the Packet class send 8 bits for bool data instead of 1?

Code: [Select]

Packet& Packet::operator <<(bool data)
{
    *this << static_cast<Uint8>(data);
    return *this;
}

2

Network / Appending two packets together

« on: September 13, 2013, 01:47:40 pm »

Is it possible to append two packets together?

Code: [Select]

// the first packet
sf::Packet packet1;
packet1 << std::string("eat") << std::string("IceCream");

// the second packet
sf::Packet packet2;
packet2 << std::string("run") << FORWARD_RUN;

// the two above packets appended would be read like
sf::Packet packet1plus2;
std::string cmd1, cmd2, item;
int runDir;
packet1plus2 >> cmd1 >> item >> cmd2 >> runDir;


3

General / No LoadFromX constructors design choice

« on: May 05, 2011, 06:50:55 am »

Why do classes like sf::Image not have overloaded constructors that implicitly call LoadFromX where X could be, for example, File?

I'm not suggesting this feature, but I'm questioning the design choice to not include it in order review my own choices in my application.

4

Window / Handling SetActive efficiently in multithreaded environments

« on: April 16, 2011, 12:58:18 pm »

I have a game engine I'm writing with SFML that sets up an interface for the Lua scripting language to provide game logic. I've set up functions for the scripting language that directly map to OpenGL calls. The problem is that sometimes the scripting language executes inside of threads invisibly to the scripting language. So, sometimes calls to OpenGL would be made without an OpenGL context. To remedy this, I internally lock/unlock a mutex and call SetActive(true)/SetActive(false) on the window each time I run any scripting language callback from any thread. However, SetActive is too expensive a function to call as frequently as I am (~200 times per second while idling). It's maxing out my 2.13GHz dual core CPU usage to 100%. When commented out on Windows XP, my CPU usage goes down to 1-12%.


A few ideas have ran past my head on how to fix this performance issue:

1.) Reduce the amount of times I call SetActive
Instead of doing SetActive(true)/SetActive(false) each time I run a callback from the scripting language, have the current thread check if it is the window active thread and, if it is not, make a request for the current window active thread to release the window so we can set it active for the current thread. All threads will call a polling function that checks if they need to release the window. This should reduce the amount of calls to SetActive drastically, especially while idling, but it still won't be at an acceptable level in complex scripts that run many different-threaded scripting callbacks every second. It can also create a lot of wait time for threads to finally read the request of other threads.

2.) Drop threading completely (or at least the invisible non-scripted threading)
This really simplifies things. I actually don't know why threads are such a hot topic. The only thing I know of that can't be done smoothly without threads is loading resources while displaying something else. There is also a hack in my application that puts input into a different thread so that the window still performs display updates while being dragged on Windows, but I can live without that.

3.) Stop calling SetActive(true)/SetActive(false) at all
Instead, create a new OpenGL context for every thread with the color buffer starting/clearing color set to be completely transparent and, when the thread finishes running a scripting callback, display the result on top of the window's (the real) OpenGL context and clear the color buffer of the thread's OpenGL context.


I'm just looking for some feedback on my problem. I've been thinking about it all day and am still not sure if I am approaching it the right way. I'll probably go attempt to implement option 3 when I get some motivation to see how it will work. I'd be completely fine with doing option 2 though. This whole thing is sort of low priority since this is just an optimization thing.


P.S. It's 4AM so I'm not sure if this post makes complete sense. :lol:

5

Network / Calling sf::SocketSelector::Add twice on the same socket

« on: April 12, 2011, 03:30:24 am »

Will calling sf::SocketSelector::Add twice on the same socket add the socket twice or add it once?

6

Network / Distinguishing multiple clients with the same IP using UDP

« on: April 07, 2011, 05:59:49 am »

As far as I can see, the only way to distinguish multiple clients with the same IP using UDP is for each client to have a unique port. If you bind two clients with the same IP to the same port, you get random behavior determining which client gets packets. The problem is that I don't have a way of guaranteeing each individual process that is ran under the same IP receives a unique port.

It seems that Winsock already has a partial answer to this problem:

Binding to a specific port number other than port 0 is discouraged for client applications, since there is a danger of conflicting with another socket already using that port number on the local computer.

Source: http://msdn.microsoft.com/en-us/library/ms737550

The above may only apply to a single computer running on the same IP whereas I need unique ports for all computers using the same IP.

UPnP is quite a mystery to me, but it may have the true answer to this problem. So, I'll be checking out the MiniUPnP library referenced here.

Conclusively, I just need two instances of the same application running on the same IP to be guaranteed to be able to receive packets. Is there a way to do this in SFML?

Edit:
After posting, I realized that I can use a temporary port to request a unique port from the server. With the unique port that the server gives, I can rebind the client to a permanent port.

However, this is just a hack. Two clients on the same IP will not be able to connect at the same time because the temporary port is the same.

7

Window / Window not updating display while being dragged

« on: March 29, 2011, 04:58:05 am »

In Windows, my window stops doing display updates while being dragged. When dragged outside of the visible desktop and back, the window gets anomalies such as this from this. I'd prefer the application didn't create these anomalies in order to be consistent with other Windows applications. How do I get this to stop happening?

8

Feature requests / My request with frame time and it's blurriness...

« on: October 10, 2008, 03:55:29 am »

This thread is corresponding to this thread.

I was just wondering if SFML should implement the feature described in the link above into sf::RenderWindow, instead of me inheriting.

Something like:

Code: [Select]

void sf::RenderWindow::PreserveImageQuality(bool Preserve)

I'll try and go a bit more into detail if you don't know what I mean, I'm in a bit of a rush at the moment though.

9

Graphics / My problem with frame time and it's blurriness...

« on: October 09, 2008, 01:55:13 pm »

I've gotten a good game engine going after spending quite some time with SFML, but now I've run into a bit of a problem.
You see, if I move a render window's view by any decimal, it blurs the image to appear to be in multiple pixels at the same time.
Up until now, It's never really been a real problem because I only drew box-shaped objects to the view.
However, now that I have started to draw objects with more complicated geometry, it's really annoying to see how blurry things can get.
Most would figure that it'd just be as easy as moving all my objects by whole numbers instead of decimals.
This wouldn't work though because I am multiplying the movement of my view by the application's frame time in order to maintain the same speed across different systems.

Here's some code that can help replicate the problem:

Code: [Select]

       float Offset  = App.GetFrameTime() * 128.f;
        float OffsetX = 0.f;
        float OffsetY = 0.f;

        if (Input.IsKeyDown(sf::Key::Up))    OffsetY = -Offset;
        if (Input.IsKeyDown(sf::Key::Left))  OffsetX = -Offset;
        if (Input.IsKeyDown(sf::Key::Down))  OffsetY += Offset;
        if (Input.IsKeyDown(sf::Key::Right)) OffsetX += Offset;

        View.Move(OffsetX, OffsetY);


I have thought of rounding the offset to the nearest whole number, but that would lower the resolution of my view.
Perhaps it'd be best if SFML rounded to the nearest whole number while rendering each frame without modifying the resolution of my view.
Anyways, I am simply looking for advice on the subject; it doesn't look too great having a blurry game.

10

Feature requests / SOIL Result Messages

« on: August 26, 2008, 10:01:14 pm »

I want to request that by default the release version of the graphics package library be compiled with STBI_FAILURE_USERMSG defined.
This will force stb_image to, instead of giving specific errors, like...

Code: [Select]

can't fopen

... give more user friendly errors, like...

Code: [Select]

Unable to open file

This would be ideal for the release version of the graphics package.


EDIT: If the above request is done, could you also change the errors in ImageLoader.cpp to contain a capital letter after 'Reason : '?
Such that...

Code: [Select]

Reason : this image format is not supported

... is changed to...

Code: [Select]

Reason : This image format is not supported

Of course, this is a matter of ill-importance compared to the initial request and definitely shouldn't be done if it causes an inconsistency in the error messages for other parts of the APIs.

11

Window / [Solved] SFML 1.3 Leaking Memory Under MinGW

« on: June 24, 2008, 03:06:47 am »

Nvwa's memory leak detector is detecting a memory leak of 176 bytes when I create a sf::Window instance under MinGW using the following code:

Code: [Select]

#include <SFML/Window.hpp>

int main() {
    sf::Event event;
    sf::Window window(sf::VideoMode(640, 480), "Window", sf::Style::Close);

    for (;;) {
        while (window.GetEvent(event)) {
            if (event.Type == sf::Event::Closed)
                return 0;
        }

        window.Display();
    }
}


Should I be concerned about this? SFML 1.2 never reported any memory leaks. I am using Windows XP with SP 2 and here's the commands I used to build the code:

Code: [Select]

mingw32-g++.exe  -g     -c test.cpp -o test.o
mingw32-g++.exe  -g     -c debug_new.cpp -o debug_new.o
mingw32-g++.exe  -o tile-d.exe main.o debug_new.o    -lsfml-window-s-d -lsfml-system-s-d


12

General discussions / SFML 1.3 and OS X

« on: June 23, 2008, 08:54:26 am »

I was so excited to upgrade to SFML 1.3, but I can't without a OS X port.

Is that port near finished? I remember seeing a thread about it being finished some time during this summer.


EDIT: There is also a typo on the download page that says, "the latest valid OSX port is still in version 1.1," but I think you mean 1.2, right?