Doob

Можно сделать морской бой на дебаг-картах, чтобы корабли выстреливали заряженный TNT и попадания проверялись через testforblock. При определенном проценте повреждений корабль тонет, можно еще добавить возможность перемещать корабли во время боя.

Только есть два минуса - нужна дебаг-карта и много места. Но зато будет намного зрелищней.

Довольно очевидная реализация 4Д: http://gamegame.2970143.pix-cdn.org/games/140053.swf

GML слишком тяжел, использовать его только в одной программе не рационально. В ОС интерфейсы создаются так же как и в СС.

Для кнопки надо перехватывать эвенты касания или клика, и запускать нужную функцию при совпадении координат.

К примеру в таблице хранятся координаты первой кнопки:

tbl = {Xmin = 10, Ymin = 10, Xmax = 15, Ymax = 15}

При эвенте клика проверяем координаты эвента:

if x >= tml.Xmin and y >= tbl.Ymin and x <= tbl.Xmax and y <= tbl.Ymax then ... end

Для переключения между элементами при помощи стрелок просто элементы храним в таблице, а эвенты нажатия на стрелки запускают смещение + или - по таблице, соответственно подсвечивая выбранный элемент из координат в таблице.

 

Вот пара туторов по СС:

http://www.computercraft.info/forums2/index.php?/topic/11046-clickable-buttons-in-cc/

http://www.computercraft.info/forums2/index.php?/topic/16925-how-to-create-a-touch-screen-on-a-terminal/

Мне что-то кажется, что сделать определение x и z из места тычка будет проще, чем сначала перегонять место тычка в азимут, а затем обратно в x и z

 

Тогда не париться и делать сразу морской бой с TNT и подвижными кораблями.

Если интересно, то направление из азимута можно задать так:

x = math.cos(a)*p

y = math.sin(a)*p

Где p это число для округления до целых блоков с необходимой точностью.

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

А лучше сделать пристрелку и вывести таблицу дальности, как в минометах.

Эта тема мне напоминает, как на КК я сделал черепашку-архиватор. В общем, используя блок шерсти как пол байта черепаха строила столбы с закодированным сообщением, бессмысленно, но работает!

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

 

Да, это удобный способ, просто и эффективно, без лишних телодвижений.

Только если сжимаешь — не юзай кириллицу в результате, они по два байта жрут, а латиница юзает 1 байт.

 

Дурака за меня не держи, я знаю, что такое ASCII

 

 

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

 

Я же показывал картинки? Камера сканирует расстояние, а не прямоугольники. Т. е. ровная стена будет выглядеть цветными кругами, а чистый бедрок, с расстояния 5-10 блоков больше чем на половину выглядит шумом.

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

 

Мой вывод - сжатие не необходимость, а понты, вроде шифрования, когда есть modem.send

r=require("robot").use while true do r() end

44 буквы,раз уж на то пошло.

 

 

Скобки и пробелы для понтов! Долой скобки и пробелы!

Теперь понял, как ты сжимаешь: вместе с индексом цвета пересылаешь количество символов.

Но откуда взялось 5, ты так и не пояснил.

 

Картинка в пещере не шумовая. В ней должно быть эффективным дельта-кодирование.

 

Кхм... Что есть сжатие?

Берем данные, которые надо сжать:

AAABBBCDDDDEE

Для сжатия используем набор кодирующих индексов:

0 = A
1 = B
2 = C
3 = D
4 = E
5 = AA
6 = BB
7 = CC
8 = DD
9 = EE
Щ = AAA
К = BBB
Ж = CCC
Ю = DDD
Х = EEE
Ъ = AAAA
Л = BBBB
Н = CCCC
И = DDDD
У = EEEE

Проходим по сжимаемому сообщению, подбирая подходящий индекс от самого эффективного к менее эффективному.

 

В итоге получаем это:

AAABBBCDDDDEE = ЩК2И9

Считаем количество символов в исходном тексте и в сжатом.

 

Вход = 13

Выход = 5

(5/13)*100 = 38.46%

Исходный текст был сжат на 38.46%

 

 

Картинка может оказаться шумовой, в этом случае алгоритм сжатия только отнимет время.

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

Ах, вот, зачем ты спрашивал в чате про разное время выполнения в разных циклах! Здесь копипаст вне конкуренции по скорости. Правда, размер программы большой. Но можно же и RAID подключить для такой задачи.

Я теперь знаю, зачем в ДЦ столько компов.

 

Кстати, спасибо за идею, я goto за цикл не считал, надо проверить потери времени при его использовании.

Не понимаю, о чем идет речь:

• 46 индексов для одного символа Имеется в виду – возможных индексов?
• для сжатия берем 46 для двух идущих подряд, 46 для 4х, 46 для 8, 46 для 16... Как берем, что делаем?
• Следовательно, в общем имеем 46*5 = 230 индексов Откуда появилось пять?
• процент сжатия равен... откуда взялась такая формула?

