Перейти к содержимому
ECS

DoubleBuffering: двойная буферизация графики

Рекомендуемые сообщения

Для экшон-шутеров OC не приспособлен, но какая-нибудь пиксельная казуальщина или продвинутые настолки работают прекрасно.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ого, что это на экране? Посмотреть исходники можно?

Это порт моей старой игрули с CC на OC

Топик:

http://computercraft.ru/topic/1563-computercraft-2d-rpg-game/

 

И еще OCEmu немного модифицированный мной

Изменено пользователем DarthWirthe

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

И еще OCEmu немного модифицированный мной
Вау! Мне нравится этот эмулятор. Вот только почему то  основная файловая система readonly

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Для экшон-шутеров OC не приспособлен, но какая-нибудь пиксельная казуальщина или продвинутые настолки работают прекрасно.

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

Ну вот например, отличная игра, Сапёр!

Или Lava runner от electronic_steve в которой очень круто можно бегать убегать.

Изменено пользователем eu_tomat

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проведен рефакторинг библиотеки с целью увеличения скорости отрисовки: все методы и поля таблиц, хоть как-либо используемые самой библиотекой, заменены на единоразово созданные локальные переменные. Удалена избыточная группировка по функциям. Изменен принцип растеризации отрезков. Добавлен метод buffer.formattedText, позволяющий изменять цвет текста в реальном времени через вставку синтаксических конструкций вида #RRGGBB.

 

Как результат - общая производительность выросла в ~3 раза по сравнению со старой версией библиотеки (первая пикча) и новой (вторая):

 

pP11Ijv.png?1

 

5bn9k6n.png?1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

все методы и поля таблиц, хоть как-либо используемые самой библиотекой, заменены на единоразово созданные локальные переменные.

Чётко! И сборщик мусора зря не напрягается, и результаты вычислений используются повторно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Библиотека обновлена с общим увеличением производительности в ~1.4 раза и уменьшением потребления памяти на 140 Кбайт путем смены концепции хранения данных. Опытным путем выяснилось, что 2 пиксельных массива вида { 0xFFFFFF, 0xFFFFFF, "S", ... } кушают в разы больше, нежели 6 таких же массивов для цветов фона, текста и символов по раздельности (пруфскрипт - https://pastebin.com/mPynSL2H):

 

wHfWMBE.png

 

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

 

00Jd1aw.png?1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В библиотеке всплыл довольно нехороший ахтунг касательно прямоугольников

По идее, если координата X прямоугольника будет уменьшаться или увеличиваться, то сам прямоугольник рано или поздно "уедет" за экран и исчезнет, что мы и наблюдаем при отрисовке обычного прямоугольника (drawRectangle).

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

С полупиксельными линиями или кругами такого не происходит.

 

cWwhL6v.gif

 

Программа, используемая на демонстрации:

Скрытый текст

local db = require('doubleBuffering')
local gpu = require('component').gpu
local kb = require('keyboard')
local tr = require('term')

tr.clear()
local scroll = 150
local scroll2 = 4

gpu.setForeground(0xFFFFFF)
gpu.setBackground(0x000000)
gpu.set(2, 40, 'Press CTRL to reset X coordinates , SHIFT to exit')
gpu.set(2, 42, 'X1 (Y&R Rect) coordinate is: ')
gpu.set(2, 43, 'X2 (G&B Rect) coordinate is: ')
gpu.set(2, 44, 'Red and Blue - Normal rectangle')
gpu.set(2, 45, 'Yellow and Green - Semi pixel rectangle')

while true do
	if kb.isControlDown() then scroll = 150 scroll2 = 4
	elseif kb.isShiftDown() then tr.clear() return end
	db.clear(0)
	db.drawSemiPixelRectangle(scroll2, 10, 8, 8, 0xFFFF00)
	db.drawRectangle(scroll2, 10, 8, 4, 0xFF0000, 0, ' ')
	db.drawSemiPixelRectangle(scroll, 28, 8, 8, 0x00FF00)
	db.drawRectangle(scroll, 19, 8, 4, 0x00FFFF, 0, ' ')
	db.drawChanges()
	gpu.setForeground(0xFFFFFF)
	gpu.setBackground(0x000000)
	gpu.fill(31, 42, 160, 2, ' ')
	gpu.set(31, 42, tostring(scroll))
	gpu.set(31, 43, tostring(scroll2))
	os.sleep()
	scroll = scroll - 1
	scroll2 = scroll2 + 1
end

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Надо же, до сих пор интересные баги всплывают! Ладно, фигня вопрос, сейчас пофиксим, тут проблема в смещении пикселей за пределами drawLimit ввиду одномерной структуры буфера экрана.

 

Только учти, что эта либа - неподдерживаемое legacy, и основная версия находится в виде Screen API в майноське. Полупиксельный метод я обновлю, но никаких гарантий по работоспособности остальных методов нет, все дела

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, ECS сказал:

Только учти, что эта либа - неподдерживаемое legacy, и основная версия находится в виде Screen API в майноське. Полупиксельный метод я обновлю, но никаких гарантий по работоспособности остальных методов нет, все дела

Я после чтения мануала по старой либе в январе пытался адаптировать новую, но что-то она не хочет есть картинки, падает. 

Повозился тогда, плюнул, да отложил на потом, никак не пойму что там не сходится

vdUjQnF.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мяу, ну явно ж какая-то кастомная отрисовка пикч идет у тебя в RenderEngine. Без сырцов фиг знает, что там происходит, и как это пофиксить. Вполне вероятно, кстати, что на скрине старая либа Image используется, где была иная RAM-структура картинок (с вложенными таблицами), а либа буферизации - новая. Я потому и прекратил поддержку всего этого балагана, т.к. по кускам собирать код никаких нервов не хватит

 

Если критично - можешь просто выдрать обновленный и исправленный метод drawSemiPixelRectangle к себе в старую либу

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
57 минут назад, ECS сказал:

Мяу, ну явно ж какая-то кастомная отрисовка пикч идет у тебя в RenderEngine.

Под этим именем у меня лежит обычный Screen.lua :D, сохранил так для удобства.

 

58 минут назад, ECS сказал:

Вполне вероятно, кстати, что на скрине старая либа Image используется, где была иная RAM-структура картинок (с вложенными таблицами), а либа буферизации - новая. Я потому и прекратил поддержку всего этого балагана, т.к. по кускам собирать код никаких нервов не хватит

Да, как оказалось проблема была в старом image, поэтому пришлось выдергивать оный из состава MineOS, долго ругаться за кучу зависимостей от библиотек этой оськи, выдергивать нужное и делать "подсистему" с требуемыми функциями (с учетом всяких упрощений их оказалось не так много, но возни это доставило). Зато все заработало, и кроме библиотеки color image-у больше ничего не нужно)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, Bs0Dd сказал:

