M
Дифф считать на канвасе можно только для что то типа UI подобных приложений, для всего остального это не выгодно
Size: a a a
2019 November 17
M
я такой подход у себя вот здесь использовал - https://github.com/ghaiklor/terminal-canvas
Ну да или для терминала (что тоже UI)
EO
MaxGraey
Ну да или для терминала (что тоже UI)
ну не совсем :)
EO
L
Roksana Petruk
Гм, есть о чем подумать
раз у тебя там в игре квадраты разноцветные, то предлагаю выкинуть раст и написать все на js канвасом
EO
стримил с ютуба видео, на лету преобразовал информацию о пикселях в аски и рендерил через свою рендерилку с дифами
например фон в терминале практически не менялся, соответсвенно полного flush символов в терминале не было, а только частичный. Это дало хороший прирост, что позволило, видео гонять в терминале с разрешением 300х150 символов где-то (уже не помню)
например фон в терминале практически не менялся, соответсвенно полного flush символов в терминале не было, а только частичный. Это дало хороший прирост, что позволило, видео гонять в терминале с разрешением 300х150 символов где-то (уже не помню)
M
стримил с ютуба видео, на лету преобразовал информацию о пикселях в аски и рендерил через свою рендерилку с дифами
например фон в терминале практически не менялся, соответсвенно полного flush символов в терминале не было, а только частичный. Это дало хороший прирост, что позволило, видео гонять в терминале с разрешением 300х150 символов где-то (уже не помню)
например фон в терминале практически не менялся, соответсвенно полного flush символов в терминале не было, а только частичный. Это дало хороший прирост, что позволило, видео гонять в терминале с разрешением 300х150 символов где-то (уже не помню)
Все верно, но у тебя изображение весьма плотное, не разряженное, можно вычеслить BBox диффы и затереть несколько участков, другое дело когда у тебя частицы или конвей по всему экрану, где участков почти столько же сколько этих самых частиц. Именно поэтому во всех играх просто перерисовывают весь экран 📺 потому что так в итоге выходит дешевле
EO
MaxGraey
Все верно, но у тебя изображение весьма плотное, не разряженное, можно вычеслить BBox диффы и затереть несколько участков, другое дело когда у тебя частицы или конвей по всему экрану, где участков почти столько же сколько этих самых частиц. Именно поэтому во всех играх просто перерисовывают весь экран 📺 потому что так в итоге выходит дешевле
Хм, возможно. Но я BBox не вычисляю, «попиксельный» дифф строю
M
Хм, возможно. Но я BBox не вычисляю, «попиксельный» дифф строю
в смысле? Я думал ты используешь ctx.clearRect который самый быстрый
L
Хм, возможно. Но я BBox не вычисляю, «попиксельный» дифф строю
и по пиксельно выводишь? а хотя, консоль же
ҪҸ
раз у тебя там в игре квадраты разноцветные, то предлагаю выкинуть раст и написать все на js канвасом
отличный совет)) (нет)
L
отличный совет)) (нет)
совет что надо
L
ясно
ну а почему нет то
ҪҸ
подскажите лучше может есть какой-то простой arm32/64 box, чтобы в нем запускать что-то?
ҪҸ
типа готовое что-то с qemu
EO
MaxGraey
в смысле? Я думал ты используешь ctx.clearRect который самый быстрый
В терминалах такого нету же. Есть управляющие символы VT100. Но если абстрактно, то я смотрю какие пиксели стирать, а какие красить. То есть по пиксельно
EO
В терминалах такого нету же. Есть управляющие символы VT100. Но если абстрактно, то я смотрю какие пиксели стирать, а какие красить. То есть по пиксельно
Просто если пиксель не менялся, то я и не шлю последовательность на его обновление. Он остаётся с предыдущего кадра
ҪҸ
подскажите лучше может есть какой-то простой arm32/64 box, чтобы в нем запускать что-то?
или просто хороший короткий мануал как что-то запустить в qemu aarch64
ҪҸ
@ryzokuken вдохновил меня пойти посмотреть что надо сделать чтобы добавить поддержку arm в cranelift