Ответ: Sigel
 

Отличный пример!
Слушай, а что насчёт того чтобы не DeInit сделать, а Destroy? Помоему более понятно и как-то принято так больше.
Вообще простейший пример, ссупер!

Ответ: Sigel
 

можно и Destroy. Но тогда все прошлые примеры придется переделывать.
не думаю что это критично (на крайняк можно просто сделать функцию типа int Destroy {return DeInit();} )

Ответ: Sigel
 

Но всёже, сам понимаешь, что как никак, а имена функций лучше раньше продумать, нежели потом когда-то делать чуть ли не полный "рефакторинг" имён функций, лишь потому что из-за не продуманности, они все как бордак..

Ответ: Sigel
 

посоветоваться.

есть у меня команда ChangeResolution - она позволяет сменить разрешение динамически (т.е. во время выполнения программы). Все бы хорошо, но мешаются динамические screenspace текстуры (это такие текстуры, в которые рендерится картинка, обычно для постпроцесса). Ясно, что при изменении разрешения, такая текстура уже не будет актуальной и ее надо пересоздать (то же относится и к фреймбуферам, но пока речь не о них).

собственно что можно сделать:

1) ничего не делать. все ложиться на плечи конечного программиста.

2) сделать список screenspace текстур. и при изминении разрешения, они будут обновляться (сжиматься или расширяться, по ситуации)

3) при смене разрешения смотреть все текстуры размером с текущее. и если такие есть то обновить их.

4) комбиация 3 и 4 пункта. если размер текстуры совпадает с размерами екрана, то автоматически заносить ее в список screenspace текстур. Если то не так - то в любой момент можно будет убрать из списка такую текстуру вручную.

Ответ: Sigel
 

Второе как то логичнее

Ответ: Sigel
 

Я считаю не привязывать такой моммент к движку, это создание по мне так "лишнего" интерфейса и каких-то "тонкостей".
Я полностью за 1ое! Это ведь в разы лучше, чем полностью перегружать ВСЮ медию и всё пересоздовать (ведь при потери графикс девайса, вся медия теряется и вся видео память от этого приложения отчищается, так ведь). А тут мы имеем только какую-то текстуру, пересоздать её, проблем нет для кодера. Но я думаю там могут быть завязки во многих других аспектах с текстурами, поэтому и не делал бы ни 3 ни 2 варрианты.

Вот ещё моммент: 2D, как с ним будет дело обстоять при смене разрешения?

Ответ: Sigel
 

напишу свои плюсы и минусы каждого метода:

1. плюсы:
* мне ничего писать не надо
* абсолютная гибкость
минусы:
* пользователю писать много. то не один десяток строчек кода скорее всего.

