- romanshuvalov
- Модератор
P.S.
ReeV
> Что с вами будет когда зайдет речь о портирование на mac(ios)? тоже с++ only,
> не выйдет..
А там разве не ObjectiveC? который обратно-совместим с обычным Си без плюсов?
TarasB
> Я не думаю, что есть ещё более нормальный способ узнать дпи.
Согласен, но имей в виду, что данные не всегда точные. Я бы опирался только на densityDpi (константы DENSITY_LOW, DENSITY_MEDIUM и т.д.). Хотя я не знаю, что у тебя там за проект такой, где нужна точность.
Кстати, я правильно считаю? Измеряю линейкой длину (~65 миллиметров), перевожу в дюймы (2,559") и делю число пикселей по этой оси (320px) на это значение в дюймах (320/2,559=125dpi)? А то что-то засомневался уже.
ALPINE
> А там разве не ObjectiveC? который обратно-совместим с обычным Си без плюсов?
Он хочет сказать, что на чистых крестах там не выйдет. Надо спрашивать у тех, кто пробовал.
ALPINE
> Хотя я не знаю, что у тебя там за проект такой, где нужна точность.
Мне нужно, чтобы кнопочки, размер которых я задал, ориентриуясь на свой экран, не были слишком мелкими на других устройствах. Точность не нужна, важен порядок.
ALPINE
> Кстати, я правильно считаю?
320/(65/25.4) = 125.04615384615384614
А ты почему в 2 шага считаешь, у тебя виндоуз калькулятор?
TarasB
> Он хочет сказать, что на чистых крестах там не выйдет.
Как хорошо, что я пишу почти без крестов.
> Точность не нужна, важен порядок.
Ну так для порядка тебе ldpi/mdpi/hdpi/xhdpi хватит за глаза. Наверное. Мне - хватит.
> А ты почему в 2 шага считаешь, у тебя виндоуз калькулятор?
Виндоуз-калькулятор вообще-то умеет со скобками работать. Но я работаю в линуксе. А расписал 2 шага чтобы уточнить правильность.
ALPINE
> Как хорошо, что я пишу почти без крестов.
А на чём же ты пишешь?
ALPINE
> Ну так для порядка тебе ldpi/mdpi/hdpi/xhdpi хватит за глаза.
Ну тогда и этих xdpi,ydpi хватит.
TarasB
> А на чём же ты пишешь?
на Си без плюсов. Ну, почти без плюсов.
ALPINE
> на Си без плюсов. Ну, почти без плюсов.
Ради портируемости на айфон?
TarasB
нет, в моём мозге не укладывается ООП, и пишу я без ООП.
А Си++ без ООП превращается в Си. За мелкими исключениями вроде невозможности объявить переменную в условии цикла и т.д.
ALPINE
> нет, в моём мозге не укладывается ООП, и пишу я без ООП.
Да в моём тоже. Да и у 99% тоже, но это уже разговор на другую тему.
ООП на уровне структур с методами (без иерархий), выделяющихся на стеке (без кучи) - такое ООП как раз вполне адекватное и КИСС не нарушает, правда никакого ОО тут уже нет, кроме названия, ну да и хрен с ним.
Просто автодеструкторы - это охренительно удобно, это сильнее, чем просто сахар.
TarasB
На всякий случай отпишусь, проверил получение xdpi на трёх устройствах. Только на одном значение dpi более-менее схоже с действительностью:
- LG Optimus L3 E400 (xdpi 141.8, а на самом деле 121.9)
- Китайский планшет LY-F1 (xdpi 160.0, а на самом деле 133.6)
- Archos 101 G9 (xdpi 144.0, а на самом деле 148.0 - в пределах погрешности линейки)
А вот как получить условный размер экрана (small, normal, large, xlarge), чтобы определить тип устройства - смартфон или планшет, я пока так не нашёл.
Я делаю так. В GLView.Renderer в методе onSurfaceChanged передается разрешение экрана, я его сохраняю и передаю в NDK:
class GLView extends GLViewAncestor
{
private static class Renderer implements GLSurfaceView.Renderer
{
public void onSurfaceChanged(GL10 gl, int width, int height)
{
JniWrapper.Init(width,height);
...
}
}
}В NDK сохраняю и инициализирую контект:
JNIEXPORT void JNICALL Java_fishrungames_halibutjnitemplate_JniWrapper_Init(JNIEnv * env, jobject obj, jint width, jint height)
{
//Сохраняем значения
Width = width;
Height = height;
//... Инициализируем OpenGL
App->OuterInit(width, height, 480.f, 320.f);
} И все.
Mephi1984
Речь о размерах экрана, а не о разрешении. Размер. Физический. Либо миллиметрах, либо в условном обозначении - small, normal, large или xlarge. Собственно, вся тема этому и посвящена.
Решение, естественно, лежит на поверхности.
android/configuration.h:
enum { ACONFIGURATION_SCREENSIZE_ANY = 0x00, ACONFIGURATION_SCREENSIZE_SMALL = 0x01, ACONFIGURATION_SCREENSIZE_NORMAL = 0x02, ACONFIGURATION_SCREENSIZE_LARGE = 0x03, ACONFIGURATION_SCREENSIZE_XLARGE = 0x04 }; int32_t AConfiguration_getScreenSize(AConfiguration* config);
Еще тут есть масса полезных запросов - узнать язык, ориентацию экрана, наличие клавиатуры и прочее. Плотность пикселей (условное значение ldpi/mdpi/hdpi) тут тоже есть, так что лезть за ней в getMetrics через яву необязательно.
Если все еще актуально, то можно использовать такой метод.
В спеке по EGL есть функция:
EGLBoolean eglQuerySurface(EGLDisplay dpy, EGLSurface surface, EGLint attribute, EGLint *value);
И дальше по тексту
Querying EGL_HORIZONTAL_RESOLUTION and EGL_VERTICAL_RESOLUTION
returns respectively the horizontal and vertical
dot pitch of the display on which a window surface is visible. The values returned
are equal to the actual dot pitch, in pixels/meter, multiplied by the constant value
EGL_DISPLAY_SCALING
Вроде бы как раз то, что нужно.
ЕМНИП, это же метод подойдет для iOS (или там нет EGL?) и еще для кучи других ОС.
trex
Попробовал. На одном устройстве вернулось 1, на другом -1. А вообще в устройстве изначально может быть забито неправильное значение, например, мой 7-й дюймовый планшет думает, что он 9-дюймовый с xlarge-дисплеем и низкой плотностью пикселей. Так что даже если eglQuerySurface и сработает, то не факт, что вернувшееся значение будет похожим на то, каким оно должно быть на самом деле.
Тема в архиве.