Pull to refresh
3
0
oWeRQ @oWeRQ

User

Send message

Да рассказывать в общем нечего, на sega megadrive часто достаточно 3-х кнопок, дискомфорта это нигде не вызывает, если надо все 6 придется использовать простаивающие шифты(курки), и тут уже зависит от игры, где-то будет удобно, а где-то придется настраивать под себя.

Обычно не тормозит, просто алгоритмы растягивания используются попроще, получается еще более размазанная картинка, а смотреть на 2/3 маленького экрана сомнительное удовольствие, целочисленное увеличение можно считать ресурсов не требует, поэтому большое разрешение на слабом девайсе это даже плюс. Не зря в Analogue Pocket запихнули 3.5" 1600х1440, другое дело что такой экран наверняка слишком дорогой.

Не уверен, что шифты на Miyoo Mini можно улучшить, просто они расположены не слишком удобно, ввиду специфики корпуса, при наличии 3d принтера можно и корпус другой сделать и накладку, но это не для всех.

Обычно никто не владел всеми консолями, библиотеку ромов приходится собирать по частям, добавлять, убирать лишние, поэтому я подбирал на Gpd Win, синхронизируя директории по сети. Кроме этого на Miyoo Mini частенько с первого раза не удавалось все запустить, то с названием проблема, то биосов не хватает, то еще что-то, иногда спасает "встроенный" файловый менеджер, но карточку дергать приходится часто. Для консолей с CD подборка довольно много занимает, за один раз на карту все не скинуть протестировать.

С геймпадами для смарта у меня не сложилось, для сяомовского геймпада неудобное и слабое крепление, в дороге можно остаться без телефона, а sn30 pro перевешивает, в общем все сложнее чем просто взять какой-нибудь геймпад с креплением, пока от этого решения полностью отказался.

Например, у rg351p экран 480x320, сравним с консолями:
GBA - 240x160, идеально, равно в два раза меньше, 2.0x2.0
GB - 160x144, можно увеличить в 2 раза, тогда на поля останется треть ширины и еще 16 пикселей сверху и снизу, 3.0x2.22
NES - 256x240(или 256x224), можно только растягивать 1.87x1.33
SMD - 320x224(и 256x224), можно только растягивать 1.42х1.42

В большинстве случаев надо масштабировать на коэффициент в районе 1.5, что особенно на слабом железе получается плохо.

Теперь возьмем rg351mp, экран 640х480:
GBA - 240x160, нужно растягивать 2.66x3.0
GB - 160x144, нужно растягивать 4.0х3.33
NES - 256x240(или 256x224), можно увеличить в 2 раза, 2.5х2
SMD - 320x224(и 256x224), можно увеличить в 2 раза, 2.0x2.14
Аналогично в 2 раза на snes, sms, pce, ps1

В большинстве случаев надо масштабировать на коэффициент 2.0, что делается гораздо аккуратнее и не требует ресурсов, но и дробные больше 2-х, тянутся лучше.

Из 351-х только RG351MP можно брать не глядя, в M и P экран не очень удачный, хорошо подходит только для GBA игр, и насколько я помню, некоторым портам требуется большее разрешение.

Если брать под 2-5 поколение приставок, на что стоит обратить внимание:

  1. Пропорции экрана только 4:3, это единственное универсальное, под это делалось все что выводило на телевизор и это лучший компромисс для портативных, и квадратный GameBoy и вытянутый GBA, и растянутое, и с полями смотрится приемлемо.

  2. Разрешение чем больше тем лучше, опять же было много разрешений, округление на полтора пикселя выглядит размыто, хороший вариант 640x480, меньше не стоит.

  3. Диагональ - 2.8' на минимальном пределе, на sega magadrive и ps1 мелковато, за-то красиво, 5' - уже слишком много для старых консолей, особенно портативных, идеально в районе 3.5 - 4.0

  4. Эмуляторы крайне желательно чтобы работали через RetroArch, по крайне мере большинство, обычно поверх него засовывают интерфейс EmulationStation или что-то свое, это не особо имеет значение, RetroArch дает кучу плюшек и единообразие интерфейса и поведения, с интернетом еще больше плюшек.

  5. Некоторые консоли требуют довольно сильное железо для эмуляции некоторых игр, если идет что-то с ps1(одни из самых оптимизированных эмуляторов), это еще не значит, что потянет на полной скорости все игры с snes, лучше брать с запасом, так же нужен запас на улучшение картинки, для пикселей фильтры/шейдеры, для 3d - большее разрешение и для ускорения(в старых играх не щадили время игрока). А оперативная память может понадобиться для перемотки назад.