2. плюсы:
* все понятно. нет никаких "тонкостей"
минусы:
* нужно внимательн смотреть при создании screenspace текстур,незабыть добавить ее в етот список (это скорее всего будет просто tex->ScreenSpace(true);, ну или что то в этом роде

3. плюсы:
* все работает автомаически
минусы:
* все работает автомаически
т.е. если нам нужна именно текстура 1024 на 768, и она случайно совпадет с размероим экрана - то она запишется как screenspace, и никак от етого не уйти.

4. сочетает плюсы 2 и 3-его метода. если ето просто текстура то и выкидываем ее из списка. если не просто - то все работает на автомате.


дык я о чем. вся фишка етого ChangeResolution в том, что не нужно перезагружать медиа, шейдеры и прочее. само изменение работает за 1-2 секунды. единственное что нужно будет пересоздавать - ето renderable текстуры. все остальное не теряется, даже при переходах fullscreen \ windowed.

тут есть тонкость...
по умолчанию 2д будет рисоваться тупо, т.е. если мы сделали, меню например, для 1024 на 768, то в разрешении 1600 на 1200 ето меню будет в левом верхнем углу. НО! если до вывода писать Start2D(1024 на 768 ) то ето меню растянется на весь екран. Причем коррекция происходит на уровне обработки вершин, т.е. качество будет не сильно теряться, как, например при рендере в текстуру и растягивание на весь кран. + граница картинка будет четкой, и даже сглаженной при включеном антиалиасинге.

кстати,добавил Destroy.
DeInit теперь считается deprecated.

Ответ: Sigel
 

В первом, самостоятельный менеджер этой темы, пишется за 20 минут.
С 2D, ну поидее мы иссключаем любые возможности перехода с разных соотношений вертикали и горизонтали? Это про то что кто-то запустит в 800,600 на вайд-скрине, и потом сменит на вайд..

Ответ: Sigel
 

HolyDel
просто сделай у текстуры метод TieToWindowSize
переход window\fullscreen сделал так же как и у меня (и у trackmania и тд) - разворот окна на полный екран и отключение оформления ?

Ответ: Sigel
 

дык в гл вроде по другому и не сделать.

для 3d сцены aspct ratio настраивается автоматически. А вот в 2d да, придется конечному пользователю думать, как сделать так, чтобы выглядело нормально. сам переход возможен, но тогда картинку или сплющит или растянет.

Ответ: Sigel
 

Слушай, а от этого же потери большие! Ведь вот запусти не фулл скрин приложение, и фулл скрин (я про ДХ), разница очень большая, даже при большем разрешении, в фуллскрине будет быстрее чем в окне..

Тут посмотреть на любую игру с гуи - это нормально и практикуемо. Большое разрешение также любят те, кто умещает на экран много интерфейса, т.к. его больше вмещается (потому что не растягивается), поэтому я думаю фичу растягивания, ни в коем случае не делай по дефолту, т.к. она то будет юзаться Только для 2Д игр, мира. Для гуи, всегда думаю будут оставлять те же размеры, а вот позиция будет привязана к ориентирам, например: низ-центр. (как в RPG панельки, например WoW)

Ответ: Sigel
 

Ну написал на блице простейшее пустое приложение.

в окне 1800 (0.555 мс)
в фуллскрин 2100 (0.476мс)

оверхед окна - 0.079мс. не слишком высокая цена при среднем времени кадра - 10 - 20 мс. зато не имеем геморроя с alt+tab - ом, бонус при смене разрешения и т.д. минус, который я так и не смог побороть - это всякие всплывающие окна (аська например)

да вопрос не в плюсах и минусах, а в том, что честный фулскрин на гл не сделать (насколько мне известно).

я и не собирался :)

Ответ: Sigel
 

ужос! это реально так?
текущий фулскрин - это окно под размер разрешния декстопа с заданным коэффциентом вывода?

Ответ: Sigel
 

ага. теперь объясните, пожалуйста, в чем ужос?

Ответ: Sigel
 

Объясняю: при "честном" фуллскрине смена буферов происходит без копирования чего-л куда-л, а просто ссылки на BackBuffer и на FrontBuffer меняются местами. В оконном режиме картинка полностью копируется в буфер окна, что занимает много времения, поэтому-то и юзать оконный режим нежелательно.
Не может быть, чтобы OpenGL не давал делать "честный" фуллскрин, иначе это же изврат полный.

Къ посту 634
Самый лучший вариант 1. У прогера своя голова на плечах.
Ну, 2 тоже покатит.
Но 3 и 4 не рулят, т.к. размер = размер экрана даже в принципе не может быть. Текстура бывает только степени двойки, т.к.ю текстуры 1280*1024 создать нельзя, только 2048*1024, нельзя сделать 1024*768, а только 1024*1024. Какая тут привязка к разрешению, вы что? Глупость нах. 1024*1024 - может оказаться как текстура какого-нибудь ГУЯ, так и текстура стены/металла/монстра и т.д.
Кроме того частенько (у меня) текстура для рендера раза в 2-4-8 меньше разрешения экрана, так что тут тоже никак не привяжешь автоматом.
Короче привязка автоматом - это ересь, либо 2 либо 1
По мне так и 1 неплохо, нечего делать всё за прогера.