freepascal.ru

Сделал по 3му варианту, пока работает только с перемещениями камеры и редактированием геометрии выделенных примитивов мышью.
Для примитивов всё выглядит прозрачно и ундо\редо неотличимо от редактирования мышью (т.е. пользовательских команд которые ундятся и редятся). В стеке запоминается адрес метода вызванного пользователем и данные передающиеся в этот метод в 2х вариантах для comit и undo.

С простыми объектами всё ок - ундится и редится как надо. c вложенными объектами тоже всё ок, вроде даже на неограниченной глубине вложенности...
Проблемы есть в случае самомодифицирующихся объектов, например примитив net - электрическая цепь, представляет из себя список соединенных отрезков. Умеет самомодифицироваться:
-в случаее если отрезки перестали соединяться распадается на несколько примитивов net, чтоб каждый содержал только соединяющиеся отрезки
-умеет объеденять соединяющиеся отрезки являющиеся продолжением друг-друга, один отрезок удаляет, второй продлевает.

Например есть T-образная цепь, в нормальном состоянии состоит из 3х отрезков с узлом в в верхней точке вертикального отрезка.
Ситуация:
Пользователь редактирует T до вида Y(изменяет геометрию верхних отрезков), потом подумав редактирует обратно до вида T(без ундо, мышкой, верхние отрезки снова стали продолжением друг-друга)
Затем отцепляет от цепи вертикальный отрезок - цепь распадается на 2 цепи. первая с двумя верхними отрезками, вторая с отсоединенным. Причем первая еще и модифицируется, узел теперь ненужен, отрезки - продолжение другдруга, один из них удаляется, другой продляется.
Т.е. в итоге в чертеже 2 цепи, по одному отрезку в каждой.
Если сейчас пользователь жмет ундо - отсоединенный отрезок снова присоединяется к верхнему сегменту, цепи соединятся, добавится узел и верхний отрезок снова разобъется на 2 (это всё делается внутри класса net, и лезти туда совсем не хочется).
При дальнейших нажатиях ундо - будет AV, т.к. примитив метод которого запомнен - удален и вместо него сгенерирован новый.

Даже если сохранить удаленный отрезок, как его подсунуть обратно? чето я совсем туплю

В зкаде я особо оптимальности кода внимания не уделял, больше алгоритмам. Сейчас в функциях векторной геометрии расставил модификаторы const - время рендера теста уменьщилось с прыгающего 108-редко128 до 90-редко108 + визуально панарамирование чертежа стало пошустрее (не рендерные затраты тоже уменьшились).

Перебор элементов списков у меня практически везде сделан в цикле через инкрементируемый указатель, во всех сторонних исходниках куда не посмотрю - в цикле через индексацию. Индексация быстрее указателя? fpc разворачивает списки?

zub писал(а):В зкаде я особо оптимальности кода внимания не уделял, больше алгоритмам. Сейчас в функциях векторной геометрии расставил модификаторы const - время рендера теста уменьщилось с прыгающего 108-редко128 до 90-редко108 + визуально панарамирование чертежа стало пошустрее (не рендерные затраты тоже
уменьшились).

Время рендера 54-73, "сглаживание линий" почти не влияет.
Стало намного веселей.

>>Стало намного веселей.
Это еще появился statemanager для OpenGL, у меня на NV9600 сейчас тоже 50-70мсек. Хз почкму он влияет на сглаживание - оно включается один раз за кадр. Видимо на ATI при включеном сглаживании переключения состояний медленней чем с выключеным

