Messages

1

General / Re: [WIN/NVidia] Context issues after context-refactoring

« on: December 12, 2016, 08:51:30 am »

Test failed See my comment on github.

2

General / Re: Mouse::isButtonPressed(Mouse::Left) vs (event.mouseButton.button == Mouse::Left)

« on: November 10, 2016, 07:58:50 am »

I also prefer using events and buffering them. Two reasons for that:
1) I don't need to waste any kind of CPU-time to get the current state. Some systems have quite some overhead to achieve this. The more state-checking I'd use, the more CPU-time I'd waste.
2) Using events and a buffer leads to a constant state while processing the current frame. State-checking might result in one key being pressed while processing the first half of my entities, not being pressed while processing the 2nd half or vice versa.

3

General / Re: "infinite" tilemap - please rate & help improve

« on: November 10, 2016, 07:24:42 am »

I want to note that by putting tiles right after one another, you might get filter-artefacts (aka texture bleeding) in case you will not render pixel-perfect from texture to screen. That means if you're slightly off-pixel with your offset or if you're rotating or scaling the sprites, the edges of them might show wrong colours due to the OpenGL-filter-algorithms also using neighbour-pixels to determine the source-colour. It often helps to either duplicate border-pixels as a save-guard or to offset your sprites a little bit (to create empty space between them) in combination with using premultiplied alpha-channels. The latter might cause darker borders instead of weirdly colours ones though.
If you're only using them pixel-perfect, all is fine. I just wanted to note it, because it's a common issue.

4

General / Re: [WIN/NVidia] Context issues after context-refactoring

« on: November 10, 2016, 06:42:21 am »

As such, people who say/threaten things like "I won't use your library unless you do things like other library X." just show how short-sighted some people have become.

Nobody said such a thing in this topic and thus it is unrelated.
However, if there's 3 developers using SFML being affected negatively by a change, there probably are more. And those end-users will be the ones causing negative feedback. If such feedback can be prevented, it should be. I believe you will agree with that stance, even if the fault is not lying on your side according to the specification.

I can't tell you why other open source projects have a similar implementation, but I can assume that's due to everyone looking at how the other libraries did it. This does not mean that's the state of the art used by stable games. For example: If you're gooling how to handle taking pictures with the camera on Android, you will find the very same implementation on lots of forums, apps and on stackoverflow. Each of them having at least 3 (!!!) critical issues of which 2 lead to crashes on certain phones and one leads to images being displayed upside down on some devices. Just because it's commonly used, it doesn't make it a stable implementation. Each of these crashing implementations however are valid if you read the docs (which are pretty bad at this point). Since there's so many different vendor-specifics, it's still flawed and needs various tweaks and fallbacks. If you don't have them, you'll get a shitstorm from the user-base about your bad camera-handling. I just don't want that to happen yet again, especially by knowing potential issues beforehand.

5

General / [WIN/NVidia] Context issues after context-refactoring

« on: November 09, 2016, 01:45:26 pm »

I have an issue with SFML since the commit about context-refactoring.

I get an error about failed context creation and other weird stuff (like invalid handle, etc) when using the git master SFML version. It all happens since the commit about removal of internal context-usage (creating context with gl version 0.0). It only appears on my Win7 HP Notebook using an NVidia Quadro 1000M (Driver version 8.17.12.7621). Using one commit earlier does not have any issues and runs just fine. I don't have the issue on other windows machines and by trying with Tank we noticed it's not related to the compiler being used either.
code:

#include <SFML/Audio.hpp>
#include <SFML/Graphics.hpp>

int main()
{
    // Errors happening in the following line (failed to deactivate, created version 0.0, failed to activate, failed to activate):
    sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window", 7, sf::ContextSettings(24, 8, 0, 2, 0));
    sf::Texture texture;


    // Errors also happening in the following line:
    if (!texture.loadFromFile("walls.png"))
        return EXIT_FAILURE;


    sf::Sprite sprite(texture);
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }
        window.clear();
        window.draw(sprite);
        window.display();
    }
    return EXIT_SUCCESS;
}

Error log (the first line says: "The handle is invalid"):

(click to show/hide)

I don't think I will be the only person having this issue and I find it rather critical, especially since SFML does work with the previous commit just fine.

6

Window / Re: [Android] Calling Window::create more than once causes blackscreens

« on: November 03, 2016, 11:25:36 am »

Bug/Issue-ticket?

7

Window / Re: [Android] Calling Window::create more than once causes blackscreens

« on: November 02, 2016, 07:14:39 am »

It's not a memory problem on my side. Even with a minimal sample, calling it more than once leads to the same issue.

8

Graphics / Re: Vertex strange stripes

« on: November 02, 2016, 07:10:11 am »

