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 - j.keller51

Pages: [1] 2
1
Graphics / Re: Possible issue with Apple M1 processor
« on: February 04, 2021, 06:07:09 pm »
^ An addendum -- I had manually changed the build architecture through Xcode to arm64 and it worked without changing any source.

However, I wanted CMake to set the architecture automatically, so I set CMAKE_OSX_ARCHITECTURES to "x86_64;arm64". However, SFML's CMakeLists.txt is hardcoded to reject anything that is not x86_64 on Mac.

I made an issue for this:

https://github.com/SFML/SFML/issues/1749

For the time being, I just commented out the architecture check in the SFML CMakeLists in my local copy.

2
Graphics / Re: Possible issue with Apple M1 processor
« on: February 04, 2021, 04:04:20 pm »
It does indeed! No changes to the source were required.

3
Graphics / Re: Possible issue with Apple M1 processor
« on: February 04, 2021, 02:54:38 am »
I can confirm that the issue does not lie with SFML.

The max antialiasing level on M1 chips is 4, and my code was set to use 8. When I changed it to 4, all RenderTextures worked again (still compiled for x86_64 and run through Rosetta).

I went a step further and compiled my project for arm64 and it runs natively on the M1 flawlessly.

4
Graphics / Possible issue with Apple M1 processor
« on: December 18, 2020, 10:38:17 pm »
I'm not making an issue for this yet because I don't have access to a computer with Apple's new M1 processor, so I can't confirm 100% if the issue lies with SFML or not. But just something to keep an eye out for:

Users of my application on M1 are not seeing any graphics that are being drawn to an sf::RenderTexture. Everything drawn directly to the window seems to be working fine.

5
Graphics / Re: macOS Texture::update -> glTexSubImage2D crash
« on: October 14, 2020, 07:56:46 pm »
I'm finding that there are some other SFML functions that need to be wrapped by sf::RenderWindow::pushGLStates() and sf::RenderWindow::popGLStates() as well, even though on the surface they don't appear to be "drawing" functions.

For example, functions like sf::Texture::loadFrom____(), which internally end up doing some OpenGL calls (and in my case, crash FL Studio). So it's not just <object>.draw() calls that need to be protected.

6
Graphics / Re: macOS Texture::update -> glTexSubImage2D crash
« on: October 14, 2020, 07:38:41 pm »
eXpl0it3r and I moved to DMs to troubleshoot this issue, in part because the code I am working with has some proprietary elements.

And important detail, and something I failed to mention in the OP, is that my SFML code is compiled in a shared library plugin that is called on and created inside of a host UI. Specifically, my plugin is a vst3 audio plugin that runs inside of digital audio workstations, and the host in this case was FL Studio.

It seems that FL Studio is using OpenGL for its UI, just like SFML. This is causing conflicts in the OpenGL state. So even though my code itself is not using OpenGL, I still need to save and restore the state as described here: https://www.sfml-dev.org/tutorials/2.5/window-opengl.php#using-opengl-together-with-the-graphics-module

When using sf::RenderWindow::pushGLStates() and sf::RenderWindow::popGLStates() around my drawing code, the crashing went away.

One final question: the documentation says that these functions can be quite expensive. Is that something I should worry about? E.g. maybe I only push/pop GL states in certain DAWs that are known to use OpenGL and cause issues.

Since I have no control or knowledge of the DAW's OpenGL usage, I can't optimize which states to save, so that seems to be off the table.

7
Graphics / Re: macOS Texture::update -> glTexSubImage2D crash
« on: September 21, 2020, 04:57:25 pm »
In other words, let me know if you have the time and are willing to follow me down the example project rabbit hole and I will oblige. It will involve some time from both of us though.

8
Graphics / Re: macOS Texture::update -> glTexSubImage2D crash
« on: September 21, 2020, 04:55:33 pm »
Call stack:
sf::Texture::update(const Uint8* pixels, unsigned int width, unsigned int height, unsigned int x, unsigned int y)
sf::Texture::update(sf::Image const&)
sf::Texture::loadFromImage(const Image& image, const IntRect& area)
sf::Texture::loadFromFile(const std::string& filename, const IntRect& area)
<< My code generating the filename string and calling sf::Texture::loadFromFile with only the 1st argument >>

As for a minimal example, I'd be happy to set one up. But I can almost guarantee that in this case, "minimal" will still require a few steps for another tester to reproduce the issue. I do know that it is reproducible on other MacOS catalina computers, though I am not sure about other macOS versions.

9
Graphics / macOS Texture::update -> glTexSubImage2D crash
« on: September 17, 2020, 09:22:09 pm »
Hi,

I'm experiencing a crash in Texture::update. It happens on the line:

glCheck(glTexSubImage2D(GL_TEXTURE_2D, 0, x, y, width, height, GL_RGBA, GL_UNSIGNED_BYTE, pixels));

