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.


Messages - Aster

Pages: 1 2 3 [4] 5 6 ... 9
46
Graphics / Blocky font rendering
« on: September 06, 2014, 03:46:57 pm »
Hi everyone.

I'm using SFML compiled from source from the feature/xcb branch.
When trying to render text in a virtual machine running Ubuntu 14.04 (both x86 and x86_64), my code gives me blocky text:

int main()
{
    // Load a font for text rendering
    sf::Font font;
    if(!font.loadFromFile("resources/sansation.ttf"))
        return EXIT_FAILURE;

    // Create a text object using the font we've just loaded
    sf::Text text;
    text.setFont(font);
    text.setCharacterSize(16);
    text.setColor(sf::Color::White);
    text.setPosition(0.f, 0.f);
    text.setString(
        "SFMLSFMLSFML"
    );

    // Create the main window
    sf::RenderWindow window(sf::VideoMode(640, 64), "SFML");

    // Start the game loop
    while (window.isOpen())
    {

        // Process events
        sf::Event event;
        while (window.pollEvent(event))
        {
            // Close window: exit
            if (event.type == sf::Event::Closed)
                window.close();

            // Escape key: exit
            if ((event.type == sf::Event::KeyPressed) && (event.key.code == sf::Keyboard::Escape))
                window.close();
        }

        // Clear the window of previously drawn content
        window.clear();

        // Draw our text
        window.draw(text);

        // Finally, display the rendered frame on screen
        window.display();
    }

    return EXIT_SUCCESS;
}

 

Here's an image:


This is weird because I'm using exactly the same font as the OpenGL example, and the OpenGL example's text renders just fine

The same code works just fine on Windows (8.1 x86_64)

Any ideas/feedback/help is appreciated.

Thanks,
Aster


47
Turns out I had a previous MSVC build of SFML and it was using those .lib files to link.

Cheers

48
Hi there.

I just reinstalled my compiler, and switched from MinGW 4.8.2 i686 to MinGW 4.9.1 x86_64.
I'm on Windows 8.1. My compiler is MinGW 4.9.1 x86_64 (64-bit). I'm using CMake 3.0.1.
I'm building with
$ git clone https://github.com/SFML/SFML && cd SFML
$ mkdir build && cd build
$ cmake .. -G"MinGW Makefiles"
$ make