When zooming, even perfectly aligned vertices/polygons might show weirdly colored pixels at the edges between the polygons. That's due to the fact that the color from the texture needs to be interpolated and that's where filters will be used by OpenGL. Those can cause texture-bleeds (where pixels next to your source-area must be taken or at least incorporated into the final color). You can't solve this problem by overlapping your vertices and you shouldn't overlap them anyway. You need to fix your texture to not have areas which during sampling might take a totally different color (as it will happen if you just put different types of textures right next to one another in the same texture file).
tl;dr: Change your texture to prevent-texture bleeding, and don't do weird offset-stuff in your render-code.

9

Graphics / Re: SFML Project not rendering shapes

« on: November 02, 2016, 06:58:45 am »

I don't see why it doesn't render anything, but I still wanted to tell you that loading the font every time you want to draw something is not a good idea and wasting a lot of cpu time.

How did you create your window and assign it to "this->game->window"? Could you show this part of the code please?

10

Window / Re: [Android] Calling Window::create more than once causes blackscreens

« on: November 02, 2016, 06:46:52 am »

The questions is this one: Why would I need to change my code which works on windows (where it can actually make changes to the window) to be different on Android? Sure it doesn't make sense, but the program shouldn't go black and be unrecoverable. That's just bad behaviour for a library. If it should not make any sense to call it multiple times on Android, shouldn't SFML take care of not doing anything at the 2nd call instead?

On iOS is also makes no sense to change the window properties, but on iOS calling it more than once isn't a problem at all and works just fine.

11

Window / [Android] Calling Window::create more than once causes blackscreens

« on: November 01, 2016, 03:05:51 pm »

As the title says. In case you're calling window.create() more than once on Android, the screen goes black and that's it. Even when calling it on the same window-instance!

12

General discussions / Re: Experimental internal-context-less branch

« on: November 01, 2016, 01:40:44 pm »

Having the same issue on Windows too since this merge (the issue of glLoadGen being broken, not the issue of missing context). However, the workaround  of using a RenderTexture does not help. glLoadGen returns only 0 on Windows. That's true for gl::MAX_TEXTURE_SIZE, gl::VERSION and gl::EXTENSIONS.

I'm having the very same issues using the default gl-Implementations (meaning not glLoadGen, but simply importing SFML/OpenGL.hpp) like "glGetString" or "glGetIntegerv". Does the provided SFML-OpenGL-example still work?
I'm getting this on Windows:
Failed to activate the window's context
Failed to create texture, its internal size is too high (20x20, maximum is 0x0)
Failed to create texture, its internal size is too high (2048x2048, maximum is 0x0)

    sf::RenderWindow m_screen;
    m_screen.create(sf::VideoMode(width, height, 32), "...", sf::Style::Fullscreen);
    m_screen.setActive(true);

    sf::RenderTexture rt;
    rt.create(20, 20, false);
    sf::Texture t;
    t.loadFromFile(filePath);

Is there any minimal example how to successfully use glLoadGen after this feature had been implemented? Or is SFML only broken for me?

13

Graphics / Re: [Android] called unimplemented OpenGL ES API - GLEXT_glBlendEquation

« on: October 11, 2016, 02:20:15 pm »

Well, I now know this method isn't implemented, but since this is deeply inside the SFML core, I can only decide to either not render using any custom blendmode or keep getting the log spammed with errors.
For now I made a custom patch to disable this on Android, but I'd prefer a generic solution on SFML's side by checking the extension string (GL_ARB_imaging) to exist. However, the GL ES implementation of SFML doesn't do any dynamic extension checking at all and I don't know why this is the case - it simply imports everything and pretends the functions to always be fully implemented.

14

Graphics / Re: White box glitch when creating multiple objects in a loop

« on: October 11, 2016, 06:43:51 am »

Don't store or return sf::Texture by value. This will cause them to be copied whenever you copy the parent object or return them from your function. A copy will cause the original sprite to reference an invalid texture. You can be glad this only leads to white boxes instead of crashing your application entirely.

15

Graphics / [Android] called unimplemented OpenGL ES API - GLEXT_glBlendEquation

« on: October 10, 2016, 10:28:18 am »

When setting a specific blendmode to render a sprite, I'm getting the following log-output on Android:

10-10 10:24:50.364: E/libEGL(18856): called unimplemented OpenGL ES API

target.draw(sprite, sf::BlendMode(sf::BlendMode::One, sf::BlendMode::OneMinusSrcAlpha));

When drawing it without a specific blend-mode, all is fine.

I can trace it down to this line in RenderTarget.cpp:

glCheck(GLEXT_glBlendEquation(equationToGlConstant(mode.colorEquation)));

Latest SFML master git version. Android 4.3 Samsung Galaxy S3.