Поэтому я не понимаю, почему сжатие для камеры в пещере будет нулевым.

 

Попробую по-порядку.

• Имеется ввиду используемых в программе цветов.
• Повторное кодирование повторяющихся символов, т. е. уже сжатие.
• Из предыдущего вывода - 1 символ, 2 символа, 4 символа, 8, 16.
• Из здравого смысла - максимально возможное сжатие - в 16 раз (т. е. 16 символов идущих подряд кодируются одним)

Сжатие в этой теоретической пещере равно 0%, потому что шум сжать невозможно.

А я короче сделаю!

У тебя целых 47 символов!

while true do require("robot").use() end -- 40 символов

::a::robot.use()goto a -- 22 символа

А вообще, это не работает, я замерял - кпд меньше 100%

Хм.. Надо попробовать генерировать рандомный текст на весь экран, а потом палитрой рисовать линии, но вряд-ли это что-то изменит, кроме смазливости изображения.

 

P.S. Можно ускорить убрав в генераторе линий os.sleep() изменив число в генераторе новых позиций с 6 на 30, но тогда дождь будет идти волнами.

Палитру юзай. Она позволяет менять цвет без перерисовки.

 

Эм... А как оно ускорит работу? Все-равно беда в циклах.

Можно и без графики, вводить только азимут и дальность выстрела.

Отличный вопрос.

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

 

Главное, не передавай избыточную инфу. Ты же сейчас передаешь цветовые индексы, а не сами цвета?

 

Конечно индексы, цвета не в лезут в сообщение... Хотя можно разбить на пакеты...

 

У меня 46 цветов, т. е. 46 индексов для одного символа, для сжатия берем 46 для двух идущих подряд, 46 для 4х, 46 для 8, 46 для 16... Следовательно, в общем имеем 46*5 = 230 индексов с индексами сжатия, в идеальных условиях (в пределах видимости 33 блока нету никаких блоков) процент сжатия равен

( ( ширина передаваемого изображения / 16 ) * длинна передаваемого изображения) / (ширина*длинна)

Но, если камера в пещере, где блоки находятся на рандомном расстоянии, то сжатие = 0%, тогда какая разница сжимать или не сжимать?

Теперь другая проблема, стоит вообще сжимать? Можно же обойтись кодированием, т. к. сообщения передаются моментально. Сжатие и разжатие отнимают время.

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

 

 

Да, я так и делал, но это замедляет процесс отрисовки в десятки раз, поэтому сделал чтобы только новые символы были 00FF00, остальные 008800, только из-за странных пустых символов теперь иногда замирают символы с лаймовым цветом.

Хорошо было на CC, там нету вымышленных ограничений - можно каждые пол-секунды перерисовывать весь экран.

Немного кривое и медлительное поделие в стиле дождя на мониторах в The Matrix.
Ускорить никак не получается из-за отжирания времени циклами и ограничением производительности мониторов, можно воспользоваться библиотекой thread, но она иногда приводит к FATAL EГГОГ, который можно исправить только уничтожив жесткий диск.
 
pastebin get Lsb5YMjg rain

 

только... формулы, чтоб угол сделать дай-чтоб сделать как у меня, достаточно прилепить x y и z к команде. Просто... это проще сделать

И мой метод позволяет регулировать высоту

 

Формулы? sin(x)*y? Теорема Пифагора? Парабола тоже имеет высоту.

Это очень странно, что в шапке темы, что в поделках... Можно же сделать проще и оригинальней.

На монитор выводить только круг с ползунком - клик по кругу задает угол, по ползунку - дальность.

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

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

Тут получается все не так уж и сложно.

 

Когда человек попадает в комнату (назовём её печенька) генерируются двери и маршрут. Одна из дверей ведёт в другую комнату (в рандомную комнату), все остальные двигают человечка по комнате "печеньке".

 

Но ещё круче, сделать а-ля Квантовую Суперпозицию. Пока человек не откроет дверь, маршрут будет не определён, и будет постоянно, в цикле изменяться.

 

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

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

Хотя, кроме тессерактов мне ничего не приходит в голову.

Вот например возможные правила:
Вся система в цикле меняет состояние по таймеру.

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

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

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

Каждое знакоместо будет содержать два пикселя. Необходимо заполнять экран символами ▄ (символ из псевдографики - нижняя часть закрашена, верхняя нет) предварительно установив цвет фона равным цвету верхнего пикселя, а цвет шрифта - цвету нижнего. Неплохо было бы заполнить весь экран такими символами заранее, а потом только менять атрибуты цвета для каждого знакоместа, Но, что то не найду такой возможности в библиотеке gpu.

 

Хм, точно, четные строки - цвет текста, нечетные - цвет фона, в разных таблицах

Пройтись в цикле параллельно по обоим таблицам устанавливая из них цвет фона и текста.