Hello, I have been using DosBox 0.65 with animator pro for a while now, and I must say I'm impressed with its performance. I have just one pet peeve though. When I use my Wacom tablet with dosbox, I have no way of controlling what coordinates of the tablet coorespond to the coordinates of the cursor in Animator Pro.
When I lift the pen up and move it somewhere else, the cursor in animator pro jumps to a different location, as one would expect, (this indicates that animator pro isn't using deltas for mouse movement) but the whole of the tablet only cooresponds to a small area on the animator pro screen. Even more confusingly, this area seems to randomly change when I move the regular mouse.
Now, I'm guessing that there's no built in option or setting in dosbox to deal with this sort of issue. So this post is to sort of probe for information about how dosbox handles mouse cursor coordinates, so I can get a basic idea of how one would go about modifying the source code to fix this behavior.
One potential avenue is the fact that Animator Pro software itself supports the usage of Summagraphics tablets (The protocol of which I have found some documentation/source code for), which originally connected through a serial port. It might be possible to grab OS cursor coordinates and translate directly to summagraphics tablet coordinates and tunnel them through an emulated com port. Problem is I have no idea how to do any of that given that 1) I am an extremely inexperienced programmer, and 2) I don't know anything about how the dosbox source is structured to deal with com ports or mouse coordinates.
Anyways, there you have it. Thanks for any help anyone can offer.
Yes. THe mouse works fine, though the wacom tablet uses absolute positioning, so even if dosbox has "captured" the mouse cursor, the wacom cursor does not behave as captured unless directly over the dosbox window.
Dosbox uses SDL, which may not fully support this kind of two-devices-in-one.
If you can compile the dosbox sources you might want to put some logging
into sdlmain.cpp to see what absolute and relative mouse positions dosbox
receives from SDL.
Ah the clip coordinates seem to be correct- As long as the mouse is not locked. When the mouse is locked, something really strange happens which I can't quite work out. The clip coordinates get bunged up. Regardless of that, animator pro still doesn't seem to be treating the coordinates correctly (even if they were correct), so I'm wondering what happens to the coordinates between the time they're collected from SDL, and handed off to the emulated program.
I have been running into the same problem with my hp TC1100 tabletPC with DosBox 0.72 (windows) trying to use the stylus input to play some classic games.
Instead of the cursor following the pen, it jumps crazily to the edges of the screen. I noticed in one case I could control it loosely by only moving the pen in the upper right quarter - as if the entire screen coordinates were mapped to the upper right 320x240. However, it is very jittery and unplayable!
Thinking it could be a problem with the resolution upsampling, I attempted tweaking the fullscreen resolution from original to my computer's native resolution of 1024x768, but it had not effect on the mouse tracking.
Hopefully I can revive this thread and build on ZenPsycho's investigations into the SDL. If anyone has any experience with this absolute coordinate handling instead of delta coordinate handling, I'd appreciate any ideas.
Okay so I had a good look at Mouse_CursorMoved() and determined through a process of selective commenting out, and experimentation, that, whatever happens with the mouse handling after Mouse_CursorMoved(), AutoDeskAnimator never sees the absolute coordinates (mouse.x and mouse.y), as a Mouse_CursorMoved that sets nothing but those results in a dead cursor. The only properties that seem to draw any response out of AAP is mouse.mickey_x and mouse.mickey_y, which appear to be deltas.
I can carefully scale the deltas to kind of almost match the width of the APP window, but the alignment still shifts around a bit in a somewhat unsatisfactory way. I have very little familiarity with the DOS os internals, but I suspect that whether the program looks at deltas, or at absolute coordinates is either completelly up to the program itself- Or absolute coordinates are not available from the OS. I don't really know which, but it doesn't matter in this case, since I don't think tweaking dosbox will fix that. I would dearly love to be proven wrong.
However, there is a ray of light, in that AAP includes a dos driver for a wacom tablet and a summagraphics tablet. That is, ancient serial port driven versions thereof. Since detailed technical documentation for the summagraphics tablet is readily available http://www.gtco.com/files/MM%20II%201201%20te … 20reference.pdf A good approach may be to create a new class that inherits from CSerial to essentially emulate the summagraphics based on tablet and coordinate information from our host OS. Cross platform tablet stuff is pretty sketchy though- SInce I only have my own mac to test on, it'd have to be a mac only fix at first.
Emulating a summagraphics would have other benefits as well, as it would open the door to a nice smooth compatibility to the host of various cad and drawing programs that also utilized this device. Unfortunately, unless I'm proven wrong by someone that knows more about DOS, I don't think it will bring much benefit for those interested in old point and click adventures. To you, I would suggest scummvm may be a better option. It does more than just LucasArts games!
It may be a while before I can get around to attempting this serial emulation project though. (It'll take me a while to understand the code enough to attempt something major like this) Anyone have any idea what kind of shit I'm getting myself into? advice? Last rites?
Well I never could actually find a way to retrieve absolute coordinates from inside dos. The assumption seems to be that a mouse just operates on deltas, end of story, and dos itself didn't keep track of any absolute position. (why would it need to? it doesn't have a windowing system). The mickey_x and mickey_y I found seem to be scaled deltas. Most programs I noticed just use those parameters. I would love to be proven wrong- I might be. I'm not an expert on dos, I just could not find out how to do it.
I don't think there were ever any APIs for that, except to implement some brand of tablet's protocol. That was only done for CAD systems, and autodesk animator, as far as I can find. That tended to be Summa Graphics. If you have a summagraphics tablet, you can in fact hook it up to a serial port and have it work in dosbox, for programs that support it.
Even if it is possible for a dos program to retrieve some form of absolute coordinate from a system call (which dosbox could satisfy, since SDL does have absolute coordinates available to it), the specific program would have to implement its mouse behavior to use that system call, and since that's closed source, you're screwed if it doesn't.
Unless it's an adventure game, in which case there's a better option than dosbox for a grand bulk of those: scummvm. (it's not just for lucasarts games anymore! They've got a cornucopia of adventure engine emulators hooked into it now) I'm pretty sure tablets work just fine with that. They can work that way since they don't depend on the ancient DOS system api to do their emulating.
for autodesk animator, I got the source code, and I'm working to release it under a BSD license, but I'm a very slow and unskilled programmer, so it's going to take me while. There are complicated technical and legal issues involved that I have to work through.
I think that theoretically it may be possible to add to dosbox a feature of calibrating tablet. So that you would be able to calibrate it for every program/game like we do with joystick. After that if you touched a screen in a different place dosbox will drive the currsor to the next position. Actually I think it would be not a dosbox but a sdl feature.
I have something new to report, and you had better believe I've gone to some great efforts to get this far! I have obtained the source code for Autodesk Animator Pro, which now lives at http://animatorpro.org.
I've just been up til 4:30am looking at the source code for both dosbox and this program, and here's what I've found:
which contains both the relative coordinates and absolute coordinates (based on the size shape and location of the SDL window) that SDL provides, and feeds them into Mouse_CursorMoved() which we find in
once again we are assigning to the mouse object both absolute and relative coordinates (in the form of "mickeys" which are resolution dependant measurements)
Information about the mouse is fed into the DOS environment via the dosbox function INT33_Handler. Setting AX register to various values, and calling Interrupt 33 in C code in dos, causes other registers to either set or get various properties from the mouse. In DosBox, the INT33_handler intercepts calls to interupt 33.
here we see AX=3 causes the absolute coordinates to be loaded into the CX and DX registers
1 case 0x03: /* Return position and Button Status */ 2 reg_bx=mouse.buttons; 3 reg_cx=POS_X; 4 reg_dx=POS_Y; 5 break;
(POS_X and POS_Y are aliases for mouse.x and mouse.y)
and here we see that setting AX=11 causes the relative coordinates to be loaded:
1 2 case 0x0B: /* Read Motion Data */ 3 reg_cx=(Bit16s)(mouse.mickey_x*mouse.mickeysPerPixel_x); 4 reg_dx=(Bit16s)(mouse.mickey_y*mouse.mickeysPerPixel_y); 5 mouse.mickey_x=0; 6 mouse.mickey_y=0; 7 break; 8
Well the problem I was having before was that Autodesk Animator was ignoring the absolute coordinates and only responding to the relative coordinates. When you combined this with a tablet, you end up with a rather lousy experience, as the emulated cursor's position gets clipped to the edges, and behaves in a relative manner, and this interacts badly with the absolution positioning of the pen cursor in the host operating system.
Now lets have a look at the mouse driver inside Autodesk Animator Pro:
so jmousey is an assembler function that takes a struct with 4 registers, and calls the int33 interrupt. We see that it's setting AX to 3... just to get the button status... ignores cx and dx.... goes on to call jmousey AGAIN with ax=11, and retrieves... .the RELATIVE VALUES. and calls it a day. In no case does this program ever pay any heed to the absolute coordinates that SDL and DOSBOX are handing to it on a silver platter.
So the quick fix here is obvious: New mouse driver for AAP, that actually pays attention to the absolute coordinates!
But after that we could go further and add pressure sensitivity. I just wonder what the most efficient/best way to get that information out of the OS and into AAP is? Is it reasonable to include the wacom SDK in dosbox? What are the implications of this? And then after that, full emulation of a serial ported wacom in DosBox? A wacom.cpp to go next to mouse.cpp... It's possible but is it worth the time, or would it be better to do a quick nasty *hack* where wacom pressure sensitivity ends up as extra parameters in interrupt 33, accompanied by the requisite driver changes in this one program? Fine for me, and my purposes, and I wouldn't expect such a hack to be accepted in the mainstream DOSBOX code, of course. Just thinking out loud.
How many other dos applications use a wacom or summagraphics tablet? I know there is at least one cad program that does... Any others?
Another approach is to write a fully external program that simply emulates a com port for dosbox to connect to. I have no idea how to do this though, but this would be somewhat more general. No idea .. too sleep deprived.
I'm runnin g acad dos 10 and 12 with dosbox and everything works just fine except for the mouse is sluggish. It overshoots the intended cursor destination sort of like the cursor was on the end of a long thin rubber stick making it difficult to pick entities. I'm using serial direct in the dosbox.conf and mouse lock on (the lock allows the middle button to function). The direct serail port mode improves the response but not enough for efficient use.
Have you had any luck tweaking the code and if so where and in what file would I find the directserial routine (if you know or can guess).
I could try to tweak it and maybe get results that may help you with tablet issues. It doesn't seem to be anything to do with the acad mouse drivers since running Norton commander in dosbox also has a sluggish mouse response but not as noticable. Any help would be appreciiated.