Что касается опыта на конкретных устройствах:

  1. Miyoo Mini - хороший экран 2.8' 640x480, четко, но мелко, с ps1 идет практически все(если не повышать разрешение рендоринга), стики почти нигде не требуются, но без них бывает не слишком удобно, шифтами пользоваться неудобно, долго играть сложно, прошивка закрытая, только оффициальная, но приложения на карте, сильно это не ограничивает кастомизацию, в дефолте пользоваться неудобно, обязательно н.адо заводить карточку с Onion OS, закинуть файлы можно только через карточку.

  2. GPD Win 1 - неплохой, но вытянутый экран 5.5' 1280x720, слишком большой, игры с огромными полями, за исключением psp, но с нее тянет не все. Дистрибутив Batocera почему то не работает, хотя в остальном проблем с дистрибутивами линукса не встречал, Windows 10 для ретроигр явно overkill, кроме того долго грузится, мало работает, не всегда успеваешь поиграть.

  3. New 3DS - слабовата, даже ps1 с трудом, но главное - ужасное разрешение, ужасно долго(через wifi) или неудобно перекидывать файлы(карточка под крышкой с винтиком), долго грузится система, эмуляторы, игры в эмуляторах. Даже для нативно поддерживаемых gba и nds плохой вариант.

  4. Android смартфон - чаще всего слишком большой и вытянутый экран, с геймпадом плохая портативность, но хорошая производительность, стоит рассматривать только для 5+ поколения, неплохо можно играть в nds без геймпада, многие игры заточены под тач, под стилус конечно, но размер экрана нивелирует это, кроме того, на 3d можно поднять разрешение.

Вероятно, на момент написания статьи еще не была доступна консоль RG353, сейчас это вероятно один из самых вкусных вариантов, удачный экран, 2 системы, хорошая производительность. Одновременно конкурент и Retroid 2+, и RG351MP.

Насколько я помню, в Opera(Presto) и Firefox инрерфейс написан на js, но по какой-то странной причине он оказался связан с js'ом и движком рендеринга выполняющимся на вкладках, возможно это "пара" дедлоков которые сложно поправить, а возможно для того, чтобы их развязать, пришлось бы многое переделать и с большой вероятностью это тоже поломало расширения, и тут я на месте разработчиков выбрал бы независимые процессы, потому, что это решить не только насущную проблему, а еще и даст место для развития.

ActiveX был и спасательной палочкой и бомбой замедленного действия, в нем не было совершенно никакой защиты, кроме подтверждения запуска, которая мешала использовать для каждого чиха. И да, это ее одна из причин, почему IE было технически сложно заменить, с хромом такой беды нет, все работает везде.

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

Yandex, Opera, Brave как я и говорил ранее, сейчас не возьмутся за поддержку движка, потому что в этом нет смысла, но это все равно люди умеющие работать с этим движком - это уже полдела, не сразу, но они смогут сдвинуть с мертвой точки, гугл тоже не сразу потянул заниматься движком, примерно 4 года они упорно тянули webkit, пока окончательно не форкнули его.

Во времена IE6 мелкомягким было глубоко наплевать на веб, они с него ничего не получали, у них не было Azure, Office 365 итд, а кроме мелкомягких IE6 никто не мог развивать.

Я не рассчитываю на Microsoft, это просто как пример одной из заинтересованных компаний, есть еще Yandex, Opera, Brave, которые сейчас не возьмутся за поддержку движка и основы браузера, но если гугл захочет координально поменять курс, пока хромиум открыт - я не вижу поводов для беспокойства, монополия с открытым кодом работает немного иначе, все можно менять медленно и аккуратно, если идти против системы - мы уже видели форк Webkit, когда Apple увлеклась своими целями их просто послали подальше, в итоге теперь Webkit в роли догоняющего.

Хром показал, что технически возможно реализовать многопроцессную модель без потери производительности, насколько я помню, даже потребление памяти было чуть ли не меньше чем у Firefox, что подтолкнуло последний оптимизировать потребление памяти. Можно много рассуждать на тему багов, но суровая реальность в том, что их продолжают находить и в старом и новом коде, а еще хуже было когда прилагалось решето под названием Adobe Flash, из-за которого браузер падал регулярно. Что касается многопоточности, вероятно было сделано что-то не правильно, но и у Opera и Firefox тех времен была общая проблема, если появляется ресурсоемкая вкладка - подвисал весь интерфейс браузера, я допускаю что переработка многопоточности повлекла бы не меньшие изменения.

