Проекты
GameDev.ru / Проекты / Форум / AvalancheProject - рендер движок под Free Pascal (3 стр)

AvalancheProject - рендер движок под Free Pascal (3 стр)

Страницы: 1 2 3 4 5 Следующая »
skalogryzУчастникwww22 мая 20186:35#30
а есть ли функции для инициализации базовых типов, чтобы свои типа Vec4RGB не писать?
function Vec4RGB(r,g,b: single; alpha: single=1): TVec4;
begin
  Result.f[0]:=r;
  Result.f[1]:=g;
  Result.f[2]:=b;
  Result.f[3]:=alpha;
end;

procedure TForm1.FormPaint(Sender: TObject);
begin
  if not Assigned(fMain) then Exit;
  FMain.Bind;
  try
    FMain.Clear( Vec4RGB(0,0.75,0.5)); // greenish fill color
    // FMain.Clear( Vec4RGB(random,random,random)); // WARNING!!! resizing of the window might make you sick 
    FMain.Present;
  finally
    FMain.Unbind;
  end;
end;

upd: нашёл - это Vec()

upd2: в Instancing примере под Лазаря, используется    procedure EraseBackground(DC: HDC); override;
но он нифига не помогает, и погоды не делает. Экран остётся чёрным (Windows 10). Что помогает, так это отключить манифест тем. (так рекомендовалось ещё с Висты)

upd3: TContext_OGL.Bind не возвращает false, в принципе. так и задумано? (wglMakeCurrent может обломиться)

Правка: 22 мая 2018 7:06

MrShoorУчастникwww22 мая 20187:06#31
skalogryz
> Что помогает, так это отключить манифест тем. (так рекомендовалось ещё с Висты)
Там вроде в настройках проекта все отключено должно быть. Ну то есть темы само собой надо отключать, но EraseBackground тоже нужен. Они разную задачу выполняют.

upd. Проверил. Да, манифест там отключен, потому что в Instancing.lpi нет строки <UseXPManifest Value="True"/>

Правка: 22 мая 2018 7:20

MrShoorУчастникwww22 мая 20187:07#32
skalogryz
> TContext_OGL.Bind не возвращает false, в принципе. так и задумано?
> (wglMakeCurrent может обломиться)
Скажем так, это временное решение, потому что я еще не разобрался в каких случаях обламывается wglMakeCurrent

Правка: 22 мая 2018 7:07

skalogryzУчастникwww23 мая 20182:02#33
MrShoor
> Скажем так, это временное решение, потому что я еще не разобрался в каких
> случаях обламывается wglMakeCurrent
а он у тебя часто обламывается?

я думал он упасть, может только, или из-за кривых параметров, или из-за кривых дров:
раз, два


MrShoor
> но EraseBackground тоже нужен
не позволят эффект "моргания" при стандартной отрисовке? (например через Invalidate).
по-моему, с Вин7 не актуально, т.к. вся отрисовка в окне принудительно через double buffer. А вот в XP - 100% поможет.

Правка: 23 мая 2018 2:03

MrShoorУчастникwww23 мая 20183:14#34
skalogryz
> а он у тебя часто обламывается?
Еще ни разу не обламывалось

> я думал он упасть, может только, или из-за кривых параметров, или из-за кривых
> дров:
> раз, два
Угу. Но кривых параметров там не должно быть на уровне классов.

> не позволят эффект "моргания" при стандартной отрисовке?
Да, эффект моргания при стандартной отрисовки. Мой TRenderMain.InvalidateWindow вызывает InvalidateRect с флагом, что не надо чистить фон. Но часть виндовых событий таки говорят, чтобы фон перерисовался. И вот тогда ты видишь моргания.

> по-моему, с Вин7 не актуально, т.к. вся отрисовка в окне принудительно через
> double buffer.
Актуально для всех версий Windows. Дело в том, что если не обрабатывать wm_erasebkgnd, то вызывается обработчик по умолчанию, а этот обработчик по умолчанию чистит фон кистью класса окна.

skalogryzУчастникwww23 мая 20185:41#35
MrShoor
> Еще ни разу не обламывалось
> Но кривых параметров там не должно быть на уровне классов.
"Window" - самый кривой из параметров. (н.р. если передать GetDesktopWindow, то валится с OSError при инициализации для apiOGL; для apiDX11 - молча проходит дальше, делает Bind, но Present никак не влияет)
про Bind всегда возвращающий true - наплевать, на самом деле,  я просто оставлю памятку, ибо не критично.

Правка: 23 мая 2018 5:47

MrShoorУчастникwww10 июня 20185:36#36
За пару дней запилил простенькую систему UI в фреймворк (в контексте идущего конкурса).
Алсо запилил маленькую демку:
tilt | AvalancheProject - рендер движок под Free Pascal
Хотя тут всего панелька с одной кнопкой и одним EditBox-ом, система классов вышла достаточно интересная. Думаю другие контролы допилить будет не проблема. Но потом. Как-нибудь.

