Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт мар 29, 2024 03:04

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 89 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Пн авг 08, 2016 19:07 
Не в сети

Зарегистрирован: Пт июн 06, 2008 14:21
Сообщения: 128
Откуда: Карелия
Благодарил (а): 1 раз.
Поблагодарили: 4 раз.
VoidVolker писал(а):
Сравнивать GDI+ и OpenGL не корректно, т.к. GDI - для работы с двухмерной графикой, а OpenGL - для трехмерной.

В этом согласиться трудно, экран же пока плоский, все решаемо.. как с видеокартой взаимодействуют, OpenGL мог не на всех работать (ранее тестировал, сейчас наверно уже все поддерживают), с GDI проблем небыло


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 01:15 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
F-MAP писал(а):
В этом согласиться трудно, экран же пока плоский, все решаемо.. как с видеокартой взаимодействуют, OpenGL мог не на всех работать (ранее тестировал, сейчас наверно уже все поддерживают), с GDI проблем небыло

Работа с трехмерной графикой отличается очень существенно. Двумерная графика, с помощью которой и рисуются элемент интерфейса Windows, основана на обычном двумерном массиве пикселей. Потребности работы с ним давно закрыты с точки зрения аппаратуры. Другое дело, что библиотеки Windows ставят точки не просто так, а дополнительно проверяют, что рисуемый элемент не закрыт каким-то другим окном. В этом кроется небольшая проблема - например, "базовый" объект TCanvas, который как раз и позволяет закрасить любой свой пиксель в любой цвет, делает это достаточно медленно, если речь идет именно о пикселях, а не более сложных фигурах. Поэтому для закраски больших фрагментов экрана даже в 2D пользуются более сложными инструментами, дающими доступ непосредственно к видеопамяти.

Трехмерная графика устроена совершенно иначе. Разумеется, мы видим не физически трехмерное изображение, а его проекцию на экран. Однако даже для того, чтобы нарисовать такую проекцию, необходимо выполнить много математической работы. Например, если мы смотрим на куб с обратной стороны, то и рисовать надо обратную сторону, а не лицевую. В итоге описание трехмерного изображения сводится к описанию сцены. В нем указывается, какие точки находятся в трехмерном пространстве, какие фигуры они образуют, и какие текстуры наложены на эти фигуры. Далее необходимо указать, с какой точки и в каком направлении мы на это все смотрим, и видеокарта самостоятельно определит положение каждой описанной фигуры. Дополнительно будут использованы эффекты освещения, тумана, наложены фильтры, убирающие "ступеньки" на линиях и т.д. - все автоматически. Именно поэтому современная видеокарта стоит весьма приличные деньги. Ее производительность и характеристики напрямую содержат информацию - сколько параллельно работающих графических ядер есть внутри и сколько треугольников в секунду способен обработать GPU. При этом речь идет о миллионах треугольников.

Разумеется, программисту гораздо удобнее описывать именно сцену, а не думать каждый раз, как пересчитывать координаты. Для этого и существуют библиотеки, работающие с трехмерной графикой. Для игровых приложений в Windows это DirectX, и конкретно DirectDraw и Direct3D. Однако это подходит больше для игр, к тому же рассчитано именно на Windows. Более универсальная и математически строгая библиотека - OpenGL. В настоящее время трудно найти видеокарту, которая не поддерживает обе эти библиотеки. Поддержка, правда, обеспечивается драйверами от производителей, но без драйверов видеокарта живет обычно до первой установки серьезной игрушки, которая обнаружит отсутствие драйверов и заставит их поставить.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 09:28 
Т.е. начальника транспортного цеха мы так и не услышим?
Повторю, пардон, вопрос. Какова связь между запуском FORTH под PASCAL-обезъянником и написанием на FORTH своей графической библиотеки?
Между:
Цитата:
Форт написан (при 10% готовности) на FreePascal с ШК и эмулируемыми стеками, Lazarus создает весь GUI динамически, имея подключенные модули.

и
Hishnik писал(а):
Есть целый пласт динамических изменений программы, для которых и Qt, и Lazarus уже пытаются добавлять разные скриптовые средства. А зачем придумыватб искусственные, если Форт является уже готовым продуманным интерпретатором-компилятором с широкими скриптовыми возможностями?


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 10:23 
Не в сети