выдергивать нужное и делать "подсистему" с требуемыми функциями (с учетом всяких упрощений их оказалось не так много, но возни это доставило)

Капец ты там потеешь :D

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 02.11.2017 в 02:33, ECS сказал:

Добавлен метод buffer.formattedText, позволяющий изменять цвет текста в реальном времени через вставку синтаксических конструкций вида #RRGGBB.

Кстати, а где он?

Не вижу такого метода ни в старом ни в новом движке, но он бы мне сильно пригодился))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Для меня прям загадка, какая ж у тебя версия либы используется: метод был оч давно добавлен в старую, но удален при переходе на майноську ввиду низкой производительности и отсутствия практического применения. Обычно я юзаю несколько drawText со смещением по X и разными цветами друг за дружкой. А для каких целей метод пригодился бы, если не секрет?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
3 минуты назад, ECS сказал:

Для меня прям загадка, какая ж у тебя версия либы используется

Самая последняя, что портировал с MineOS. Просто стало интересно, метод вроде упоминается, а в самой библиотеке его нет:blink:

 

5 минут назад, ECS сказал:

Обычно я юзаю несколько drawText со смещением по X и разными цветами друг за дружкой.

Дак вот и мне так приходится извращаться, но при написании страничек (для браузера, что я показывал) это создает дополнительные проблемы, ибо нужно просчитывать координаты смещения и вбивать их руками, а при изменении страницы кучу раз потом менять значения... вот и хотелось бы это упростить, ну, значит, не судьба:(

gRrbGHu.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
58 минут назад, Bs0Dd сказал:

Просто стало интересно, метод вроде упоминается, а в самой библиотеке его нет

Метод упоминается только на этом форуме в виде чейндж-лога, в документации на гите он отсутствует, и в процессе эволюционирования либы был выпилен по причине фиговой производительности. Если честно, то оставить его проблем не составило бы, однако либа менялась, принцип рендеринга тоже, принцип хранения кадров вообще расслоился на 6 таблиц вместо изначальных 2х, и долгосрочная поддержка неиспользуемой фичи мне показалась накладной. Да и браузер твой загнётся на фиг при отрисовке, т.к. formattedText имел тонну лишних условий и обрезок строк в каждой итерации отрисовки в буфер

 

1 час назад, Bs0Dd сказал:

ибо нужно просчитывать координаты смещения и вбивать их руками

Что там просчитывать-то, один раз в цикле заюзать unicode.len()? И зачем хранить постоянно координаты смещений каждой цветной строки? Не эффективней ли будет организовать структуру таблицы в виде изначальной точки первого символа и перечислений вида "цвет, строка, цвет, строка."? Чет тип такого:

local lines = {
  { 2, 5, 0xFFFFFF, "Hello world!", 0xFF0000, " It's a red symbols", ...}
}

local line, x, y, str
for l = 1, #lines do
  line = lines[l]
  
  x, y = line[0], line[1]
  for i = 3, #line, 2 do
    str = line[i + 1]
    
    buffer.drawText(x, y, line[i], str)
    
    x = x + unicode.len(str)
  end
end

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в тему...

×   Вы вставили отформатированное содержимое.   Удалить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.


×
×
  • Создать...