Values for tablet pressure in ArtEffect

[Michael Sykes]

First of all the main question.
If I use full tablet emulation in WinUAE and set ArtEffect to "R. Schwingel" the pressure support works. Well, sort off.
It seems the input values for min/max pressure are too big.
Is there any way to change that? Maybe change the emulated values for pressure in the next version? I attached a screenshot to demonstrate the problem.

Another thing is that I have to move the pointer to the upper left corner of the screen with my real mouse before I can start using the pen. Or it will jump around like crazy.

Also if I move the pointer(with pen) to the upper 2 lines of a screen it is "warped" down to the bottom of the screen. No matter if pal or p96.

I use a wacom intous pro if thats of some use.
ArtEffect was the only tool that worked for me with pressure.
DPaint,TV Paintand other stuff works but all without pressure support.
Tested with and without tablet.lib emulation.

[emufan]

DPaint want a special tablet.library, which you can find in the AccuPoint packages.

#1) well, if winuae emulates this lib - i'm not sure whats the problem, but on the disks there is some kind
of config tool (IIRC), which may help.

[Michael Sykes]

Most of the tools expect a tablet conected to the serial port and do only work on real hardware.
This is a usb tablet and WinUAE is somehow injecting the tablet data from windows into the amiga input.device and emulates a tablet.library if enabled.
So from the Amiga OS side there is nothing conected on the serial port.
I guess the R. Schwingel driver in ArtEffect just expects another tool to do the same. Thats why it works. It gets the data from the input.device but that data is unfortunately not correct.

[emufan]

and some sort of virtual com port which maps to a usb port. like this one ?
then you could switch wihin winuae the serial port to COM1 - the vcp which maps to your usb tablet.

Virtual COM port (VCP) drivers cause the USB device to appear as an additional COM port available to the PC. Application software can access the USB device in the same way as it would access a standard COM port.

no clue if this can work at all.

btw: Wacon_150 is done by Roland Schwingel.

[Toni Wilen]

All tablet values (including pressure) ranges are not documented in input.device tablet command documentation. Tablet can tell min and max values but recommended range is not documented and "too large" (but still fully in range of documentation) values won't work with many programs.

I have no idea what is "correct" range or if programs were only tested with some popular tablet and other tablets copied same behavior or something..

[Michael Sykes]

Toni can't you add something like an offset slider so the user can adjust the min/max values translated from Windows to the emulator?
There is also some kind of deadzone to configure in most of the real drivers. Maybe thats the problem?
Feels like the threshold for painting and the deadzone overlap. Thats why the brush is so big when I press really soft.
A bit more room for configuration would be nice.

[Toni Wilen]

No because it was not needed with real tablets (at least some). It needs to be done correctly!

[emufan]

the Wacom_150 package has some debuging tools for the wacom tablets, comes with source and may help to make some improvements?!

[idrougge]

I have a cheap Wacom tablet connected to an Amiga in case you need some testing. Don't know if it supports pressure at all, though.

[Michael Sykes]

Originally Posted by emufan

the Wacom_150 package has some debuging tools for the wacom tablets, comes with source and may help to make some improvements?!

There are indeed 3 tools to read the values.The two for serial.device don't work.
And the one that reads directly from the input.device shows 0-65280 for pressure.

Maybe thats the maximum it can cope with but the range of most tablets is something like 0-2048.
Does it really have to be like 2048 on pc = 65280 in Amigaland?
Or should it be 2048 pressure points on the Amiga,too. More or less depending on the model of the tablet.

To my surprise even the tilt of the pen seems to be shown.
Are there any tools to use that feature?

[Toni Wilen]

I have seen that testing tool, unfortunately it only shows the values, not expected range. (and as I said, API has min and max value reporting but as I also said, it does not seem to work as documented.)

Someone with compatible tablet need to run this program and report all min and max values. (including tilt)

EDIT: without tilt values, I guess I can assume same range as pressure should work. Anyway, at least pressure range is needed.

[hexaae]

Since we're talking about ArtEffect 4.0...
Is it normal that opening it on Workbench public screen (32bit 1080p UAEgfx with Picasso emulation) 2-3 times it alters the first palette colors (= windows and background colors)? Was it a known issue?

