gdalgorithms-list

Re: [Algorithms] Kinematic Collision

[Jon W. <jw...@gm...>]

pontus birgersson wrote:
> > However, in general, you'll want the animation to be driven by the
> > movement, and not the other way around. Each frame, you determine how
> > far you've traveled since the last frame, and forward the animation an
> > appropriate amount to avoid foot sliding. (The animation is marked up,
> > or you measure this based on certain named bones).

> Not sure exactly how this would benefit a fighting move though. Where 
> would the initial movement come from if not from the animation?
>

Physics. Because you wanted to include a physics engine. If you don't 
use a physics engine, you don't have that option.

> If I understand you correctly this is exactly what I did my candidate 
> thesis on, converting animation data into forces which are then 
> applied to a ragdoll which correspond to the rig. I never managed to 
> get it looking as well as I'd like though I only tried with explicit 
> integration medthods, and an implicit method would probably lend 
> itself much better to this.
>

That'd be good to find out :-)

>
> > "desires" -- "I want to land my left fist on his nose in 400
> > milliseconds, and I think it will be *there* at that time." Similar to
> > Natural Motion / Endorphin in real-time, with player guidance,
> > perhaps.

> Maybe I should look into endorphin, kind of pricy though if I remember 
> correctly.

Usually, it's the case that quality has to cost, because there is much 
less competition the more specialization and higher quality you want. 
The cheap generic crap is just that, cheap. That doesn't mean that 
everything that's expensive is good, of course, but it does mean that 
it's generally hard to be consistently good without being expensive.

Middleware seems to start at the $250 range (old Torque, C4 engine, 
etc), take a leap to the $5k-$10k+ range (Granny, FMOD, etc), take 
another leap to the $50k range (physics packages etc), and then have a 
top strata at $150k+ (full engines, scene graphs, integrated editors, 
etc). Within that range, I wouldn't think endorphin is entirely out of 
reason.

Sincerely,

jw




-- 

  Revenge is the most pointless and damaging of human desires.

Re: [Algorithms] Kinematic Collision

[Pierre T. <pie...@gm...>]

>
> First: Fighting games are somewhat special. I wouldn't expect you can
> use a "standard" character controller for that.
>

I think this thread proved that there is no such thing as a "standard"
character controller ;)

What kind of fighting games are we talking about here? Dead-or-alive/Tekken
stuff?

I know that Oni (and the remake whose link I previously posted) used vanilla
Quake-style controllers (NxCharacter, in the second case). It was good
enough for those 3rd person games where fighting is just one part of the
gameplay. For me, the most painful issue was "throws", where one character
has to grab and throw another. I think most games just author the 2
animations (for the player and the opponent) for a certain position, or
rather relative position between the 2 characters. At replay time they just
reposition the 2 characters so that they're at the right distance from
eachother, and then just play the animations as usual.

Do you guys know of games really doing more than that?

The problem then is when the character runs into roadblocks that
> simply aren't in the animation. You might want to apply a limited
> amount of force (enough to get going with super-human speed, of
> course), and if the limbs are too far out of place after a while,
> cancel the animation/attack -- you probably tried to punch a mountain
> wall or something similar.


I think people just make sure the bounding volume is big enough to enclose
the whole punch motion. So it is never possible for the character to punch a
mountain wall. It sometimes makes you use 2 bounding volumes though: one to
collide against the level, one to collide against the opponents (since you
need to be close to opponents for the punch/kick attacks to reach them).


> And once you start to integrate animation
> and physics even more, you might start expressing animations as
> "desires" -- "I want to land my left fist on his nose in 400
> milliseconds, and I think it will be *there* at that time." Similar to
>  Natural Motion / Endorphin in real-time, with player guidance,
> perhaps.
>
> If you or anyone else learn anything more about this, I would be very
> interested in hearing about it!
>

Same here. I wonder what's the most advanced thing done in games in that
respect, or if all of this is really needed (I had the impression it wasn't,
so far)

- Pierre

Re: [Algorithms] Kinematic Collision

[pontus b. <her...@ho...>]

Hi, thanks for your reply!

