Messages

1

Window / Re: Xbox 360 controller: invalid axis values (linux)

« on: February 04, 2015, 09:39:37 am »

I think the problem I mentioned is related to the linux switch to xcb. Do you still have the problem if you use an older version of sfml? (I think the 2.2 tag is pre-xcb).

Okay, to test I rebuilt SFML from the 2.1 tag:

• The error messages about not finding the USB device no longer appear.
• The weird values I'm getting for the X/Y axis on the 360 controller are still there (including the bizarre crossover coming from moving other axis controls or pressing certain buttons)

2

Window / Re: Xbox 360 controller: invalid axis values (linux)

« on: February 03, 2015, 09:28:35 pm »

I think the problem I mentioned is related to the linux switch to xcb. Do you still have the problem if you use an older version of sfml? (I think the 2.2 tag is pre-xcb). Also do the random values change as you move the controller axis as if it is reading the controller, but wrongly, or are the values just random regardless.. as if the controller may as well not be connected?

The values do change in response to moving the axis control. They do not change when the controller is still.

Another thing I noticed is that the axis values will also change very slightly when pressing some of the other buttons: LT, RT, and the center guide / xbox logo button.

I will try testing with an older version later.

3

Window / Re: Xbox 360 controller: invalid axis values (linux)

« on: February 03, 2015, 08:45:43 pm »

Maybe related to this? I get weird results in Ubuntu with the 360 controller too.

It does sound like a similar issue. However it sounds like you are getting random values from a phantom controller that isn't actually connected? Whereas my controller is connected except it's getting nonsensical values from the axis control.

The error message displayed at the console is the same however.

I'll post a comment over there as well just in case.

4

Window / Xbox 360 controller: invalid axis values (linux)

« on: February 03, 2015, 05:22:26 pm »

Hello,

I started digging into coding gamepad support for my game, but ran into some issues, particularly with getting seemingly bad values from the axis inputs on my (brand new) Xbox 360 wired controller.

When I compile and start my program, I see the following printed to stdout:

Unable to get joystick attribute. Could not find USB device for joystick at index 0.
Unable to get joystick attribute. Could not find USB device for joystick at index 0.

When I query the values of sf::Joystick::getIdentification(0), I get the following:

name: Microsoft X-Box 360 pad
vendorId: 0
productId: 0

I am able to see input occurring from all of the buttons and axis, however the state of the axis appear to be incorrect. In the resting/center position, either of the axis will return values anywhere across the spectrum, from -1 to 1.

For example:

sf::Joystick::update()
float x = sf::Joystick::getAxisPosition(0, sf::Joystick::X);
float y = sf::Joystick::getAxisPosition(0, sf::Joystick::Y);

sf::Vector2f normalized = normalize(x, y);

Output at resting/center position (not touching the controller):

x: -0.977409
y: 0.211355

If I move the controller around and then release it back to the resting state, it will give a totally different set of nonzero values. At least one of the x/y axis is typically pegged at around 0.9 (or -0.9).

Interestingly, I plugged in another generic controller with a similar layout (an old Belkin Nostromo N45) and it works fine with the same code, giving zero values in the center position and normal/expected values throughout it's movement range (although SFML outputs the same warning message about not finding the USB device).

However, the Xbox gamepad works great and behaves as expected in all other games on my system, so I don't think it's faulty controller hardware.

I'm running the latest SFML (built from github source) on Archlinux x86_64. The xpad driver module is automatically loaded.

5

General / Re: Thor: Moving particle emitters

« on: December 03, 2014, 10:45:20 am »

instead of calling UniversalEmitter::setParticlePosition() repeatedly with a constant, you could consider passing it a function/functor/lambda expression once. This functor would then infer the position itself.

Right on, thanks for the tip. That looks like it would be cleaner.

6

General / Re: Thor: Moving particle emitters

« on: December 03, 2014, 10:27:43 am »

Okay, I believe I've answered my own question. Or rather, I read the tutorial again and paid closer attention to the "Value and reference semantics" section.

Essentially, adding an emitter into the particle system is actually making a copy of that emitter. This section in the tutorial introduces refEmitter(), which adds it by reference instead. So, instead of doing:

