Messages

1

Window / Re: Detecting keypresses on Mac OSX Catalina

« on: January 23, 2023, 02:27:04 am »

Arrow keys work just fine with events. Make sure your modifier detection code isn't consuming the event before it hits your other key event handling.

I can't see any way that that could be the case. My main loop is literally this (the parameter is passed by reference):

while(window.pollEvent(currentEvent)) handle_one_event(currentEvent);
 

And just to test if maybe you were right, I added this as the very first thing in handle_one_event, before my modifier detection code (which does swallow some key events):

if(event.type == sf::Event::KeyReleased) {
        std::cout << "A key was released!\n";
}
 

And I see the message if I press and release a modifier key, but not if I press and release any other key.

That said, I tried opening up a different project and it works in that project, so there must be something I'm doing somewhere that makes it stop working…

One thing to also keep in mind, since you used the words "chords", that many (cheap) keyboards can't handle more than 3-4 key presses at a time, usually depending on certain blocks of keys.
You'd need to have a keyboard n-key-rollover support, if you want to not have such a limitation.

That shouldn't be a problem, I'm only looking for 2 arrows at a time.

2

Window / Re: Detecting keypresses on Mac OSX Catalina

« on: January 22, 2023, 01:48:15 am »

Ctrl and Alt also generate key events. You can track the state of the keys (key pressed/released) with variables and look it up during a click event.

This works perfectly for the modifier keys. However, it turns out I also need to detect chords composed of arrow keys, yet for some reason no other key besides the modifiers ever sends a KeyReleased event. Am I doing something wrong?

3

Window / Re: Detecting keypresses on Mac OSX Catalina

« on: January 13, 2023, 02:13:16 am »

Ctrl and Alt also generate key events. You can track the state of the keys (key pressed/released) with variables and look it up during a click event.

So that's really the only way, is it?

It would be great if a future version added modifiers to the mouse events though, to support this use-case. Apparently the underlying Cocoa events already contain that information. (No idea about the equivalent on other operating systems though.)

The monitoring permission request is a security feature of macOS and nothing we can or should be able to workaround. With isKeyPressed you can get key inputs from any application, thus essentially building a key logger, which is why macOS decided to require monitoring permission for that part of the API.

I get that theoretically that could be used in such a way, but I think it could've been built in a way that didn't trigger the monitoring permission… even if it meant doing exactly what you just said internally to SFML.

Still, perhaps if mouse modifiers were supported, there would no longer be any need to use isKeyPressed.

4

Window / Detecting keypresses on Mac OSX Catalina

« on: January 12, 2023, 03:27:40 pm »

I'm having issues with detecting certain keypresses when building on Mac OSX Catalina. The system seems to think that the application wants to be able to monitor input while in the background, which isn't even true.

According to another post I found on this forum (quoted below), it's caused by using IsKeyPressed, and the solution is to use events. But that's not possible – I'm trying to do is handle modified mouse clicks (eg, Alt+Click) and scroll wheel (eg, Ctrl+Wheel). The MouseButtonEvent does not have a modifier key field, so the only option is to manually check for the modifier. The same applies to the scroll event.

I know for certain that other apps can handle modified mouse clicks and scroll wheel without needing to register for input monitoring in System Preferences, so why is it that there's no way to do this in SFML? If IsKeyPressed does not work, what other options are there? Perhaps the Mac implementation of IsKeyPressed is incorrect.

If you actually use events and not real-time input (sf::Keyboard::IsKeyPressed), then things should work fine.

For real-time input you will have to grant the app input monitoring privileges as far as I know, that's one of the major changes in Catalina for all applications.
There are ways to disable some stuff for developers, but as I am not a macOS user, I don't really know and would need to research myself.

EDIT: Based on the contents of the framework package, I appear to be using version 2.5.1.

5

Window / Re: Working with multiple monitors

« on: September 09, 2017, 04:58:55 am »

I see. I guess I'll have to either wait or use OS-specific routines for it. I don't suppose there's any plans to implement this?

6

Window / Working with multiple monitors

« on: September 03, 2017, 03:44:12 am »

Is there any way to distinguish between the main monitor and secondary monitors? I have a fullscreen mode which calls getDesktopMode() to determine the size of the screen and resizes the window to fit it; however, it always uses only the size of the main monitor. I'd like it to take the size of whichever monitor the window currently resides on (based on the window's origin). Can this be done in SFML?

7

Window / Re: Splash screen not showing

« on: April 08, 2014, 03:12:03 am »

Anyway, I got it to work with what feels like a hack

What about solving it properly? That is, draw it as long as it lives, not 10 times (what kind of magic number is that?!) and have an empty event polling loop.

10 was pretty much a random number. "As long as it lives" is roughly "until the sound finishes playing", so I might look into doing it properly later, but for now all I'm concerned with is that it works. At the moment I have other more important issues to focus on.

8

Window / Re: Splash screen not showing

« on: April 07, 2014, 05:30:24 pm »

That still seems very counterintuitive.

Anyway, I got it to work with what feels like a hack — loop the lines drawing the first splash 10 times and add an extraneous pollEvent() to that loop, and everything suddenly works perfectly. It doesn't make sense that I should need to draw the exact same thing 10 times for it to work (simply adding a pollEvent() without looping didn't help), but whatever. At least it works.

9

Window / Re: Splash screen not showing