All the modules build fine, except for sfml-graphics, which fails with:
Linking CXX shared library ..\..\..\lib\sfml-graphics-2.dll
cd /d C:\Users\Aster\Programming\temp\SFML\build\src\SFML\Graphics && "c:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_link_script CMakeFiles\sfml-graphics.dir\link.txt --verbose=1
"c:\Program Files (x86)\CMake\bin\cmake.exe" -E remove -f CMakeFiles\sfml-graphics.dir/objects.a
c:\MinGW\x86_64\mingw64\bin\ar.exe cr CMakeFiles\sfml-graphics.dir/objects.a @CMakeFiles\sfml-graphics.dir\objects1.rsp
c:\MinGW\x86_64\mingw64\bin\g++.exe     -shared -o ..\..\..\lib\sfml-graphics-2.dll -Wl,--out-implib,..\..\..\lib\libsfml-graphics.a -Wl,--major-image-version,2,--minor-image-version,1 -Wl,--whole-archive CMakeFiles\sfml-graphics.dir/objects.a -Wl,--no-whole-archive ..\..\..\lib\libsfml-window.a ..\..\..\lib\libsfml-system.a "C:\Program Files (x86)\SFML\lib\glew.lib" -lopengl32 ..\..\..\..\extlibs\libs-mingw\x64\libfreetype.a ..\..\..\..\extlibs\libs-mingw\x64\libjpeg.a -lwinmm -lgdi32 -lopengl32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
CMakeFiles\sfml-graphics.dir/objects.a(GLExtensions.cpp.obj):GLExtensions.cpp:(.text+0x21): undefined reference to `glewInit'
CMakeFiles\sfml-graphics.dir/objects.a(GLExtensions.cpp.obj):GLExtensions.cpp:(.text+0x43): undefined reference to `glewGetErrorString'
c:/MinGW/x86_64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles\sfml-graphics.dir/objects.a(GLExtensions.cpp.obj): bad reloc address 0x0 in section `.pdata'

I don't have GLEW installed separately from SFML (I usually do, but I installed SFML before GLEW this time), but this shouldn't be important since SFML ships with the "right" version of GLEW.

Is this issue MinGW x86_64 specific? How can I fix it without installing GLEW manually?

Cheers,
Aster

49
Window / Re: Alt-F4 not sending sf::Event::Closed to sf::Window
« on: July 17, 2014, 11:41:59 pm »
Alright. Just going to confirm that this bug does happen in Ubuntu 14.04 with Unity.

50
Window / Re: Alt-F4 not sending sf::Event::Closed to sf::Window
« on: July 17, 2014, 11:10:30 pm »
After going through every commit between now and April 25th, I think this may either be an issue with Linux that has never been noticed, or an issue with Arch because something is too bleeding-edge again.

51
Window / Re: Alt-F4 not sending sf::Event::Closed to sf::Window
« on: July 17, 2014, 09:35:45 pm »
Edit: note; my SFML build is a couple months old.

How old exactly? We could find the commit that broke it.

52
Window / Alt-F4 not sending sf::Event::Closed to sf::Window
« on: July 17, 2014, 09:10:58 pm »
Hi there.

Upon testing my game on Linux, as it has no menu yet, the only way to close it is using Alt-F4.
This method works perfectly fine on Windows with both fullscreen and windowed mode..
.. But on Linux, it only works in windowed mode. With fullscreen mode, Alt-F4 won't send the sf::Event::Closed event, and Alt-Tab won't change the window's focus.

I've tested this on Archlinux with GNOME 3, GNOME Classic, and XFCE.
I'm using SFML from latest git.


Here's some example code:
#include <SFML/OpenGL.hpp>
#include <SFML/Window.hpp>

int main()
{
        sf::Window window{sf::VideoMode::getDesktopMode(), "Whee", sf::Style::Fullscreen};

        while(window.isOpen())
        {
                sf::Event event;
                while(window.pollEvent(event))
                {
                        switch(event.type)
                        {
                        case sf::Event::Closed:
                                window.close();
                                break;
                        default:
                                break;
                        }
                }

                glClear(GL_COLOR_BUFFER_BIT);
                window.display();
        }

        return 0;
}

 

The OpenGL stuff (include, glClear and window.display()) is optional, but I put it in there so that you can clearly see the fullscreen window.
The only way for me to exit this program or return to my desktop is to switch to a different TTY and pkill it.


Any help is appreciated.
Cheers.

53
SFML projects / Re: Zombie survival multiplayer game
« on: July 16, 2014, 01:22:35 am »
This looks great! Graphics seem very polished and high-quality! Although I'm not so much of a fan of zombie games, I must say I'm looking forward to the outcome of this project. I can't wait for more recent screenshots.

Cheers

54
SFML projects / Re: C++ Bot
« on: April 29, 2014, 08:41:45 pm »
SFML's networking library really isn't suitable for using existing protocols, and writing this stuff in C++ is tedious and difficult. Use Python and its standard library for this kind of stuff. Assuming you can actually find out what the protocol is.

55
Feature requests / Re: Replace Xlib with XCB
« on: April 24, 2014, 08:11:09 am »
Right. I just hope it gets merged soon now that it's been brought up again.
I don't think clipboard support needs a forum thread again. I'll just finish up my PR, and it'll be discussed there. I guess.

56
Feature requests / Re: Replace Xlib with XCB
« on: April 24, 2014, 02:29:07 am »
Also, ignoring all the crazy feature requests on the forums, SFML doesn't get many new community-contributed features due to everyone being scared of working on it just to never have their PR accepted, or just getting a "no.". Or at least that's how I feel.

And then asking on the forums is mostly "we'll consider it" and "no.".
Hopefully the way SFML evolves will change along with our new SFML "task force". ;)

57
Feature requests / Re: Replace Xlib with XCB
« on: April 24, 2014, 02:24:57 am »
Clipboard support has been declined on and on again by the SFML dev(s), because it's "inappropriate". However, clipboard support requires access to the window handle on at least 2 of 3 major platforms, and all of SFML's competitors have it.

Now, as for XCB stuff, it doesn't really matter when it gets done, it's just something that should be done for the sake of SFML being more maintainable and easier to make evolve, as I'm sure clipboard support was mostly denied not because of it being "inappropriate", but because it's damned hard to do with Xlib. Also, XCB doesn't change anything from the user's point of view. In fact, it could just be ninja'd into SFML and nobody would notice.

Sorry for the passive aggressiveness. After almost a whole day of trying and way too much coffee, I might be a bit jumpy.

58
Feature requests / Replace Xlib with XCB
« on: April 24, 2014, 12:01:15 am »
So, I've been adding clipboard support to SFML, and Windows was trivial.

Then came Xlib.
Xlib is bad. It hasn't been updated in 12 years.
It's complicated, and slow, and makes you want to throw grapefruit at strangers.

But! XCB exists.
It's more up-to-date, doesn't suck as much.
It's still X, which is a downside.
But let's look at the bright side, it's already implemented, but this PR is a year old, and nothing has been decided.
It's probably out of date, but if the SFML dev team would should a glimmer of interest, I'm sure it would be updated in a single day.

SFML needs to be ported to XCB, it's a question of modern code, and it'll probably even be faster as such.
So yeah, SFML claims to be modern, but it uses a 12-year old, outdated backend.

(Also, newlines, newlines everywhere!)

59
Could you please provide a simple code example that reproduces the issue? Nobody wants to read through your messy code to find a bug that probably isn't even SFML's fault.

60
Feature requests / Re: Ostream operators << for SFML classes
« on: March 19, 2014, 07:00:01 pm »
Alright, I'm not going to quote everything, but..
I agree on the unintuitiveness of << with no >>.

The features added in SFML from GitHub often don't add anything major. (This is where you link me a single major feature as proof that I'm lying.)

SFML has sf::NonCopyable, why not make sf::Printable or similar?

And no, the purpose of the ostream<< operator is obviously not to debug SFML. I said it might make it easier.

Also, if I had the expertise required to fix some of those bugs, I would. But I don't, hence why I use something high-level such as SFML.

Pages: 1 2 3 [4] 5 6 ... 9
anything