Pull to refresh

Comments 28

А нельзя кат перенести выше? Ужасно ленту загромождает, сократите текст до ката раза в 3-4, пожалуйста.
То чувство, когда до ката контента больше, чем после...)
Поправилась, текст сократила. Если надо ещё меньше — подумаю над заменой картинки.
Если понравится — у меня уже есть наброски продолжения статьи

Интересно, что будет дальше. Продолжайте.
Материала у меня хватает. По тематическим хабам и тегам сложились определенные ленты, я не стану их заспамливать частыми статьями. Все-таки моя тема несколько нестандартная, еще немного и можно её в «Ненормальное программирование» помещать. Сами посудите: разработка приложений для Android не на Java — это уже некая альтернативщина. А тут я беру Embarcadero Delphi XE7 у которого разработка мобильных приложений определена через платформу FireMonkey. Там эти самые приложения можно печь как пирожки. А мне не хочется пирожков из готовых полуфабрикатов, домашняя кухня вкуснее, хотя и требует гораздо больших усилий.
Проект любопытный, но статья абсолютно неинформативна. Если соберетесь писать следующую часть, расскажите больше о самой структуре приложения, тонкостях и потенциальных подводных камнях — как в разделе «под капотом», но более детально и пошагово.
Не волнуйтесь, уж если мы залезли «под капот», то не не вылезем оттуда пока не разберем «движок» до гайки. Если идти последовательно, то начать наверное придется с создания окна, инициализации EGL, создания и настройки контекста GLES. Можно подойти с другой стороны и начать с рисования — треугольник, плоские фигуры, 3D примитивы, поверхности, текстурирование, меши. Я как раз собиралась написать в первой версии фигуры вращения и хоть простенькие частицы. Вообще-то начинать принято с выбора среды разработки, но это скользкая тема. А мне бы хотелось начать сразу с тестирования мобильной демки, вон какие подробные инструкции написала. В общем главное начать :))
Про рисование на низком уровне уже была фундаментальная серия статей. А вот настройка окружения до минимальной рабочей версии, с которой можно было бы поиграться самостоятельно — это было бы интересно.
Та серия статей от haqreu была про «софт-рендер» (кроме «аддендума» про GLSL шейдеры).
В шейдерах можно делать многое, на ffp можно делать разное, на CPU (софт-рендер) можно сделать всё © Б.Т.' 2015.

«Настройка окружения до минимальной рабочей версии» — так это же и есть моя «Первая демка» предъявленная в статье. Этот вопрос уже доступен тем, кто скачал из репо исходники, я там на комментарии и ссылки не поскупилась (модули AppWindow.pas, AppForm.pas).
Разбирать такое построчно выйдет длинновато и скучновато, не факт что решусь.

То ли дело рисование граф. примитивов. Вот, фигуры вращения сделала. Вчера было «500 лет граненному стакану», как никак :))

image
У haqreu в его «Кратком курсе...» рассмотрено рисование на предельно низком уровне (в хорошем смысле этого слова) — вообще без OpenGL драйвера, чистый софт рендеринг. Я же могу написать о практическом рисовании в реальном времени на экране средствами GPU, только GPU будет мобильный, а полученный текст на GLES будет полностью совместим с OpenGL на PC. Дело в том, что у меня на GLES нет чего-то подобного glu или glut (графической библиотеки), начинать приходится с вывода треугольника. Там даже квада нет (на GL_QUADS круто секономили), я квады из 2-х треугольников рисую.
Ладно, графика никуда от меня не убежит, надеюсь. ОК, принято. Разберу работу программы от старта (что создаём, что и как инициализируем и зачем) до цикла рисования и обработки тачскрина.
Еще момент: тексты с OpenGL хорошо переносятся на другие языки программирования. Но под мобильную платформу нужно еще иметь компилятор, который выдаст бинарный .so и архивчик с инсталляцией apk на выходе (Delphi пошел по пути ndk). Поэтому я не даю гарантий, что моя последовательность действий при старте приложения прямо применима для Java (Java это sdk и там несколько иная кухня на машине Dalvik).
Мне повезло и у меня есть две руки, это позволило найти один баг — если сначала начать вращать камеру, а потом не отрывая пальца начать двигаться (стрелочками), после чего оторвать палец от вращения камерой — состояние поворота камеры сбросится на предыдущее.
Еще один момент — у вас при смене ориентации экрана то ли меняется fov у камеры то ли ее центровка — в общем при вращение наблюдаются явные искажения. Заметил это, запустив демку в вертикальном режиме, потом повернув в горизонтальный.
Фпс при обзоре всех шариков — около 12.
Телефон Samsung Galaxy Note 3 n9000, gpu Mali-T628MP6
Зачет, вот что значит прямые руки. Оба замечания поставила на первое месте в моём todo, после фикса отпишусь.
Я замечала перескоки камеры при «двуручном» управлении, но срабатывает «синдром разработчика» — как-то так жму что летаю без глюка.
Поэтому и нужен объективный сторонний тест. Хотелось бы нормально отладить все нюансы простой демки и только потом двигаться дальше. Лично я выступаю за качество софта, функциональность мы еще успеем расширить, потом и статьи хорошие напишем.
Сам принцип управления полетом следует обсудить. На PC это допустим клавиши WASD + мышь, а как сделать на тачскрине?

