основы создания видеоадаптера разберу точно. В прошлом видео говорил, что буду делать символьный вывод, практически не зависимый от ЦП, и вероятно основы для 2D графики: например спрайты. На 3D тяжеловато нацеливаться. )))
Почему можно выбросить эти системы 1)потеря времени 2)если ты ее сделаешь то сион её у тебя упрет и глазом не успеешь моргнуть , группа людей на этом просто тупо за тебя заработает 3)есть подобные технологии и можно работать сразу в браузере смотри в полном описании на моём канале
Hello, could you make an installation and setup tutorial if IDE, NDK etc. This is a bit of a mystery given the many videos based on older SDK do not work anymore.
День добрый. В этом нет ни чего сложного. Просто установите Android Studio. SDK и NDK обычно идёт вместе с ним. Если NDK будет не установлен, то сделайте это через настройки Android Studio. Для ZenGL вам надо будет только сделать такую же структуру для проектов, что сделана в демо-версиях для Android. В дальнейшем, вероятно всё будет ещё проще. Я работаю над этим. ------------ Google translate: Good afternoon. There is nothing complicated about this. Just install Android Studio. SDK and NDK usually come with it. If the NDK is not installed, do it through the Android Studio settings. For ZenGL you will only need to make the same structure for projects that was done in the demo versions for Android. In the future, everything will probably be even simpler. I'm working on it. developer.android.com/studio/projects/install-ndk You can also find out a lot of information here: forum.lazarus.freepascal.org/index.php/topic,49143.0.html
Серж а не проще уже создать болванку для пустого проекта ZenGl? Чтобы можно было просто из лазаруса создать простой проект zengl. Можно посмотреть как у меня сделано. В ray4laz
Да, подобное нужно сделать, но тут другой подход думаю применить. Сделать сборщик проекта, так, чтоб пользователь настройки необходимые выставил, собрал проект и мог уже открывать его в Lazarus. Там тоже много разных нюансов, и время... на всё нужно время. ))) Это жестоко, где бы столько рук найти и/или времени. )))
Вы решили полностью реализовать OpenGL, включая трехмерность? (если в видосе на это ответ есть, простите, я не стал весь видос смотреть, пока времени нет)
@@stevenhoxville3734 sourceforge.net/projects/new-zengl/ На GitHub написано, что проект переведён на Sourceforge. Там же и ссылка есть, правда не наверху... )
Добрый день. Нет, тут java используется посредственно, как связка. ZenGL - это движок паскалевский. Делаем программу на паскале, компилируем, и собираем через Eclipse. Получается почти нативное приложение на Android.
Привет! Что-то поменялось в плане производительности , при использовании 8 ядер? Не могли бы вы записать маленький ролик , как у вас работает GUI? Я имею ввиду отзывчивость системы.
Привет! Немного меняется, если увеличивать количество ядер. Больше зависит от количества памяти, но опять же если система загрузилась. Отзывчивость не очень хорошая. Лучше ставить небольшие разрешения, чтобы более быстро работала эмулируемая система. Первоначальный экран приходится долго ждать, и с задержками запуск приложений происходит. Так что, если кажется что система плохо работает, то вероятнее всего так и будет. Какие-то вещи может лучше делать без GUI, потому что в командной строке достаточно резво работает.
@@sergshutk2757 У меня на основном компе относительно древняя система на базе UBUNTU 18.04. Чтобы не получилось так , что я поставлю новый Debian на основной компьютер , а с ARM ничего не получится, я накатил Debian в VirtualBox , а уже на него в QEMU aarch64 систему. Как бы все получилось , но все конечно тормозит заметно. Тормоза касаются именно интерфейса GUI (gtk). Если что-то делать в терминале , то терпимо. Такое впечатление , что системные события явно загружены/перегружены. Вот и хотелось бы увидеть реальное поведение GUI , прежде чем ставить на основной компьютер. Может там будет не лучше... Если у вас будет время и желание , может вы запишете простые действия типа открыть файловый менеджер , переход по папкам , вызов меню , нажатие по кнопкам , открытие браузера (любой страницы). Это бы визуально помогло понять , стоит ли ставить дополнительную нативную систему Debian 11. Кстати , glxgears показывает неплохие результаты , но весь интерфейс (кнопки , меню , и пр.) в других окнах заметно тормозит и нередко плохо прорисовывается. Кстати , проблема прорисовки есть и в терминале. И это я поставил еще легковесную lxde.
Извиняюсь что поздно отвечаю. В общем, можно запустить эмулируемую систему без оболочки. Там работает быстро достаточно. Графическая оболочка всегда будет тормозить и иногда очень долгая загрузка будет. Сами графические приложения могут работать достаточно хорошо, когда загрузятся, я видео смотрел в достаточно большом формате. Ставить или не ставить второй системой на компьютер Linux-систему, тут решать вам. Попробуйте WSL в Windows, если виртуалка через WSL будет лучше работать, то думаю стоит накатить Linux. А вообще у многих стоит далеко не одна система на компьютере. Есть ещё PROXMOX, там вообще можно несколько систем запустить одновременно работающих. Но нужен мощный компьютер. Да, ещё, можно тестировать ARM-приложения на x86-машинах. В Linux точно. Вот ссылка где расписано как это можно сделать. azeria-labs.com/arm-on-x86-qemu-user/
Lazarus v2.2 должен открывать все старые проекты (возможно что и нет). Lazarus более ранних версий может не открыть проекты Lazarus v2.2. Для этого в "параметры проекта" (для Lazarus v2.2) надо установить галочку совместимости со старыми версиями. Если надо открыть какой-то определённый модуль, то в "редакторе исходного кода" найдите раздел uses - правой клавишей нажать на нужный модуль. Откроется подменю, где надо выбрать верхнюю строчку "открыть объявление NNNNN".
Серж, а тут разве нет оптимизации, когда первым записанное константное выражение помещается сразу в код, и, соот-но, пишется в регистр одной строкой? Т.е. у тебя vA + vB / cC, где v - переменные, а c - константы. Замени деление братным умноженипм, он у тебя константу посчитает на этапе компиляции. И будет у тебя cÇ * vB + vA.
Да, мы можем так сделать. В этой ситуации надо смотреть, будет ли выгода, если мы заменим деление умножением в SIMD. Не нашёл информации по скорости исполнения XMM-команд. Поэтому надо в очередной раз тесты делать. И я хочу рассмотреть получаемый код глубже. И, он показывает, что оптимизация не полная. Каждый раз, когда встречается константа или переменная, то компилятор (FPC) не выполняет предварительных переводов. Он последовательно просматривает поступающие данные и на каждом шаге их переводит в данные подходящие для использования в XMM. А таких данных, встречается очень много. Пользователи в каждой вызываемой функции/процедуре прописывают какое-нибудь число. И получается, что если оптимизации не будет, то и скорость работы программы падает. В общем я занимаюсь "ерундой", которая может принести немалый прирост в работе программы, особенно если она достаточных размеров. )))
Не в эмуляторе дело. В виртуалке на WinXP нормально звук идёт. Но там AC97, а KolibriOS нормально работает только с HD-звуком (что идёт по умолчанию). На i5-3230m вообще звук не работает. Я даже пытался подменить sound.sys на интеловские. Результата нет.
Здравствуйте. Случайно наткнулся на Ваше видео. Ваши видео было бы проще находить если бы в названии видео всегда фигурировали ключевые слова типа ZenGL, Delphi, Pascal. Ну и прописывание тегов помогло бы большему количеству людей Вас найти. Если Вы не против, то я бы хотел записать обзор по Вашему движку. Возможно это тоже привлечет немного аудитории к Вам.
День добрый! Благодарю за информацию! Да, она полезна и я знаю об этом. Но забываю периодически. Движок не мой, я лишь его продолжатель. Но лично я не против. Большая просьба указать сайт автора под видео если будет видео-обзор.
@@sergshutk2757 Я планирую сделать видео обзор на этом канале с аккаунта, которого я сейчас пишу. Спасибо. Я под видео постараюсь указать все ссылки, которые смогу найти. Ссылка на сайт ZenGL у меня есть, ссылка на github есть и ссылка на Ваш канал тоже.
Видео отчёт, больше, чтоб я не забывал, что сделано. ))) А может кому пригодится. Многое основано на прошлых видео. Начнём с того, что давно я начинал делать клавиатуру для Android. Я хотел отделить дополнительные вызовы и снизить нагрузку на работающую программу. Основную часть сделал, но в это же время, что-то меня отвлекло и я переключился на выделение контекста для MacOS Cocoa. Что тоже заняло значительную часть времени, так как хотел "быстрее" сделать и не хотел использовать основные классы NS*. Как в итоге оказалось - зря! Конечный код, который создают данные классы достаточно мал! И вполне соответствует требованиям ZenGL (а точнее тем, на которые рассчитываю я). Создав контекст для MacOS, столкнулся с проблемой библиотек. Но так и не решил их по сей день, потому что занимаюсь полем ввода, об этом позже. И не решил проблем этих как для MacOS Cocoa (в основном BigSur), так и для Android 64. Потому, в данное время большинство приложений под Android можно запустить только в 32-х битном режиме. Хотя, на самом деле, большую часть можно запустить и на 64-х битной системе. Отключая определённые библиотеки. Потому, это только в планах. Так вот, создав контекст для MacOS я не смог, банально, работать с текстом. Там вроде через NSString, как я понял позже, это делать надо, но у меня уже ни какого желания не было выдёргивать эти функции оттуда... И, уже вспоминая, что до этого делал клавиатуру, решил убить двух зайцев разом, сделать вывод текста и обработку клавиатуры, с автоматической поддержкой Android. И таким образом появилась идея создать поле ввода. Но рассматривая все поля ввода, ознакомившись с ZenGL и уже более досконально зная его, было понятно, что такие решения мне ни как не подходят. Я прекрасно помню моменты, когда я вместо каких-то визуальных компонентов уже создавал свои, которые быстрее работают, но имеют свои недостатки. Допустим их сложнее масштабировать, либо решать какую-то визуальную составляющую, которая будет хорошо масштабироваться. Само поле ввода было сделано достаточно быстро. Но, решения и идеи, которые могли затронуть данную идею, "топили" проект глубже и глубже. Так как поле ввода - это одна из составляющих для ускорения разработки приложений, а так же одна из составляющих визуальных компонентов, то и решать надо было это ко всем возможным, созданным в будующем, элементам визуальной составляющей: кнопки, поле вывода, поле мемо и/или вдруг ещё каких. Так как библиотека ZenGL больше рассчитана на графические приложения и игры, то идеи приходили достаточно быстро, а реализация этих идей стопорила процесс. А мелкие проблемы, которые возникают повсеместно, нужно было сразу решать, чтоб не искать их где-то в дебрях кода, когда уже всё будет готово и совмещено с основной программой. Идеи и решения проблем. Вырезка текста, по размерам поля ввода. Решение glScissor было откинуто сразу, как только было понятно, что пользователь захочет повернуть поле ввода. Поворот поля ввода. Вырезка была сделана вручную. Что привело к модификациям кода в самом ZenGL. Ускорению работы кода и уменьшению расчётов во время работы программы. Но только для текста!!! Вероятно это надо будет сделать и для любых спрайтов!!! Работа с текстом. Надо было решать, в каком формате будет содержаться текст в поле ввода. UTF отпадал сразу, всё шло против того, чтоб использовать данный формат. Он не имеет стабильного размера для символа, а это очень большой минус, это замедляет работу приложения и увеличивает его размер, во время его работы. Потому, было решено сделать работу поля ввода в формате Unicode, для этого достаточно быстро текст конвертируется и туда и обратно. Создать собственный API для ZenGL. С данного времени, это идёт разработка собственного движка-API для ZenGL - Green Engine. В данное время так же идёт под лицензией zlib. Причина создания - это достаточно не малая наработка, и я не совсем корректно относить это к ZenGL. Green Engine будет работать только с ZenGL. Более того, основная его часть будет встроена в код ZenGL и работать от прямых системных вызовов системы, в которой (или под которую) будет вести разработку пользователь. Она так же в свободном доступе! Ни каких ограничений не имеет, кроме указанных в лицензии. Вы не сможете использовать данную наработку в других библиотеках (обидно, но стабильность работы созданных программ вынуждает оставить только в таком варианте), если только сами не перепишите её полностью. Так же, данное API по большей части не будет содержать графической составляющей! Она будет предоставлять пользователю возможность рисовать визуальную составляющую, самому. Предоставляя определённые координаты или наоборот получая от координаты пользователя. Или то и другое вместе. Создание менеджера визуальных компонентов. Это огромная часть нового API (а точнее огромная амбиция, ещё не реализованная). Если эту часть реализовать, то можно будет добавлять любой новый компонент достаточно быстро, уже не влазя во внутренний код, а пользуясь данным менеджером. В данный момент времени, я им занимаюсь и он ещё почти не протестирован. Так же были выявлены проблемы с отдельными участками кода. Которые были устранены (возможно не полностью).
Предоставление пользователю работы с текстом. Загрузка/сохранение текстовых файлов средствами ZenGL была сделана. Почему это не было раньше не было сделано, не знаю, видимо Andru был другими проблемами занят. Не сделана загрузка в StringList. Реализую позже или сможете реализовать сами, загрузив текстовый файл. Из плюсов. Всё, что было создано, достаточно быстро поддаётся переработке и доработке. Многие вещи, которые ввожу, автоматически "встают на свои места". Код автоматизирован. Останется только "вклинить" его внутрь ZenGL и отладить на разных системах. капс работает для цифр - исправил. Клавиатура работает только для латиницы и кирилицы. И тоже не все форматы наверняка поддерживает.
Прийди с такими убеждениями в любую компанию, вот смешно будет))) Удали и этот комментарий, ведь как я понял ты удаляешь все, которые не совпадают с твоим мнением
Про удаление ответ дан выше. Да, в первую очередь я смотрю со своей стороны. Но это даже не чисто моё мнение. Поспрашивайте у множества программистов, они ответят, что нет ни какого "лучшего" языка программированию. Всё зависит от самого человека. Если человек стремится в какую-то компанию и знает направление, то наверно он и выберет тот для изучения тот ЯП который будут требовать там, куда он собирается устраиваться? )))
@@sergshutk2757 понимаешь, под каждую задачу есть свой инструмент, под каждую проблему есть свой язык программирования. Ты же не будешь делать игру на питоне, ведь он медленный? Я уверен, что ты сидишь на паскале толи из за своей лени, толи из-за того, что тебе нравится сразу создавать, а не учить. По поводу вопроса о трудоустройстве в компанию - попробуй трудоустроиться туда с паскалем
@@user-jv1bw7kl3q трудоустроится трудно, но найти заказы, человеку с опытом не так трудно. Для заказчика вообще не важно, в большинстве случаев, на каком языке сделана программа (есть заказчики, не спорю, которым обязательно важно на каком языке программирует человек), главное чтоб эта программа хорошо работала. А по поводу паскаля, я сижу на нём потому что это не худший ЯП. ))) И я могу компилировать (именно компилировать) свой код под нужную для меня систему (используя FPC).
@@user-jv1bw7kl3q каждый выбирает то, что подходит ему. Кто гонится за деньгами, тот выбирает тот ЯП, который (как считает этот человек) "принесёт" ему деньги. И, я знаю не мало людей, кто программирует на паскале и зарабатывает нормальные деньги. Хотя многие уходят на другие ЯП. Но это относится абсолютно ко всем ЯП. )))
Дальнейшие тесты показали, что списком массивов пользоваться стоит когда массивы больших размеров. В таком случае скорость при работе со списками против обычных вызовов увеличивается.
Так же проблемы с дефайнами (define) проявляются. GetLazarus (по крайней мере я сталкивался) считает {$DEFINE LINUX} равноценно, точнее включает в себя {$DEFINE ANDROID}, хотя для них общим должен быть {$DEFINE UNIX}, поэтому надо учитывать это при разработке приложений, а где меняются записи дефайнов я не разбирался...
плохое владение матчастью и при этом попытка кого-то учить, вам бы освоить хотя бы азы программирования, прежде чем лезть в эти дебри, если у вас на калькуляторе столько сложностей, то боюсь представить что будет в случае проекта на миллион строк.
Когда делаете подобный комментарий, следовало бы сначала указать что именно не нравится. Всё остальное, не зная ни человека, ни его способностей, ни чем он занимается, обычная голословность, ни чем не подкреплённая.
@@sergshutk2757 ошибки в логике, делать избыток объектов уже само по себе плохо, архитектурная ошибка. Мне не надо знать человека, чтобы понимать его ошибки. Вам не стоит обучать кого-либо подобным практикам, они мягко говоря вредительские. Это сродни индийской практике писать программы используя огромное кол-во IF
@@pamparam3495 вы вообще программировали на языке Game Maker-а? Вы знаете этот движок? Вы понимаете о чём видео? Вы дальше того момента, как я описывал делать объектами калькулятор, смотрели видео? По одному изначальному ответу, понятно, что и двух минут не просмотрено. Для вас лично, ГМ/ГМС - это графический движок основанный на объектах, и многое у него проще реализовать через объекты, чем как-то прописать программно. Я сравнивал действия создавая объекты и через массив прописанный в объекте. Массив в ГМС работает медленнее объектов. Где-то в моих видео это описано.
@@pamparam3495 а по поводу IF... тут даже обсуждать нечего, любой CASE, любой цикл и подобное - это и есть IF, только в языках высокого уровня этот IF прописывать в этих командах не надо. Учите матчасть и изучайте ассемблер для своего просвещения.