Мужики, помогите пожалуйста скомпилить бинарник для linux x86, с кросскомпиляцией у меня не выходит((
исходники http://svn.shamangrad.net/zcad/trunk/
нужен транковый Lazarus и прилепить из cad_source/patch anchordocking.patch и opengl_win_gtk2.patch

Вопрос с компиляцией снимается - обзавелся убунтой х86.

Попрошу совета с реализацией простого скриптового языка для "чертежных команд" - механизмов создания и изменения примитивов. Сейчас их у меня два вида:
"Простые" - по сути просто процедуры, пользователь нажал кнопку или хоткей - процедура выполнилась и всё. Например пользователь нажал ctrl+A запустилась процедура SelectAll_com и пометила все примитивы в чертеже как выбранные. Нажал del - процедура Erase_com удалила все выбранные примитивы.
"Сложные" - это классы со своими onStart,onEnd,onCancel,onMouseEvent и т.д. При запуске такой команды она становится активной, хапает на себя контроль мышки, может вывешивать в инспектор объектов свои параметры, добавлять тулбары со своими действиями. Завершается такая команда когда пользователь прокликает нужное количество раз (сама вызывает CommandManager.ExecuteCommandEnd) или нажмет еск. Например Circle - сначала ждет клика в центре планируемой окружности, потом клика для расчета радиуса, паралельно рисуя "резиновую" окружность.

Реализован примитивный стек команд - во время выполнения "сложной" команды можно вызвать "простую" ("сложную" нельзя) потом управление возвращается в "сложную". Например вызовы ундо\редо во время черчения полилинии отменяют\возвращают начерченные вершины.

Эти "сложные" команды стали черезчур сложными(( охота их упростить.
Есть мысль разбить их на маленькие, организовать общение через некий стек возвращаемых значений и комбинировать через некий скрипт. например Line_com (чертит линию) можно свести к "скрипту" GetPoint;GetPoint;CreateLine
GetPoint - ждет указания пользователем точки и помещает ее в стек возвращаемых значений, CreateLine выбирает из стека 2 точки и создает на их основе линию.
Также хочется иметь возможность создания новых инструментов черчения без программирования, а изменением скриптов - например рисование линий стрипом и фаном

Интересует мнение стоит ли овчинка выделки и может есть похожие языки чтоб не придкмывать синтаксис.

Автолисп из автокада.
Если не выпендриваться - интегрировать какой-нибудь существующий скриптовый язык, например луа или php.
На общении через стек основан Форт, но он уж очень своеобразный для массового применения.

>>Автолисп из автокада.
>>Если не выпендриваться - интегрировать какой-нибудь существующий скриптовый язык, например луа или php.
Полноценные скриптовые языки в данном случае сложны и не нужны и нужно как можно проще иначе мне не осилить
>>На общении через стек основан Форт, но он уж очень своеобразный для массового применения.
Спасибо! читаю про форт

Так есть ведь реализация паскаля для FreePascal. Зачем что-то выдумывать? Подключить, и в шоколаде!

zub я бы смотрел в сторону LUA. Но это моё ИМХО

Рекомендую PascalScript или Lua. С луа немного позамороченей работа, а паскальскрипт привычнее и интегрируется легче, правда хз как он в работе, я его не сильно трогал)

Lua хоть и перспективней PascalScript но штука чужеродная - непонятно как она впишется в типы данных паскаля, имею ввиду классы обжекты рекорды и т.д.
Гляжу PascalScript - многообещающе, но пока непонятно с какой сторны его начинать лепить. До шоколада надо копать и копать

Подпилил стек команд до возможности вложенного выполнения "сложных" команд - упрощение команд на лицо, но нет контроля за стеком возвращаемых значений, там может оказаться не то что ожидается и тогда швах((
Вообще в томже автокаде есть не только автолисп, изначально для простых маросов там задуман свой язык DIESEL который позволяет в зависимости от текущих условий сформировать строку и подсунуть ее на выполнение интерпретатору команд, но на кнопки можно вешать и лисп.

Завел страничку на SF https://sourceforge.net/projects/zcad/files/ там бинарники под win и lin, исходники пока остались на шаманграде

Добавлено спустя 12 часов 58 минут 3 секунды:
PascalScript не совсем то что мне надо. Он подходит для автоматизации "простых" команд - ненадо писать процедуры обертки для действий, например переключение типа проекции сейчас завернуто в

Код: Выделить всё

function ChangeProjType_com(Operands:pansichar):GDBInteger;
var
   ta:TmyAction;
begin
     ta:=tmyaction(MainForm.StandartActions.ActionByName('ACN_PERSPECTIVE'));
  if GDB.GetCurrentDWG.OGLwindow1.param.projtype = projparalel then
  begin
    GDB.GetCurrentDWG.OGLwindow1.param.projtype := projperspective;
    if ta<>nil then
                   ta.Checked:=true;

  end
  else
    if GDB.GetCurrentDWG.OGLwindow1.param.projtype = projPerspective then
    begin
    GDB.GetCurrentDWG.OGLwindow1.param.projtype := projparalel;
      if ta<>nil then
                     ta.Checked:=false;
    end;
  redrawoglwnd;
  result:=cmd_ok;
end;

Будет круто если подобные обертки получится вытянуть из бинарника и посадить на скрипты.
Для "сложных" команд надо чтото другое, они не выполняются в виде процедуры, они размазаны по обработчикам onЧетоТам, PascalScript скрипт

Код: Выделить всё

var
    point:GDBVertex;
begin
        point:=GetPoint.run;
end;

Работать не будет, GetPoint.Run запустится, перехватит мышку на себя и управление вернется в скрипт. А возвращаемое значение возникнет только тогда когда пользователь ткнет мышкой и выполнится GetPoint.MouseClick

Для "сложных" команд надо чтото другое, они не выполняются в виде процедуры, они размазаны по обработчикам onЧетоТам

Значит пора рефакторить)

zub писал(а):Lua хоть и перспективней PascalScript но штука чужеродная - непонятно как она впишется в типы данных паскаля, имею ввиду классы обжекты рекорды и т.д.
Гляжу PascalScript - многообещающе, но пока непонятно с какой сторны его начинать лепить. До шоколада надо копать и копать

Если Вы про http://wiki.freepascal.org/Pascal_Script, который от RemObjects, то я его использовал и мне понравилось.
Я его использовал примерно так: пользователь вводил некую формулу или группу формул (перечень доступных переменных я ему предоставлял), например: "if Abs(Param3)>1e-6 then Result:=Param1+Param2/Param3 else Result:=Param1;"
Я дальше этот текст уже сам оборачивал нужными конструкциями и отправлял на выполнение.

Нечто подобное можно и для вашей задачи.

B4rr4cuda
>>Значит пора рефакторить)
Я слабо представляю в какую сторону, внутри GetPoint.run крутить application.run?

alexey38
>>Если Вы про http://wiki.freepascal.org/Pascal_Script, который от RemObjects, то я его использовал и мне понравилось.
да, про него.
>>Нечто подобное можно и для вашей задачи.
Можно и нужно. Он поддерживает record? object?
Примеры из поставки требуют хорошего напильника чтоб завестись под лазарем((