> Date: Sat, 12 Sep 2009 20:56:56 -0700
> From: jw...@gm...
> To: gda...@li...
> Subject: Re: [Algorithms] Kinematic Collision
> 
> First: Fighting games are somewhat special. I wouldn't expect you can
> use a "standard" character controller for that.
> 
> However, in general, you'll want the animation to be driven by the
> movement, and not the other way around. Each frame, you determine how
> far you've traveled since the last frame, and forward the animation an
> appropriate amount to avoid foot sliding. (The animation is marked up,
> or you measure this based on certain named bones).
Not sure exactly how this would benefit a fighting move though. Where would the initial movement come from if not from the animation?


> Now, you have another problem with fighters: that of an irresistible
> force hitting an immovable object. You *can* play back animations as
> force constraints on a rigged character/ragdoll. It doesn't have to
> look sloppy, if you use enough force in the joints, and also a little
> bit of look-ahead to get the velocity as well as the position right.
> Don't know if it's good enough for a fighter, though.
If I understand you correctly this is exactly what I did my candidate thesis on, converting animation data into forces which are then applied to a ragdoll which correspond to the rig. I never managed to get it looking as well as I'd like though I only tried with explicit integration medthods, and an implicit method would probably lend itself much better to this.


> The problem then is when the character runs into roadblocks that
> simply aren't in the animation. You might want to apply a limited
> amount of force (enough to get going with super-human speed, of
> course), and if the limbs are too far out of place after a while,
> cancel the animation/attack -- you probably tried to punch a mountain
> wall or something similar. And once you start to integrate animation
> and physics even more, you might start expressing animations as
> "desires" -- "I want to land my left fist on his nose in 400
> milliseconds, and I think it will be *there* at that time." Similar to
>  Natural Motion / Endorphin in real-time, with player guidance,
> perhaps.
Maybe I should look into endorphin, kind of pricy though if I remember correctly.


Pontus


> 
> If you or anyone else learn anything more about this, I would be very
> interested in hearing about it!
> Sincerely,
> 
> jw
> 
> 
> 
> On Sat, Sep 12, 2009 at 2:13 AM, pontus birgersson
> <her...@ho...> wrote:
> > This thread is really interesting (or was up to a point). Before it dies
> > down I'd like to ask for some recommended reading. This is something that I
> > find a true pain whenever I start a new project because there's animation
> > and there's physics and they both want different things and are VERY rigid
> > in how you can use them.
> >
> > In my experience which mostly dealt with fighting games, the attack
> > animations will include a player translation which needs to be exact in
> > order for it to look good, i.e. I must use translation on individual frames
> > and NOT apply a force which delays and smudges movement.
> >
> > The animation being translated first poses the problem of not letting the
> > player’s world position go out of sync with its pelvis (root joint) so
> > various spatially based algorithms don't get thrown off. This can of course
> > be solved by tricking around with spatial delta for each animation key frame
> > and applying the correct translation/rotation on a per frame basis. After
> > this step I end up taking the transformation from the pelvis bone on that
> > particular key frame and instead apply it directly to the entity world
> > position.
> >
> > When I've done this it feels like I've effectively contradicted the way I'm
> > allowed to work with physics simulated objects though. Unless the physics
> > integration method is an implicit one, as far as I understand it, I'm not
> > supposed to move the object using translation, only by force or suffer the
> > hell that is unstable physics...
> >
> > So if that's the case, and do point out if I'm wrong, what does this
> > character controller that I keep hearing about do differently from this that
> > make physics and animation, not only speak the same language but also like
> > each other?
> >
> > Regards
> > Pontus Birgersson
> >
> > ________________________________
> > Med Windows Live kan du ordna, redigera och dela med dig av dina foton.
> > ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> > trial. Simplify your report design, integration and deployment - and focus
> > on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
> >
> 
> 
> 
> -- 
> 
> --
> Americans might object: there is no way we would sacrifice our living
> standards for the benefit of people in the rest of the world.
> Nevertheless, whether we get there willingly or not, we shall soon
> have lower consumption rates, because our present rates are
> unsustainable.
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

_________________________________________________________________
Använd nätet för att dela med dig av dina minnen till vem du vill.
http://www.microsoft.com/sverige/windows/windowslive/products/photos-share.aspx?tab=1

Re: [Algorithms] mouse smoothing

[James R. <ja...@fu...>]

Err, you really shouldn't be using raw input any more.  You should be 
obtaining mouse data through the Windows messages sent to your 
application/window.  More importantly you shouldn't attempt to by pass 
any acceleration that Windows provides per the users settings.  (There's 
nothing worse than trying to play a game with a mouse cursor that crawls 
across the screen like a snail with a broken leg.)


