Ну разрешение экрана по вертикали сможешь определить. Допутим это Y.
Вот и делай текстуру близкой к этом. Не забывай про тайлинг. Для кирпичиков это не нужно будет например.
Следи за FPS за последню минуту. Если вдруг резко упадет - то повышать разрешение не надо.
Я вспоминаю старые трюки с домофоном. Обычно от нескольких лет использования пина
(3 или 4) цифры, на кнопках образуются довольно заметные потертости. И далее - дело
техники.
4 известные цифры дают 24 комбинации пинов. Осталось их быстро перебрать.
На некоторых корпоративных конфигурациях Windows 11 тоже используется
разновидность pin кода в 6 цифр.
Я знаю только одно приложение которое пострадало от резкой быстроты.
Это DOS-овская игра digger. Она нормально шла на 286 тачках и
слишком быстро летала на 486. Просто нельзя было играть. Приходилось
ее тормозить кнопкой Турбо (да была такая).
Интересно почему автору поплохело от скорости. Обычно люди радуются...
Евгений Мартынов, ты опиши реальную бизнес-задачу. И скорее всего С++ ники тебе накидают
много советов. А просто так хотеть аннотацию - это выглядит как дамский каприз.
Очень странно что у тебя был паблик который не администрируется.
Обычно такие паблики быстро превращаются в "городской чят" где
мат и личные оскорбления в норме и люди будут крепить линки
на педофилию и призывы к терроризму. Вобщем мораль басни
такова что тебе проще все закрыть. Надеюсь ты не сильно пострадал.
Евгений Иванов, не знаю чел. Ничего не могу сказать. Вот те кто пишут что 100х100 это не много
- пускай сделают proof. Приложение на 10 строчек которое двигает эти 10 тыщ юнитов
и транслирует стабильный fps. И после этого можно пойти шаг-за шагом и сличать различия
между эталоном и твоим кодом.
WbICHA, ну если мы с тобой следующим тестом будем тестировать создание файлов то вдруг
окажется что Node и браузер это очень сильно разные вещи. Хотя да... они могут использовать
какой-то один engine.
Но когда в топик приходит человек с бенчмарком - то самый первый вопрос к нему это на каком
программном продукте мы тестироуем (разрядность 32/64) и ОС и версии всего-всего.
Поэтому я категорически не согласен с таким волюнтаризмом в тестах.
Впрочем тебе еще прилетит от коллег если ты будешь продолжать что-то где-то измерять
и публиковать цифры без конкретики где это работало.
Автор, ты задаешь правильные вопросы. Но у меня вопрос к условиям эксперимента.
В тегах указано слишком много. Мы не можем проводить аналогии между браузерным JS
и той технологией которая называется Node.JS. Они обе - хорошие в своих сегментах
но сравнивать так нельзя.
Когда публикуешь отчет - желательно приводить среднее время выполнения или даже лучше
процентиль.
Вот среднее
> (1079 + 811 + 890) / 3
val res0: Int = 926
> (2698 + 2620 + 2659) / 3
val res1: Int = 2659
Старый способ быстрее более чем в 2 раза. В чем причина - непонятно. Возможно
сработала типизация либо боксинг. И транслятор/jit поняли что речь идет не об
абстрактных объектах а о целых числах. Массив целых оказался компактнее.
Почему и как это происходит - нам не ведомо.
Надо дизассемблировать саму сборку которая получена после работы runtime
и смотреть что там собрано и как.
Вот и делай текстуру близкой к этом. Не забывай про тайлинг. Для кирпичиков это не нужно будет например.
Следи за FPS за последню минуту. Если вдруг резко упадет - то повышать разрешение не надо.