У меня задаётся фиксированный FOVY=90 градусов, по горизонтали это выходит больше * AspectRatio (соотношение сторон дисплея). Угол конечно широковат, тестирую так, такие вещи как угол обзора камеры принято выносить в настройки. При смене ориентации экрана… то же самое, FOVY=90, только теперь Y другой. На практике поворот устройства в вертикальную ориентацию приводит в итоге к «приближению» изображения (перескок координат в сторону стал виден только на низком FPS, он связан с тем, что я тороплюсь применить новые длину и ширину дисплея, они в EGL должны еще «устаканится»). Вывод — при повороте нужно корректировать FOV, точнее считать AspectRatio как обратную величину.

Модуль Camera.pas, здесь будут правки.
procedure TCamera3D.Apply(aWidth, aHeight: Single);
begin
Aspect := aWidth / aHeight;
glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(FieldOfView, Aspect, zNear, zFar);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity;

glRotatef(Pitch, -1, 0, 0);
glRotatef(Yaw, 0, 1, 0);
with Position do
glTranslatef(-x, -y, -z);

glLightfv(GL_LIGHT0, GL_POSITION, @LightPosition); // in current GL_MODELVIEW projection
end;


Еще я явно перестаралась с нагрузкой на GPU в демке. 4096 сфер * 80 треугольников в каждой = 327680 треугольников. Смысл теста был такой — в центре шаро-куба FPS выше, так как в один момент можно наблюдать только часть объектов, фрустум кулинг проверяла.

Еще раз спасибо за грамотный репорт. Если у Вас есть соображения что можно сделать полезного из моих скромных наработок — напишите, именно Ваше мнение мне будет ценно.
На тачскрине можно сделать так же как и на PC — кнопочки WASD + палец для обзора. WASD можно заменить на виртуальный стик.
Виртуальный стик? У меня примитивный GUI (что впрочем, даёт простор для творчества), кнопки рисую сама, координаты касания на тачскрине определяю, попадание в кнопку вычисляю. Кнопка может быть не квадратной. Пока думалось так — окружность, 4 сектора, повернуть на 45 градусов — получится 4 кнопки, как на пульте телевизора. Стик вижу иначе — круглая область, где в зависимости от точки касания сразу будет направление перемещения по 2 осям (в локальной системе координат камеры). Это все надо пробовать. Юзабилити управления — одна из важнейших задач для меня.
Свой скайп и VK написала в Диалог.
Попробуйте фиксировать диагональный FOV. В этом случае размеры останутся прежними и на вид никаких изменений не произойдёт.
Хотя, всё зависит от задач. В некоторых случаях лучше горизонтальный FOV фиксировать.
Правильно, диагональный FOV у меня на планшете постоянный. Сейчас фиксирован FOVY, эта традиция идёт от
OpenGL.pas procedure gluPerspective(fovy, aspect, zNear, zFar: GLdouble); stdcall;
В результате под Windows, если сделать широкое низкое окно можно получить FOVX до 180 градусов. Может это и не баг, а полезная фича, если например сидишь в засаде:)) Думаю перейти на фиксировнный FOVX, так будет понятнее. Библиотеки glu на GLES у меня нет, поэтому имитирую известную функцию вот так:
procedure gluPerspective(fovy, aspect, zNear, zFar: double);
var m: TM4x4; sn,cs,c,dz,ar: Double;
begin
 if aspect = 0 then Exit;
 dz:=zFar- zNear;
 if dz = 0 then Exit;
 ar:=fovy*g2r2; //Pi/360
 SinCos(ar,sn,cs);
 if sn=0 then Exit;
 c:=cs/sn;  //cotangent
 FillChar(m, SizeOf(m), 0);
 m[0,0]:=c/aspect;
 m[1,1]:=c;
 m[2,2]:=-(zFar+zNear)/dz;
 m[2,3]:=-1;
 m[3,2]:=-2*zNear*zFar/dz;
 glMultMatrixf(@m);
