Messages

1

General discussions / Re: Switched times to Uint32 milliseconds in SFML 2

« on: June 25, 2012, 01:38:39 am »

The Time/seconds API should be changed so that it uses double rather than float. As shown previously, float is not precise enough for timing.

2

General discussions / Switched times to Uint32 milliseconds in SFML 2

« on: December 14, 2011, 03:31:08 am »

This change is a clear and useless regression.

Use double, keep the API compatibility and keep it precise down to microsecond level for 300 years. Time precision greater than 1 ms is important for various things including audio clock sync, profiling and such. 1 ms jitter is apparent on smooth 60 FPS animation even if not particularly disturbing.

There are highly precise timers available on all major platforms, so there is also no reason to only offer 1 ms precision. Double precision floating-point is lightning fast to calculate with and the extra four bytes for a clock memory footprint cannot be significant either (especially since floats are promoted to double anyway when put into registers or passed to functions).

If you read the arguments FOR using integers in the thread, you would see that that "extra precision" you need wouldn't exist even if floats were used. OSes only guarantee precision to the millisecond level.

As others have pointed out, that belief is bogus. All OSes worth a mention provide nanosecond or similar precision in their time interfaces, and the actual timers on pretty much any platform are of very high precision too. I highly doubt SFML ever getting ported to a system where time precision wouldn't be better than 1 ms.

Also, it needs to be emphasized that double precision float (i.e. double) is needed. Single precision (i.e. float) is not enough as was demonstrated by the original issue that started this thread. Double precision floating-point calculations are extremely fast even on modern mobile platforms (not to mention x86), so the performance won't be an issue. Neither should the 8 byte memory footprint for a time value matter anywhere.

3

Feature requests / Shaders, vertex shaders?

« on: July 07, 2011, 12:07:32 am »

Vertex shaders are seldom needed for moving the vertices (besides the matrix multiplication) but rather they are used for preparing input data for fragment shaders to use. Not so sure how useful this would be for 2d sprites.

You cannot use vertex shaders to create any new geometry (for tesselation). Geometry shaders (OpenGL 3.3) can create new objects (paint your sprite multiple times on one pass, perform stereo3d/multiangle rendering from one render pass to multiple buffers, etc). Tesselation shaders (OpenGL 4.0) are designed for subdividing triangles (i.e. they can be used to wave/morph a sprite) but a bleeding edge GPU is required. Open-source graphics drivers only support OpenGL 2.1 (3.x is in development).

4

Feature requests / Pre-multiplied alpha

« on: July 06, 2011, 11:57:21 pm »

Ideally this could be the default, with alphas premultiplied during image loading as necessary (e.g. PNG does not use premultiplied alpha, TIFF does). There are no drawbacks of doing premultiplied alpha, only benefits.

5

General discussions / Benchmark : SFML2 vs D3DXSprite

« on: July 06, 2011, 11:49:12 pm »

It is meaningless to benchmark anything above 200 FPS or so as display drivers and other software is not optimized for that. Consider e.g. SFML doing something per frame, taking 1 ms each time. This would limit your FPS to 1000 no matter what you render, while another system might get you 10000 FPS. But if you are developing an actual game (targeting 60 FPS), that 1 ms extra delay makes pretty much no difference what-so-ever.

So do as someone suggested, draw enough sprites to slow it down to 30 FPS, then redo your benchmark and you'll get useful results.

6

General discussions / Switched times to Uint32 milliseconds in SFML 2

« on: July 06, 2011, 11:33:33 pm »

This change is a clear and useless regression.

Use double, keep the API compatibility and keep it precise down to microsecond level for 300 years. Time precision greater than 1 ms is important for various things including audio clock sync, profiling and such. 1 ms jitter is apparent on smooth 60 FPS animation even if not particularly disturbing.

There are highly precise timers available on all major platforms, so there is also no reason to only offer 1 ms precision. Double precision floating-point is lightning fast to calculate with and the extra four bytes for a clock memory footprint cannot be significant either (especially since floats are promoted to double anyway when put into registers or passed to functions).

7

General discussions / OpenGL

« on: July 06, 2011, 11:13:33 pm »

OpenGL SuperBible 5th Edition appears to be the only book even somewhat up to date (OpenGL 3.2/3.3 while the latest standard is 4.1). It is fairly good but you'll want to improvise a bit as they still use GLUT in their examples (and I suppose you would prefer SFML).