[Michael Sykes]

Originally Posted by idrougge

I have a cheap Wacom tablet connected to an Amiga in case you need some testing. Don't know if it supports pressure at all, though.

If it supports pressure can you download the testing tool(AmigaOSTabletAPI) from the aminet and give us a hint what the max value for pressure is.
It's in "Wacom_150.lha" in the Develop drawer.

@ Toni
Is there any way to change the left klick threshold?
Or even better can I disable the leftklick for the pen somehow?

And how can I disable the Mouse?
Even if I set it to "none" it is still there.


I can't klick anymore but it still moves the pointer.Did I miss something?

As long as the the mousepointer is moved to the upper right corner of the screen, with my mouse(or the touch mouse of the tablet) thats not a big deal.
But if it moves (just a few pixel to the right or down is enough) the pen behaves not as expected.

As soon as you press the tip of the pen onto the tablet the pointer jumps towards the position of the (other?) pointer(moved by the real mouse) and back to the original position of the pen.

It seems to be related to the klick event sent by the pen to simulate a left mousebutton. It does not happen constantly only for a microsecond.
If you hold it down tight it draws normal. Once you release it it jumps again.

Maybe it's the left klick, send by the tablet, that confuses the system to think it has to use the mouse now. Wich was at a different position as the pen the last time it checked.

Could WinUAE move the real mouse to the position of the pen or to the upper left corner once the pen is used?
Something like force 0;0 for the coordinates of the Amiga mouse as long as the pointer is moved by the pen or disable all input events for the mouse.

EDIT:
@hexaae: Yes thats true. Just let it use it's own screen.

EDIT2: in Xi Paint it is possible to define a range from -9999 to 30000. If I set it from 0-30000 it has the maximup pressure when I push the tip in around 40%. Thats exactly how far I have to press it to show me ~30000 in the Wacom tool.

When I pass that point it stops drawing untill I release pressure.

[Toni Wilen]

Originally Posted by Michael Sykes

Is there any way to change the left klick threshold?
Or even better can I disable the leftklick for the pen somehow?

And how can I disable the Mouse?
Even if I set it to "none" it is still there.


I can't klick anymore but it still moves the pointer.Did I miss something?

Do you mean workbench or arteffect only?

Tablet emulation replaces mouse but this API probably is not used by most (old) drivers because it was only implemented in v39. Intuition internally converts them to mouse movements automatically.

Probably best solution is to emulate the serial tablet protocol assuming this was the most common way many programs worked. (instead of using AOS supported method because it was implemented too late and there was no (?) drivers that used it)

[idrougge]

http://www.haage-partner.de/amiga/ar...e.htm#frage117

Which tablet drivers support pressure sensitivity with AE?

ArtEffect uses the pressure data send by a Kickstart 2.x compatible way (in an intuimessage). Most existing tablet drivers do not support this NORMAL way, they instead are providing their own mechanism to receive pressure data. But we don't want to implement the private pressure mechanism of several tablet drivers. So for now Tableau from ESCENA is the only one that support this with ArtEffect.

[Michael Sykes]

I think that was for an older version of AE. There are also drivers for the metioned tablet from H&P for the tableau. But the Wacom driver from Roland Schwingel does the same as Tonis emulation. It gives intuition information about the position and pressure. AE4 supports that system friendly way. XiPaint4 also supports it.
I mean last time I checked it, it worked (sort of) with the R. Schwingel driver selected in AE4.
But I still think the values that WinUAE translates from real tablet to emulated tablet interface are off scale. Thats why both programs act strange if you enable pressure support. It's as if the whole range is quenched into the first 5-10% of the tips total(physical) pressure range.
once you go over that dit stops drawing(xipaint) or acts strange(AE4).

Originally Posted by Toni Wilen

Do you mean workbench or arteffect only?

I want do disable the leftklick for the pen if possible. Everywhere!
From what I see in the Wacom1.5 driver it was an option to do that.

It seems if i set the pen on the virtual paper the simulated mousclick makes the brush as big as if you press the pentip fully in.
Everytime you set the brush on the paper. So every first tip is full size brush no matter how soft the pressure is. As I wrote at least in AE4 it works sort of.

