Messages

1

Graphics / Graphics or Icons in sf::Text

« on: May 02, 2014, 08:25:49 pm »

I'd like to display a label with the following text:

Press ENTER to start

But have "ENTER" be a graphic that looks like an enter key. I'd like to be able to do similar things with, say, a graphic of the left mouse button. The text in this graphic shows something similar to what I'd like to achieve:

I'm looking for some input on the best way to achieve this in SFML. What I've come up with so far is to either implement a bitmap font and use special characters that I wouldn't otherwise use in the text of my game (e.g., ~) as stand-ins for my graphics. In this case the actual text would be:

Press ~ to start

and in the bitmap font the ~ character would be the enter graphic. This is somewhat hacky but I can live with that, the real downside is that I'd have to implement a bitmap font myself.

Another possibility to is to expand on a TTF font, adding the icons similar to an icon font like Font Awesome. On the upside this doesn't require me to implement anything in SFML but now I'm mucking around editing fonts.

Either way, getting this to work is going to involve some work on my part. So I'd like to hear some critiques of my two ideas and some thoughts from others about how to approach this issue.

2

General discussions / Re: SFML 3 - What is your vision?

« on: May 02, 2014, 07:58:44 pm »

So you want to add a second class that does the same as sf::View but with another name?

The tutorial on Views is called Controlling the 2D camera with views which implies that View is the camera but doesn't explicitly state it (the word "camera" is only used in the title"). Maybe adding a sentence in the opening section that states something along the lines of, "a View is what you use for a camera in SFML" would clear this up?

3

Feature requests / Re: Bitmap fonts (again)

« on: April 30, 2014, 12:23:47 am »

The problem is to find one which is standard, and as far as I know there's none.

I think the best you're gonna get is a defacto standard.

The two other frameworks I have experience with, Moai and Cocos2D, both use BMFont. I believe it covers all your requirements (features are listed on the site).

4

General discussions / Re: SFML 3 - What is your vision?

« on: April 28, 2014, 01:08:55 am »

I feel that SFML 2.x does a good job of covering the basics. Want to open a window? Use the keyboard and mouse? Draw some stuff to the screen? All that stuff just works and is simple to use. I'm not saying these things can't be improved but I feel that the core of SFML is pretty good.

I think one place where SFML drops the ball a bit is when it comes to scenarios that aren't clearly part of the core of a multimedia library. Another problem is that SFML becomes a lot less simple once you start on a non-trivial app.

For example, it's simple and fast and easy to load up a texture and display it with a sprite but once you start having a lot of sprites and performance falls into the gutter you have to fall back to sf::VertexArray and really get your hands dirty in managing all your sprites to optimize drawing, which is pretty low-level and not something typically characterized as "simple" . Adding something like sf::SpriteBatch that would take sf::Sprites as children could allow for quick an easy batching of draw calls reducing the friction of using SFML for a common task.

The things I'd like to see are about expanding utility and making SFML simpler and easier to use as apps become more complex.

• C++11 required.
• "System Info" Class: a class to get information about the current system at runtime. I'm thinking things like OS name, OS version, RAM, CPU, GPU, etc.
• A mouse disconnect event. This one might seem odd at first but think of people using wireless mice or laptops where peripherals or more regularly attached/dettached
• Sprite batching. This is a pretty obvious win for drawing performance and while it can be achieved via sf::VertextArray it would be a lot simpler and user-friendly to be able to batch sf::Sprite out of the box. link to Cocos2D sprite batch for an example
• Support for texture compression. This is more of an actual concern for Android/iOS and a "nice to have" for desktop.
• Support for texture atlasing. Like sprite batching this is another obvious win for drawing performance. Texture Packer is one such tool SFML could support. It supports Custom exporters so SFML could have its own tool-independent format.
• Actions and Easing. Essentially the ability to manipulate the properties of objects over time. See example.
• More support for 3rd Party Tools. This would depend on the addition of new features first but I think it's worth considering. Examples include Texture Packer, Glyph Designer, Particle Designer (or Particle Editor for non-Mac folk), and I'm sure there are plenty of others.

