freepascal.ru

Чуток прибрался в исходниках - окончательно разделил векторный движек и зкад + удалил все зависимости внутри движка от функций зкада.
Заодно раскидал все юниты в папки по назначению и тотально всё переименовал: zcxxxxx.pas - файл зкада, zexxxxx.pas - файл движка. За время работы над зкадом несколько раз менял принципы именования юнитов - накопилась большая каша. Переименование пока не коснулось системы контейнеров, подумываю поменять этот велотрактор времен D6 на что нибудь на основе генериков

Попробовал PasDoc для генерации документации - очень годно получается... дело за малым - комментировать хотя бы основные моменты))

зы. Наконец то зкад компилится релизным лазарем 1.6+3.0

Затеял переделку контейнеров с велосипеда на указателях на велосипед на генериках. "Стабильности" теперь долго невидать(( последняя более-менее рабочая ревизия - 1857

zub, ты в bim идеологию вникал?
Я собственно к чему, acad манипулирует числами с большой точностью. Это его плюс и минус одновременно. Плюс в том что генпланисты могут планы с точными координатами выполнять, минус в том что для отдельного здания точность не нужна большая, а при большом объеме данных тормозит все. Для программ проектирования bim зданий, точность больше пары знаков после запятой не нужна. Может стоит в программе для координат использовать свой тип данных. Что то вида

чтобы потом можно было создавать отдельные сборки, которые будут быстрее работать за счет замены в одном месте строки с выше приведенной, на строку с меньшим возможным кол-вом знаков после запятой в типе данных. Насколько я понимаю, это должно ускорить проверку при больших объемах.
или бред?

Свой тип есть почти на всё, в том числе и на оброботку координат, с стародавних времен зовется GDBDouble, но скоро и до него дойдут переименования))
На современных компах ускорения думаю небудет, да и памяти не так много сэкономится. А вот точность упадет в разы.
Я в свое время немало усилий положил для отображения геометрии сильно удаленной от начала координат без искажений. потом поменял разрядность того что рисуется (не того что в примитивах) с double на single и всё испортил - удаленная геометрия снова искажается.

Бим - смутно представляю что это такое

Попробовал с GDBDouble=single
Есть некоторые прблемы:
Бакенд OpenGL реализован без перегрузки функций, поэтому ждет ^double а приходят ^single - нифига не рисуется
Какието проблемы в "скриптовом" "движке" - где то сидит захардкоденый double... приводит к краху зкада на старте

А вот simplecad (в нем нет скриптов и инспектора объектов) завелся и нормально отображает примитивы в окне с gui рендером

А разница в скорости?

Разницу в скорости на современных компах незаметно. Когдато давно была

zub писал(а):Разницу в скорости на современных компах незаметно. Когдато давно была

это с двумя линиями не заметно.

Чуток объективных показателей - создание миллиона рандомных линий + пространственная "разбивка"
double

Add lines: 1.4201 second
Rebuild spatial tree: 1.1597 second

537564 KB отъеденой памяти диспетчере процессов

single

Add lines: 1.3750 second
Rebuild spatial tree: 0.9873 second

456912 KB
чуток быстрее, но не критично

Последнее время преследовали проблемы с сборкой - при небольших изменениях в коде приходилось полностью пересобирать проект - перекомпиляция вываливалась с ошибкой. Как только начал юзать генерики - эта проблема попила кровушки((
И наконец после http://svn.freepascal.org/cgi-bin/viewv ... sion=34069 вылеты при компиляции вылечились!

Попробовал запилить регистрацию типов данных на основе RTTI для несложных record`ов вдобавок к используемому сейчас парсенью pas файлов.
Чтоб например какойнить команде для показа своих опций в инспекторе ненадо было их прописывать в \rtl\system.pas (в виде описания соответствующего типа данных), а достаточно было выполнить процедуру наподобии

и можно было показать var MyRecord:MyRecord в инспекторе.
В принципе ниче сложного, но оказалось RTTI не хранит информацию о типах "синонимах", например:

Раньше я мог привязать к типу GDBAngleDouble процедуру отображения в инспекторе в соответствии с настройками чертежа: Радианы\Градусы\МалолиЧтоЕще и оно бы работало для всех TTestRec где встречаются данные типа GDBAngleDouble.
РТТИ что такое GDBAngleDouble не знает и возвращает для Angle тип Double((

zub писал(а):РТТИ что такое GDBAngleDouble не знает и возвращает для Angle тип Double((

тебе нужно так:

Подробно написано, как ни странно, в Type Aliases.
Если ты раньше TypeInfo не использовал, то всё должно работать как и прежде но если использовал, то тонкости описанны по ссылке.. и, судя по всему, это как раз те тонкости, которые ты хочешь использовать!

скалогрыз
Слона то я и не приметил. Спасибо!

скалогрыз писал(а):GDBAngleDouble= type double;

Зачем давать имя новому типу данных с дублированием старого?

Sharfik, например, для контроля ошибок.