EDIT: I disabled all pen buttons for WinUAE in the wacom tool under windows.Just in case.Same effect. Exept I cant use the pen in the WinUAE config window anymore.


Forget about the jumping mouse so far. If I move it to the upper left it works.
Most important for me is pressure.

Originally Posted by Toni Wilen

Tablet emulation replaces mouse but this API probably is not used by most (old) drivers because it was only implemented in v39. Intuition internally converts them to mouse movements automatically.

Probably best solution is to emulate the serial tablet protocol assuming this was the most common way many programs worked. (instead of using AOS supported method because it was implemented too late and there was no (?) drivers that used it)

That would mean it could work in TV Paint. That would be soooo awesome.

But the way it is now seems to work with AE and XiPaint.
At least there are some effects if you enable pressure.
I still think it maybe a good idea to add the slider or somthing like that to tell winuae how to translate the 2048 steps from my pen to my Workbench.

The XiPaint manual claims there is no way that intuition can tell the software details about the real range of the pen and thats why you have to define a minimum, a maximum and a threshold.

So just in case there is no way to do so like in AE and it expects some values fom random real HW wouldnt it be a good idea if we(the user) had a way to experiment with different values?

[emufan]

you could try to contact Fabrice aka TVPaint - may happen, he can help somehow.

[Toni Wilen]

From intuition.h:

/* New for V39, Intuition supports the IESUBCLASS_NEWTABLET subclass
* of the IECLASS_NEWPOINTERPOS event. The ie_EventAddress of such
* an event points to a TabletData structure (see below).
*
* The TabletData structure contains certain elements including a taglist.
* The taglist can be used for special tablet parameters. A tablet driver
* should include only those tag-items the tablet supports. An application
* can listen for any tag-items that interest it. Note: an application
* must set the WA_TabletMessages attribute to TRUE to receive this
* extended information in its IntuiMessages.
*
* The definitions given here MUST be followed. Pay careful attention
* to normalization and the interpretation of signs.
*
* TABLETA_TabletZ: the current value of the tablet in the Z direction.
* This unsigned value should typically be in the natural units of the
* tablet. You should also provide TABLETA_RangeZ.
*
* TABLETA_RangeZ: the maximum value of the tablet in the Z direction.
* Normally specified along with TABLETA_TabletZ, this allows the
* application to scale the actual Z value across its range.
*
* TABLETA_AngleX: the angle of rotation or tilt about the X-axis. This
* number should be normalized to fill a signed long integer. Positive
* values imply a clockwise rotation about the X-axis when viewing
* from +X towards the origin.
*
* TABLETA_AngleY: the angle of rotation or tilt about the Y-axis. This
* number should be normalized to fill a signed long integer. Positive
* values imply a clockwise rotation about the Y-axis when viewing
* from +Y towards the origin.
*
* TABLETA_AngleZ: the angle of rotation or tilt about the Z axis. This
* number should be normalized to fill a signed long integer. Positive
* values imply a clockwise rotation about the Z-axis when viewing
* from +Z towards the origin.
*
* Note: a stylus that supports tilt should use the TABLETA_AngleX
* and TABLETA_AngleY attributes. Tilting the stylus so the tip
* points towards increasing or decreasing X is actually a rotation
* around the Y-axis. Thus, if the stylus tip points towards
* positive X, then that tilt is represented as a negative
* TABLETA_AngleY. Likewise, if the stylus tip points towards
* positive Y, that tilt is represented by positive TABLETA_AngleX.
*
* TABLETA_Pressure: the pressure reading of the stylus. The pressure
* should be normalized to fill a signed long integer. Typical devices
* won't generate negative pressure, but the possibility is not precluded.
* The pressure threshold which is considered to cause a button-click is
* expected to be set in a Preferences program supplied by the tablet
* vendor. The tablet driver would send IECODE_LBUTTON-type events as
* the pressure crossed that threshold.
*
* TABLETA_ButtonBits: ti_Data is a long integer whose bits are to
* be interpreted at the state of the first 32 buttons of the tablet.
*
* TABLETA_InProximity: ti_Data is a boolean. For tablets that support
* proximity, they should send the {TABLETA_InProximity,FALSE} tag item
* when the stylus is out of proximity. One possible use we can forsee
* is a mouse-blanking commodity which keys off this to blank the
* mouse. When this tag is absent, the stylus is assumed to be
* in proximity.
*
* TABLETA_ResolutionX: ti_Data is an unsigned long integer which
* is the x-axis resolution in dots per inch.
*
* TABLETA_ResolutionY: ti_Data is an unsigned long integer which
* is the y-axis resolution in dots per inch.
*/

