на самом деле я не 100% уверен в этом способе используя deltaTime(в примере#1 он сработал идеально, а во-втором не очень) потому что можно делать таймер как делал я используя timer += deltaTime и проверку If. НО про этот способ написали те, кто и создали эту функцию с повышенным фпсом, а значит они точно знают о чем говорят(пост: devforum.roblox.com/t/introducing-the-maximum-framerate-setting/2995965 ) поэтому вам решать какой способ использовать. я прям на 100% не уверен, но оба они выглядят хорошо.
Название и тема видео похожа на название и тему видео от английского роблокс студиера Stepwiepfing'a 🧐, но я всё равно рад что нашёл ру ютубера чьи знания в скриптинге не кончаются на принте)
на Unity кстати это уже давно есть, нельзя привязываться к фреймрейту, но в roblox всем было без разницы, хотя там тоже это правило должно учитываться... ведь... А если у человека слабый комп? И у него условно 25 fps место 60, в итоге имеем что игра вообще замедленна
В хороших системах всегда использовали dt, так как это базированная вещь в любых движках, поэтому проблемы могут возникнуть только в плохих системах, которые написаны неопытными скриптерами
огоооо, супер не ожидал тебя тут увидеть. кстати спасиб что когда-то зашел на мой стрим объяснять мне этот ваш так называемый OOP, месяца 3-4 назад наверно пересмотрел тот стрим+нашел rbx файл и чисто только из-за этого понял +- как все работает и начал юзать модульные скрипты в принципе. ты крутой ✌ вывел в люди так сказать
"Хорошие" примеры кода фактически являются также плохими, так как они используют анонимные лямбда функции, которые негативно влияют на производительность. Вместо этого: RunService.Heartbeat:Connect(function(deltaTime) --То что будет совершаться end) Нужно писать это: local function deltaTime() --То что будет совершаться end RunService.Heartbeat:Connect(deltaTime)
а можешь скинуть где почитать про негативное влияние лямбды на производительность? я поискал и ниче такого не нашел, мб плохо поискал. буду рад узнать что-то новое
@@clockus Ты не найдёшь, так как эта проблема есть только на luau и она практически никак не влияет. Такая же проблема есть и с переменными на этом языке, если их не делать локальными, то это также скажется на производительности, хотя на оригинальном lua этого нет.
@HUEGLOTIK1337 нууу даже интересно потестить стало, потом посмотрю как время появится. "не локальные переменные" это ты имеешь ввиду используя _G? и раз уже на то пошло, на других языках я так понял лямбды не несут импакта производительности?
@@FondiX_0 кстати я поискал и тоже не нашел, попробывал сам сделать в роблокс студио и никакой законномерности не нашел. то лямбды были быстрее то обычные функции быстрее
Я в недоумении насчет пример номер 3. У меня всё работает если ставить долгую задержку, как на видео - 1 секунду или типо того. Но если я хочу, чтоб каждую секунду проигрывалась функция 60 раз, то есть чтобы задержка была 1 / 60, то всё идет не так как хотелось бы. В таком случае всё не будет так гладко и приятно, а будут различия при разных FPS... Я уже устал мучаться и искать решение этой штуки, ведь примеры №1 и №2 мне не подходят
Как в 3 примере сделать взрыв не раз в 1 секунду, а 60 или 120 раз в секунду? UPD: в 3 примере нельзя поставить число меньшее чем 0.0167 (1/60), ведь кадры не идеальны и при 60 fps кадр не появляется каждую 0.0167 секунды, а с разбросом (как было в видео)
@@FondiX_0 Пробовал, но оно не работает таким образом. В самом видео видно, что при 60 fps не всегда выдает 0.0167, т.е. 1/60, на 0.005 больше/меньше и так далее. Оно бы работало, если бы всё было идеально, но увы
@@SadlekAski если поставить 0.5 или даже 0.1 то да, оно будет работать. Но если ставить число от 1/60 и меньше, то так как мы хотим оно не будет работать. Система не идеальна и каждый кадр появляется не каждые 0.0166 секунд (1/60). Допустим игра выдает кадр каждые 0.015 секунды, тогда если мы поставим "число" равное 1/60 (т.е. чтоб было 60 взрывов в секунду), то взрывов в секунду у нас будет 30, ведь скрипт ждет пока сумма будет равна или больше чем 0.0166, а такое у нас происходит каждые 2 кадра, (0.015*2 = 0.03 >= 0.0166). И это если у нас идеальные 0.015, а так взрывов в секунду может быть и 35 и 42 и 57 и так далее.
тут проблема в другом. Мы имеем время всегда больше секунды например 1.01 и эту дробную часть просто обнуляем из-за чего немного не стабильный цикл получается. Чтобы дробную часть не обнулять можно использовать остаток от деления, вот так. timer %= 1 Тогда все дробные части будут оставаться. А чтобы проверить что была превышена секунда можно хранить два таймера и их сравнивать. lastFrameTimer = timer timer %=1 if lastFrameTimer > timer then [что-то делаем] end Вместо 1 подставляем нужную цифру. Хотя подобное писать в Heartbeat не советую. Точно такой же трюк можно совершить с task.wait(1) которая вернёт фактическое время которое прошло и оно явно будет выше цифры которую в неё передали. local T = 1 -- сколько секунд ждать local ostatok = 0 wait true do ostatok = (task.wait(T-ostatok)+ostatok) % T [что-то делаем] end Только решение с task.wait не будет делать проверку каждый кадр и это решение более оптимизированно
на самом деле я не 100% уверен в этом способе используя deltaTime(в примере#1 он сработал идеально, а во-втором не очень) потому что можно делать таймер как делал я используя timer += deltaTime и проверку If. НО про этот способ написали те, кто и создали эту функцию с повышенным фпсом, а значит они точно знают о чем говорят(пост: devforum.roblox.com/t/introducing-the-maximum-framerate-setting/2995965 ) поэтому вам решать какой способ использовать. я прям на 100% не уверен, но оба они выглядят хорошо.
Название и тема видео похожа на название и тему видео от английского роблокс студиера Stepwiepfing'a 🧐, но я всё равно рад что нашёл ру ютубера чьи знания в скриптинге не кончаются на принте)
на Unity кстати это уже давно есть, нельзя привязываться к фреймрейту, но в roblox всем было без разницы, хотя там тоже это правило должно учитываться...
ведь... А если у человека слабый комп? И у него условно 25 fps место 60, в итоге имеем что игра вообще замедленна
В хороших системах всегда использовали dt, так как это базированная вещь в любых движках, поэтому проблемы могут возникнуть только в плохих системах, которые написаны неопытными скриптерами
УРООО ТЕСМИИИ
огоооо, супер не ожидал тебя тут увидеть. кстати спасиб что когда-то зашел на мой стрим объяснять мне этот ваш так называемый OOP, месяца 3-4 назад наверно пересмотрел тот стрим+нашел rbx файл и чисто только из-за этого понял +- как все работает и начал юзать модульные скрипты в принципе. ты крутой ✌
вывел в люди так сказать
@@clockus ещё одна проблема - это модуль спринг, он некорректно работает с большим фреймрейтом, его надо переписывать
"Хорошие" примеры кода фактически являются также плохими, так как они используют анонимные лямбда функции, которые негативно влияют на производительность.
Вместо этого:
RunService.Heartbeat:Connect(function(deltaTime)
--То что будет совершаться
end)
Нужно писать это:
local function deltaTime()
--То что будет совершаться
end
RunService.Heartbeat:Connect(deltaTime)
а можешь скинуть где почитать про негативное влияние лямбды на производительность? я поискал и ниче такого не нашел, мб плохо поискал. буду рад узнать что-то новое
@@clockus Ты не найдёшь, так как эта проблема есть только на luau и она практически никак не влияет. Такая же проблема есть и с переменными на этом языке, если их не делать локальными, то это также скажется на производительности, хотя на оригинальном lua этого нет.
@HUEGLOTIK1337 нууу даже интересно потестить стало, потом посмотрю как время появится. "не локальные переменные" это ты имеешь ввиду используя _G? и раз уже на то пошло, на других языках я так понял лямбды не несут импакта производительности?
@@clockusНе только "_G" переменные, но и любые переменные без "local" в начале менее производительней на luau. Насчёт других языков я не знаю.
@@FondiX_0 кстати я поискал и тоже не нашел, попробывал сам сделать в роблокс студио и никакой законномерности не нашел. то лямбды были быстрее то обычные функции быстрее
хорошие разработчики сразу учитывают проблему не равного фпс, так что навредит это обновление только не опытным)
Я в недоумении насчет пример номер 3. У меня всё работает если ставить долгую задержку, как на видео - 1 секунду или типо того.
Но если я хочу, чтоб каждую секунду проигрывалась функция 60 раз, то есть чтобы задержка была 1 / 60, то всё идет не так как хотелось бы.
В таком случае всё не будет так гладко и приятно, а будут различия при разных FPS...
Я уже устал мучаться и искать решение этой штуки, ведь примеры №1 и №2 мне не подходят
Респект, на самом деле годно, хоть и видео подойдет не на большую аудиторию
Как в 3 примере сделать взрыв не раз в 1 секунду, а 60 или 120 раз в секунду?
UPD: в 3 примере нельзя поставить число меньшее чем 0.0167 (1/60), ведь кадры не идеальны и при 60 fps кадр не появляется каждую 0.0167 секунды, а с разбросом (как было в видео)
подумай, а вообще сделай число 1 ниже
@@FondiX_0 Пробовал, но оно не работает таким образом. В самом видео видно, что при 60 fps не всегда выдает 0.0167, т.е. 1/60, на 0.005 больше/меньше и так далее. Оно бы работало, если бы всё было идеально, но увы
@@SadlekAski если поставить 0.5 или даже 0.1 то да, оно будет работать. Но если ставить число от 1/60 и меньше, то так как мы хотим оно не будет работать. Система не идеальна и каждый кадр появляется не каждые 0.0166 секунд (1/60). Допустим игра выдает кадр каждые 0.015 секунды, тогда если мы поставим "число" равное 1/60 (т.е. чтоб было 60 взрывов в секунду), то взрывов в секунду у нас будет 30, ведь скрипт ждет пока сумма будет равна или больше чем 0.0166, а такое у нас происходит каждые 2 кадра, (0.015*2 = 0.03 >= 0.0166). И это если у нас идеальные 0.015, а так взрывов в секунду может быть и 35 и 42 и 57 и так далее.
@@НикитаМикулич-с3г ну да
тут проблема в другом. Мы имеем время всегда больше секунды например 1.01 и эту дробную часть просто обнуляем из-за чего немного не стабильный цикл получается.
Чтобы дробную часть не обнулять можно использовать остаток от деления, вот так. timer %= 1
Тогда все дробные части будут оставаться. А чтобы проверить что была превышена секунда можно хранить два таймера и их сравнивать.
lastFrameTimer = timer
timer %=1
if lastFrameTimer > timer then [что-то делаем] end
Вместо 1 подставляем нужную цифру.
Хотя подобное писать в Heartbeat не советую. Точно такой же трюк можно совершить с task.wait(1) которая вернёт фактическое время которое прошло и оно явно будет выше цифры которую в неё передали.
local T = 1 -- сколько секунд ждать
local ostatok = 0
wait true do
ostatok = (task.wait(T-ostatok)+ostatok) % T
[что-то делаем]
end
Только решение с task.wait не будет делать проверку каждый кадр и это решение более оптимизированно
у меня камера чуть поломалась из-за этого апдейта, но фиксится легко благо
Приветствую, подскажите пожалуйста как сделать чтобы меню в игре появлялось только при старте, а если игрок умер то меню снова не появлялось?
братишка спасибо большое, мне теперь половину игры всей переписывать
по моему ничего не изменится, т.к. почти все сейчас с bloxstrap'ом
хз кто как, а я через пару скриптов ограничил фпс в ручную
дельта тайм это основа геймдева ес че
перевел
Скорей наоборот
Такое в Unity и вроде как в Unreal Engine
сильно ничего не поменяется,у многих итак стоит фпс анлокер
то что удалили из гд добавили в роблокс)))
Жду видео про самый лучший,часто используемый найнужнейший найкрутейший сервис
Tweenservice возможно либо RunService
workspace
Че то слишком сильно за стиви захавал даже эпизоды емае
Тот самый я на телефоне которой не имеет функции менять fps
Миллионы "тех самых их"
Тоже самое, у меня даже экран 120 герц 🤔
@@luascripts не может быть, что у тебя 120 герц, но менять нельзя
ты крутой