Messages

1

Window / memory leak from accessing iOS sensor data?

« on: February 28, 2016, 10:37:16 pm »

Running on an iOS device with one or more sensors enabled (via SensorManager::setEnabled()), seems there's about a .1MB/s leak in memory (with around 60 FPS). Anybody else see this?

Playing with the Objective-C code in SensorImpl.mm, if I wrap accesses of the motionManager properties within autorelease pool blocks, then memory doesn't appear to leak anymore. I noticed too that SFML is building with ARC disabled. That seems out-of-favor these days (in favor of using ARC). I couldn't get toggling of ARC use to avoid the leak however.

2

Feature requests / Re: Window-moved events

« on: January 30, 2016, 08:27:28 pm »

Hi Hapax,

I do believe that the SFML events framework could be expanded to handle window movement and that this would be attractive even if only a single movement event was generated at the end of the window being moved.

As mentioned, I did work around not having window movements handled through the Event mechanism and I did it similarly to the code you'd linked. So my post isn't about whether window movements can be handled at all, but whether the SFML Event code (and paradigm) should be expanded to include window movements as events also.

Under Mac OS X (at least in the release I'm running), window repositioning isn't detectable through the Window::getPosition() method until after movement has stopped (whether by pausing a mouse drag or by releasing it). This sounds similar at least to what Laurant describes is the behavior under Windows.

I don't see the lack of detectability of intermediate movements as a strong enough argument against including window movement in the SFML events code. I do however see this behavior as worthy of documenting with verbiage like:

Note: event generation is operating environment dependent. Some platforms have sensors for which sensor events can be handled while others do not. Other events may have similar dependencies.

3

General discussions / Re: iOS Port, news?

« on: January 30, 2016, 07:41:07 pm »

I have the iOS port working. At least on the OS X simulator for iPhone 4 and iPhone 5.

Ran into linker problems with the weak linkage and the sfmlMain mechanism. That may be a clang specific issue. Not sure. Worked around it for the moment by changing the SFML code to do away with the weak linkage mechanism. Seems like there will be better ways to get it working but at least that's working for me right now.

4

General / Re: Would like to port windows game to iOS

« on: January 18, 2016, 02:28:37 pm »

I attempt to compile the code, however I get an error

In GIContext.cpp I get 5 different "parse issue"

Each saying that "Unknown type name 'ContextType'

I've run into this also. Have you figured out the problem?

Looking at SFML/sfml-window/GlContext.cpp it looks like SFML_OPENGL_ES needs to be defined in order for the SFML_SYSTEM_IOS conditional code to be reached and ContextType to get defined (for iOS). I went back to my cmake-gui window under the SFML options and enabled "SFML_OPENGL_ES". Pressed "Configure" then "Generate". After that, Xcode was able to successfully build every "sfml-" target except for sfml-audio. In the November 29, 2013 post that Laurent referenced, he says: "There's no audio module on iOS". Apparently that's still the case.

Hope this helps.

@Laurent, any update on the audio module for iOS? Back when you posted (back in 2013), you'd said you were waiting for libsndfile to add a license exception for iOS.

5

Feature requests / Re: Window-moved events

« on: January 17, 2016, 08:25:38 pm »

...Do you have a use-case?...

Hi Hiura,

Thanks for asking.

My use case for this is having a window that's like a tank partially full of water. When the window moves, I want the water to move too - sloshing back and forth - like it were water in a tank that just got moved.

In this case, a perfect simulation - while it'd be nice - isn't necessary. So even if the underlying window management doesn't provide a real-time (or close to real-time) stream of movement events, just getting the final move delta is enough.

It was easy for me to code around not having these window-moved events, but I'd prefer using the event model supported by window.pollEvent() if it delivered these.

Is there a desire on the part of SFML development to move away from event-driven programming? I ask because maybe there's a more preferable paradigm. If not, then I'm curious to understand why there may be any resistance to expanding the SFML event model.

I'm not familiar with what Microsoft Windows provides in the way of window-movement information but at least in the X Window System there's the XConfigureEvent that apparantly provides this kind of event notification for window moves. No idea if X Window System developers later saw that as a mistake though.

Thanks again.

6

Feature requests / Window-moved events

« on: January 14, 2016, 05:12:13 pm »

Haven't seen this asked for before... so here goes: how about the events code being expanded to include window movement events?

What do users think of this feature proposal?

I.e.:

• Add an enum entry to Event.hpp like Moved.
• Rename MouseMoveEvent to MoveEvent.
• Use MoveEvent for MouseMoved and Moved event types.
• Adding code to dispatch these new window moved events to the event retrieving methods of the Window class and any other appropriate places.

I realize I can get window position information and still react to window movement but having it be part of the normal events system/mechanism seems more elegant. Thank you.