Tibor Klajnscek wrote:
> I haven't seen anyone mention this, but if you're using raw input 
> (which is most likely the case), you're bypassing all windows' 
> sensitivity and acceleration functions already.
>
> Cheers,
> Tibor
>
> On 13.9.2009 8:31, Jeff Russell wrote:
>> This thread has been totally worth it, just for adding "delta mickey" 
>> to my vocabulary. Bypassing windows mouse acceleration curves might 
>> be of interest to developers, actually, I had forgotten about that.
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
>> trial. Simplify your report design, integration and deployment - and focus on 
>> what you do best, core application coding. Discover what's new with 
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> GDAlgorithms-list mailing list
>> GDA...@li...
>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] mouse smoothing

[Tibor K. <tib...@gm...>]

I haven't seen anyone mention this, but if you're using raw input (which 
is most likely the case), you're bypassing all windows' sensitivity and 
acceleration functions already.

Cheers,
Tibor

On 13.9.2009 8:31, Jeff Russell wrote:
> This thread has been totally worth it, just for adding "delta mickey" 
> to my vocabulary. Bypassing windows mouse acceleration curves might be 
> of interest to developers, actually, I had forgotten about that.
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] mouse smoothing

[Alen L. <ale...@cr...>]

Sylvain wrote at 9/12/2009:
> I've never seen a game where it helped/where I felt I played better with
> it. Whether I had crappy or good mouse.

It's not about playing better. Of course you play worse with it
because you have more lag. It's about some people getting sick from
jerky view motions. Thus it is more important to have it in FPS than
in TPS. Think of it as an accesibility option.

JM2C,
Alen

Re: [Algorithms] mouse smoothing

[Jeff R. <je...@8m...>]

This thread has been totally worth it, just for adding "delta mickey" to my
vocabulary. Bypassing windows mouse acceleration curves might be of interest
to developers, actually, I had forgotten about that.

Re: [Algorithms] mouse smoothing

[Fabian G. <f.g...@49...>]

Tom Plunket wrote:
>>> Yeah, there is some non-trivial approach to doing this, and it's done by
>>> the OS. :-)
>>>
>>> In Windows, you can adjust parameters related to this. The most notable
>>> (in my opinion) is the acceleration slider which is a power function on
>>> the velocity.
>> That's not doing any smoothing either, though; quite the opposite, it
>> further exaggerates the input mouse motions.
> 
> I had guessed that it downward expanded slow movement, too, but I never
> really dug into it to see for sure.  There is the mouse speed slider, too,
> though, which scales the velocity linearly, which could "damp" the motion
> in a different way.

There's a small article explaining the mouse acceleration algorithm used 
in Windows XP:

   http://www.microsoft.com/whdc/archive/pointer-bal.mspx

It's hard to say for sure whether it's slowing down small motions since 
there's no "1:1 translation" reference curve in the graphs. However, the 
curves are piecewise linear with no huge slope differences; if there's 
any downward scaling done at some point, its effect would be quite mild.

> I wonder, though, if the input is noisy but is sufficiently filtered by
> the software path.  I mean some of these mice claim 1000dpi, I can't
> imagine they're not going to have some jitter at the hardware sampling
> level.

Not sure what happens at the mouse firmware level to get data this 
sparkly clean (well, unless you're on a surface it can't track properly 
on...) :). But you can get the raw delta mickeys from the raw input API 
on Windows (or DirectInput too for that matter) and just by directly 
opening the USB device on Linux. Aside from the obvious lack of mouse 
acceleration (which may be what you want in your game!), the values are 
just as noiseless as the mouse pointer coordinates.

-Fabian

Re: [Algorithms] Kinematic Collision

[Jon W. <jw...@gm...>]

First: Fighting games are somewhat special. I wouldn't expect you can
use a "standard" character controller for that.

However, in general, you'll want the animation to be driven by the
movement, and not the other way around. Each frame, you determine how
far you've traveled since the last frame, and forward the animation an
appropriate amount to avoid foot sliding. (The animation is marked up,
or you measure this based on certain named bones).

Now, you have another problem with fighters: that of an irresistible
force hitting an immovable object. You *can* play back animations as
force constraints on a rigged character/ragdoll. It doesn't have to
look sloppy, if you use enough force in the joints, and also a little
bit of look-ahead to get the velocity as well as the position right.
Don't know if it's good enough for a fighter, though.

