Messages

16

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

« on: October 10, 2016, 08:30:30 am »

OK, so, since this is live now, I'm getting the following log-output when creating a simple RenderWindow on Android:

E/libEGL(2065): call to OpenGL ES API with no current context (logged once per thread)

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

If I afterwards try to use glLoadGen, I get no valid return values from the calls (glGetError always returns 0, glGetString(GL_VERSION) returns 0, glGetIntegerv(GL_MAJOR_VERSION, &v) writes nothing to v, etc):

    sf::RenderWindow m_screen;
    m_screen.create(sf::VideoMode(width, height, 32), "...", sf::Style::Fullscreen);
    m_screen.setActive(true);
    gl::sys::LoadFunctions();
    int maxTextureSize = 0;
    gl::GetIntegerv(gl::MAX_TEXTURE_SIZE, &maxTextureSize);

If, however, I create a RenderTexture after creating the window and before using glLoadGen, glLoadGen works properly, but I'm still getting the error log about missing GL-context. Looks like there's something broken now.

17

Window / Re: [Mac] Fullscreen modes not scaled to screen size

« on: June 27, 2016, 03:39:17 pm »

Well, I am not in the position to decide what needs to be done.

The possible solutions are:
1) A soft-switch (as currently) which actually incorporates the entire screen and doesn't care about aspect-ratio
2) A soft-switch (as currently) which actually incorporates the entire screen and does letter-boxing
3) A hard-switch
4) A combination of all the other three, up to the developer to chose from
Personally I prefer (1) or (3) as (2) is something the user needs to implement himself also on all other platforms if not using a native aspect-ratio and therefor it's not a business of SFML. Version (3) gives a damn on Apples guideline (or doesn't, depending on how you want to read/interpret them). Version (1) would work quite closely to the current implementation, but it would actually use the entire screen. Version (2) would give the user/programmer an unexpected result since that is not what happens on Linux or Windows iirc. The resulting solution should of course be consistent to the other OS-specific behaviours.

I could possibly implement it myself and make a PR, but that would be useless until there's a decision made by the SFML-team on which solution is the desired one. (4) is not something I might be willed to invest my time in as it would be too much time-consuming.

18

Window / Re: Way to NOT pass reference to RenderWindow to a class?

« on: June 27, 2016, 12:51:05 pm »

You might consider only passing a RenderTarget& instead of a RenderWindow&.

19

Window / Re: [Mac] Fullscreen modes not scaled to screen size

« on: June 27, 2016, 12:40:39 pm »

Don't get me wrong, but the topic and reason for the behaviour on OS X had been discussed long enough. I know you're only trying to help, but posting things about how they work on a different system, are practically not helpful. I am glad you did revive this necro-thread though, it probably still has not been changed. Has it?
The worst thing that could happen is that the thread gets closed with: "Works for me. 6Dragon6 has proven so" - although the problem still remains. Just because someone didn't read the topic in it's entirety. I want to prevent an upcoming of the idea that there is no problem on OS X at all and I'm just not clever enough to set a proper view. But it's not related to views at all.

20

Window / Re: [Mac] Fullscreen modes not scaled to screen size

« on: June 27, 2016, 06:32:50 am »

Windows and OS X behave different. No matter if I apply a proper view (which I'm doing) or not. Please stop discussing until you have it running with OS X. You're not helping at the moment. It works fine on Windows, Linux, Android and iOS. It does not on OS X.

21

Window / Re: [Mac] Fullscreen modes not scaled to screen size

« on: June 26, 2016, 11:09:11 pm »

No, it doesn't work. Because on OS X, the window does not fill the entire screen. The view is unimportant here. The code fills the remaining area with black. See the screenshots I had attached in my first post.

22

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

« on: January 15, 2016, 12:33:31 pm »

No. Such an example would require external dependencies to glLoadGen, etc.. I still don't know to handle it on my side though, I just picked glLoadGen in the past and it used to work, whereas now it doesn't. There probably indeed isn't a proper context active or something, but I can't tell.

23

General discussions / Re: Android and iOS ports available for testing

« on: December 04, 2015, 05:30:56 pm »

Does this work on other platforms? Because I'd say a Vertex itself isn't actually drawable.

24

General discussions / Re: Android and iOS ports available for testing

« on: November 30, 2015, 08:35:56 pm »

Jup, I'm using the branch Mario mentioned to grab the AssetManager and extract my files.

25

General discussions / Re: Android and iOS ports available for testing

« on: November 30, 2015, 02:51:20 pm »

Afaik there's no "native" way of getting the apk structure. The NDK doesn't offer any class or method for that. You could use a zip-lib (also provided by the NDK) to explore the archieve. Or use a Java-call.
The Asset-Manager and Asset-Dir classes in the NDK only provide access to a file you already know the path of.
I just did exactly that recently (unpack a multi-layer deep asset-folder from the APK), so I'm pretty sure that's the only way (Java or zip-lib). It's easy to find a native snippet of using the Asset Manager to unpack a known directory or file though. There's various samples.

26

General discussions / Re: Android and iOS ports available for testing

« on: November 26, 2015, 10:43:28 pm »

There are tutorials how to build them and there are sample applications. Except an announcement, it can't really get much more official than that.

27

General / Re: Rotating player depending on the mouse position

« on: November 23, 2015, 07:46:47 pm »

Shouldn't that be atan instead of tan? And are you sure you have to operate with angles in radians instead of degrees?

28

Graphics / Re: Problems using textures in classes

« on: November 23, 2015, 07:36:47 pm »

Did you use a debugger to narrow down the line in which the error occurs (stacktrace, where it gets called from)?

Apart of that, I'm not sure you should use an sf::Texture as a value-member of your enemy class. It will get loaded multiple times redundantly and if you're not careful, it will get copied, which is bad for performance and memory footprint.

29

Graphics / Re: Is there a way to combine (add) sprites?

« on: November 15, 2015, 08:47:11 am »

Any way to achieve this (other than duplicating all my sprite sheets and adding a fire on the copies)?

Actually this. You can do that also via code at runtime (by using Images or RenderTextures), but I think you should consider refactoring your code. I also had such a one-sprite-approach (actually a one-bounding-box return). It didn't work out. I had to expand to return multiple. It's the far more flexible approach though. Everything else looks like dirty workarounds. As you already see now.

30

Graphics / Re: I have been toying with sprites and textures and found an oddity

« on: November 14, 2015, 07:21:52 pm »

Rotating a 150x120 sprite by 90° results in a 120x150 bounding box. That is totally logical.