particle_system.addEmitter(emitter);

I just needed to do:

particle_system.addEmitter(thor::refEmitter(emitter));

... and of course make sure the object remains in-scope. I can now successfully transform the emitter.

Very cool little library! Thanks to the author. I was kind of hoping I could skip writing particle and sprite animation stuff myself, at least for now. This looks like it should work for my needs, as long as I can successfully build it on all of the major platforms.

7

General / Re: Thor: Moving particle emitters

« on: December 03, 2014, 08:49:52 am »

I've never used Thor's particle system, but looking at the tutorial it seems you'd place the position of particles with: emitter.setParticlePosition()

Thanks for the reply. Yes, at first glance that would seem like the solution - however as stated in my post, the setParticlePosition method only seems to effect the initial position. Subsequent calls to this method, after the emitter has been added into the particle system, have no effect.

The docs seem to confirm this:

Sets the initial particle position.

Seems like being able to transform emitters after creation would be basic functionality. I must be missing something.

8

General / Thor: Moving particle emitters

« on: December 03, 2014, 08:22:54 am »

Hello,

I'm trying out Thor 2.0 with the git development version of SFML and have a basic question about the particle system. However after several attempts and re-reads of the docs, I seem to be missing something simple or fundamental: how do I change the position of the particle emitters themselves after creation?

I need to be able to move emitters along with other moving objects in my game, such as the main character. However subsequent calls to emitter.setParticlePosition() have no effect, unless perhaps I completely remove and re-create the emitter on every frame, which of course doesn't make sense.

According to the tutorial:

There is one concrete emitter type in Thor, namely thor::UniversalEmitter. This class can determine parameters like emission rate as well as initial particle conditions such as position, rotation or lifetime. However, UniversalEmitter itself has no geometric representation in 2D space.

Since the API doesn't seem to have any obvious setPosition()-like method, beyond setting the initial parameters upon creation, what's the trick to transforming emitters in 2D space?

Thanks!

9

General discussions / why sfml is not on the wikipedia ?

« on: March 16, 2012, 10:25:50 pm »

Perhaps consider issuing a press release when 2.0 is ready? That may help generate some official coverage on more 'notable' tech/media sites.

10

General / Can't compile code, 'class sf::X' has no member named 'Y'

« on: March 12, 2012, 11:25:32 pm »

In the latest version (as of this past weekend), the naming conventions have changed: everything is now camelCase. For example, "IsOpen" is now "isOpen".

See this thread: http://www.sfml-dev.org/forum/viewtopic.php?t=6709

You'll need to adjust your code accordingly. Most online tutorials etc are out of date now, but you can compare your code to the official documentation (which is kept up to date): http://www.sfml-dev.org/documentation/2.0/

11

General / Trying to make separate timer and rendering loops

« on: March 11, 2012, 10:46:25 pm »

It would be great to get some updated & complete working examples of how the new system works for us newbies and how we can implement clocks & delta timing using the new API. Thus far I have been unable to find anything current on this topic.

The new SFML Clock / Time system is simple. Here is a topic I found on it with delta.
http://www.sfml-dev.org/forum/viewtopic.php?t=7068&sid=4ca8b34ceb82a49c0ee67ba417382da7

Thanks, I did see that thread and the docs, and I think I got a simple test semi-working. I guess I'm still just trying to wrap my head around the overall concepts. Wikis and tutorials come in handy here, helping to illustrate the big picture, and most of the SFML-specific ones are broken at the moment. Maybe now that the new naming convention and API have been pushed...  :wink:

12

General discussions / New naming convention

« on: March 11, 2012, 10:41:56 pm »

It's pushed.

Woohoo! Thanks Laurent.  

13

General / Trying to make separate timer and rendering loops

« on: March 11, 2012, 04:37:15 am »

Mrhello, have you looked at the Basic Game Engine tutorial on the SFML Wiki? In the section on Game Loop it has some information you may be interested in

Unfortunately the wiki is out of date (as are all existing tutorials) and does not seem to reflect the new time/clock API changes.

It would be great to get some updated & complete working examples of how the new system works for us newbies and how we can implement clocks & delta timing using the new API. Thus far I have been unable to find anything current on this topic.