I am on MacOS 10.15.6 using SFML 2.5.1, self-built with CMake.

The crash is due to EXC_BAD_ACCESS.

Here's where it gets weird.

The image dimensions are 1403 x 132. Since each pixel is 4 bytes, we have a total data size of 740784 bytes. When debugging, the size of Texture::m_pixels is exactly 740784 bytes.

Inside Texture::update(), const Uint8* pixels is a valid pointer to the start of Texture::m_pixels's internal buffer.

However the bad access crash is telling me it was trying to access a memory location 741376 bytes past pixels. It's over-reading by 592 bytes for some reason.

Just to confirm the input arguments once more:
x = 0
y = 0
width = 1403
height = 132

I don't know anything about OpenGL but it doesn't make sense to me that it is reading more data than width * height * 4. Could another application be interfering somehow?

Thanks

10
Window / SFML as a subview
« on: August 13, 2020, 04:56:20 pm »
I'm using SFML in a plug-in environment, e.g. a host application gives me a window and I have to make the SFML window a child of that window.

In Windows, this "just works" and I haven't had issues.

On OSX, I've had to make a couple of patches:

1. Resizing
I encountered weird behavior where the drawing area was resized incorrectly while "live resizing" the NSWindow.

If the window width before the resize operation began was x, and the current window width while resizing is x' = x + dx, then you would expect the SFML drawing width to also be x' = x + dx. Instead, it is x + 2*dx. This applies for expanding and contracting the window. The same applies for the y axis.

Illustration of this:


Weirdly, when contracting, the empty area is filled by the SFML window's background color, whatever that is set to.

As soon as the mouse is released, the SFML drawing area snaps back to the correct size.

The fix I came up with was, in src/SFML/Window/OSX/SFOpenGLView.mm:

Change
-(void)update
{
    // In order to prevent an infinite recursion when the window/view is
    // resized to zero-height/width, we ignore update event when resizing.
    if (![self inLiveResize]) {
        [super update];
    }
}

to
-(void)update
{
    [super update];
}
 

This made the window resizing behave as expected.

Obviously, the inLiveResize check was supposed to be doing something important, so maybe just taking it out isn't a good long-term solution. Thoughts?

2. Crash when deconstructing sf::RenderWindow
When the parent window is closed, I deconstruct the sf::RenderWindow also. Internally, this calls sf::RenderWindow::close(), which prints a warning about how closing a subview is not valid, and then crashes in WindowImplCocoa::~WindowImplCocoa() on line 159: drainThreadPool().

At a total loss due to not having much experience in MacOS/Obj-C coding, I simply commented out drainThreadPool() and the crash stopped. However I suspect this will create a memory leak.

---

I know that SFML is primarily used for games, operating in its own window that it controls, so this might seem like an edge case, but it might be worth considering testing and handling situations like these to make the library more versatile. I really do enjoy SFML.

11
Window / Legacy MacOS OpenGL Freeze
« on: February 04, 2020, 05:15:49 pm »
Hi,

I've been working on an app that I want to be available for older MacOS versions. On MacOS 10.10, this very simple code causes the window to totally freeze up (MacOS shows the spinner icon) when the mouse hovers over it. As soon as the mouse leaves the window, it resumes rendering.

int main() {
    sf::RenderWindow window(sf::VideoMode(800,600), "Test Window");
   
    while (window.isOpen()) {
        sf::Event event;
        while (window.pollEvent(event)) {
            if (event.type == sf::Event::Closed)
                window.close();
        }
       
        window.clear(sf::Color::Black);
       
        sf::CircleShape circ(50);
        circ.setOutlineColor(sf::Color::Red);
        circ.setOutlineThickness(10);
        circ.setFillColor(sf::Color::Blue);
        circ.setPosition(50, 50);
        window.draw(circ);
       
        window.display();
       
       
    }
    return 0;
}

Here is the MacOS spin report:

Quote
Date/Time:       2020-02-04 07:48:19 -0800
OS Version:      10.10.5 (Build 14F27)
Architecture:    x86_64
Report Version:  21

Command:         Zivix Graphics Playground
Path:            /Users/USER/Downloads/ZivixGraphicsPlayground-30.app/Contents/MacOS/ZivixGraphicsPlayground
Version:         ??? ()
PID:             908

Event:           timeout-lite
Duration:        10.00s (process was unresponsive for 2 seconds before sampling)
Steps:           101 (100ms sampling interval)

Hardware model:  MacBookPro11,3
Active cpus:     4