end;

Ура, у меня появилась некая «карма» и я поставила свой первый +1 на Хабре. Вот за что поставила: за внимательное чтение статьи и точное выполнение условий авторского эксперимента, за корректный баг-репорт, разумный юмор и позитивное отношение.
И это хорошо.
Главное не упоминать особо о карме, здесь за это её минусуют :/
Логично, учту. А о контекстной рекламе на сайте упоминать можно?
Мегафон пишет прямо под моей статьей, предлагает купить их китайский Android-смартфон. Я не советую.
Для разработки программ под Android нужно иметь устройство на базе Android. Эмуляторы Android на PC слишком медленны и неуклюжи. Для тестирования софта я применяю недорогие 7" планшеты: Samsung GALAXY Tab3 Lite SM-T110 и Nomi A07000 (последний вообще пародия на планшет, впрочем для тестирования как раз отлично, это моя «нижняя планка»). Еще задумываюсь о приобретении смарта, что-то вроде старенького HTC мне бы подошло. Тестировала и на навороченных дорогих моделях — разницы никакой. CPU и GPU пишут изрядно круче, на практике прирост производительности невелик.
Пожалуйста, используйте для кода теги:
<source lang=«delphi»>
</source>
Спасибо, я искала эту возможность. Сейчас проверю. Рассмотрим функцию поворота камеры в пространстве которая используется в текущем демо. Это тот же модуль Camera.pas.
// такой поворот имеет вырожденные точки сверху и снизу
procedure TCamera3D.MoveForvard(V:Single);
var i:Integer; ah,av: Single; rz,rh,rv,dr:TV3;
begin
 ah:=Yaw*g2r;   // horizontal angle in XZ plane
 av:=Pitch*g2r; // vertical angle
 // polar to decart from -Z
 dr.x:=cos(av)*sin(ah);
 dr.y:=sin(av);
 dr.z:=-cos(av)*cos(ah);
 Position:=Position+dr*V;
end;

Для поворота камеры в итоге я планирую использовать другой вариант.
Вот тут лежит моя предыдущая демка под Win, камера заметно лучше — bionica-game.tumblr.com
Там есть вопрос с нарастающим креном, углы Эйлера — поворот по 2-м осям непременно даст поворот по 3-й оси.
Придется выбрать из двух зол, либо ввести управление креном.

А для того чтобы проверить — есть кнопочка предпросмотра.
вот тут

Прошу прощения, про камеру я хотела рассказать Torvald3d, вышла путаница. С другой стороны, это комментарии к моей статье, я тут стараюсь отвечать оптом на все на вопросы читателей. У меня могут быть и встречные вопросы. Я совсем не разбираюсь в хабро-рейтингах, кармах и т.п.
Задачка: статью выложила сегодня после обеда, сразу получила минуса за неправильно поставленный кат (в ленте смотрелось некрасиво), это справедливо. 17 человек добавили статью в избранное, за проголосовало 4, против проголосовало 6 (кажется все из за ката). Я понимаю что в минусах.
Вопрос 1: нужно ли писать продолжение статьи при таких раскладах?
Вопрос 2: может нужно заменить картинку над катом, чтобы в ленте никому не мешало?
Вопрос 3: те 17 что добавили в избранное, они не все имели возможность голосовать, или имели?
Вопрос 4: сколько мне надо набрать кармы, чтобы, например, поставить + Torvald3d, его репорт попал в точку.
Работаю над продолжением статьи.
Основная проблема — длинные ступни у NPC. Никак не могу подобрать им подходящие ботинки :))

image
Да не заморачивайтесь вы этими хабарейтингами. Я обычно прислушиваюсь к комментариям и стараюсь их учесть в следующих статьях.
Писать нужно, учтя все, за что огребли в предыдущих статьях)
На счет картинки — всегда стараюсь писать поменьше текста до ката и выставить покруче картинку — это привлекает внимание. Из-за большого количества постов, на сплошном тексте обычно взгляд не задерживается.
Уфф, я сделала-таки фигуры вращения. Еще оптимизировать надо, импорт path с SVG надо бы, сечения solid фигур с «крышками», но это уже детали. Придумала: следующая моя демка (и, возможно, статья) будет посвящена проблеме космического полицейского мусора. Знаете ли Вы, что только с начала этого года 40% аварий НЛО произошло при их столкновении с неопознанными орбитальными мусорными объектами (рус.«НОМО», англ.«UOTO»). Что там только не летает — страшно подумать. Гринпис, спасем орбиту!
Only those users with full accounts are able to leave comments. Log in, please.