www.jaycrowe.com

Thank you for the detailed info Victor. That really helps me a lot to understand have the games that don’t support joysticks works with axis.

Sorry, I didn’t intend for you to play Q4 and write a sketch for the Orb to work in the game. I was trying to write it with hopes of getting more people interested. I am hopping that all this work/time you’re spending writing a sketch for Q4 will work with other non-joystick games as well without any or much tweaking. If it does maybe more people will be interested in your OrbShield and want to play the games they have (old or new) with their Orb or 4k. Right now I think everyone is laying back to see what happens with the programming and if it is wroth shelling out money for your device. I think it is and I don’t play games anymore!! I am very surprised that we haven’t heard from more folks on the subject...like Jay. Jay where are you? I thought you were excited about Victor’s OrbShield? Well, you know I’ll do whatever I can to help Victor...I just hope I don’t drive you crazy with all my questions!

I didn’t intend for you to play Q4 and write a sketch for the Orb to work in the game.

Heh--not to worry! I was working at the same problem from another direction. I've always wanted to really be able to use the orb in games that don't support joysticks at all; I just tried this with The Maw (a silly little two-hour game) and realized the frustration with the WASD mapping, so I was going to work on this anyway, and your issues with good mouse support really just motivated me to get on with it. Which is a Very Good Thing actually, because I'm seriously almost there! I hope to post something in the next few hours--it's not 100%, but it's a lot more solid.

First: Mouse updates are indeed the problem--they need to be a lot more frequent. I've now got something which works at about 10 msec, or so it claims, and that is fast enough to be smooth. However, to achieve this you have to turn off joystick updates--ie the joystick shows up as a device, but doesn't move. That's fine for this (since we're assuming we're dealing with a game that doesn't accept joystick input) but it's a bit strange. It also periodically will keep the same update a few times in a row, which is strange.

Anyway, with the faster updates I had to drop the mouse scaling a bit, but it feels really good and I was able to play a bit of Q4. I'm going to include a WASD template sketch in the next round of downloadable orb software, and may clean up a few more things.

The second part is the four-way mapping, which I'm actually going to describe here since I'm working on a documentation update and had to draw the pics anyway...

Okay, one way to map axes to keypresses is what we already have, ie you say "okay, the first third of the X-axis will be "A", the second third will be nothing for a null zone, and the third third will be "D", and then you can do the same with the Y axis and W/S, and you get this:


Good so far. But there's a problem: you have to push the orb pretty far to get it out of the dead zone. "Aha", you think (at least I did), "this is easy; we'll just make the size of the null zone smaller for each axis!" But then you get this:



Now, this doesn't immediately look bad. But it turns out that now it is very difficult to move just straight forward or left/right, because if you push fairly hard, you inevitably wiggle a bit and get into one of the (now massive) diagonal zones, which probably isn't what you wanted! This is incidentally a big problem when emulators like MAME emulate four-way or eight-way joysticks with analog joysticks--the feel really matters.

So what you really want in this case is to define "pie wedges" for each direction, so that the size of the "target region" increases the further you get away from the center, which you can do by finding x/y and using arctangent (in this case the atan2 function) to figure out where you are angle-wise. That way you just set a value for the "null region" at the center and you get this:



I've done a test implementation of this and it actually works pretty well (the pie wedges are more evenly spaced than they look in the picture)--at least in the Q4 demo I can run forward now without sliding left/right constantly, and with fairly tight sensitivity. Unfortunately the test implementation interferes with other keyboard bindings, so I'm going to spend a couple hours and work it in nicely. Hopefully uploads before too much longer!

ALSO, Ron: I had a case where it went berserk like you described with the demo earlier! Really crazy--it made it so that whenever I moused over a window, it closed it, and then the whole system shut down! It was a little like it was constantly pressing alt-F4, but I'm totally mystified as to how that could happen. So I believe you--but I've got no idea how to fix it!

As for more interest in the device, I think the amount of work you and I keep doing are good indications that it's still in beta, in a sense, which may throw folks off. With this next update and a few changes to some things, I may be satisfied enough to try making a proper release out of it (particularly if the Magellan and Orb5K support can be added) and that may attract a few more folks, not to mention if we can get this WASD problem licked so that it can come with a "drop in" replacement for many games, we'll be pretty close to a usable device. We're getting a surprising amount of power out of the little thing; I'm very pleased.