Давно не встречал сайты не работающие в Firefox, наверное со времен доминирования ослика. Были временные моменты с устаканиванием кодеков для контента - не более.
В Firefox много раз значительно меняли интерфейс, начиная с первых версий (версии 1, 2, 3, 4 выглядели по разному), расширения регулярно ломались, без перехода на многопроцессную модель у браузера просто не осталось бы шансов перед конкурентами с повышением сложности веб-приложений - утечки, потеря отзывчивости и стабильности просто неминуемы.

Опять же, существование Firefox никак не помешало внедрить 3-й манифест для расширений и серьезно порезать возможности блокировщиков, однако общественное мнение все же заставило их увеличить лимит правил. Хотя гугл и рулит разработкой хрома, им пользуются и другие крупные компании, Microsoft например, у которых есть свои интересы и если гугл начнет чудить - они в состоянии начать свой форк. Мне кажется гугл все же довольно ограничен, новый функционал относительно легко заблокировать в браузерах на основе хромиума, а существенно порезать старый невозможно не поломав все.

Во всем согласен, кроме сравнения с осликом, во-первых, он вообще не развивался около 5 лет(IE6), причем принципиально, потом долго тащили за собой обратную совместимость, во-вторых, он был закрытый и совершенно не ориентированный на разработчиков. Это совершенно другая ситуация, если гугл решит на 5 лет залезть в криокамеру - не придется начинать с нуля, выпуская новую систему вы не окажитесь без шансов получить полноценный браузер итд.

Пока нет никаких предпосылок, что хром развивается из-за конкуренции с огнелисом и недоразумением на эпловских устройствах. Так же им это не сильно мешает проталкивать свои стандарты.

Но пока ФФ весьма успешно конкурирует - нет причин им не пользоваться, это все еще очень достойный браузер.

Для меня в значительной степени компенсирует Firefox Lockwise для паролей, для закладок и частично для вкладок закрывает Pocket, а историю и настройки большого смысла синхронизировать на мобильные не вижу.

"убрали поиск" - это отдельное от строки адреса поле? Тогда для вас "Новость" это поле можно _до сих пор_ вернуть опцией в настроках "Добавить панель поиска на панель инструментов" или просто перетащить поле поиска в настройках тулбара. Если честно, я не помню как это было при обновлении, но что-то мне подсказывает, что это просто дефолтные настройки.

Например, можно использовать для видео один сервер, а для снижения нагрузки скачавшие продолжают его раздавать, правда это реализуется и существующими технологиями(Webtorrent, Peertube), и это никак не решит проблему хранения личных данных, но тут может помочь мотивация коинами, те, кто выделяет место получают за его копеечку, возможно, за широкий получают больше, маленькая ширина канала компенсируется кол-ом копий. Деценрализация не означает, что все бесплатно и только частными лицами, просто будете платить за 100 гиг не облачному сервису, который в один момент может сломаться/закрыться/заблокироваться, а всем кто участвует в хранениии.

Уже были попытки сделать децентрализованный поиск, это возможно, например, YaCy или поиск в RetroShare.

Я имел ввиду числа на выходе, в примерах это массив чисел, вариантов да, будет меньше, но при k >= 16 буду проблемы с минимальным и максимальным, даже если все считается правильно, ответ вряд ли засчитается:

> Number('11199999999999999')
11200000000000000

P. S. Перечитал условия задачи, там не зря сказано "приведенное к строке", только в примерах все равно числа

Вы правы, я сильно просчитался в сложности, 20 знаков действительно не большая проблема, это далеко не полный перебор.

Возможная ошибка, с которой столкнулся автор - числа больше MAX_SAFE_INTEGER(9007199254740991 или 16 символов) в js округляются, на конце получаются нули, похоже авторы задачи это не предусмотрели, в результате минимального и максимального значения должно быть или BigInt или строка.

Подзадача: если n = 1, а k = числу, которое мы ищем - подзадача решена,
если нет - перебираем все числа (>= последнего) рекурсивно вызывая
подзадачу.

Перебор 20 цифр вряд ли это подразумевает, наверное должно быть более производительное решение, найти минимальное и максимальное - легко, а вот как посчитать кол-во вариантов не знаю.

Если большинство не знает что такое децентрализация - это еще не значит, что она им не нужна, децентрализованные сервисы нельзя так просто заблокировать(зависит от реализации) и они вас так просто не могут отменить, авторам контента не смогут просто так отрубить монетизацию, а патрион - перестать помогать собирать донаты.

Information

Rating
Does not participate
Registered
Activity