Правка: 10 июня 2018 6:14

skalogryzУчастникwww13 июня 20185:26#37
MrShoor
> TavmCustomTextEdit looks promise, but need more improvements.
> At least need replacement caret with separate graphics. Adding a symbol into the middle of string looks bad

ну офигеть, а кто это говорил:
> ... графика отвязана от логики контрола.
> В руки дается канвас, который уже умеет в хинтинг по пиксельной сетке + в нем
> есть достаточно продвинутая работа с текстом.
Добавление "|" в качестве курсора не является частью логики TavmCustomTextEdit, а лишь способом её отображения ;)

по-уму все текстовые операции, нужно выносить в отдельный модуль... и процесс может начать расти Лавинообразно! :)

Кстати, у меня встречные претензии:
1) fText стал UnicodeString, и это хорошо, но вот SetText() и сам fText, хорошо бы сделать protected. Иначе дочерний класс текст без нотификации OnChange поменять не сможет.
2) если отрывать логику от представления, то и каретку нужно либо убирать из TavmCustomEdit. Либо делать CaretVisible виртуальным.
Иначе при движения курсора, последний может пропадать:
test42 | AvalancheProject - рендер движок под Free Pascal

а не слишком жирно UPS на каретку тратить?

3) а у тебя в Винде русский charset, как системный ANSI? потому что при попытке напечатать "привет мир", у меня печаталась "всякая хрень". И вот накопал :)
+ тест

Правка: 13 июня 2018 6:10

MrShoorУчастникwww13 июня 20187:04#38
skalogryz
> ну офигеть, а кто это говорил:
Всмысле кто? Я говорил. Ну то есть я бы может и добавил твой пример в репозиторий, но ему нужны доработки.

> по-уму все текстовые операции, нужно выносить в отдельный модуль... и процесс
> может начать расти Лавинообразно! :)
Зачем в отдельный модуль выносить текстовые операции? Почему нельзя оставить логику работы с текстом в CustomEdit, а отображение в наследниках?

> 3) а у тебя в Винде русский charset, как системный ANSI? потому что при попытке
> напечатать "привет мир", у меня печаталась "всякая хрень". И вот накопал :)
Ага, русский как дефолтный ANSI стоит с давних времен. Какая-то программа не поддерживала юникод, и я когда то ставил. И вот как следствие - моя программа тоже не поддерживает юникод. xD
Спасибо, что раскопал это. Щас почитаю еще подробнее что к чему, и пофикшу. ;)

MrShoorУчастникwww13 июня 20187:08#39
skalogryz
> Иначе при движения курсора, последний может пропадать:
Кстати, если ты заглянешь в TavmCustomEdit, то там такая штука есть:
procedure TavmCustomEdit.Notify_Char(AChar: WideChar; const Ex: TKeyEventEx);
begin
  inherited Notify_Char(AChar, Ex);
  if Ord(AChar) < 32 then Exit;

  FCaretStartTime := Main.Time64; //устанавливаем текущее время

  if not CanAddChar then Exit;
  Text := Text + AChar;
end;
Как раз чтобы курсор не пропадал пока вводишь. :)

> а не слишком жирно UPS на каретку тратить?
А есть варианты эффективнее?
1. UPS - это не OnIdle. Происходит только с заданными интервалами.
2. Invalidate же происходит только когда каретка спряталась или показалась:

  if newCaretState <> FCaretState then
  begin
    FCaretState := newCaretState;
    Invalidate;
  end;  
Иначе вообще ничего не происходит
3. На событие OnUps контрол подписывается только в момент получения фокуса и отписывается при потере фокуса. А одновременно не более одного контрола могут держать фокус.

Правка: 13 июня 2018 7:13

skalogryzУчастникwww13 июня 20187:13#40
MrShoor
> Кстати, если ты заглянешь в TavmCustomEdit, то там такая штука есть:
а FCaretStartTime приватный...

MrShoor
> Почему нельзя оставить логику работы с текстом в CustomEdit, а отображение в наследниках?
потому что ты насаздаешь определённую йерархию:
всё что имеет дело с текстом должно наследоваться от CustomEdit (например CustomMemo или ComboBox)
(хотя даже в LCL-е combobox от едита не наследуется).

Если компонент "текстовой" обработки, будет существовать отдельно от Edit-а, то ты улучшаешь гибкость системы.

MrShoor
> А есть варианты эффективнее?
чё-нить моделеннее, типа системного таймера?
да хотя пофигу - всё равно идёт через очередь сообщений.

Правка: 13 июня 2018 7:24