The problem then is when the character runs into roadblocks that
simply aren't in the animation. You might want to apply a limited
amount of force (enough to get going with super-human speed, of
course), and if the limbs are too far out of place after a while,
cancel the animation/attack -- you probably tried to punch a mountain
wall or something similar. And once you start to integrate animation
and physics even more, you might start expressing animations as
"desires" -- "I want to land my left fist on his nose in 400
milliseconds, and I think it will be *there* at that time." Similar to
 Natural Motion / Endorphin in real-time, with player guidance,
perhaps.

If you or anyone else learn anything more about this, I would be very
interested in hearing about it!
Sincerely,

jw



On Sat, Sep 12, 2009 at 2:13 AM, pontus birgersson
<her...@ho...> wrote:
> This thread is really interesting (or was up to a point). Before it dies
> down I'd like to ask for some recommended reading. This is something that I
> find a true pain whenever I start a new project because there's animation
> and there's physics and they both want different things and are VERY rigid
> in how you can use them.
>
> In my experience which mostly dealt with fighting games, the attack
> animations will include a player translation which needs to be exact in
> order for it to look good, i.e. I must use translation on individual frames
> and NOT apply a force which delays and smudges movement.
>
> The animation being translated first poses the problem of not letting the
> player’s world position go out of sync with its pelvis (root joint) so
> various spatially based algorithms don't get thrown off. This can of course
> be solved by tricking around with spatial delta for each animation key frame
> and applying the correct translation/rotation on a per frame basis. After
> this step I end up taking the transformation from the pelvis bone on that
> particular key frame and instead apply it directly to the entity world
> position.
>
> When I've done this it feels like I've effectively contradicted the way I'm
> allowed to work with physics simulated objects though. Unless the physics
> integration method is an implicit one, as far as I understand it, I'm not
> supposed to move the object using translation, only by force or suffer the
> hell that is unstable physics...
>
> So if that's the case, and do point out if I'm wrong, what does this
> character controller that I keep hearing about do differently from this that
> make physics and animation, not only speak the same language but also like
> each other?
>
> Regards
> Pontus Birgersson
>
> ________________________________
> Med Windows Live kan du ordna, redigera och dela med dig av dina foton.
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 

--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world.
Nevertheless, whether we get there willingly or not, we shall soon
have lower consumption rates, because our present rates are
unsustainable.

Re: [Algorithms] mouse smoothing

[Tom P. <ga...@fa...>]

>> Yeah, there is some non-trivial approach to doing this, and it's done by
>> the OS. :-)
>>
>> In Windows, you can adjust parameters related to this. The most notable
>> (in my opinion) is the acceleration slider which is a power function on
>> the velocity.
>
> That's not doing any smoothing either, though; quite the opposite, it
> further exaggerates the input mouse motions.

I had guessed that it downward expanded slow movement, too, but I never
really dug into it to see for sure.  There is the mouse speed slider, too,
though, which scales the velocity linearly, which could "damp" the motion
in a different way.

> There's no point in smoothing mouse input, really; unlike most input
> devices, mice don't have any appreciable noise in their output. All the
> smoothing does is make everything feel laggy.

I wonder, though, if the input is noisy but is sufficiently filtered by
the software path.  I mean some of these mice claim 1000dpi, I can't
imagine they're not going to have some jitter at the hardware sampling
level.

-tom!

-- 

Re: [Algorithms] mouse smoothing

[Fabian G. <f.g...@49...>]

> Yeah, there is some non-trivial approach to doing this, and it's done by the OS. :-)
> 
> In Windows, you can adjust parameters related to this. The most notable (in my opinion) is the acceleration slider which is a power function on the velocity.

That's not doing any smoothing either, though; quite the opposite, it 
further exaggerates the input mouse motions.

There's no point in smoothing mouse input, really; unlike most input 
devices, mice don't have any appreciable noise in their output. All the 
smoothing does is make everything feel laggy.

Re: [Algorithms] Kinematic Collision

[pontus b. <her...@ho...>]

This thread
is really interesting (or was up to a point). Before it dies down I'd like to
ask for some recommended reading. This is something that I find a true pain
whenever I start a new project because there's animation and there's physics
and they both want different things and are VERY rigid in how you can use them.