These are community related but I think worth mentioning for a "vision" of what SFML can become:

• More solicitation for community contributions. A coding style guide, an intro README, and a sub-forum specifically for discussing contributions are a couple suggestions for fostering more community support.
• Maintain a list of contributors. It's always nice to give people who help you out their due Having some sort of licensing agreement for contributors might be a good idea as well (sample link).

Another thing that I think would be informative is to try to find people who have used SFML in the past but moved away from it for one reason or another. Finding out what lead them to drop SFML for ____ will likely shed some additional light on SFML's deficiences. You might have to look them up and contact them directly but I do see people in the forums and github tracker stating things along the lines of, "oh, it's cool you finally fixed this but I've since switched to SDL."

5

Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID

« on: March 09, 2014, 05:27:13 pm »

The pull request has been merged. Thanks again for your great efforts.

Excellent! Glad to help.

6

Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID

« on: March 03, 2014, 02:10:51 am »

Yep. In my example, the accelerometer simply had no buttons, so that would also be a possibility to detect it. This check also seems to be used elsewhere. But let's keep that for later.

Sounds good.

No. According to that list, it's indeed "Jess Technology Co., Ltd" (0f30). But Windows uses the same manufacturer ID and assigns it to Saitek. It looks like others have had this assignment, too.

Hmmm...Googling reveals a company called Jess Tech that does make gamepads. I wonder if they are a re-badge of Saitek pads for certain markets?

I'm wondering whether vendorId would be a better name than manufacturerId. It seems to be a bit more often used (e.g. in Android API, but also discussions across the Internet). On the other hand, "manufacturer" might be more expressive.

I've been going back and forth on this as "manufacturer" is rather a pain to type (especially compared with "vendor") and, as you mentioned, "vendor" tends to be used more often. Honestly, I went with "manufacturer" because I implemented the Windows version first and that's how the value is referred to in the JOYCAPS structure. I could go either way, though I'm inclined toward changing it to vendor for the reasons above.

I've also added a few remarks to the pull request.

I saw that, looking through them in detail now but they seem straightforward.

What do you think, are there important things left for a first version?

I think we could ship this feature as-is and I'd be an immediately useful improvement to SFML. The Linux driver issue discussed earlier in the thread is something I'd like to get worked out but I don't think it's needed for a v1 release.

7

Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID

« on: March 02, 2014, 09:37:38 pm »

I think you shouldn't waste too much time with driver-specific issues (unless you enjoy it ).

A sick, twisted part of me kinda wants to dig into this but I think I'll pass for now if you're not worried about it. A little further investigation shows that xpad works well for most people so it's not like we leave a ton of folks out in the cold by not fully supporting non-standard drivers.

8

Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID

« on: March 02, 2014, 09:35:09 pm »

From my testing the names for devices seem to be completely arbitrary on every OS. It's possible that Linux either adds the vendor name or it's convention for driver authors to do so. I suspect most controller drivers for Windows are written by the manufacturer while Linux versions are added by the community which may also have something to do with differing naming schemes for the same device.

In any case it's probably best to rely on the vendor and manufacturer IDs to accurately identify controllers in code and use the name to identify the controller to the user.

I also noticed that I get extra joysticks on Linux -- one of them is the VirtualBox mouse integration device and another is a VirtualBox USB tablet (which I assume has to do with my drawing tablet). In both cases these devices appear as joysticks in /dev/input/js so in that since SFML is picking them up as expected. Perhaps the Linux implementation should be extended to further test connected joysticks to ensure they are actually joysticks.

JessTech ColourRumblePad (wrong manufacturer: Saitek is correct)

Does the manufacturer ID correspond with Saitek? Here's a list of USB IDs.

9

Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID

« on: March 01, 2014, 11:13:42 pm »

