Messages

1

General discussions / Re: Incredible performace of Lua (luajit) over C++

« on: June 16, 2015, 03:11:37 am »

Modern C++ compilers will also take advantage of SIMD instructions as well (if you let them optimize for modern CPUs) and are actually quite aggressive about vectorizing loops and other code constructs.

I know that. However, once you've compiled C++ to use SIMD you can't run your program on a CPU that doesn't feature those instructions. With Lua on the other hand, this is decided at runtime and uses it only if the CPU supports that feature. Therefore your LuaJit program can run both on an old CPU and use only the available instructions and on a newer CPU and use newer instructions without having two binaries.

But that wasn't the point of my post. I simply suggested that LuaJit might have optimized the resulted instructions while C++ didn't (probably wasn't allowed). Which means that the result of the benchmark is almost irrelevant.

2

General discussions / Re: Incredible performace of Lua (luajit) over C++

« on: June 02, 2015, 04:57:28 pm »

From what I could gather a while back. LuaJit uses SIMD instructions if allowed (by default) and available on the CPU. But you seem to miss the point. In almost every line of your code, you'll end up calling functions. And sometimes (many times) you'll end up calling functions from C/C++ (hopefully through FFI if you want to keep the speed otherwise it's useless with generic binding). And C/C++ will kill LuaJit when it comes to function calls.

Yes, LuaJit could outperform C/C++ when it comes to number crunching, if you have a really modern CPU and you allowed the use of SIMD instructions (will choose the best available instructions). But I highly doubt your code will be only numeric expressions.

Create two serious applications with a few thousands lines of code and not just a simple generic function. And then run them again. You could also disable SIMD instructions in LuaJit if you really want to have a one on one benchmark.

Not to mention that when you start using FFI in LuaJit to maintain that speed. All your safety goes out the window. You might think that C/C++ is an unsafe language. Just wait until you deal with that.

3

General discussions / Re: Setting up C++11 SFML in Eclipse for windows Tutorial

« on: March 13, 2015, 06:00:51 pm »

I've always had trouble with TDM GCC so I've stopped using it. Don't know why but some libraries just failed to compile. Instead I've started using MinGW-w64. I never had any issues with that. The only downside is that `-static-libstdc++` and `-static-libgcc` have no effect. You still have to distribute your application with some of their dlls.

4

General discussions / Re: SFML 2.3 Roadmap

« on: January 26, 2015, 01:11:42 pm »

Regarding the "feature/no_libsndfile_all_os (PR)". I've seen stb_vorbis.c used in Urho3D and it was quite impressive considering it's just a singe source file with a small executable size.

5

General discussions / Re: Conditional C++11 Support

« on: January 13, 2015, 03:14:20 am »

I dont think there is a need for a legacy (Non C++11) version. You can still use C++98 with C++11, and if you dont have access to a compiler that allows C++11, I'd suggest updating.

I'm quite comfortable using C++11. Actually it's the only thing that I use. I'm trying to use the latest version that I can. Currently I'm using MinGW-w64 x32 4.9.2 and I can't wait for when 5.0 will become widely used.

I was actually referring to those who can't use such software. But never mind that.

6

General discussions / Re: Conditional C++11 Support

« on: January 13, 2015, 12:12:50 am »

Maintaining one SFML version is already a lot of work. I don't think that a legacy version in parallel is possible in any way.

Doesn't have to be official or obligatory to maintain a legacy version. But just to keep it there as an "unofficial" version that is still maintained for the sake of compatibility.

But yes I agree with you that migration to C++11 should be a top priority task for projects that could take advantage of it's features and have the possibility to do so.

7

SFML projects / Re: [GUI] SFML backend for ImGui

« on: January 07, 2015, 07:13:26 pm »

now how can one get that string of bytes from a binary file?

I'm not sure it even works (correctly) but... uhm... you get the idea:

#include <iostream>
#include <iterator>
#include <fstream>
#include <iomanip>
#include <string>
#include <vector>

int main(int argc, char** argv)
{
    std::cout << "Enter the number of bytes to add a new line or use 0 for continuous." << std::endl;
    std::cout << "Row length: ";

    unsigned int row_len = 0;

    std::cin >> row_len;

    std::cout << "Enter 1 if you want spacing between array elements or 0 if you don't." << std::endl;
    std::cout << "Element space: ";

    bool elem_space = false;

    std::cin >> elem_space;

    std::cout << "Enter the path of the input file that should be converted." << std::endl;
    std::cout << "File path: ";

    std::string src_path;

    std::cin >> src_path;

    if (src_path.empty()) {
        std::cout << "No path to the source file was specified. Aborting..." << std::endl;
        return 1;
    }

    std::ifstream src_file(src_path, std::ifstream::binary);

    if (!src_file.is_open()) {
        std::cout << "Unable to open source file: " << src_path << std::endl;
        return 1;
    }

    std::streampos src_size = 0;

    src_size = src_file.tellg();
    src_file.seekg(0, std::ios::end);
    src_size = src_file.tellg() - src_size;
    src_file.seekg(0, std::ios::beg);

    std::string dest_path(src_path);
    dest_path.append(".cpp");

    std::cout << "Note: Output data will be saved into " << dest_path << std::endl;

    std::ofstream dest_file(dest_path);
    if (!dest_file.is_open()) {
        std::cout << "Unable to open destination file: " << src_path << std::endl;
        src_file.close();
        return 1;
    }

    std::cout << "transferring from " << src_path << " to " << dest_path << \
                " with a row length of " << row_len << std::endl;


    std::vector<unsigned char> src_data;
    src_data.reserve(src_size);

    src_data.insert(src_data.begin(), \
                    std::istream_iterator<unsigned char>(src_file), \
                    std::istream_iterator<unsigned char>());

    dest_file << "static const unsigned char file_data[] = {\n";

    unsigned int byte_count = 0;
    for (std::vector<unsigned char>::iterator itr = src_data.begin(); itr != src_data.end(); ++itr)
    {
        if (itr + 1 != src_data.end()) {
            dest_file << "0x" << std::hex << std::setfill('0') << std::setw(2) \
                        << int(*itr) << (elem_space ? ", " : ",");
        } else {
            dest_file << "0x" << std::hex << std::setfill('0') << std::setw(2) \
                        << int(*itr) << "\n};";
            break;
        }

        ++byte_count;
        if(row_len > 0 && byte_count % row_len == 0) dest_file << "\n";
    }

    src_file.close();
    dest_file.close();

    return 0;
}
 

8

General discussions / Re: Conditional C++11 Support

« on: December 31, 2014, 06:11:10 pm »

While C++11 won't make huge impact on SFML itself. I'm very sure (certain actually) that C++11 will make a significant difference in the development of the application in which SFML is/will be embedded.

Sadly for me I've started to learn C/C++ when C++11 was widely available and I've found that going back to older C++ makes development much harder (at least for me). I just couldn't see my self working with legacy C++ code and enjoy doing so.

I have to say that C++11 is the only thing that made me love programming with C++ while seeing others complain that C++ is a horrible language (those dynamically typed language lovers that waste 25% code checking if they work with the correct type).

I'd love to see SFML going for C++11 but until that happens try at least to get a stable legacy C++ version that is more or less stable enough to last for a long period and to allow developers to migrate their software. And if possible to even maintain it afterwards as a legacy option for those in need of such library.

C++ is definitely going through a "revolution" on whether developers should move to C++11 or keep the legacy C++ code. And that's mostly because of compiler and platform support for the new standard. At least that's how I see things.

9

Feature requests / Re: allow to build SFML as a monolithic library

« on: November 03, 2014, 09:08:04 pm »

Just to be clear on my previous post (because it might have been interpreted wrong). I wasn't saying that my ways are better or that there is an actual standard. By standard I mean how most developers do it, recommend you to do it and tell you to do it.

I was just saying that if the O.P. wants a monolithic library then he's free to make a project for it. And that it's not the end of the world to try something like that.

About the projects. There's not much to show. There's just some code that I've been experimenting with it and come to the conclusion that GLFW might be more suitable for someone who needs a "whole in one" library. (SDL tries to take too much control over things)

The Sound, Network and Graphics modules are good for simple things and what I found them to be great at is to provide a base for implementing your own and learning something in the process.

I'm not some expert and was just a personal opinion. Sorry for not placing an "Off topic" at the top

10

Feature requests / Re: allow to build SFML as a monolithic library

« on: November 03, 2014, 06:27:06 pm »

Honestly, I just made a Code::Blocks project (a while ago) which does (did) exactly what you're asking for. I know it's not recommended but it makes (made) a few things easier for me. And I'm not the kind of person who follows the standard just because "Hey, that's the standard bro!". As long as it makes things easier or makes sense to me, I tend to bend/change things to my advantage.

Most of the developers don't even bother with the Sound, Network and sometimes Graphics modules. All they need is a cross platform window api. Which is why I prefer GLFW over SFML (does what it promises and nothing more). But it sucks that GLFW doesn't support mobile platforms. Feel free to try making your own project (for your IDE) that includes the needed modules and as long as you have the proper files included and define the proper macros then you're good to go. My project made a static library and for some reason the overall size of my executable was smaller (way more smaller)

11

Feature requests / Re: Remove GLEW dependency in favour of glLoadGen

« on: April 07, 2014, 03:47:37 am »

I remember that we had this suggested once already, but I can't find the thread.

Anyways this could indeed be easier to use. I wonder however, if I want to use my own OpenGL code, what header do I have to include? Will that all still work via the SFML/OpenGL.hpp header?

It was one of my question when I tried to reduce the executable size from SFML and SFGUI based application because they both used two different libraries back then  (SFML GLEW and SFGUI GLee). Topic Replace SFML and SFGUI dependency of Glew and GLee with OpenGL Loader Generator?

While OpenGL Loader Generator is very lightweight in size that doesn't mean it comes without costs. It doesn't offer as much functionality like GLEW. But sometime I wonder who needs it. And also you'll be surprised to know that glLoadGen is much more pretentious then GLEW if you don't know the linking order of libraries.

I'm all up for glLoadGen because it's small and simple but would be preferred to either let the user implement it's own or to have an implementation for both libraries and let the users pick the one they want or need.

If they want minimal then glLoadGen is for them or if they want functionality then it's GLEW

12

General / Re: Linker Error, unresolved external

« on: February 11, 2014, 10:42:08 pm »

I don't work with Microsoft Visual C++ and you seem to be using it. You should follow this tutorial and see if you linked your project to the SFML's libraries (the .lib files) and if SFML is compiled as static then you should also link your project to SFML's dependencies. Read more here, even if it's for MinGW its still applies to MSVC except the libraries are .lib files.

13

General / Re: Problems Trying to use sf::CirlceShape and sf::Sound SFML 2.1

« on: February 11, 2014, 10:12:24 pm »

opengl32, glu32, kernel32, user32, gdi32, winspool, shell32, ole32, oleaut32, comdlg32, advapi32, winmm are libraries that should be located in your MinGW folder.

glew.a, freetype.a, jpeg.a, openal32.a, sndfile.a are located in your SFML directory extlibs\libs-mingw\x86 but depending on your platform and compiler they might be located in a different directory under the extlibs folder.

One more thing to mention I have them currently linked as:

graphics , sound , window , system instead of as graphics , window , system , sound because sound uses window I read.

you can safely place sfml-sound after the three basic SFML (graphics, window, system) libraries.

Thanks for the reply.

When you link to the static SFML sound library you must also link the following third party libraries to your project: openal32, sndfile

I have included these two dlls.

I wasn't referring to the dll's I was referring to the libraries that allows you to use the code in those dll's (openal32.a, sndfile.a from SFML\extlibs\libs-mingw\x86).

When you compile SFML statically the compiler doesn't import the required static libraries into the SFML's static libraries. Therefore it's your job to link SFML's dependencies to your project if your project is an executable or dynamic link library (dll for short).

14

General / Re: Problems Trying to use sf::CirlceShape and sf::Sound SFML 2.1

« on: February 11, 2014, 09:33:18 pm »

The thing is that you link to a static build of SFML therefore you will soon run into "undefined blah...blah" related problems.

• When you link to the static SFML libraries (graphics, window, system) you must also link the following system libraries to your project: opengl32, glu32, kernel32, user32, gdi32, winspool, shell32, ole32, oleaut32, comdlg32, advapi32, winmm (I'm not sure about winmm)
• Third party libraries that are also required by the static SFML libraries (graphics, window, system) and you must link to your project are: glew, freetype, jpeg
  Note: make sure to link Glew after SFML because sometimes you get "undefined blah...blah" messages that will make you hit your head against the walls without knowing what the problem is.
• When you link to a static Glew build make sure to also define in your project: GLEW_STATIC
• When you link to the static SFML network library (I think) you must also link your project to the following system libraries: ws2_32
• When you link to the static SFML sound library you must also link the following third party libraries to your project: openal32, sndfile

Based on your current project you should link to the following libraries in the following order: opengl32, glu32, kernel32, user32, gdi32, winspool, shell32, ole32, oleaut32, comdlg32, advapi32, winmm, sfml-graphics-s, sfml-window-s, sfml-system-s, glew, freetype, jpeg . And define the following GLEW_STATIC if you link to the static Glew library inside SFML extlibs folder.

Your first attempt should work just fine however I can't figure out why it doesn't compile! Try to link to the specified libraries and see if it works

15

SFML projects / Re: Space Racer

« on: February 08, 2014, 04:33:39 pm »

What you should do with the game camera is to rotate it with the vehicle. It's really hard to control a vehicle when the camera only moves up and down. Other than that it's a great game