САПР на Lazarus
Модератор: Модераторы
Отличная новость 
Вот настало время когда надо свой векторный редактор (2D/3D) делать.. Привет Alex2013у.
Добавлено спустя 9 минут 50 секунд:
только я думаю усилить либлами:
Intel® Math Kernel Library (Intel® MKL)
Intel® Integrated Performance Primitives (Intel® IPP)
Добавлено спустя 9 минут 50 секунд:
только я думаю усилить либлами:
Intel® Math Kernel Library (Intel® MKL)
Intel® Integrated Performance Primitives (Intel® IPP)
Использовать за основу zcad не вариант?
При всей спорности решений и "корявости" внутри - многие вопросы у меня уже решены.
При всей спорности решений и "корявости" внутри - многие вопросы у меня уже решены.
у меня двигатель написан в с++11 Linux
Опирался на GLScene
Но нужен редактор всего этого дела. В ручную писать XML тяжело, даже мне.
Сижу и думаю на чем писать..
Добавлено спустя 17 минут 44 секунды:
на с++ нужно подключать либлы.. могут быть "вилы" в портирование не другие платформы..
Qt лицензия $3000, и пока не видел серьезные проекты..
а на делфи могу делать визуальные компоненты..
Опирался на GLScene
Но нужен редактор всего этого дела. В ручную писать XML тяжело, даже мне.
Сижу и думаю на чем писать..
Добавлено спустя 17 минут 44 секунды:
на с++ нужно подключать либлы.. могут быть "вилы" в портирование не другие платформы..
Qt лицензия $3000, и пока не видел серьезные проекты..
а на делфи могу делать визуальные компоненты..
Редактор игровых 3Д моделей?
тем более придется делать одному
Добавлено спустя 2 минуты 51 секунду:
наверное ближе к флэш анимации с аппаратным ускорением.
Добавлено спустя 2 минуты 51 секунду:
zub писал(а):Редактор игровых 3Д моделей?
наверное ближе к флэш анимации с аппаратным ускорением.
Тогда зкад наврятли подойдет - "универсализация" движка до ума не доведена
>>у меня двигатель написан в с++11 Linux\
Наверно и утилитки к этому двигателю стоит писать в томже ключе, и сам двигатель в утилитах использовать как можно больше
>>у меня двигатель написан в с++11 Linux\
Наверно и утилитки к этому двигателю стоит писать в томже ключе, и сам двигатель в утилитах использовать как можно больше
zub писал(а): "универсализация" движка до ума не доведена
Цель одна - embedded устройства. Тут пришлось переписать под Raspberry Pi #1 - работало..
Поэтому важно аппаратная оптимизация.
Я же сначала писал на fpc. Но из-за сложности разбора и перевода хендлов, ликования, отладки.. в итоге написал все на gcc.
Вот сейчас встал вопрос: на чем писать мне пользовательский интерфейс.. и писать буду один.
Добавлено спустя 1 минуту 23 секунды:
Пока ответ один - Lazarus/Delphi.
>>Но из-за сложности разбора и перевода хендлов
Что имеется ввиду?
Что имеется ввиду?
Ну допустим ffmpeg который я использую. Там мало того, что структура ответвленная, то может от версии сильно разнится..
Есть хендлы которые используют активно предпроцессор, и какой на выходе параметр может получится точно не скажешь..
Добавлено спустя 2 минуты 16 секунд:
чтобы собрать параметр.. смотришь в 20ти хендлах что от чего зависит.. уходят в kernel
Добавлено спустя 3 минуты 54 секунды:
сижу думаю чем мне реализовать такой подход:

Добавлено спустя 4 минуты 1 секунду:
tbrgabitmap - осилит?
Есть хендлы которые используют активно предпроцессор, и какой на выходе параметр может получится точно не скажешь..
Добавлено спустя 2 минуты 16 секунд:
чтобы собрать параметр.. смотришь в 20ти хендлах что от чего зависит.. уходят в kernel
Добавлено спустя 3 минуты 54 секунды:
сижу думаю чем мне реализовать такой подход:

Добавлено спустя 4 минуты 1 секунду:
tbrgabitmap - осилит?
>>Есть хендлы которые используют активно предпроцессор, и какой на выходе параметр может получится точно не скажешь..
Слабо понимаю слабо понимяю почему gcc тут лучше, разве что имеет нативные хидеры. ну да ладно
>>сижу думаю чем мне реализовать такой подход:
Вижу самодельные контролы (комбобоксы) их нормальные устанешь делать... самое простое - рисовать "такой подход" ручками на какомто канвасе, потом по кликам вставлять в нужные места нужные системные контролы с нужными значениями. такой подход очень ресурсобережлив. в инспекторе объектов (последний пост предидущей страницы) использую именно такой подход.
>>tbrgabitmap - осилит?
Для объема графики как на картинке - имхо с лихвой. только хз как он на пи работает
Слабо понимаю слабо понимяю почему gcc тут лучше, разве что имеет нативные хидеры. ну да ладно
>>сижу думаю чем мне реализовать такой подход:
Вижу самодельные контролы (комбобоксы) их нормальные устанешь делать... самое простое - рисовать "такой подход" ручками на какомто канвасе, потом по кликам вставлять в нужные места нужные системные контролы с нужными значениями. такой подход очень ресурсобережлив. в инспекторе объектов (последний пост предидущей страницы) использую именно такой подход.
>>tbrgabitmap - осилит?
Для объема графики как на картинке - имхо с лихвой. только хз как он на пи работает
zub писал(а):Слабо понимаю слабо понимяю почему gcc тут лучше, разве что имеет нативные хидеры. ну да ладно
вот чтобы написать так
Код: Выделить всё
// Find the decoder for the video stream
pCodec=avcodec_find_decoder(pCodecCtx->codec_id);
Нужно точно знать где codec_id находится в pCodecCtx
при этом avcodec_find_decoder может просто быть предпроцессорной величиной.. которая в последствии превращается в серию команд.. и для грамотного перевода на рельсы fpc нужно их все вписать..
Вроде в "дорожной карте" записано что компилятор паскаля в планах сможет спокойно читать сишный код.. но когда это будет реализовано?
zub писал(а):Вижу самодельные контролы (комбобоксы) их нормальные устанешь делать...
Вот меня и напрягает что в лазарусе почему то нет развитых контролов.. либо это тяжкий труд.. либо их некому делать..
zub писал(а):только хз как он на пи работает
на pi не надо.. Вообще Raspberry по вычислительным способностям где то на уровне Pentium4, с аппаратными кодеками/декодеками.. И сейчас это стало не можно, а нужно.
Добавлено спустя 8 часов 51 минуту 46 секунд:
Интерфейс который я показал был взят из Blender3D.
Оказалось они рисуют его через OpenGL
Добавлено спустя 26 минут 52 секунды:
Думаю можно через BGRABitmap..
Уже что то типа того делают:
http://wiki.freepascal.org/uE_Controls
Правда нет нужных Edit, Memo.
Вставлять в нужный момент системные контролы всяко проще чем писать свои и организовывать их работу внутри вивпорта.
Кроме того для начала можно обойтись без контролов на примитивах - инспектор штука универсальная)) и постепенно ростить мясо, мышцы и жирок
Кроме того для начала можно обойтись без контролов на примитивах - инспектор штука универсальная)) и постепенно ростить мясо, мышцы и жирок
Жить можно.
Добавлено спустя 4 минуты 57 секунд:
Можно эмулировать системный ввод. Ловить фокус, нажатие клавы.. и рисовать так как надо..
Это приведет к тому, что будет унифицированный интерфейс для разных платформ.
Добавлено спустя 4 минуты 53 секунды:
Добавлено спустя 4 минуты 57 секунд:
Можно эмулировать системный ввод. Ловить фокус, нажатие клавы.. и рисовать так как надо..
Это приведет к тому, что будет унифицированный интерфейс для разных платформ.
Добавлено спустя 4 минуты 53 секунды:
Код: Выделить всё
TTestBGRAEdit = class(TCustomControl)
private
{ Private declarations }
FMouseEnter:Boolean;
protected
{ Protected declarations }
procedure CreateParams(var Params: TCreateParams); override;
procedure InitializeWnd; override;
procedure MouseMove(Shift: TShiftState; X,Y: Integer); override;
procedure MouseEnter; override;
procedure MouseLeave; override;
procedure WMPaint(var Msg: TLMPaint); message LM_PAINT;
public
{ Public declarations }
constructor Create(AOwner: TComponent); override;
published
{ Published declarations }
end;
- Вложения
-
- o.gif (30.6 КБ) 21292 просмотра
Всетаки графический редактор (роде даже 3д фигурировало) и чтото вроде лазаревного дизайнера - разные вещи
