HLFX.Ru Forum Страницы (2): [1] 2 »
Показать все 54 сообщений этой темы на одной странице

HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Технические вопросы (https://hlfx.ru/forum/forumdisplay.php?forumid=20)
-- Библиотека FLTK (https://hlfx.ru/forum/showthread.php?threadid=5048)


Отправлено XaeroX 31-10-2017 в 07:49:

Библиотека FLTK

Изрядно намучившись с поддержкой самописной библиотеки виджетов vWidgets в волатиле, я принял решение от неё отказаться (код - в девнул, воспоминания - в треш). Решил найти готовое решение. Основные критерии - простота, кроссплатформенность, легковесность бинарников при статической линковке, возможность использовать в коммерческих проектах с закрытыми сорцами. В итоге выбор пал на FLTK
http://www.fltk.org/index.php

Потыкал - вроде интересно выглядит. Под линукс и макось собралась почти без проблем, всего каких-то два часа гугления и работы в консоли (это реально "быстро" и "без проблем", есличо) примеры под макосью заработали. Под винду пока собирать не пробовал.

Кто-нибудь пользовался этой библиотекой? Какие подводные камни?
Что используете в своих проектах, монстры типа Qt или wxWidgets, или что-то аналогично-легковесное?

__________________

xaerox on Vivino


Отправлено nemyax 31-10-2017 в 08:46:

Сам не писал под фултик и пользовался всего одной программой на нём (Dillo). Могу только сказать, что штатный селектор файлов там никуда не годится. Хотя не знаю, потребуется ли тебе такого рода функциональность в движке. А с кнопками-ползунками-скролами проблем не встречал.
Но это так, заметки мимокрокодила.


Отправлено XaeroX 31-10-2017 в 09:45:

Цитата:
nemyax писал:
Хотя не знаю, потребуется ли тебе такого рода функциональность в движке.

В движке нужны собственно окошки, кнопки, лейблы, чекбоксы, радиокнопки, листбокс. Вроде бы всё. В общем, самые базовые вещи.

__________________

xaerox on Vivino


Отправлено (_-=ZhekA=-_) 31-10-2017 в 10:55:

Цитата:
XaeroX писал:
Под линукс и макось собралась почти без проблем

На Андройде тоже будет работать? )

__________________
Kiss my ass if you don't like my Ford!
------------------------------------------
Game Area51 Update 1
First Person Shooter Released Jul 24, 2017
The game is a 3d shooter with the elements of the quest.

http://button.moddb.com/download/medium/125531.png


Отправлено nemyax 31-10-2017 в 11:03:

Цитата:
XaeroX писал:
В общем, самые базовые вещи.

А что там с OpenGL-вьюпортом, не разбирался? А то вон в gtk3 прям специализированная GtkGLArea есть. Правда только для GL 3.2 и выше.


Отправлено XaeroX 31-10-2017 в 13:53:

Цитата:
nemyax писал:
А что там с OpenGL-вьюпортом, не разбирался?

Тоже имеется, как я понял.
http://www.fltk.org/doc-1.1/Fl_Gl_Window.html
Цитата:
(_-=ZhekA=-_) писал:
На Андройде тоже будет работать?

На андроиде эти диалоги не особо нужны.

__________________

xaerox on Vivino


Отправлено XaeroX 02-11-2017 в 08:32:

Так, ну что. Пока полёт нормальный, под виндой работает.

Цитата:
nemyax писал:
штатный селектор файлов там никуда не годится

Там есть Fl_Native_File_Chooser.

__________________

xaerox on Vivino


Отправлено nemyax 02-11-2017 в 12:29:

Сильно тулкит увеличивает размер исполняемого файла на венде?


Отправлено XaeroX 02-11-2017 в 14:29:

Прилично увеличивает, учитывая, что я линкую статически и FLTK, и CRT.
Просмотрщик текстур увеличился с 250 кб до 500 кб.
Остальные пока ещё не перевёл на FLTK.

Добавлено 02-11-2017 в 21:29:

Зато под макосью просмотрщик текстур наконец-то заработал, и не пришлось сношать мозги с Cocoa.

__________________

xaerox on Vivino


Отправлено Crystallize 02-11-2017 в 15:15:

А Джек будешь переносить?


Отправлено XaeroX 04-11-2017 в 08:44:

Мне всё больше нравится FLTK! Портирование, по крайней мере, простых GUI-программ - это удовольствие.

http://pix.academ.info/images/img/2017/11/04/03cd30e904b0aaff1f6cfe27a6af7b68.png

__________________

xaerox on Vivino


Отправлено nemyax 04-11-2017 в 10:39:

XaeroX
Там есть возможность ловить кейкоды нажимаемых клавиш, а не символы?


Отправлено XaeroX 04-11-2017 в 11:32:

nemyax
Нет, конечно. Это вообще где-то есть?

__________________

xaerox on Vivino


Отправлено nemyax 04-11-2017 в 11:42:

В gtk заявлено: https://developer.gnome.org/gdk3/st...tml#GdkEventKey


Отправлено FiEctro 04-11-2017 в 12:34:

XaeroX
Супер! Ждем порт Джека

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено XaeroX 04-11-2017 в 12:50:

nemyax
Я подозреваю, что эти hardware_keycode не только не портабельны, но ещё и от модели клавиатуры зависят. Толку-то с них?

__________________

xaerox on Vivino


Отправлено nemyax 04-11-2017 в 13:04:

Надо бы повыяснять, совпадают ли они с вот этими.


Отправлено XaeroX 04-11-2017 в 13:11:

Это виндовые виртуальные сканкоды, они ведь и называются virtual. С чего они должны совпадать?
В движках делают специальные маппинги системные сканкоды <-> движковые сканкоды, и таблицы соответствий для каждой ОС свои.

__________________

xaerox on Vivino


Отправлено nemyax 22-02-2018 в 18:21:

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


Отправлено XaeroX 22-02-2018 в 23:32:

Без доков, просто создал новый проект, добавил туда все нужные файлы, настройки сделал по вкусу.
Сложности будут, наверное - т.к. FLTK написан на С++, там классы.

__________________

xaerox on Vivino


Отправлено nemyax 23-02-2018 в 05:29:

А собирал какой студией?


Отправлено XaeroX 23-02-2018 в 07:54:

nemyax 2017.

__________________

xaerox on Vivino


Отправлено nemyax 23-02-2018 в 08:38:

XaeroX
И какую версию FLTK ты взял?


Отправлено XaeroX 23-02-2018 в 08:57:

Дык самую свежую на тот момент, с их сайта. FL_ABI_VERSION = 10302.

__________________

xaerox on Vivino


Отправлено nemyax 26-02-2018 в 15:06:

Да, вроде отличная штука. Для сборки за глаза хватает студии 2008 экспресс, исполняшки маленькие и статически линкованные. Круть.


Отправлено XaeroX 26-02-2018 в 17:14:

nemyax
Дык!

__________________

xaerox on Vivino


Отправлено FreeSlave 26-02-2018 в 18:00:

Цитата:
XaeroX писал:
Я подозреваю, что эти hardware_keycode не только не портабельны, но ещё и от модели клавиатуры зависят. Толку-то с них?


Есть смысл знать физическое расположение клавиш, если хочешь чтоб игроки могли одинаково класть руки в независимости от qwerty/azerty.
Но я не знаю, насколько такая практика распространена в играх.

__________________
I'm on github
I'm on opendesktop.org


Отправлено XaeroX 26-02-2018 в 18:04:

FreeSlave
Ты предлагаешь вшить в игру аппаратные сканкоды всех известных клавиатур?

__________________

xaerox on Vivino


Отправлено nemyax 26-02-2018 в 18:14:

Уж наверняка цифробуковки-то у большинства клавиатур имеют одинаковые кейкоды.
Кстати, они таки доступны через static int Fl::event_key().


Отправлено XaeroX 26-02-2018 в 18:16:

nemyax
Это не аппаратные сканкоды, а виртуальные. От ОС зависят, в общем.

__________________

xaerox on Vivino


Отправлено nemyax 26-02-2018 в 18:22:

Не исключено, что в FLTK они обёрнуты одинаково. Но чё гадать, с другой стороны.


Отправлено FreeSlave 26-02-2018 в 20:02:

XaeroX, походу это можно через виртуальные сканкоды сделать. В SDL есть такая штука https://wiki.libsdl.org/SDL_Scancode
Нажатие на A на azerty клавиатурах возвращает SDL_SCANCODE_Q. Глянул сорцы - там маппинги на коды в ОС. Так что ты прав, хардвар-коды тут лишние.

__________________
I'm on github
I'm on opendesktop.org


Отправлено nemyax 09-06-2018 в 09:51:

Вопросики скорее не про саму либу, а про организацию взаимодействия её с OpenGL. Вот сделал я подкласс Fl_Gl_Window и реализовал триде-вьюпорт для геометрии. Всё зашибись, но теперь я хочу ещё один подкласс, который будет дваде-вьюпортом для ювишек.
Все данные на отрисовку доступны через один и тот же VBO — и для 3D, и для 2D. Надо ли предпринимать что-нибудь особенное, чтобы обе разновидности вьюпорта работали одновременно? Как лучше поступить с шейдерными прогами: создавать под каждый тип вьюпорта свою или юзать общую (и вкорячивать дополнительные условия и униформы в шейдеры)? Не будет ли гонок из-за общего доступа к VBO?


Отправлено XaeroX 09-06-2018 в 10:09:

Цитата:
nemyax писал:
Надо ли предпринимать что-нибудь особенное, чтобы обе разновидности вьюпорта работали одновременно

Нужно расшарить ресурсы между контекстами обеих вьюпортов.
Не могу сказать, как это делается в FLTK, увы.
Цитата:
nemyax писал:
Не будет ли гонок из-за общего доступа к VBO?

Что именно ты собираешься писать в VBO каждый кадр? Нельзя обойтись стейтом и униформами?
Цитата:
nemyax писал:
Как лучше поступить с шейдерными прогами: создавать под каждый тип вьюпорта свою или юзать общую (и вкорячивать дополнительные условия и униформы в шейдеры)?

Нужно профилировать и сравнивать. Я бы (при отсутствии времени на профилирование) предпочёл первый вариант.

__________________

xaerox on Vivino


Отправлено nemyax 09-06-2018 в 10:28:

Цитата:
XaeroX писал:
Нужно расшарить ресурсы между контекстами обеих вьюпортов.

Ну то есть если по-простому, то завести что-нибудь наподобие:

C++ Source Code:
1
struct render_state
2
{
3
  GLuint shader_program_3d;
4
  GLuint shader_program_2d;
5
  GLuint vert_buffer;
6
  GLint my_uniform3d_1;
7
  GLint my_uniform3d_2;
8
  GLint my_uniform2d_1;
9
  GLint my_uniform2d_2;
10
};


И в обоих подклассах определить и присвоить:
C++ Source Code:
render_state *shared_res;

Так получается?

Цитата:
XaeroX писал:
Что именно ты собираешься писать в VBO каждый кадр?

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


Отправлено XaeroX 09-06-2018 в 10:42:

nemyax
Тебе надо расшарить идентификаторы между двумя OpenGL-контекстами. Это делается по-разному в зависимости от ОС. Например, под виндой это wglShareLists. В FLTK должно быть что-то такое в API (в Qt, допустим, есть).

Цитата:
nemyax писал:
у меня содержимое будет перезаписываться только при выполнении команд в основной проге.

Тогда в чём может заключаться гонка?

Добавлено 09-06-2018 в 17:42:

Судя по коду, FLTK по дефолту шарит все контексты с первым.
Ну тогда вообще ничего специально делать не надо.

__________________

xaerox on Vivino


Отправлено nemyax 09-06-2018 в 10:51:

Цитата:
XaeroX писал:
Тебе надо расшарить идентификаторы между двумя OpenGL-контекстами. Это делается по-разному в зависимости от ОС.

Ага, благодарю, буду копать.

Цитата:
XaeroX писал:
Тогда в чём может заключаться гонка?

Мало ли, вдруг при чистом чтении она тоже может происходить. Я как-то glVertexAttribPointer-ом насовал вершинам атрибутов с соседних вершин дальше по массиву, чтобы не дублировать. Так у меня рендерилось то ожидаемое, то кокаета хрень, как повезёт. Вот теперь дую на воду.


Отправлено nemyax 04-07-2018 в 14:00:

Цитата:
XaeroX писал:
Судя по коду, FLTK по дефолту шарит все контексты с первым.
Ну тогда вообще ничего специально делать не надо.

Не похоже на то. Стоят рядом два одинаковых GL-окошка, одно рендерит буфер, другое нет. Идентификаторы они на отрисовку отдают одни и те же.


Отправлено XaeroX 04-07-2018 в 14:02:

nemyax
Я же говорю - "судя по коду"

C++ Source Code:
if ( context ) {
  if ( context_list && nContext ) [b]wglShareLists( context_list[0], context )[/b];
  add_context( context );
}

__________________

xaerox on Vivino


Отправлено nemyax 05-07-2018 в 13:21:

Карочы надо взять у первого GL-окошка контекст через void *my_shared_context = first_good_gl_win->context(); и потом явно задавать его другим нужным окошкам через other_gl_win->context(my_shared_context);. Тогда будет шариться.


Временная зона GMT. Текущее время 22:47. Страницы (2): [1] 2 »
Показать все 54 сообщений этой темы на одной странице

На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024