mouse clicking

[Jasper1984]

but in all GUIs i have ever used, it works like this: when doing mouse-down on a button, then moving away and doing mouse-up somewhere else, the button is not clicked. that is useful when you do mouse-down, then "ow, i do not really want to do that", and then move away. it would be counter intuitive otherwise.

Meh, all those guis are wrong on that. Anyone _ever_ clicked down on a button and moved away to cancel?

[Gnomre]

Meh, all those guis are wrong on that. Anyone _ever_ clicked down on a button and moved away to cancel?

I do all the time, but only rarely in spring

[Hacked]

if the behavior in spring worked like a normal app then i wouldnt feel the difference
but sometimes spring runs slow and even if i mouserelease on the button itself, if i move my mouse away before the next update if registers the mousedown in the wrong spot

for me its only really a problem when i play bigger games

[ZellSF]

but in all GUIs i have ever used, it works like this: when doing mouse-down on a button, then moving away and doing mouse-up somewhere else, the button is not clicked. that is useful when you do mouse-down, then "ow, i do not really want to do that", and then move away. it would be counter intuitive otherwise.

Meh, all those guis are wrong on that. Anyone _ever_ clicked down on a button and moved away to cancel?

I have, in situations where I wouldn't know another way of cancelling. I do know how to cancel building stuff in Spring though, so I support changing this behavior.

[Pxtl]

I'm pretty sure momfreek is wrong. The issue is not "mouseup not mousedown" because this doesn't happen in other engines. If your computer is running slowly, you don't click the wrong things because of the mouseup event, because the location of the mouseup event is tied to it.

After all, I don't think any of us are dragging while we click.

Now, I haven't seen the code, but I'll bet the location isn't being stored. That is, the logic is
"click event added to event cue"
"event cue processing"
"during event cue processing, fetch the location of the mouse".

Now, the problem is that a whole game frame passes between that click and the processing, and if you're running a little slowly that can be a lengthy time period and the mouse may have travelled far.

The logic should be
"click even added to event cue including mouse location"
"event cue processed, fetching the location from the queue"

The fact that accidental drags are happening is because the mouseup and mousedown events are happening a whole game-frame apart. Mousing needs to exist in its own thread, and every event needs to be rigidly tied to the location that the event occurred, not sloppily fetching the location when a processor gets around to seeing it.

[imbaczek]

The problem is that mouse messages are processed in the same thread as the rest of the game. That causes all those mouse issues when fps gets low. HW cursors help a bit with movement, but not with clicks.

I think the proper way would be to make the event-handling use a proper producer-consumer design, that is putting mouse events in a queue when they happen and processing them in a different place later.

[Wisse]

I move mouse faster than I click so I'm constantly selecting wrong buildings. Usually the one on the right side of what I meant to select. That's happening to me all the time no mater what my fps is, so I strongly support "on mouse click" rather than release. Game registers click instantly when I release mouse, it's my fault, releasing it over the wrong building because I already pressed where I wanted and I'm going for build as fast as I can.
This could possibly show more because I'm used to super fast mouse movement (1-2cm on my mousepad covers whole screen by width).

I never had any issues I could relate with fps either. It just get slow in big games, but by than everything runs slower so it doesn't bother.

[momfreeek]

I'll compile 77b5 with this patch for you guys.

ooh. any progress on this? where to download? I've no idea what I'd need to do to compile a syncing binary.

I'm pretty sure momfreek is wrong. The issue is not "mouseup not mousedown" because this doesn't happen in other engines. If your computer is running slowly, you don't click the wrong things because of the mouseup event, because the location of the mouseup event is tied to it.

As others have mentioned, this problem occurs at high fps.

IThe fact that accidental drags are happening is because the mouseup and mousedown events are happening a whole game-frame apart.

At a decent fps, mousedown and mouseup will happen many frames apart:

http://en.wikipedia.org/wiki/Button_mashing
Takahashi Meijin is considered to be the fastest button masher in the world, with a record of 16 presses of a button in one second.

http://www.gametrailers.com/player/user ... mments_top
13 times a second (his fingers are a blur)

^ Gives an idea of finger responsiveness compared to cpu responsiveness (and these guys are hammering a game controller like crazy mofos, not using a mouse). Note that fingers are stronger and more responsive when gripping than opening their grip (its easy enough to test that for yourself). If you aim, click, aim somewhere else, the difference in position between mousedown and mouseup is far more than the hardware cursor might correct at a decent fps. At lower fps, the advantages of the hardware cursor will be scuppered by this problem.

Anyway, there's not really any need to argue this point cause you can check the difference for yourself.

Please try the patch. Click build buttons and place buildings as fast as you can. I think you'll be surprised how fast and accurate you can do it compared to the current mouse handling which forces you into the habit of clicking very carefully. IMO the difference speaks for itself.

[lurker]

http://evolutionrts.info/~lurker/noresi ... spring.zip (should still sync, but I shuffled some files since the last compile)

The ideal version of this code should probably make sure you either release the mouse on the same command button or release the mouse within a half second of pressing down. That lets you have quick, moving clicks and also won't force you into something you didn't finish clicking on.

[momfreeek]

didn't work for me It briefly shows a command window and exits... no infolog or anything

I just swapped the original exe. Is there anything else I need?

[lurker]

Shouldn't need anything else. Is there anything helpful in infolog.txt?

[Wisse]

I get same error. I got it before this mouse patch was added (when it was only no fullscreen fix) also.