« on: April 07, 2014, 04:56:04 pm »

You must handle events, even if you don't care for input. This is required or the OS will mark your process as unresponsive and window manager will most likely ask the user if they want to end the unresponsive process.

I know the OS does this, but this is still during the initialization process. Normally you don't start handling events until after initialization is finished, right?

10

Window / Re: Splash screen not showing

« on: April 07, 2014, 04:50:47 pm »

Are you trying to say the window only updates if you're handling events?

Yes, you must handle events to keep the window responsive.

Keeping it responsive implies I want the window to respond to input, which at this point isn't the case. Do you have to handle events even just for the window to be displayed?

As for clear(), I'm pretty sure you don't need to call it. Other stuff seems to be working perfectly fine without ever calling it.

EDIT: That said, this is a perfect situation for calling it, since I just want to fill the screen with black. (I actually forgot it existed.)

11

Window / Re: Splash screen not showing

« on: April 07, 2014, 04:35:51 pm »

Uh, I did draw something. I called both the draw() and the display() functions. How does this not count as drawing something?

Like every other window, a splash screen must also be updated. Handle events and adhere to the usual clear/draw/display cycle.

Are you trying to say the window only updates if you're handling events? That seems odd.

12

Window / Splash screen not showing

« on: April 07, 2014, 09:26:24 am »

I'm trying to create a splash screen on startup, but it seems that calling window.display() isn't sufficient to make the contents of the window instantly visible, for some reason. My procedure can be summed up as follows:

• Fill the window with black (using a RectangleShape)
• Load the splash screen into a texture.
• Create a Sprite and draw it centred in the window.
• Call display() on the window.
• Play the sound. (This is the only part that works perfectly.)
• Institute some sort of delay.
• Repeat all the above steps a second time.

I actually have two problems; the main problem is that nothing shows up until the main event loop, by which point the splash screen has been erased; also, I'm unsure how to create the sort of delay where pressing a key ends it prematurely.

I'm not sure what portion of the code would be best to post here. It uses several utility functions, so simply copy-pasting the splash code would probably not be very instructive. The window does get created prior to the splash code, incidentally.

Stepping through the code in the debugger hasn't helped much, although somehow I'm sometimes able to see the second splash screen when I set certain breakpoints and hop between them with F9 (continue). With breakpoints disabled, this never seems to happen.

Any ideas? Or requests for particular parts of the code?

13

Graphics / Re: Tesselations (texture issue)

« on: April 07, 2014, 08:15:11 am »

This is the expected behaviour, please read the documentation. To repeat a texture you must call texture.setRepeated(true) and use a textureRect bigger than the texture itself. Yes, it implies that you can only repeat the whole texture, not a sub-rectangle of it.

Alright, thanks for that info; I was wondering if that might be an issue. I guess I'll have to copy the desired portion to a new texture and repeat that.

for some reason RenderTexture doesn't have a setActive function

It does.

Oh, it must've been that RenderTarget doesn't have one, then.

Anyways regarding your issue, why don't you simply use SFML functions? If the whole texture should get repeated you could set texture repeat and adjust the texture rect. If it's only part you could simply generate a vertex array that uses the texture.

Um, I am using SFML functions. The stuff with GL_SCISSOR isn't directly related to the tiling; it just ensures that the tessellation is clipped to the intended area (since the actual area drawn two will, in general, be larger than the area I want to fill in order to ensure that the tiling always lines up the top left of the texture with the top left of the window).

14

Graphics / Tesselations (texture issue)

« on: April 06, 2014, 11:43:05 pm »

I'm trying to tile an image across an area, but instead of tiling, the image is stretching to fill the area.

The tiling function is as follows:

Code: [Select]

void tileImage(sf::RenderTarget& target, RECT area, sf::Texture& img, RECT srcRect, sf::BlendMode mode){
img.setRepeated(true);
sf::Vector2u imgSz = img.getSize();
area.left -= area.left % imgSz.x;
area.top -= area.top % imgSz.y;

sf::RectangleShape tessel(sf::Vector2f(area.width(),area.height()));
tessel.setTexture(&img);
tessel.setTextureRect(srcRect);
tessel.setPosition(area.left, area.top);
sf::RenderStates renderMode(mode);
setActiveRenderTarget(target);
glEnable(GL_SCISSOR_TEST);
glScissor(area.left, area.top, area.width(), area.height());
target.draw(tessel, renderMode);
glDisable(GL_SCISSOR_TEST);
}
The texture that's passed in contains several images of which I only want to tile one, that contained in the rectangle "srcRect". The rectangle "area" is the area in which the image should be tiled. The setActiveRenderTarget call just calls target.setActive() if target is a RenderWindow, because for some reason RenderTexture doesn't have a setActive function (which makes me wonder if this'll work on a RenderTexture, but I'll get to that later).

I'm hoping I'm just missing something obvious here. I know roughly what needs to happen (the texture should be drawn with normalized texture coordinates > 1), but I'm not sure what I've missed in trying to get SFML to do this. Will I need to copy the portion I want to repeat into a new texture?

15

System / Re: Problems with making my own InputStream

« on: November 18, 2013, 10:37:43 pm »

Ah, okay, that makes sense. Still, I think the point was that compressing the file and stripping all signs that it's a compressed file would do a far better job of obfuscating its contents than XORing the contents with a constant.