In my experience which mostly dealt with fighting games, the attack animations
will include a player translation which needs to be exact in order for it to
look good, i.e. I must use translation on individual frames and NOT apply a
force which delays and smudges movement.



The animation being translated first poses the problem of not letting the player’s
world position go out of sync with its pelvis (root joint) so various spatially
based algorithms don't get thrown off. This can of course be solved by tricking
around with spatial delta for each animation key frame and applying the correct
translation/rotation on a per frame basis. After this step I end up taking the
transformation from the pelvis bone on that particular key frame and instead apply
it directly to the entity world position.



When I've done this it feels like I've effectively contradicted the way I'm
allowed to work with physics simulated objects though. Unless the physics
integration method is an implicit one, as far as I understand it, I'm not
supposed to move the object using translation, only by force or suffer the hell
that is unstable physics...



So if that's the case, and do point out if I'm wrong, what does this character
controller that I keep hearing about do differently from this that make physics
and animation, not only speak the same language but also like each other?



Regards

Pontus Birgersson


_________________________________________________________________
Med Windows Live kan du ordna, redigera och dela med dig av dina foton.
http://www.microsoft.com/sverige/windows/windowslive/products/photo-gallery-edit.aspx

Re: [Algorithms] mouse smoothing

[Jason H. <jh...@st...>]

Although you are asking about mouse smoothing in a FPS-style game, a 
similar but opposite problem exists when dealing with light guns or the 
cursor on the Wii using the DPD pointer: preventing jitter and 
restricting movement when not enough change has occurred.

After doing some experiments with a recent title I worked on, which 
involved quite a bit of point-and-clickery, it turns out that the 
simplest method was to accumulate virtual 'mickeys' of change, but do 
not actually begin moving the mouse cursor on-screen until a threshold 
was reached.  Once the cursor was unlocked, it did not settle down until 
the average velocity reduced below some threshold.  Smoothing the 
transitions between the two states (locked/unlocked) was simply done by 
the cheap unstable spring method, where each frame we took (x,y) = 
a*currentPos + (1-a)*newPos, and "a" ramped over a very short time down 
to 0. During the locked state, it always chose the current position to 
be the centroid of several previous samples.

The above gave us a nice slow moving cursor that didn't stick in one 
place and didn't jitter as long as the aim didn't deviate too much, too 
quickly.  And it (fairly) immediately launched into motion if the aim 
changed drastically, but the cursor caught up smoothly.  Not great for a 
FPS, but for a mechanical device with bulk and inertia to overcome, it 
might make sense to try something similar.

JH

Jeff Russell wrote:
> Okay, seems we have a consensus :-P No filtering:
>
> x += dx;
>
> Just curious if there was some non-trivial approach that i didn't know 
> about that was maybe good for this. TBH I've never quite understood 
> the importance either, but some of our users are asking for it.
>
> Cheers,
>
> Jeff
>
> On Fri, Sep 11, 2009 at 8:58 PM, Sylvain Vignaud <vi...@ii... 
> <mailto:vi...@ii...>> wrote:
>
>     I've never seen a game where it helped/where I felt I played
>     better with
>     it. Whether I had crappy or good mouse.
>
>     Nicholas "Indy" Ray wrote:
>     > I agree that mouse smoothing in a FPS is not a good default!
>     I've had
>     > better experience with a few third persons games, but I figure only
>     > then if aiming isn't important.
>     >
>     > Indy
>     >
>     > On Fri, Sep 11, 2009 at 1:11 PM, Oscar Forth
>     > <os...@tr...
>     <mailto:os...@tr...>
>     > <mailto:os...@tr...
>     <mailto:os...@tr...>>> wrote:
>     >
>     >     TBH any form of enforced filtering just annoys me.  I FAR prefer
>     >     no filtering, my experience is that most PC gamers agree.  So
>     >     whatever you do for filtering ... make sure it can be turned
>     off!
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

-- 
Jason Hughes
President
Steel Penny Games, Inc.
Austin, TX

Re: [Algorithms] mouse smoothing

[Jeff R. <je...@8m...>]

Okay, seems we have a consensus :-P No filtering:

x += dx;

Just curious if there was some non-trivial approach that i didn't know about
that was maybe good for this. TBH I've never quite understood the importance
either, but some of our users are asking for it.

