Ok thanks!
I think I’ll just remake a release with the other fix (2 fingers -> Spen).
The other issue is probably less problematic as you are not locked in the frozen state if I understand correctly.
pen button is not a big issue, especially since the keyboard is working with no issues since the last update 
Thanks for the fix. Got the latest versions - no problems at all anymore 
About the pen button blocking thing I’ll check if Java logs different results tonight.
Drop me a mention whenever there’s some other android issue coming up.
Thanks a lot for testing!
Apparently there is an issue on Chrome OS where the file picker doesn’t list any files 
, but forget about it (unless you have a Chrome OS).
This is the issue with Android, there’s way too many devices with different behavior (and with different Android verison on top of that), iOS is a more reassuring platform.
Actually this is the reason why Nomad has trial version for Android: so that I don’t waste too much time on supporting everything if some devices fail to work.
–
Below the full code that I’m using (I’m listening the inputs on the View with onTouchEvent, not the on the Activity with onTouch, not sure if it makes a difference).
package com.stephaneginier.nomad;
import android.content.Context;
import android.opengl.GLSurfaceView;
import android.view.MotionEvent;
import androidx.annotation.Keep;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;
class AppView extends GLSurfaceView {
static void sendTouchEvent(int pid, int idx, int action, MotionEvent me) {
// debug_log(pid, action);
// AppLib.onTouchEvent(pid, action, me.getX(idx), me.getY(idx), me.getPressure(idx), me.getToolType(idx), me.getSize(), me.getButtonState());
}
@Override
public boolean onTouchEvent(MotionEvent event) {
final MotionEvent me = MotionEvent.obtain(event); // deep copy
queueEvent(new Runnable() {
public void run() {
int action = me.getActionMasked();
if (action == MotionEvent.ACTION_MOVE) {
for (int pid = 0; pid < 4; ++pid) {
int idx = me.findPointerIndex(pid);
if (idx >= 0) sendTouchEvent(pid, idx, action, me);
}
} else {
int idx = me.getActionIndex();
int pid = me.getPointerId(idx);
sendTouchEvent(pid, idx, action, me);
}
}
});
requestRender();
return true;
}
// render stuff
[...]
}
Did some tests with Java and the result seems… different. Btw as you probably noticed I had a wrong impression about how actions are encoded so the logs I sent yesterday are partly garbage.
I used this code now, based on your post above
public boolean onTouchEvent(final MotionEvent event) {
queueEvent(new Runnable() {
public void run() {
int action = event.getActionMasked(); // action&0xff
int buttonState = event.getButtonState();
int nPointers = event.getPointerCount();
if (action == MotionEvent.ACTION_MOVE) {
Log.w(OGLAndroidTester.TAG, "MotionEvent ("+event.actionToString(action)+") "+nPointers+" pointer(s) with buttonState "+buttonState);
for (int ix = 0; ix < nPointers; ++ix) {
int id = event.findPointerIndex(ix);
int pointerId = event.getPointerId(ix);
int toolType = event.getToolType(ix);
Log.w(OGLAndroidTester.TAG, "--->Finger ID#"+id+" y="+event.getY(ix));
}
} else {
int ix = event.getActionIndex(); // (action&0xff00)>>8
int id = event.getPointerId(ix);
Log.w(OGLAndroidTester.TAG, "MotionEvent ("+event.actionToString(action)+") "+nPointers+" pointer(s) with buttonState "+buttonState);
Log.w(OGLAndroidTester.TAG, "--->Finger ID#"+id+" y="+event.getY(ix));
}
Log.w(OGLAndroidTester.TAG, " ");
mRenderer.setColor(event.getX() / getWidth(), event.getY() / getHeight(), 1.0f);
}
});
return true;
}
this is s-pen approach-hover-draw-hover-remove, weirdly there is no action_down or hover event recorded for some reason:
MotionEvent (ACTION_MOVE) 1 pointer(s) with buttonState 0
--->Finger ID#0 y=710.95917
MotionEvent (ACTION_MOVE) 1 pointer(s) with buttonState 0
--->Finger ID#0 y=710.95917
...
MotionEvent (ACTION_MOVE) 1 pointer(s) with buttonState 0
--->Finger ID#0 y=706.6617
MotionEvent (ACTION_MOVE) 1 pointer(s) with buttonState 0
MotionEvent (ACTION_MOVE) 1 pointer(s) with buttonState 0
--->Finger ID#0 y=704.8798
MotionEvent (ACTION_UP) 1 pointer(s) with buttonState 0
--->Finger ID#0 y=700.8968
MotionEvent (ACTION_HOVER_ENTER) 1 pointer(s) with buttonState 0
--->Finger ID#0 y=700.0583
MotionEvent (ACTION_HOVER_ENTER) 1 pointer(s) with buttonState 0
--->Finger ID#0 y=542.0583
this is s-pen approach-hover-draw-hover-remove with the button held down, no hover either, move seems to be action 213 (?) no idea what’s happening maybe my logging is broken (again) but it could also be the reason for the blockage
MotionEvent (213) 1 pointer(s) with buttonState 34
--->Finger ID#0 y=729.61646
MotionEvent (213) 1 pointer(s) with buttonState 34
--->Finger ID#0 y=729.61646
MotionEvent (213) 1 pointer(s) with buttonState 34
--->Finger ID#0 y=729.19714
MotionEvent (213) 1 pointer(s) with buttonState 34
--->Finger ID#0 y=728.35864
MotionEvent (213) 1 pointer(s) with buttonState 34
--->Finger ID#0 y=727.52014
MotionEvent (213) 1 pointer(s) with buttonState 34
--->Finger ID#0 y=727.1008
MotionEvent (213) 1 pointer(s) with buttonState 34
--->Finger ID#0 y=727.1008
MotionEvent (213) 1 pointer(s) with buttonState 34
--->Finger ID#0 y=726.89124
MotionEvent (213) 1 pointer(s) with buttonState 34
--->Finger ID#0 y=701.6305
MotionEvent (ACTION_HOVER_MOVE) 1 pointer(s) with buttonState 34
--->Finger ID#0 y=699.63904
MotionEvent (ACTION_HOVER_MOVE) 1 pointer(s) with buttonState 34
--->Finger ID#0 y=699.63904
this is a normal finger draw, this has the down event, but 2 up events strange enough
MotionEvent (ACTION_DOWN) 1 pointer(s) with buttonState 0
--->Finger ID#0 y=640.0
MotionEvent (ACTION_MOVE) 1 pointer(s) with buttonState 0
--->Finger ID#0 y=640.0
MotionEvent (ACTION_MOVE) 1 pointer(s) with buttonState 0
--->Finger ID#0 y=622.04675
MotionEvent (ACTION_MOVE) 1 pointer(s) with buttonState 0
--->Finger ID#0 y=621.1182
MotionEvent (ACTION_UP) 1 pointer(s) with buttonState 0
--->Finger ID#0 y=621.0
MotionEvent (ACTION_UP) 1 pointer(s) with buttonState 0
--->Finger ID#0 y=621.0
here’s some stuff related to the 213 I found in the chromium source code https://github.com/Samsung/ChromiumGStreamerBackend/blob/master/content/public/android/java/src/org/chromium/content/browser/SPenSupport.java
I don’t have access to a chromebook unfortunately
I can imagine Android causes more trouble as there’s more diversity with the hardware and software there, trial version seems like a good insurance.
It probably won’t make much of a difference (if you use only one pointer at a time) but actionToString expects the action from getAction instead of getActionMasked.
I think that’s it!
I’ll use these values to make the conversion and we’ll see if it works on next release.
A bit strange that in Java there’s a different Move Action ID when the button is down.
Just curious, what development environment do you use? Java in Visual Studio works but seems to be not as well supported as C++.
I use Sublime Text. I’m not really a fan of big IDE.
For Android I use the tools from Android Studio (most of the time I use the command line gradlew to deploy the apk on my device for testing).
By the way something that you can test is to open the dev log in Nomad.
Go in the Interface menu, and at the bottom tap 5 times on the button and then click on “imGui logs”.
Then you’ll one window with graphs (ignore it) and one with logs.
You can check if you have a log that starts with “Unknown motion action: 213”.
It says just that “unknown motion action: 213”, and at the beginning “unknown motion action:211” and "…:212 " at the end (which my log doesn’t seem to have catched)
Perfect then!
I should have told you to check those logs, we could have saved some time.
There were there since the beginning 
Maybe a Visual Studio thing…
Haha happens 
might have helped a bit with the other cancel event thing though.
The s-pen hover events arrive btw in Activity.onGenericMotionEvent. This might be useful for the option to adjust the draw size with the button 
for example 
thank you very much for the application. Whoever has problems with simultaneously pressing the stylum and fingers, this function is configured in the settings / settings of the S-pen. For some reason, the orientation of the turns and fixing along the axes (android tab s7 +) do not work for me, another problem arose, I can not make an even cut like in the video. For some reason, my lines run obliquely, and not straight or parallel. And please also add Russian.
Hi, I didn’t find a setting like this on my tablet, what is it called?
I’m not sure I understand how you made the masking on the first image.
My first guess is to make sure you are using Orthographic camera, to avoid perspective distortion.
I started to check about internationalization, but it’s going to take some time, my interface wasn’t really designed with that in mind.
I sort of succeeded, but only after creating a new object that I did not move, but only because I did not move or rotate it. I cannot rotate objects by 90 °, magnetization does not work, or I don’t understand how to turn it on, for the training video, the rotation works when holding the guide and displacement, no matter how much I hold it does not work, apparently it only works for iPad? or only in the paid version? I will definitely buy your program a little later, after my salary. there is still no possibility of orientation along the camera axes. face, profile. make either buttons or as shown in Blender, it will be very !
Screenshot_20210102-172143_Nomad|690x414 convenient.
To rotate 90°, you need to use the slider on the left (just put the maximum value, 90).
Then it will rotate by increment when you start using the gizmo rotate arc.
The next release will have a small cube on the corner to snap the view.
For now you can use the icon at the bottom left (the second camera icon).
1 Like