Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Thanks to your log files this is now possible:
Huge image showing Hourglass running a mouse game: http://i.imgur.com/q7OzXVI.png
The game is called Meteor and did not spawn a window before because before spawning a window, the game checked if you had a compatible mouse, and if not it would terminate.
There is still A LOT to implement regarding mouse support, but... PROGRESS!
Special thanks to Scepheo and a few other friends of mine who helped me get this far.
For those of little faith, the game is freeware and can be gotten here:
http://www.jbplay.com/games/meteor/
Try starting it in Hourglass r81.
(Note: The game fails under Windows 7, don't know why)
Way to go, Warepire! Looking forward to your work with integrating the mouse culminating in a new "mouse support" version of Hourglass.
For another game that we know runs in Hourglass, you could try testing out the mouse with Braid's jigsaw puzzle sections.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
I don't have the money to buy that game right now, so I cannot test it. (I know I could pirate it, but I prefer to work with guaranteed official versions when I am testing for compatibility)
OpenTyrian also works both with and without mouse imput, and you can run it on Hourglass. Although you might not be able to playback it completely correctly, it should be enough for this purpouse.
http://code.google.com/p/opentyrian/
"An artist who can’t take constructive critique on their work is only hurting themselves and their potential.
Conversely, and artist that can’t communicate a critique in a constructive way isn’t helping anybody."
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I've got a rather interesting thing to say about mouse input for Hourglass.
Note: I've not messed with the download you provided :P, so forgive me if I am wrong here...
Are you going to provide actual "real" mouse movement. For example, say point A is on the left of my screen, Point B in the Middle , point C on the right. For me to get from Point A to point C, it is required to go to point B. My thought is, all TAS's would be invalid if you're able to go from point A without actually having to move towards Point B, before Point C; and can just go straight to Point C.
Basically, if I can be at point A, enter frame advance mode, then move the mouse to Point C, then frame advance again... on playback, it'd appear that the mouse is teleporting.... So my question is, perhaps code a "mouse" in hourglass as well, instead of using the real mouse?
Are you going to provide actual "real" mouse movement. For example, say point A is on the left of my screen, Point B in the Middle , point C on the right. For me to get from Point A to point C, it is required to go to point B. My thought is, all TAS's would be invalid if you're able to go from point A without actually having to move towards Point B, before Point C; and can just go straight to Point C.
If A and C are near enough (which might actually be over hundred pixels apart, don't know about the API), fast enough mouse motion can jump from one to other in one step, bypassing B.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Remember, TASes are supposed to be super-human, if the game accepts the input, then it's all fair to me.
Otherwise we might as well ban maximum range on analog sticks and left+right on d-pads because in my opinion it's all the same abuse. (Input that wasn't intended to be possible)
Remember, TASes are supposed to be super-human, if the game accepts the input, then it's all fair to me.
At least with some systems apparently whatever electrical protocols of controllers can represent is fair game (including messing with controller type identification).
I think that a typical mouse can only move (signed byte) pixels in X and Y diections in a given message, if this protocol is still in use: http://en.wikipedia.org/wiki/Mouse_(computing)#PS.2F2_interface_and_protocol
Although, couldn't programatically moving the mouse around escape this limitation? I know that WM_MOUSEMOVE messages use two bytes and just say the final location of the mouse, so there's no 'one byte' limitation there. If you programatically move the mouse more than 128 pixels it would just create 'one mouse movement' not chunk it up, right?
Finally, my understanding is that a mice informing the computer about a mouse movement is interrupt based (so can happen as often as it wants, whenever it wants) - so any game that polls for mouse movement once per frame instead of learning about it via interrupts can have arbitrarily far mouse movements in one frame, regardless of above concerns.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
creaothceann wrote:
Warepire wrote:
if the game accepts the input, then it's all fair to me
Why should we respect the game's opinion on that matter? :)
Just think about touch devices. It's still a cursor, and you can teleport it anywhere. Mouse input on Windows doesn't strictly mean it's a mouse.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