Cheers,

Jeff

On Fri, Sep 11, 2009 at 8:58 PM, Sylvain Vignaud <vi...@ii...> wrote:

> I've never seen a game where it helped/where I felt I played better with
> it. Whether I had crappy or good mouse.
>
> Nicholas "Indy" Ray wrote:
> > I agree that mouse smoothing in a FPS is not a good default! I've had
> > better experience with a few third persons games, but I figure only
> > then if aiming isn't important.
> >
> > Indy
> >
> > On Fri, Sep 11, 2009 at 1:11 PM, Oscar Forth
> > <os...@tr...
> > <mailto:os...@tr...>> wrote:
> >
> >     TBH any form of enforced filtering just annoys me.  I FAR prefer
> >     no filtering, my experience is that most PC gamers agree.  So
> >     whatever you do for filtering ... make sure it can be turned off!
>

Re: [Algorithms] mouse smoothing

[Sylvain V. <vi...@ii...>]

I've never seen a game where it helped/where I felt I played better with 
it. Whether I had crappy or good mouse.

Nicholas "Indy" Ray wrote:
> I agree that mouse smoothing in a FPS is not a good default! I've had 
> better experience with a few third persons games, but I figure only 
> then if aiming isn't important.
>
> Indy
>
> On Fri, Sep 11, 2009 at 1:11 PM, Oscar Forth 
> <os...@tr... 
> <mailto:os...@tr...>> wrote:
>
>     TBH any form of enforced filtering just annoys me.  I FAR prefer
>     no filtering, my experience is that most PC gamers agree.  So
>     whatever you do for filtering ... make sure it can be turned off!
>     ------------------------------------------------------------------------------
>     Let Crystal Reports handle the reporting - Free Crystal Reports
>     2008 30-Day
>     trial. Simplify your report design, integration and deployment -
>     and focus on
>     what you do best, core application coding. Discover what's new with
>     Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>     _______________________________________________
>     GDAlgorithms-list mailing list
>     GDA...@li...
>     <mailto:GDA...@li...>
>     https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>     Archives:
>     http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] mouse smoothing

[Nicholas \Indy\ R. <ar...@gm...>]

I agree that mouse smoothing in a FPS is not a good default! I've had better
experience with a few third persons games, but I figure only then if aiming
isn't important.

Indy

On Fri, Sep 11, 2009 at 1:11 PM, Oscar Forth <
os...@tr...> wrote:

> TBH any form of enforced filtering just annoys me.  I FAR prefer no
> filtering, my experience is that most PC gamers agree.  So whatever you do
> for filtering ... make sure it can be turned off!
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>

Re: [Algorithms] mouse smoothing

[Doug P. <dpo...@gm...>]

IMHO the best solution is simple filtering (like Jon posted above) with a
user controlled slider for the alpha value.


On Fri, Sep 11, 2009 at 1:11 PM, Oscar Forth <
os...@tr...> wrote:

> TBH any form of enforced filtering just annoys me.  I FAR prefer no
> filtering, my experience is that most PC gamers agree.  So whatever you do
> for filtering ... make sure it can be turned off!
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>

Re: [Algorithms] mouse smoothing

[Oscar F. <os...@tr...>]

TBH any form of enforced filtering just annoys me.  I FAR prefer no
filtering, my experience is that most PC gamers agree.  So whatever you do
for filtering ... make sure it can be turned off!

Re: [Algorithms] mouse smoothing

[Alen L. <ale...@cr...>]

Friday, September 11, 2009, 8:08:43 PM, Jeff wrote:
> What is your preferred method for smoothing mouse input for a game (for
> cases where the mouse is used to tilt and swivel a first person or third
> person view)?

Taking the mouse deltas from current and last frame and doing a
weighted average using frame times as weights seems to work great.

HTH,
Alen

Re: [Algorithms] mouse smoothing

[Jon W. <jw...@gm...>]

Jeff Russell wrote:
> Survey Time:
>
> What is your preferred method for smoothing mouse input for a game 
> (for cases where the mouse is used to tilt and swivel a first person 
> or third person view)?  "Too much" smoothing might be just trading 
> latency for smoothness, and too little might seem jerky, etc.  What 
> algorithms do people like?
>
> Jeff