8

General discussions / New global inputs in SFML 2

« on: July 06, 2011, 11:03:06 pm »

The way I see it (application programmer POV), there should be two modes:

Mouse pointer mode:
- Used when the user needs to point and click things
- The pointer behaves normally
- A function to get the pointer position (desktop coordinates, e.g. 0x0...1920x1080)
- A function to get the pointer position within the window (possibly negative or greater than the window dimensions, and may not always correspond 1:1 to desktop pixels, consider e.g. compositing WMs)
- Different cursors possible for different windows/areas (handled by the GUI)
- ButtonPress and other such events that store the pointer position at the time the event occurred (necessary for precise clicks)

Relative motion mode:
- Used in FPS games and with various GUI widgets (e.g. draggable spinctrls)
- Cursor hidden (or doesn't move)
- A function to get the number of dots the mouse has moved since the last time it was read
- When switching back to pointer mode, the cursor is made visible at the position where it was before switching to relative movement

In an ideal case dots are much more precise than pixels: 2000 DPI mice are common but a few people would want just one inch of movement to move the cursor all the way across the screen and more. Also, there is no acceleration nor smoothing applied to dots, where pixels are suspect to the usual Xorg/Windows/OSX processing. This also has implications when touchscreens or other such input devices are used.

9

General discussions / SFML 2.0 Releases

« on: February 24, 2011, 11:09:54 am »

You know, Khronos tried that same thing with OpenGL 3.0 and failed. Instead, they finally had to release because it wasn't going anywhere. Since then it has been perfected in the subsequent releases even though that has meant some API borkage via deprecated and removed features in 3.1 and other further releases.

Maybe most importantly you really find out how the API should work when the library is in widespread use and you get user feedback. Unfortunately that will only happen with an actual release.

10

General discussions / SFML 2.0 Releases

« on: February 23, 2011, 06:43:17 pm »

SFML2 seems somewhat dead with no updates on news. Perhaps it would be a good time to go for release early, fix after, to get things rolling again? Trying to make too big changes and then releasing a "perfect new version" is not healthy.

11

Feature requests / N900 port

« on: October 28, 2010, 12:11:31 am »

Good to know. I'll get back to this later then, possibly on MeeGo and/or N9.

12

Feature requests / N900 port

« on: October 24, 2010, 02:38:13 am »

It would be nice to have SFML for the Nokia N900 phone. Since the Maemo OS that the phone uses is essentially a desktop Linux system, porting SFML might only require compiling and .deb packaging, at least if SFML can run on GLES2.

Any chance of that happening or are there some obstacles that I am overlooking?

I will install the SDK and hack around a bit to get used to that and after a while I could probably try porting SFML myself, if it seems feasible. Maemo already has all the libraries that SFML depends on (as well as plenty of others such as Boost, SDL, glibmm, ...).

13

Feature requests / Joystick names and other information

« on: August 13, 2010, 03:14:08 am »

We (Performous developers) need joystick names for controller autodetection. SDL and ClanLib provide this information, but I couldn't find anything about it in SFML docs, so either I missed something or here's a request for such feature.

SDL and ClanLib also fail to display some controls (GHWT guitar tilt sensor) and device identification information (we cannot tell GHWT guitars and drums apart because both look identical on SDL/ClanLib). I'm afraid that there is little that SFML could do to solve this and that the actual problem lies on a lower level (joystick drivers). The required information is available on the evdev API, but apparently it gets lost somewhere along the way.

14

Feature requests / Multiple Mice

« on: August 13, 2010, 03:06:16 am »

Multiple keyboards is one frequently requested feature (for Performous multiplayer). I'm looking forward to this.

15

Feature requests / Mouse capture/grab

« on: August 13, 2010, 03:04:01 am »

It would be optimal if raw mouse movements could be read, avoiding the concept of screen pixels, desktop acceleration/speed adjustment and other cruft entirely, but unfortunately I don't think this is very practical on Windows nor Linux. On Linux you could read the input event device directly, but that requires root access

Even so, it would be very good if SFML offered an API for this kind of mouse control and then internally implemented the best known solution for each platform. The current way of application programmers having to hack something together is the worst solution.

In such an API, the user wants to know how much the mouse has moved since the last read, without having to wonder about window center coordinates or other such things. This should also always hide the cursor.