MrShoorУчастникwww13 июня 20187:30#41
skalogryz
> а FCaretStartTime приватный...
А есть вообще смысл его выносить в протектед?

> должно наследоваться от CustomEdit
Наследовать текстовую логику сложно. Можно либо взять её целиком, либо не брать, и реализовывать новую. Вертеть 100500 виртуальных методов, которые можно было бы перекрыть выглядит не очень.
На вскидку я кстати вижу всего 3 логики для контролов.
1. line edit
2. multiline edit
3. rich edit
Собственно CustomEdit в идеале должен покрыть первый вариант.

skalogryzУчастникwww13 июня 201816:19#42
MrShoor
> Наследовать текстовую логику сложно. Можно либо взять её целиком, либо не брать, и реализовывать новую.
и это проще сделать, если:
skalogryz
> все текстовые операции, нужно выносить в отдельный модуль.
И сделать текстовые операции отдельным классом.
Тогда реализация контрола, будет использовать класс для работы с текстом.
А любые правки в классы обработки текста, будут автоматически применятся ко всем контролам, использующим их.
Классы должны возвращать достаточно информации, чтобы в код .DoValidate() был проще.

MrShoor
> А есть вообще смысл его выносить в протектед?
ну если не наследовать от TavmCustomEdit, а наследовать от TavmCustomControl, то, конечно, выносить в протектед ничего не нужно.

MrShoor
> На вскидку я кстати вижу всего 3 логики для контролов.
> 1. line edit
> 2. multiline edit
> 3. rich edit
ну это одна логика, со свойстами: isSingleLine (подавлять linebreak-и) и isRichText (если false, подавлять все расскаски... например при вставке текста из буфера обмена).

MrShoorУчастникwww13 июня 201817:42#43
skalogryz
> И сделать текстовые операции отдельным классом.
Я пока не вижу как оно будет проще. Можешь набросать примерное api такого класса?

skalogryz
> ну это одна логика
Не согласен. Если multiline еще худо бедно можно натянуть костылями на singleline логику, подавляя перевод строки, удаляя переносы при вставке, оборачивая мультилайн апи в сингл лайн и прочее, то рич эдит сильно будет отличаться, и если натягивать рич эдит на другие контролы, то костыльного кода будет много больше, чем если бы мы сделали отдельную реализацию.

skalogryzУчастникwww14 июня 20182:53#44
MrShoor
> Я пока не вижу как оно будет проще. Можешь набросать примерное api такого класса?
нужно как минимум 2 класса:
+ TTextLayout
+ TTextCommand

Соответсвенно, у какого-нить едита (мемы, комбобокса) структура будет такой:

  TFancyControl = (TavmCustomControl) 
  private
    fControl : TTextCommand; // вызывается через Notify_Char, изменения SelLength
    fView : TTextLayout;  // вызывается при DoValidate(), а так же оповещается при изменениях текста
    ...
  end;
у какого-нить рич-едита, fView будет вызываться чаще (при измении форматирования).
И как видишь, ничто не мешает Edit,Memo,RichEdit сделать одним контролом.
Виндовский Edit/Memo не есть RichEdit, по одному очень важному признаку. Edit/Memo скролируются по строкам, RichEdit по пикселям

Опять же, если возможность редактирования не нужна, то получаем такую вещь:

  TFancyLabel = (TavmCustomControl) 
  private
    fView : TTextLayout;  // вызывается при DoValidate()
     ...
  end;
TTextControl попросту не используется, и получаем Label, с хитрыми возможностями выкладки, и форматированием текста.

На простых контролах - да, TTextLayout, будет заниматся тем, что выводить текст в прямоугольник.
Но как, долго ты хочешь сидеть в рамках прямоугольника?!
Кроме того, когда появится ClipRect, и весь текст уже не нужно будет выводить на экран, уже захочется иметь что-то автоматическое, что сообщит, какой минимальный кусок текста нужно вывести с каким клип-ом.

ЗЫ: ...я бы и каретку сделал бы отдельным классом. :)
Основная прелесть, в том, что классы должны быть открытыми. Т.е. любой другой писатель контролов, мог бы использовать их по-своему усмотрению, без принуждения наследоваться от EditControl-ов.
Например: сколько вариантов RichComboBox ты видел в Делфях?

ЗЗЫ: если говорить об играх, претендующих на интеллектуальность: РПГ, Стратежки и т.п. То там присутствует куча всяких "пособий" для чтения, где всегда есть необходимость в выкладке rich текстов (с картинками, кнопками прочим гипертекстом). (не каждый же раз писать свой верстальщик - один раз для всего)

Правка: 14 июня 2018 3:23

Страницы: 1 2 3 4 5 Следующая »

/ Форум / Проекты / Собираю команду

2001—2018 © GameDev.ru — Разработка игр