Флейм
GameDev.ru / Флейм / Форум / Часто ли вы упираетесь в потолок? (2 стр)

Часто ли вы упираетесь в потолок? (2 стр)

Поделиться

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

122Постоялецwww14 ноя. 201710:54#15
endeavour_pr
> А если скрыть хардварный курсор, и читая данные о его позициях рисовать там
> где он есть при условиях что он находится в приделах окна ?
Свой курсор будет отставать от хардварного, проверено. Видимо вплоть до кадра будет отставать. В навороченных движках с долгим конвеером кадра может и на 2-3 кадра, помню в Готике3 такое было.
MAMOHT-92Постоялецwww14 ноя. 201713:18#16
Maltakreuz
> Хотя сильно зависит от предметной области. Если ты делаешь процедурную анимацию
> или свою сборку мусора/АИ то такое вполне может случаится. Если же делаешь
> оконное приложение или хтмл-парсер у упираешься в потолок то явно что-то пошло
> не так.
плюсую, водь вся эта хрень под спойлером в 0 - посте, ну не верю я, что прям нельзя этого было избежать, что прям эти uniq нужны, ну и шаред тем более. ИМХО Shared они скорее для многопоточности нужны, расшаривая объект, между потоками, которые имеют разное время жизни, ну или какой-то сложный сильно связанный кастомный граф, где связку между нодами можно сделать через shared+ weaked.

Ну а так, опять же в большинстве случаев хватит, сделать одного владельца у объекта с временем жизни больше, чем у юзеров, ну а там, хоть сами через указатель и new / delete, хоть просто объект и передачу ссылок или адреса на него, ну и сдается мне, что в нормальный архитектуре всякой дичи со сменой владельца у объектов должно быть по минимуму.

romgermanПостоялецwww14 ноя. 201713:21#17
Можно курсор устанавливать через винапи, если что
kiparПостоялецwww14 ноя. 201713:23#18
romgerman
Как это поможет текст возле него вывести? Обновлять курсор при каждом изменении текста?
endeavour_prПостоялецwww14 ноя. 201713:29#19
romgerman
Через винапи это хардварный и есть.Можно вообще не заморачиваясь использовать хардварный, но нужен свой кастомный для плюшек.
Я думаю читать через винапи позиции хардварного, который будет скрыт, также нужно вычислять еще кое какие данные курсора, потом ставить кастомный нарисованный в прочитанные позиции но вопрос можно ли так вообще делать.Начал делать такую реализацию но пока что забил на это.
beejahПостоялецwww14 ноя. 201717:21#20
Вообще не очень понятно, почему напрягают тормоза, когда текст "возле курсора".
Ну, отстает при движухах - и хрен с ним - что за курсором глазами бегать, что за текстом.
А когда курсор стоит - такой проблемы и нет. Я к тому, что дилемма Эскобара, не с тем, возможно, борьба идет.

Правка: 14 ноя. 2017 17:22

cNoNimУчастникwww14 ноя. 201717:52#21
endeavour_pr
> Я думаю читать через винапи позиции хардварного, который будет скрыт, также
> нужно вычислять еще кое какие данные курсора, потом ставить кастомный
> нарисованный в прочитанные позиции но вопрос можно ли так вообще делать.Начал
> делать такую реализацию но пока что забил на это.
А как то можно по другому?
endeavour_prПостоялецwww14 ноя. 201718:09#22
cNoNim
хз, задействтвать дополнительный инпут ? но все равно придется вычислять позиции курсора относительно окна, узнавать где фокус и может быть что-нибудь еще.
Откуда DirectInput берет эти данные ? В какой то игре на DirectX это довольно  быстро сделано, может быть даже таким же способом или каким-то аналогичным.
beejahПостоялецwww14 ноя. 201718:41#23
endeavour_pr
> хз, задействтвать дополнительный инпут ?
С вероятностью, близкой к единице, тут ввод вообще ни при чем.
Просто читай, как можно позже. Если вынуть курсор из петли апдейта - никак (я хз, может, ты курсором гоблинов убиваешь там, лол), заведи второй, тупо для отрисовки.
endeavour_prПостоялецwww14 ноя. 201719:40#24
beejah
> С вероятностью, близкой к единице, тут ввод вообще ни при чем.
Тогда откуда отставание ?  перемещаешь быстро курсор и видно насколько отстает кастомный.
И откуда оно берется ? Фпс  много, тестировал на пустой сцене на которой кроме курсора и нескольких объектов ничего не было.
Типа можно предположить что между кадрами курсор успевает проделать путь а инпут не апдейтится, хз
раб вакуумной лампыПользовательwww14 ноя. 201720:01#25
У меня свой курсор. Всё обсчитывал вручную. Работа была - адская.
beejahПостоялецwww14 ноя. 201720:10#26
endeavour_pr
> Тогда откуда отставание ? перемещаешь быстро курсор и видно насколько отстает
> кастомный.
В смысле "откуда"? Ты в курсе, что у тебя в принципе всё там отстает от реальности?
Ты вообще никогда не визуализируешь текущее состояние системы.
Либо прошедшее, либо предполагаемое.

> И откуда оно берется ? Фпс много
2000 кадров в секунду + один кадр на полсекунды - это тоже "фпс много". Но "хвост" ты даже обдолбавшись транками успеешь заметить.
Тут конкретные цифры нужны - 1. пиковый + средний интервал между чтением курсора и визуализацией (можно тупо пессемистично взять фрейм. или половину. да хоть треть, тут вообще рулят порядки уже, лол), 2. скорость мыши. Вычисляешь ожидаемый лаг в пикселях, прикидываешь, насколько он меньше визуального.
Если намного - значит, да, тупо апдейт курсора не успевает.

> Типа можно предположить что между кадрами курсор успевает проделать путь а
> инпут не апдейтится, хз
Ды сбрось фпс всинком в 60 и не трахай мозг.
Чего ты на каких-то теоретических сверхскоростях гадаешь. Нахера?

beejahПостоялецwww14 ноя. 201720:17#27
Пц у разрабочика проблема - сцена рендерится так быстро, что курсор апдейтиться не успевает. Лол.
Выкинь модную видюху, поставь древнее говно, проблема уйдет на второй план.

Правка: 14 ноя. 2017 20:18

endeavour_prПостоялецwww14 ноя. 201720:23#28
beejah
Я не про лаги.
endeavour_prПостоялецwww14 ноя. 201720:25#29
beejah
> Пц у разрабочика проблема - сцена рендерится так быстро, что курсор апдейтиться
> не успевает. Лол.
> Выкинь модную видюху, поставь древнее говно, проблема уйдет на второй план.
И речь не об этом, это известная в юнити проблема

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

/ Форум / Флейм / Программирование

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