Messages

46

General discussions / Re: SFML 3 - What is your vision?

« on: April 25, 2014, 12:31:05 pm »

I'm a bit confused. What role is SDL playing in this all? Because I don't think it's really an option to have SDL or GLFW as dependency of SFML...

You don't need to link them, Emscripten does that automatically. So they're just another part of the #ifdef chain. Emscripten doesn't specify most of it's own window creation functions (it all gets compiled down to canvas HTML and Javascript in the end), but hijacks/reuses a few existing and common cross-platform libraries to provide the hook between canvas and code. There are some emscripten does provide, like getting the size of the canvas.

Going away from Emscripten, C++11. C++11. All of the C++11.

And maybe the ability to hook into the file loading to add custom type support.

47

General discussions / Re: SFML 3 - What is your vision?

« on: April 25, 2014, 11:21:44 am »

GLEW or any manual extension loading is not required for emscripten. All supported GL calls work out of the box. The graphics API needs to be ported to work with OpenGL ES 2.

Damnit Brain-fart, GLFW. not GLEW xD argh, those aren't confusing similar names at all

As I understood it you have to use EGL (+X11), GLFW, or SDL to create a window for OpenGL. I edited to list them, but doesn't SFML already use GLFW in parts?

Also the Android port I'm guessing uses EGL, so there's already that code available.

48

General discussions / Re: SFML 3 - What is your vision?

« on: April 25, 2014, 11:14:01 am »

Perhaps we can elaborate what changes are exactly needed to make this happen.

Of the top of my head:
The Windowing API would need to support EGL, GLFW or SDL 1.2 for creating windows.
The Graphics API needs to support the WebGL subset of OpenGL (which is a subset of OpenGL ES 2).
Audio API.
Networking would need porting to WebSockets/WebRTC. Probably easier to drop support of it for Emscripten.

49

General discussions / Re: sf::Shader -- API to set uniforms

« on: April 20, 2014, 04:24:32 pm »

Agreed. sf::Shader::Matrix definitely conveys that this matrix concept is related to the Shader and not the core Mathematical Matrix concept. I'd assume sf::Matrix was a full-fledged Matrix implementation comparable to the one provided by XNA and be required to look at the documentation to ensure I wasn't missing something and figure out it's much more limited use-cases.

With sf::Shader::Matrix I'd be much more likely to assume was just an adapter without going into the documentation (I regard requiring less documentation visits as being a very good indicator of quality of design).

Though the implementation detail of whether Matrix stores data by-value is a question. Being able to return a sf::Shader::Matrix from a function would simplify integration with the more fully-featured Matrix implementations provided by a maths library.

As an aside, it's a shame SFML 2 can't drop the non-C++11 support. Because std::array would be a useful C++ standard structure for the previous array discussion.

50

General discussions / Re: sf::Shader -- API to set uniforms

« on: April 20, 2014, 03:54:46 pm »

SFML has so far only implemented the mathematical operations and structures it needed. The lack of a magnitude with regards to sf::Vector jumps to mind. This does potentially reopen up a bigger design discussion on how much Mathematical operation support should SFML provide.

Using it as nothing more than prettying up the pointer and reducing the number of parameters on a shader function seems like a waste. More appropriate would perhaps if it stored the matrix array internally and provided read/write access to that storage.

From there, SFML could take the current Vector approach, namely store it's relevant fields and provide the simplest operations needed, and developers who need more can write functions and overloading operators to provide that.

Or SFML could provide a more full-featured matrix implementation, but that then raises the question "Where is the dot product function on sf::Vector?". Considering the complexity of matrices, a simple addition would be comparable to a complex vector operation. An inconsistency and a can of worms it may not be the best time to open.

51

General discussions / Re: sf::Shader -- API to set uniforms

« on: April 20, 2014, 03:41:38 pm »

I'm in favour of the Matrix wrapper. Maybe not a whole Matrix class, but giving the matrix overload a strong typing.

Requiring the developer to pass naked pointers to the Shader API smells like Primitive Obsession to me. Wrapping that low level concept in some kind of higher level container seems the most user friendly and what I'd expect from a modern C++ API.

52

SFML projects / Re: SFML Input Manager

« on: April 06, 2014, 01:21:37 am »

On a side note this is not directly possible, you need a C style function interface to call unmanaged code, hence CSFML.

Not strictly true. You can use C++/CLI to interface between C++ and .NET, wrapping C++ classes in a CLI wrapper. But this isn't compatible with Mono (to the best of my knowledge).

53

SFML projects / Re: Game Develop : Free game development tool

« on: March 30, 2014, 01:14:57 am »