"This number should be normalized to fill a signed long integer". In other words, this documentation says range should be HUGE. This is the only part where anything about range is mentioned.

In other words part 2: most likely no one has used this API..

[Michael Sykes]

Before someone reads all my thougts just go to my last post. I think thats more than enough information...
^^

All I can tell you is that the maximum range XiPaint prefs supports are -9999 to 30000.
Anything below or above will reset to the last valid value entered last time.

I was testing different values and I found that it works best(so far,still testing) with:
min: -9999
th: -9998
max: -1

With these values it behaves realy good but now the lower 20% of the pen pressure dont work.
Wich means it makes a fat white dot once I set it on the tablet but does not draw if i move it(mouse click?). Now when I press harder it slowly starts drawing more and more. As expected.

EDIT: the fat dot also appears when you release the pen tip from the surface.That must be the lmb. it's the exact same pressure I have to use to see the klick event in that tiny API tool. So it draws a dot on every klick and release message. but respects the pressure in between those two events.
And about the values for xi-paint if I set the threshold closer to zero the range for the pressure gets smaller.
If i set maximum to a positive value it starts behaving strange again. Default was something like -126,1,26345.

At least some progress. But why do I have to tweak it to negative values?

EDIT2:

I used the windows config to configure the pressure send from the driver to the app.
The result looks even better than with the tweaked XiPaint prefs alone. It feels more linear now on the Amiga side. Or the range to controll it is/feels bigger.

EDIT 3: Toni how are the values from the pen translated by the emulation?
Is it possible that there are just too many steps for the pressure.

Because if I press really hard(80%+) the brush gets dark after it got from 0-100% brightnes correctly and starts over again getting brighter. There is a small gap in between the two ranges.

Didn't realize it at first because I normaly don't have to press it that hard and was too fast on the last 20%.
But you can even see it in the sreenshot if you look closely. Thats for sure not a variance in the pressure of my hand.

Another thing is if I set the pen to 1024 steps instead of the 2048 it can do, it works better and the pressure doesn't feel as jerky/hard to controll.

Maybe you could convert whatever input value windows gives to 512 or 256 pressure steps on the Amiga side. Or transmit only every 2nd or 4th change, like frameskip.
Simply divide whatever the driver sends by 2 or 4. I doubt that hardware from the 90s came up with over 2000 different values. Maybe the old programms work internaly only with 3 digits and thats why XiPaint clips and starts over again(like an overflow). AE does a similar thing if I select pressure for the color density plus the too big brush compared to the brush size set. But that may be a bug. AE is full of them.

[Michael Sykes]

Just reading an interesting page that I found about the wintab api.
http://www.wacomeng.com/windows/docs...#_Toc275759739

Looks like the 65280, shown in the Amiga tool, is indeed correct.
From what I undersand (and thats not much) the wintab api gives us exactly 256 pressure values from an array where the physical value is mapped to a 0-255 scale.
The array indices are stretched evenly over the input range...

So it doesnt matter what's the sensetivity of the pen, on the windows side?

On the Amiga side it would allways look like 0% = 0 and 100% = 65280 ?

Lets say the Amiga software checks for changes of that value and assumes a step for every change.
Now it gives a color value to that step and adds more color with each step.
Lets say a white line gets darker.

What if the software assumes the first 128 changes are all there is,
so the pen must have been pressed again. So it only gets to ~32000 wich should be ~128 steps.

What would happen if the software reaches an internal limit of 128 steps(or less) and there is more input.
Would that explain why the brush stops drawing in the middle of the physical pressure range and start drawing again if I press harder?
Had this strange effect in both XiPaint and AE.
The curve settings in windows are only hiding the problem in the upper range.

It is really as if there are to ranges of pressure and that darn initial mouselick. ;-)