Did some more in-depth testing this morning.

Windows 8 x64

Compiled with Mingw GCC 4.8.1.

• Xbox 360 wired/wireless: both work great as expected since they are as close to an "official" gamepad as we're likely to get for Windows.
• Dual Shock 3: I'm using the Motioninjoy driver with Better DS3 for configuration. I've set the pad to use XInput meaning it shows up in the system as a wireless 360 pad. As far as getting the identification info and using the pad things work fine. I've found the driver to be a little buggy at times though -- random disconnects or switching from XInput to DirectInput mode.

Linux

All distros are 64 bit and tested via VirtualBox running from a Windows 8x64 host. I tested the following distros:

• Ubuntu 13.10
• Linux Mint 16
• Manjaro
• Fedora 20

• Xbox 360 wired: Works great.
• Xbox 360 wireless: Mostly works but we don't get the product or manufactuer IDs. Nor do the triggers register. More on this below.

There are two drivers for the Xbox 360 pad on Linux: xpad and xboxdrv. Xpad is shipped with the kernal and is the defacto "official" Linux driver. Xboxdrv is a third party driver that must be installed manually (and part of the installation is disabling xpad entirely). So it's an either-or situation with these drivers.

I wanted to give xboxdrv a try because Linux was not recognizing my wireless 360 pad. So I did some Googling and found that people were also using xboxdrv. Now, my wireless pad may not be recognized due to the VM situation but it appears that xpad doesn't recognize it while xboxdrv does.

When testing the pad with jstest-gtk in Ubuntu all the sticks, triggers and buttons work as expected. Similarly, when using the lsusb -v command in Terminal I can see the product and manufacturer IDs. However, when running in my gamepad testing app neither the product nor manufacturer ID can be read. Both the triggers are ignored as well.

For the product and manufacturer IDs I think the problem is that I xboxdrv needs to be run as a daemon (docs) but I unable to do this even when I sudo to root. This bears some more investigation but I really don't feel like dealing with manually configuring Linux drivers today so I'll come back to it tomorrow or next week Possibly the issue with the triggers is related.

I'd be great if someone can test wireless 360 pads on a native Linux install (non-VM) so we can see if xpad will recognize them.

Here's the link to the reference I used for setting up xboxdrv: link.

Mac OS Lion (10.7)

SFML compiled with Clang and C++11 enabled.

• Xbox 360 wired/wireless: I'm using the Tattieboggle 0.08 driver (tried using newer versions with no such luck, maybe they are for newer OSX versions?). Both controllers worked fine.
• Dual Shock 3: Connected via Bluetooth using the built-in OSX driver (I believe this has been included since Snow Leopard). Controller works great with the exception that L2 and R2 only register as buttons not as the analog triggers they are. Hopefully this is addressed in newer OSX versions.
• Wiimote (no attachements), with nunchuck, with Classic Controller: Connected via Bluetooth using the WJoy 0.7.1 driver. All the buttons and analog sticks work as expected. The driver doesn't appear to report values from the motion sensors in the Wiimote.

10

Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID

« on: March 01, 2014, 04:44:56 am »

If there are no other objections, I will test the code on the weekend and give you further feedback. You said you already tested it, so the main things should work. But the more joysticks and operating systems we can investigate, the better.

I just pushed up a commit with the sf::Joystick::Identification change as discussed. Tested things out on the following:

• Windows 8 x64: 360 wired and wireless controllers
• Mac OS Lion (10.7): 360 wired
• Ubuntu 13.10 x64: 360 wired
• Linux Mint 16 x64: 360 wired
• Manjaro x64: 360 wired
• Fedora 20 x64: 360 wired

All the Linux distros are tested using VirtualBox with a Windows host OS. Everything seems to be working okay. Going to take some more time tomorrow to go over things and test out my other controllers.

BTW, I wrote this quick and dirty app for testing joysticks awhile back. Link.

11

Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID

« on: February 28, 2014, 01:05:55 am »