Heaviest stack for the main thread of the target process:
  101  start + 1 (libdyld.dylib + 13769) [0x7fff930fc5c9]
  101  main + 685 (ZivixGraphicsPlayground + 19197) [0x100114afd]
  101  sf::Window::display() + 60 (ZivixGraphicsPlayground + 626988) [0x1001a912c]
  101  sf::priv::SFContext::display() + 33 (ZivixGraphicsPlayground + 555041) [0x100197821]
  101  -[NSOpenGLContext flushBuffer] + 27 (AppKit + 3354155) [0x7fff99a52e2b]
  101  CGLFlushDrawable + 66 (OpenGL + 53178) [0x7fff921fefba]
  101  glSwap_Exec + 97 (GLEngine + 119089) [0x7fff98c3d131]
  101  glsFlushDrawBufferIsBackingStore + 307 (GLRendererFloat + 76058) [0x7fff9819e91a]
  101  CGSLockWindowBits + 34 (CoreGraphics + 1337281) [0x7fff8ec237c1]
  101  CGSLockWindowRectBits + 72 (CoreGraphics + 1336943) [0x7fff8ec2366f]
  101  lock_window_backing + 910 (CoreGraphics + 279119) [0x7fff8eb2124f]
  101  CGSWindowSynchronizeBacking + 40 (CoreGraphics + 279926) [0x7fff8eb21576]
  101  _CGSSynchronizeWindowBackingStore + 110 (CoreGraphics + 536520) [0x7fff8eb5ffc8]
  101  mach_msg_trap + 10 (libsystem_kernel.dylib + 70878) [0x7fff8d41d4de]
 *101  ipc_mqueue_receive_continue + 0 (kernel + 1144832) [0xffffff8000317800]

It seems to have something to do with NSOpenGLContext::flushBuffer, though my googling didn't turn up anything very helpful.

Any suggestions are much appreciated!

Thanks,
Jon

12
Window / Re: Legacy MacOS NSOpenGLPixelFormat failure and fix
« on: February 04, 2020, 03:59:25 pm »
I don't have access to push a branch to the git repo. I'll open an issue.

Thanks

13
Window / Legacy MacOS NSOpenGLPixelFormat failure and fix
« on: February 03, 2020, 06:54:32 pm »
Hi,

I'm building an app with SFML and we are targeting older versions of MacOS (back to 10.10). However, using SFML to create the window crashes or hangs in MacOS 10.10.

It seems to be caused by this line:

SFContext.mm
NSOpenGLPixelFormat* pixFmt = [[NSOpenGLPixelFormat alloc] initWithAttributes:&attrs[0]];

pixFmt returns nill which causes the function to return without setting m_context, which is still uninitialized, and then other code tries to use it.

Through more investigation, I found that if I changed this line:

attrs.push_back(NSOpenGLPFAAccelerated);

to

if (@available(macOS 10.14, *))
    attrs.push_back(NSOpenGLPFAAccelerated);

The window opens and draws my objects correctly on 10.10.

I don't know anything about OpenGL, but this test suggests to me that hardware acceleration for antialiasing wasn't supported in earlier versions of MacOS. Can somebody who is more familiar with OpenGL or MacOS comment? And, should this be a patch in future versions of SFML?

14
General discussions / MacOS 10.15 Keyboard Permissions
« on: October 31, 2019, 06:07:13 pm »
Hi,

My Mac computer recently updated to the new MacOS 10.15 Catalina. sf::Keyboard::isKeyPressed() no longer returns anything but false, and this error pops up in the console the first time I do a call to isKeyPressed() for a key:

Quote
2019-10-31 11:43:35.409526-0500 <appname>[63159:1973539] [default] 0x100017a54: TCC deny IOHIDDeviceOpen
We got a keyboard without any keys (1)

From a cursory google search, TCC deny IOHIDDeviceOpen is something other developers are seeing when their app tries to get global keyboard access (i.e. seeing key presses even when the app doesn't have focus). It seems that the app has to request keyboard permission if it wants this kind of access.

Is there a built-in window-based keyboard state check in SFML? For example, I'm still receiving keyPressed and keyReleased events, so I could implement my own keyboard class that uses these to update its own state, but this seems like something that should be in SFML already.

Thanks.
Jon

15
General discussions / MacOS SDK 10.15 Crash
« on: October 25, 2019, 04:16:59 pm »
Hi,

I updated XCode to 11.1 yesterday, which replaced the MacOS 10.14 SDK with 10.15. When I got things to compile again, this code caused a crash in renderWindow.create():

Quote
int main () {
   
    sf::Window window;
    window.create(sf::VideoMode(800,600), "My Window");
    sf::RenderWindow renderWindow;
    renderWindow.create(window.getSystemHandle());
   
    while (window.isOpen()) {
        sf::Event event;
        while (window.pollEvent(event)) {
            if (event.type == sf::Event::Closed)
                window.close();
        }
    }
   
    return 0;
}

Please note that this is a stripped down example of a much larger and more complex program, made to illustrate the crash. That is to say, there is a reason for the Window/RenderWindow dichotomy, but it's not relevant here.

I found the 10.14 SDK online, downloaded it and switched my project back to 10.14, and now everything runs as it should.

Pages: [1] 2