Good luck Looks like a nice tool, the pictures give me some vibes from when I played around in Consruct awhile ago.

I guess my only real questions before I'd throw money are:
1. What advantages does this have over Construct2 or Game Maker? (Free is the obvious one, just curious if there's anything else specifically they don't do that you do).

2. I know you say it may be open source if you raise enough, but if not are there any plans for source code licensing or similar of the main tool?

54

Network / Re: [Bug?] std::string on Packets crashes on Windows but not Linux (mingw/g++)

« on: March 23, 2014, 04:16:57 pm »

My point was more that for your average modern 2-4 player game, JSON would be "sufficient enough" for usage.

But anyway getting distracted...has anybody actually tried this code on their setup? :S Because if it's not just happening for me, the only reason I can think for it failing is some DLL/EXE boundary shenanigans.

But I can pass it to an sf::String constructor just fine, and get the value from toAnsiString, and aren't they both crossing the System DLL boundary?

55

Network / Re: [Bug?] std::string on Packets crashes on Windows but not Linux (mingw/g++)

« on: March 22, 2014, 04:00:36 pm »

sizeof(sf::Uint32) = 4
sizeof(std::string::value_type) = 1
sizeof(std::wstring::value_type) = 2
Seems like pretty standard sizes to me.

As an aside, you say strings won't compose much of networking, but I would like to note that client/server communication via JSON isn't that uncommon in games.

56

Network / Re: [Bug?] std::string on Packets crashes on Windows but not Linux (mingw/g++)

« on: March 22, 2014, 02:28:35 pm »

I'm using the latest version of the nuwen mingw distribution. I rebuilt SFML again to make sure I hadn't accidentally updated the compiler and not SFML, but the crash still happens.

I found a work around in passing an std::string to an sf::String and serialising the sf::String on send, and deserialising to another sf::String and then extracting the std::string from the sf::String via toAnsiString on receive.

57

Network / [Bug?] std::string on Packets crashes on Windows but not Linux (mingw/g++)

« on: March 21, 2014, 05:58:20 pm »

Hello. So I want to make sure this isn't me doing something stupid or previously mentioned before I open an issue on it.

The following code will run on Linux perfectly, but on Windows (using the nuwen distribution of MinGW) the code compiles but crashes when trying to deserialise the string from the code. Changing it to a sf::String works, so that's a potential workaround. std::wstring will crash too, despite the documentation listing it as supported.

#include <SFML/Network.hpp>
#include <cstdint>
#include <iostream>
#include <stdexcept>

inline std::uint16_t getFreePort()
{
        sf::TcpListener listener;
        listener.listen(sf::TcpListener::AnyPort);
        return listener.getLocalPort();
}
       
int main(int nArgs, char** ppcArgs)
{
        typedef std::string PacketData;
        auto generatePacketData = []() { return PacketData("Hello_World"); };
        auto printPacketData = [](std::ostream& stream, PacketData data) { stream << data; };
       
        const auto port = getFreePort();
        const std::string ip = "127.0.0.1";
       
        std::cout << "Listener listens" << std::endl;
        sf::TcpListener listener;
        if ( listener.listen(port) != sf::Socket::Status::Done )
                throw std::runtime_error("Could not listen on port " + std::to_string(port));
        listener.setBlocking(false);
       
        std::cout << "Client Socket Connects" << std::endl;
        sf::TcpSocket clientSocket;
        if ( clientSocket.connect(sf::IpAddress(ip), port) != sf::Socket::Status::Done )
                throw std::runtime_error("Could not connect to listener on port " + std::to_string(port));
        clientSocket.setBlocking(false);

        std::cout << "Waiting for networking overhead" << std::endl;
        sf::sleep(sf::seconds(1));
       
        std::cout << "Server accepts" << std::endl;
        sf::TcpSocket serverSocket;
        if ( listener.accept(serverSocket) != sf::Socket::Status::Done )
                throw std::runtime_error("Could not accept listener on port " + std::to_string(port));
        serverSocket.setBlocking(false);
       
        const PacketData inData = generatePacketData();
       
        std::cout << "Client sends packet" << std::endl;
        sf::Packet sendPacket;
        sendPacket << inData;
        clientSocket.send(sendPacket);
       
        std::cout << "Server receives packet" << std::endl;
        sf::Packet receivePacket;
        const auto status = serverSocket.receive(receivePacket);
       
        PacketData outData;
        switch(status)
        {
        case sf::Socket::Status::Done:
                std::cout << "Server received packet" << std::endl;
                receivePacket >> outData;
                std::cout << "Server clears packet" << std::endl;
                receivePacket.clear();
                break;

        default:
                throw std::runtime_error("Did not receive packet");
        }
       
        std::cout << "Received packet: ";
        printPacketData(std::cout, outData);
        std::cout << std::endl;
       
        return 0;
}
 