Зарегистрирован: Пт июн 06, 2008 14:21
Сообщения: 128
Откуда: Карелия
Благодарил (а): 1 раз.
Поблагодарили: 4 раз.
Hishnik писал(а):
F-MAP писал(а):
В этом согласиться трудно, экран же пока плоский, все решаемо.. как с видеокартой взаимодействуют, OpenGL мог не на всех работать (ранее тестировал, сейчас наверно уже все поддерживают), с GDI проблем небыло

Работа с трехмерной графикой отличается очень существенно. Двумерная графика, с помощью которой и рисуются элемент интерфейса Windows, основана на обычном двумерном массиве пикселей. Потребности работы с ним давно закрыты с точки зрения аппаратуры. Другое дело, что библиотеки Windows ставят точки не просто так, а дополнительно проверяют, что рисуемый элемент не закрыт каким-то другим окном. В этом кроется небольшая проблема - например, "базовый" объект TCanvas, который как раз и позволяет закрасить любой свой пиксель в любой цвет, делает это достаточно медленно, если речь идет именно о пикселях, а не более сложных фигурах. Поэтому для закраски больших фрагментов экрана даже в 2D пользуются более сложными инструментами, дающими доступ непосредственно к видеопамяти.

Трехмерная графика устроена совершенно иначе. Разумеется, мы видим не физически трехмерное изображение, а его проекцию на экран. Однако даже для того, чтобы нарисовать такую проекцию, необходимо выполнить много математической работы. Например, если мы смотрим на куб с обратной стороны, то и рисовать надо обратную сторону, а не лицевую. В итоге описание трехмерного изображения сводится к описанию сцены. В нем указывается, какие точки находятся в трехмерном пространстве, какие фигуры они образуют, и какие текстуры наложены на эти фигуры. Далее необходимо указать, с какой точки и в каком направлении мы на это все смотрим, и видеокарта самостоятельно определит положение каждой описанной фигуры. Дополнительно будут использованы эффекты освещения, тумана, наложены фильтры, убирающие "ступеньки" на линиях и т.д. - все автоматически. Именно поэтому современная видеокарта стоит весьма приличные деньги. Ее производительность и характеристики напрямую содержат информацию - сколько параллельно работающих графических ядер есть внутри и сколько треугольников в секунду способен обработать GPU. При этом речь идет о миллионах треугольников.

Разумеется, программисту гораздо удобнее описывать именно сцену, а не думать каждый раз, как пересчитывать координаты. Для этого и существуют библиотеки, работающие с трехмерной графикой. Для игровых приложений в Windows это DirectX, и конкретно DirectDraw и Direct3D. Однако это подходит больше для игр, к тому же рассчитано именно на Windows. Более универсальная и математически строгая библиотека - OpenGL. В настоящее время трудно найти видеокарту, которая не поддерживает обе эти библиотеки. Поддержка, правда, обеспечивается драйверами от производителей, но без драйверов видеокарта живет обычно до первой установки серьезной игрушки, которая обнаружит отсутствие драйверов и заставит их поставить.

В этом ни кто не спорит, видеокарта сама все сделает! Вопрос в другом, как к примеру, мышкой захватить вращающийся треугольник и переместить в другое место без GDI? (OpenGL)


Последний раз редактировалось F-MAP Ср авг 10, 2016 10:58, всего редактировалось 1 раз.

Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 10:33 
F-MAP писал(а):
Вопрос в другом, как к примеру, мышкой захватить вращающийся треугольник и переместить в другое место?
Примерно, так - http://t0.esy.es/. Только, как видите, это быстро надоедает.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 11:15 
Не в сети

Зарегистрирован: Пт июн 06, 2008 14:21
Сообщения: 128
Откуда: Карелия
Благодарил (а): 1 раз.
Поблагодарили: 4 раз.
gudleifr писал(а):
F-MAP писал(а):
Вопрос в другом, как к примеру, мышкой захватить вращающийся треугольник и переместить в другое место?
Примерно, так - http://t0.esy.es/. Только, как видите, это быстро надоедает.

Да кому как, в Астрофорте, уже при DOSе были многооконные интерфейсы, Pascal был в ступе, ну вот тоже кому то надоело...


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 11:26 
Какой-то конкурс ответов на не заданные вопросы...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 12:29 
Не в сети