Okay, I thiiink this works (looks good to me although there are a few weirdnesses, notably that axes are working reverse of what I expect so I had to label the "forward" button as "S", but it works in practice, and I can't figure out why this is, yet).

Also moved a bunch of the loop logic into a "orbduino_loopfunc( buffer, translator, device )" function so the loop function can be smaller in most sketches.

Give these a try; WASD is the sketch, spaceorb_wasd is the new orb_translator.h (make sure it goes into the right place).

You can add button bindings for more functionality--this is just a barebones WASD with button0 = mouse0, button1 = mouse1. I'll actually make a Q4 sketch for the 4k and keyboard bindings to try and play the demo properly (grin). (edit--which I did; worked just fine. Short demo, though).

Sorry for the late reply Victor, I have a lot going on right now with my family.

I can see you have been very busy, your documentation and graphics are Outstanding! Plus, the new Sketch and Translator file are a lot smoother in Q4. I checked out your sketch and translator file, I noticed the changes you made and I am amazed as always of how intelligent you are to write these programs!

In Q4 I did experience drifting (look up/down or turn left/right when I let go of the ball) a couple of times, it might have been my Orb sticking. I also had a hard time aiming at an object when lightly moving the Orb ball but overall I think these new files are a great improvement over the last files for Q4.

vputz wrote:ALSO, Ron: I had a case where it went berserk like you described with the demo earlier! Really crazy--it made it so that whenever I moused over a window, it closed it, and then the whole system shut down!

I not saying I’m happy it happened to you but I am glad you know that the Orb can make windows act weird sometimes. I was starting to think that my PC had a problem.

vputz wrote:I'll actually make a Q4 sketch for the 4k and keyboard bindings to try and play the demo properly (grin). (edit--which I did; worked just fine. Short demo, though).

You made a 4k sketch for Q4? Send it this way, I just happen to have a 4k laying around needing a workout.

Something to look at:

http://netzhansa.blogspot.com/2009/04/r ... board.html

uses 'Teensy, a new AVR based development board'

Thanks, Ferengi. But unfortunately the proprietor of Teensy has taken a very strong stand that his firmware will remain closed-source and I am determined that this should be a 100% open-source project. He and I have exchanged moderately heated words on the topic actually. I have looked pretty seriously at the AVROpendous boards (based on the same AVR chip), and even purchased one, but they are not easily programmed via the Arduino environment. It really is a pity as either of these would take the job of the USB interface very nicely, thus making a very tidy device indeed.

In general, I feel that the hobbyist community surrounding the Arduino makes that platform a better bet for this despite the slight hardware mismatch. Should Teensy open itself, or AVROpendous provide Arduino environment compatibility, I may reevaluate things. All it will change in the software are a few pin definitions and a slightly different USB library, depending on the replacement chip's capabilities.

Also, Ron: Here's what I used for Q4; 1-6 are weapons, 7-8-9 are reload, jump, duck, and I think B is flashlight, but you can change those. Oddly, I didn't notice the drift so much with the 4k, but I've no idea why that would be; could just be that I had the mouse available for compensation.

Thank you Victor, your 4k sketch for Q4 is prefect!! I tried it both ways, 4k & mouse then just using the 4k. I don’t know why movement is so much smoother and the precision is outstanding using the 4k alone then the Orb? I still have a lot going on here but I need to check your WASD Sketch again with another Orb (I have a new Orb in the box somewhere?) when I have a chance...too much difference between the two sketches!

I am curious about why you have “translator.set_axis_key_bindings( axis_key_bindings, 10 )” in both WASD and 4k sketches when you only have 4 axis key bindings in the sketch? Is it so more axis key bindings can be added to the sketch?

Yeah, I'm not sure why the orb feels more "drifty" than the 4k--when it seems like the orb should be less drifty, since the 4k drops packets periodically. I'm still working that one out!

[quote]I am curious about why you have “translator.set_axis_key_bindings( axis_key_bindings, 10 )” in both WASD and 4k sketches when you only have 4 axis key bindings in the sketch? Is it so more axis key bindings can be added to the sketch?/[quote]

Hmm. You should never set the number in set_XXX_key_bindings to anything more than the number actually supplied, or Bad Things could happen (basically the orb will read from uninitialized memory which could do weird stuff).

Basically though, what you see is me being lazy. Those lines are "commented out" with // characters, which just means they are never compiled (they aren't there). I did that when I was testing the fourway bindings in case I needed them back. Commenting them out has the same effect as just deleting them. When I update on the site, I'll try to make sure those lines are gone completely so they don't confuse people.

I actually enjoyed the Q4 demo enough to buy the game for $5 (heh)--seems enjoyably basic and old-school!

vputz wrote:Yeah, I'm not sure why the orb feels more "drifty" than the 4k--when it seems like the orb should be less drifty, since the 4k drops packets periodically. I'm still working that one out!

I played Q4 awhile tonight with a new Orb, after a short period of time the drifting was so bad I couldn’t control it. When I tried to exit the game my mouse was uncontrollable also and I had to unplug the Orb so the mouse would work normally. This is just a thought, could this drifting problem be the result of the Orb being designed to be used vertical or horizontal?

Thank you for explaining the meaning of the (//) in your sketches and not to add more key bindings then the ones actually supplied. I printed your WASD and SpaceBall Q4 sketches to compare them and noticed a few differences I wanted to ask you about. First, I see you used “button mouse bindings” in the WASD sketch and “button key bindings” in the SpaceBall Q4 sketch? If I wanted too, could I add more “button mouse bindings” or “comment out” the ‘button mouse bindings’ and add ‘button key bindings’ to the WASD sketch? Second, in the WASD sketch you have “const PROGMEM short Polarity[] = { 1,1,1,-1,1,1};” and in the Q4 it is “const PROGMEM short Polarity[] = { 1,-1,-1,-1,-1,-1};”? I was just wondering why WASD has only one dash in the middle of the ones and Q4 has them between all the ones.

vputz wrote:I actually enjoyed the Q4 demo enough to buy the game for $5 (heh)--seems enjoyably basic and old-school!

Yea, I’m not surprised, I like Q4 also. In my younger days I was wild about Quake and played all the Quake games and add-ons until I lost interest when the Orb didn’t work with newer games. Tonight I actually played past the beginning of the game and whacked some bad gays and I got whacked!

after a short period of time the drifting was so bad I couldn’t control it. When I tried to exit the game my mouse was uncontrollable also and I had to unplug the Orb so the mouse would work normally.

Oh, hang on! That's actually good information. Whether I can do anything about it remains to be seen.

Okay, what sometimes happens is that, if the mouse update interval is too short, the mouse updates just sort of pile on top of each other and the Arduino doesn't have time to update them correctly. There are a couple ways of dealing with this, none of which I do particularly well-- right now I just change the mouse update time. Let me think on this, but we may be able to do something. One idea might be to check and see if any messages are pending and then either skip the one about to be sent or add it to the next one, etc.

I see you used “button mouse bindings” in the WASD sketch and “button key bindings” in the SpaceBall Q4 sketch? If I wanted too, could I add more “button mouse bindings” or “comment out” the ‘button mouse bindings’ and add ‘button key bindings’ to the WASD sketch?

You can do either--or both. Since there are only two mouse buttons (or three) it doesn't make much sense to bind more orb buttons to them, but you sure could (in fact you could probably make two bindings of one button, one two each mouse button, and have one orb button press both mouse buttons. Not sure why, but you could). And you can have one orb button bound to either a mouse button, keyboard key, or both. So sure, you can do either of those things.

Second, in the WASD sketch you have “const PROGMEM short Polarity[] = { 1,1,1,-1,1,1};” and in the Q4 it is “const PROGMEM short Polarity[] = { 1,-1,-1,-1,-1,-1};”? I was just wondering why WASD has only one dash in the middle of the ones and Q4 has them between all the ones.

The polarity means which way the axes map; a "1" means that "left" on the orb is "left" in the computer; a -1 means that "left" on the orb is "right" on the computer. For some reason, the mouse axes worked opposite the way I expected, so I put the "-1" in for the WASD sketch.

The reason the WASD sketch and Q4 sketch are different is that the WASD sketch was for the orb and the Q4 sketch was for the 4k. Ordinarily you would just use the polarities and axis maps in orb_translator.h:
...but since the mouse was working backward, I had to change the 4th entry to the reverse of what it was, so Polarity_spaceorb_face went to {1,1,1,-1,1,1} and Polarity_spaceball_4k went to {1,-1,-1,-1,-1,-1}.

Cooking for some friends today, but if I have some free time in the next few days I'll think about that mouse activity and try something a bit more clever than what we're doing now.

vputz wrote:Oh, hang on! That's actually good information. Whether I can do anything about it remains to be seen.

I'm glad my mouse screwing up was good information to you Victor. (Grin) What you said about the mouse updates piling on top of each other and the Arduino not having time to update them correctly makes sense to me. Now I know why the drifting slowly became uncontrollable.

vputz wrote:you can have one orb button bound to either a mouse button, keyboard key, or both. So sure, you can do either of those things.

Thank you for all the great information. I don’t think I would add more button mouse bindings but I will add button keyboard bindings to the WASD sketch later on when the drifting problem is solved.

vputz wrote:The polarity means which way the axes map; a "1" means that "left" on the orb is "left" in the computer; a -1 means that "left" on the orb is "right" on the computer. For some reason, the mouse axes worked opposite the way I expected, so I put the "-1" in for the WASD sketch.

I remember reading one of your earlier post and you commenting on the Orb/mouse axis working the opposite on the computer. Now, what I understand is the (1’s) are axis and means “left” on the Orb but on the computer it’s right. When you added the dash before one (1) I am assuming you only changed direction on one axis in the Orb sketch and five in the Q4 sketch...is this right? I know you’re busy and I am also so you don’t need to go into great detail Victor if I am wrong, I’m just trying to understand how the dashes worked with the axis in your sketches.

I am assuming you only changed direction on one axis in the Orb sketch and five in the Q4 sketch...

Ah, sure, I should have explained that a bit more. No, I changed the same axis on both--but in the orb sketch, in was a Spaceorb, so it went from {1,1,1,1,1,1} to {1,1,1,-1,1,1}, and in the Q4 sketch it was a 4k, so it went from {1,-1,-1,1,-1,-1} to {1,-1,-1,-1,-1,-1}; in both cases, the 4th number (rotation about the x axis, or pitch) is what is reversed.

Not sure when I'll get to orb work, although I may have seen a related issue in that the WASD sketch would periodically get a key "stuck" so that I would have to unplug/replug (I'm using my 4k to play Fable, just to force me to use the orb more). Although when I think about it, I'm trying to figure out why the orb would have more frequent mouse updates than the 4k and not coming up with any good ideas. If you have time, try adding the line "translator.mouse_interval = 20;" in the setup() function of the WASD sketch and play with that number a bit to see if it gets smoother (the higher the number, the less frequent the mouse updates, so if it's too big the mouse seems jerky, and if it's too small the updates pile onto each other). I'm not sure it will help things, but it might.

vputz wrote:I should have explained that a bit more. No, I changed the same axis on both--but in the orb sketch, in was a Spaceorb, so it went from {1,1,1,1,1,1} to {1,1,1,-1,1,1}, and in the Q4 sketch it was a 4k, so it went from {1,-1,-1,1,-1,-1} to {1,-1,-1,-1,-1,-1}; in both cases, the 4th number (rotation about the x axis, or pitch) is what is reversed.

Thank you Victor for taking the time to explaining how the dash works with the axis. I now understand how the dash works with the axis (1's) in your sketch.

I had a chance to play Q4 a couple of hours tonight using your “translator.mouse_interval” file in the WASD sketch. The file worked great Victor! I increased and decreased the value and found 20 or 21 the best (very close) for smoothness without drafting or jerking. I also cleaned up the canceled out files and added 3 button key bindings. I now have a very useable sketch for playing Q4...thank you!

Give it a go, Willy! I need to update the software on the site, and things have gotten a little busy, but hopefully I'll have time in a few weeks to add support for the Magellan SpaceMouse (and thus hopefully the Spaceball 5k) and get that pushed out (my Magellan arrived finally so I have something to test).