To make this a little algorithms-relevant: Smoothing is like a filter 
for a signal. The signal is the delta mickeys (mouse ticks) per frame. 
The output is the amount to move the viewpoint. (The viewpoint itself is 
the integral of this signal).

Personally, I've never used more than a single-pole first-order filter 
(a k a a "leaky integrator.")

deltaMickeys = deltaMickeys * (1 - alpha) + newMickeys * alpha;
heading = fmod(heading + deltaMickeys * Scale, TwoPi);

Although perhaps you could treat the filter as a FIR (or even an IIR). 
Box-filtering as a FIR might work okay as long as you have a high 
sample/frame rate.

Personally, I prefer "alpha' to be 1.0 in the above equation, though. 
The hardware already has inertia, so smoothing shouldn't be necessary, 
unless your frame rates are so low that control is a problem, and at 
that point, smoothing isn't the right solution...

Sincerely,

jw



-- 

  Revenge is the most pointless and damaging of human desires.

[Algorithms] mouse smoothing

[Jeff R. <je...@gm...>]

Survey Time:

What is your preferred method for smoothing mouse input for a game (for
cases where the mouse is used to tilt and swivel a first person or third
person view)?  "Too much" smoothing might be just trading latency for
smoothness, and too little might seem jerky, etc.  What algorithms do people
like?

Jeff

Re: [Algorithms] Kinematic Collision

[Mat N. <mat...@bu...>]

I think you're comparing the best games from then to the worst games now.

MSN
-----Original Message-----
From: James Robertson [mailto:ja...@fu...] 
Sent: Friday, September 11, 2009 12:14 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] Kinematic Collision

TV and movies have been progressively dumbed down over the years to the 
point now where 90% of programs are formulaic garbage that even the 
simplest of morons can understand.  I don't see that the majority of 
games are much different to be honest.

Back in the days of way back the people who played games were people who 
enjoyed learning all those damn combos and skills and wanted something 
challenging that they could spend hours and hours playing, mastering, 
and ultimately perfecting.  Now that the market has broadened, more and 
more games have to appeal to newer types of gamer who consider games 
something to do when there's nothing on TV for half an hour.  They want 
their quick fix of fun that their brains have been trained into 
demanding but really don't want to have to think about what they're doing.



Danny Kodicek wrote:
>  > Danny Kodicek wrote:
>   
>>>> Absolutely; I can't see myself playing Manic Miner any more
>>>>         
>>> Actually, I recently played a port of MM for the first time 
>>>       
>> in 20 years, and
>>     
>>> it was as addictive as ever. Sometimes simple gameplay is 
>>>       
>> as good as it ever
>>     
>>> was.
>>>       
>> OK, you tempted me :) I went here:
>>
>> http://www.darnkitty.com/manic/
>>
>> ... But after a few minutes of repeated dying on the first 
>> level, I gave up!
>>     
>
> I wonder if that's the biggest change in gaming since those days: we're much
> less willing to spend ages getting pixel-perfect on a game. I was looking at
> a review of Arkham Asylum, talking about how great the combat was because it
> did all the work for you and you just pressed two buttons, and it occurred
> to me that lots of games have gone down this route recently, making combat
> much more about movement and button-mashing than about mastering complicated
> systems of combos. I'm not particularly saying one is better than the other,
> but it's interesting how much these things have changed. The selling point
> of most games is now about big worlds and exploration, rather than the kind
> of micro-world pinpoint accuracy of those days.
>
> Obviously, there's still plenty of that going on in the casual game market,
> though.
>
> Danny
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>   

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Kinematic Collision

[Mike S. <mik...@gm...>]

On Fri, Sep 11, 2009 at 6:54 AM, Nisarg Kothari <lee...@gm...> wrote:
>> 90% of programs are formulaic garbage that even the
>> simplest of morons can understand.
>
> This has always been the case. You just weren't paying attention before.

Is there an algorithmic solution to this problem?

Mike

Re: [Algorithms] Kinematic Collision

[James R. <ja...@fu...>]

Actually it's more likely I was paying too much attention.



Nisarg Kothari wrote:
>
>     90% of programs are formulaic garbage that even the
>     simplest of morons can understand.
>
>
> This has always been the case. You just weren't paying attention before.
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Kinematic Collision

[Nisarg K. <lee...@gm...>]

>
> 90% of programs are formulaic garbage that even the
> simplest of morons can understand.
>

This has always been the case. You just weren't paying attention before.