Зарегистрирован: Пт июн 06, 2008 14:21
Сообщения: 128
Откуда: Карелия
Благодарил (а): 1 раз.
Поблагодарили: 4 раз.
gudleifr писал(а):
Какой-то конкурс ответов на не заданные вопросы...

Разве форум не для обсуждения?..


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 12:38 
F-MAP писал(а):
Разве форум не для обсуждения?..
Нельзя что-то обсуждать, если никто друг друга не слушает. Впрочем, Вы правы - этот форум воспринимается рядом форумчан (и мной в том числе), как PR-площадка. Обсуждать здесь что-то уже давно не получается. Разве что, микро-самодельщики делятся сведениями о багах конкретных фигулек.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 14:56 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
F-MAP писал(а):
В этом ни кто не спорит, видеокарта сама все сделает! Вопрос в другом, как к примеру, мышкой захватить вращающийся треугольник и переместить в другое место без GDI? (OpenGL)

Вобщем-то это немного разные вещи. События от мышки посылаются сами по себе, и всегда можно рассчитывать, что нажатие-отпускание кнопок будет известно программе (вместе с координатами). Как программа отреагирует на нажатие, зависит уже от пользовательского кода. Отдельный момент - визуальные компоненты, поддерживающие Drag&Drop, но часто необходимо определять, захвачен ли объект, какими-то другими методами. Особенно это касается трехмерной сцены, где под каждой точкой экрана бесконечное число точек сцены (все точки прямой, перпендикулярной этому месту на экране), к тому же при вращении сцены или камеры одна и та же точка трехмерного пространства оказывается в разных местах. Для того, чтобы с этим всем работать, надо иметь базовые возможности библиотек, а не готовые функции на все случаи жизни. Примеры из OpenGL оставляют интересное впечатление. С одной стороны, выглядит красиво, с другой - оно плохо преобразуется в конкретные пользовательские программы. Задача, которую я предполагаю решить в этом проекте - минимизация объема кода, специфичного для ОС и библиотек. В инструментах, относящихся к Rapid Application Development, уже давно сделан важный шаг в эту сторону - программист не пишет код, относящийся к "главному циклу" GetMessage - TranslateMessage - DispatchMessage. Довольно неудобно запихивать ВСЮ отрисовку в единственный кусок кода под case wm_paint. Можно сделать еще один шаг, который, кстати, подсказывает OpenGL - программирование в стиле машины состояний. Например, сейчас реализованы элементы авторазмещения компонентов - каждый следующий располагается справа от предыдущего, при помещении куда-либо панели она становится родителем для всех компонентов, помещаемых после нее и т.п. В данном случае OpenGL является попросту равноправным компонентом в этом ряду, который тоже можно поместить куда-то.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 15:35 
Hishnik писал(а):
Задача, которую я предполагаю решить в этом проекте - минимизация объема кода, специфичного для ОС и библиотек.
Все бы хорошо, но, как я уже неоднократно пояснял, Ваше решение опять сводится к попытке заставить FORTH делать "как положено" (ОО-интерфейсам уже 40 лет), хотя он уже полвека уже умеет это делать "по своему".
Например, сколько раз Вам повторять, что цикл обработки сообщений никуда не надо "прятать", т.к. это просто цикл управления самого FORTH? Или, что совмещение вывода информации с ее графическим представлением естественно реализуется перекомпиляцией рисовалки?
Разделите, наконец, в голове две независимые задачи: 1) как научить программу интерфейсам? 2) как это реализовать на FORTH? Причем, второй вопрос может возникнуть только в том случае, если естественным способом "научить программу интерфейсам" будет выбран метод последовательнных приближений. Иначе, как обычно, получите реализацию на FORTH худого С++, на котором будете рожать худой Qt.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 17:22 
Не в сети

Зарегистрирован: Пт июн 06, 2008 14:21
Сообщения: 128
Откуда: Карелия
Благодарил (а): 1 раз.
Поблагодарили: 4 раз.
Hishnik писал(а):
F-MAP писал(а):
В этом ни кто не спорит, видеокарта сама все сделает! Вопрос в другом, как к примеру, мышкой захватить вращающийся треугольник и переместить в другое место без GDI? (OpenGL)