I haven't implemented FreeBSD, when using FreeBSD the getName(), etc functions all return the defaults.  I wasn't able to get a KDE nor Gnome installed on FreeBSD, nor could I find any documentation on the usb api SFML is using. Is the FreeBSD version working? The code for it seemed spare and there isn't an official download on the SFML download page.

Agreed on the contructor/initialization list. If we're liking this API change I can make all the updates to the PR before the weekend (probably Friday evening). No sense testing what we've got if we're making a bunch of API changes now.

12

Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID

« on: February 26, 2014, 11:45:25 pm »

Okay, it sounds like this is the current proposal for the new information:

class Joystick
{
public:
    struct Identification
    {
        Identification()
        {
            name = "No Joystick";
            manufacturerId = 0;
            productId = 0;
        }

        sf::String   name;                      ///< Name of the joystick
        unsigned int manufacturerId;            ///< Manufacturer identifier
        unsigned int productId;                 ///< Product identifier
    };

    static Identification getIdentification(unsigned int joystick);
};
 

The previously existing info (button count and axes) would remain where it is and sf::JoystickInfo would be renamed back to sf::JoystickCapabilities. I think this works nicely.

13

Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID

« on: February 18, 2014, 06:08:06 pm »

hasAxis() and getButtonCount() exist already now, so they won't be removed. Thus, the info structure would only contain 3 members (name, manufacturer ID, product ID)... The question is whether it's worth aggregating these attributes to a common type.

So this is a slight change from your previous proposal. Now JoystickInfo would not contain buttonCount or axes. Would axes and buttonCount go back into a JoystickCapabilities struct?

That makes more sense to me. That said, let me play devil's advocate:

It seems odd to me that we'd put name, vendor ID and product ID into an info structure but leave out button count and axes. All those things fall under the category of "info". And they are all contained in the current JoystickInfo struct (from the pull request).

Looking at that from the perspective of a developer using SFML I'd expect a getInfo() method to return all available info to me, not some subset of it.

14

Window / Re: Exposed Joystick Name, Product ID and Manufacturer ID

« on: February 18, 2014, 12:02:39 am »

What you've described is essentially what's happening with the current get*() methods behind the scenes. This is what getProductId() looks like:

Code: [Select]

unsigned int Joystick::getProductId(unsigned int joystick)
{
    return priv::JoystickManager::getInstance().getInfo(joystick).productId;
}

Making this change would reduce the number of methods in the joystick API by 4, replacing getButtonCount(), hasAxis(), getName(), getProductId(), and getManufacturerId() with getInfo(). Which might be nice but it's not as if there are dozens of methods in the joystick API (or likely to be many more).

On the downside, the convenience of hasAxis() would be lost with this change. Conceptually, I think going with getInfo() breaks from the logic of the current API.

As it stands all of the methods of sf::Joystick ask a specific question about the capabilities or state of a specific joystick: isConnected(), isButtonPressed(), hasAxis(), etc. getInfo() changes that so we instead ask specific questions about joystick state but a non-specific, indirect question about joystick info.

Further, when reading code I think sf::Joystick::getName(index) is easier to read and comprehend than sf::Joystick::getInfo(index).name.

While it would be easier to pass around a JoystickInfo object rather than multiple properties this doesn't strike me as something that will be happening all that much -- probably only when a joystick is first connected and being configured. I prefer the readability of the current API.

15

General discussions / Re: Android/iOS "Soon"

« on: February 11, 2014, 01:30:42 am »

After I wrote to the author of libsndfile he said that he would contact all the copyright holders (there seems to be a lot), and make a license exception that would allow static linking on iOS. I'm still waiting for news, so at the moment there's no audio on iOS.

Have you had any update on this? I'm doing an iOS project for work (using Cocos2d) and saw ObjectAL mentioned as an alternative sound engine to the built-in Cocos2d stuff. Maybe it would be a good fit for SFML iOS (possibly Mac too)?