Am I missing something obvious, is std::string/std::wstring not supported with sf::Packet and it crashes or just works because of some overloading nonsense, or is it a known (or unknown) bug in sf::Packet?

Whilst I can use the sf::String solution, a compiler error would of been be nicer than my roundtrip tests of my SFML wrappers crashing (not failing, just straight up crashing) and me having to break out the debugger because of this unintuitive gotcha in SFML's packets.

58

SFML projects / Re: A Simple and Easy to Use State Manager

« on: March 19, 2014, 11:18:46 am »

The example is a unclear about what functions/interfaces the 'states' need to implement.

The basic functionality is neat, but why the need for a Context?

Are contexts maintained separately? If so, wouldn't different managers for different windows make more sense? Or just passing the window into the draw function as a reference, since drawing should be the only thing that depends on the Window.
Can I have duplicate state classes with different enumerators?
Does the system handle adding states with the same enumerator but different context?
Is there any way to pass parameters to states when constructing them? Not allowing this forces some really nasty hacks to achieve Dependency Injections.

Yes I could get many of these answers by looking at the implementation, but ideally I could get it from either Examples or Tests (or Tests as examples).

As an aside, I've come to hate the phrase "Manager". It tells me nothing about the class, it just tells me it "manages stuff", which can mean anything and ends up a magnet of functionality. Often it's a sign SRP is being broken or about to be broken. Trying to come up with a more descriptive name, and from the looks of this "FiniteStateMachine" is the best I can come up with, but it's also a lie if each context is a separate FSM.

59

Feature requests / Re: set functions should return reference to self

« on: February 25, 2014, 12:26:22 am »

Function chaining is great when used for a Fluent syntax. For example, the following code is highly readable and functional:

sqlFactory.select("*")
          .from("some_table")
          .where("somevalue = 12")
          .execute();
 

In C++, libraries like cpplinq achieve similar results with syntax such as:

cpplinq::from(some_collection)
    >> cpplinq::where([](auto data) { return data.value == expected; })
    >> cpplinq::select([](auto data) { return data.other_value == expected; })
    >> cpplinq::to_vector();
 

Such syntax is both readable and greatly extensible. In these situation the chaining is inherent to the design pattern and, increases readability. It's intuitive and useful. However, as others have pointed out setters do not logically return a value so should not, it's simply not a returned value one would intuitively expect.

60

General discussions / Re: Unit Testing

« on: February 15, 2014, 05:47:01 pm »

But the project as a major GUI aspect, so I don't see very well what kind of unit test I can do. As a matter of fact, I've only planned tests on model classes that play with the SQL database. I don't see well other tests I could make.

Testing the GUI can be automated through a few tools. First of all, you can test everything after an action with the standard methods of dependency injection. Your GUI code should be as shallow as possible anyway (bolded for emphasis). The GUI layer is only responsible telling your underlying system what to do or being told what to do by your underlying system, and those things can and should be testable.

As for testing actual GUI actions (i.e a click), usually that is preserved for more end-to-end tests (like what one would do with Selenium) and depends on the system. I'm not familiar with how to do so on Windows, but this wikipedia page is probably a start.

On Linux, however, this is actually surprisingly simple. You can expose your GUI to the accessibility layer and drive your tests through that. People should be doing this anyway for blind users. By making it testable you also increase the number of people who can use your software. Win win.

For testing SQL interaction, there are a few ways to do it. End-to-end and integration tests often involve using a local SQL server you control, building the server up to contain the information you want at the start of the test and cleaning it at the end. There are probably some SQLite based libraries for this, but if you can't find any SQLite alone should cover that need.

For unit level tests, you can mock out the SQL server functions and just verify they are called.

In case you can't tell, I'm a huge fan of fractal TDD. End-To-End acceptance tests at the top, and drill down to specification tests one step below and then all the way to individual classes and functions.  Always mocking/stubbing out dependencies as you go to the degree that level calls for.

At the highest level, you mock nothing. These tests make sure it all fits together. At the specification level, you stub externals such as servers and databases. Your specification calls for you to interact with them in certain ways, you aren't testing they behave as expected at this level. At the unit level, you mock out anything that isn't inside the class/function being tested. Your classes specify they behave in certain ways, if it's not the class you are currently unit testing you don't care if they actually do or not because their unit tests will guarantee that.