Вобщем-то это немного разные вещи. События от мышки посылаются сами по себе, и всегда можно рассчитывать, что нажатие-отпускание кнопок будет известно программе (вместе с координатами). Как программа отреагирует на нажатие, зависит уже от пользовательского кода. Отдельный момент - визуальные компоненты, поддерживающие Drag&Drop, но часто необходимо определять, захвачен ли объект, какими-то другими методами. Особенно это касается трехмерной сцены, где под каждой точкой экрана бесконечное число точек сцены (все точки прямой, перпендикулярной этому месту на экране), к тому же при вращении сцены или камеры одна и та же точка трехмерного пространства оказывается в разных местах. Для того, чтобы с этим всем работать, надо иметь базовые возможности библиотек, а не готовые функции на все случаи жизни. Примеры из OpenGL оставляют интересное впечатление. С одной стороны, выглядит красиво, с другой - оно плохо преобразуется в конкретные пользовательские программы. Задача, которую я предполагаю решить в этом проекте - минимизация объема кода, специфичного для ОС и библиотек. В инструментах, относящихся к Rapid Application Development, уже давно сделан важный шаг в эту сторону - программист не пишет код, относящийся к "главному циклу" GetMessage - TranslateMessage - DispatchMessage. Довольно неудобно запихивать ВСЮ отрисовку в единственный кусок кода под case wm_paint. Можно сделать еще один шаг, который, кстати, подсказывает OpenGL - программирование в стиле машины состояний. Например, сейчас реализованы элементы авторазмещения компонентов - каждый следующий располагается справа от предыдущего, при помещении куда-либо панели она становится родителем для всех компонентов, помещаемых после нее и т.п. В данном случае OpenGL является попросту равноправным компонентом в этом ряду, который тоже можно поместить куда-то.

Ну все равно, объект нужно где то хранить, чтоб программист знал и мог им манипулировать, в OpenGL кажется очень проблематично


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 17:47 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
F-MAP писал(а):
Ну все равно, объект нужно где то хранить, чтоб программист знал и мог им манипулировать, в OpenGL кажется очень проблематично

Ну, библиотеки вообще не являются местом хранения пользовательских данных. Они (и OpenGL, и DirectDraw и GDI) являются набором функций, которые делают что-то с окнами. Что именно они сделают, зависит от программиста. В каком именно месте экрана появится объект, тоже зависит от программиста. Поэтому да, Форт может хранить данные об изображении и вызывать подключенные функции.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 20:07 
Не в сети

Зарегистрирован: Пт июн 06, 2008 14:21
Сообщения: 128
Откуда: Карелия
Благодарил (а): 1 раз.
Поблагодарили: 4 раз.
Hishnik писал(а):
F-MAP писал(а):
Поэтому да, Форт может хранить данные об изображении и вызывать подключенные функции.
Вообще то к этому все и идет...как форту внедриться в скриптовый язык...


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Forth + Lazarus IDE
СообщениеДобавлено: Ср авг 10, 2016 21:15 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
F-MAP писал(а):
Вообще то к этому все и идет...как форту внедриться в скриптовый язык...

Форту не нужно туда внедряться, поскольку он и есть скриптовый язык. Если программы без возможности интерпретации надо писать сразу со всеми вариантами их поведения, то наличие интерпретатора позволяет управлять поведением уже в процессе работы с гораздо более широкими возможностями. Например, программист прекрасно знает, как поменять размер, положение и надпись на кнопке. Проблема только в том, что после редактирования текста необходимо все это перекомпилировать. Конечно, можно заранее предусмотреть возможность редактирования этих параметров, но тогда опять-таки надо придумывать диалоговые окна, формы, таблицы... получится тот же Дельфи. Если же программа имеет встроенный интерпретатор, то можно в процессе работы получать доступ к параметрам уже созданных компонентов, независимо от того, было ли это предусмотрено. А если, как в Форте, есть еще и компилятор, то появляется возможность создавать целые списки таких действий, задавать условные операторы, циклы и другие конструкции управления.

Скриптовые языки в последнее время получают все большее распространение. Это не только такие достаточно известные вещи, как Tcl и Lua, но и внутренние языки в тех же Qt и Lazarus. Причина понятна - от программ ожидаются все большие возможности, и реализовать их все только в графическом интерфейсе довольно сложно. В учебниках по визуальным средам разработки часто встречаются главы по динамическому созданию компонентов - это на ту же тему. Так что Форт как хорошо проработанный язык вполне годится на роль управляющего средства для ресурсов программы.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 89 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 15


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB