GreenCubes

Вышел "Снимок" Minecraft 12w08a, и готов к тестированию!

Наконец-то появился новый 8-ой "снимок" 2012 года! Разработчики были заняты поездкой на LEGO и Mojam, и поэтому изменений меньше, чем обычно...

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

Баги:
- Железный голем не издаёт каких-либо звуков даже при повреждении.
- Железный голем из-за своих размеров не способен пройти в дверь.
- Сосны и берёзы не спавнятся.

Скачать клиент.

На следующей неделе будут исправлены все ошибки игры и выйдет долгожданный релиз Minecraft 1.2

А также, собственно, несколько слов о защитниках.

ИМХО Урод этот голем, в принципе как и жирели деревни, которую он защищает, а автор видимо любит сквидварда.


Крафт.


Видео.
http://youtu.be/GcrVsyLG6uY

I h8 that fucking ginger bustard. Ещё раз он украдёт идею с ГК и я где-нибудь напишу про него злой пост.

Я присоединяюсь к скромному мнению некоторых игроков, которые думают, что Jeb играет на GreenCubes

Сто тысяч монет тому, кто скажет IP джеба с пруфами.

Нет, по логам пробью.

Ну, играть-то может и не играет, но по крайней мере сайт вполне мог видеть и читать. Гугл-переводчик ещё никто не отменял.
Меня смущает то, что апдейты повторяют апдейты Greencubes и идут в том же порядке.

P.S.: Двое подозреваемых (, )

В суд на него подать

Хмм, кстати, давно хотел поинтересоваться, как хранится мир в майнкрафте. Там массивы объектов (скажем, массив объектов Block в объекте Chunk), или массив примитивных типов?
Мне кажется, что экономичнее будет держать несколько массивов (скажем, есть объект Chunk, в нём массив id блоков, массив уровня освещения), чем тучу объектов и этим насиловать сборщик мусора (в особенностях Джавы мало разбираюсь, но в сишарпе лучше тоже не плодить объектов, там тоже сборщик есть). Или у нотча опять всё не так?

Ну что ты, хранить массив объектов - безумно дорого в таких масштабах.
Каждый блок - пять массивов примитивных типов (byte - нижний ID, пол байта - верхний ID (только на GC и в 12w07+), пол байта - дата, пол байта - свет неба, пол байта - свет блока) + ещё несколько служебных карт типа координата-объект (например, для тайлов) + на GC есть по 1 биту на блок массив для синхронизации поршней. Итого 3 байта + разное число байт на блок. Могла бы расписать сколько было бы памяти на блок, если бы это был массив с полями (ID, data, skylight, blocklight), но мне лень поднимать инфу по памяти в яве. Как минимум, раз в 6 больше - у нас бы памяти не хватило на 300+ человек + сверхнизкая производительность + GC бы сошел с ума, т.к. у нас бывает кэш чанков по 30000 тысяч и более, а в каждом 32 тысячи блоков...

интересно ,как скоро они выпустят все виды полублоков и известняк...

Надо же, я уж думал, что там хуже...
Но вот нотч как-то сумбурно все эти вещи применяет - с одной стороны, более-менее экономичный способ хранения чанков в памяти (ну, по крайней мере раньше был, до 16х16х16), с другой - тучи идиотских проверок свойств блока, и на этом всё безобразие не заканчивается.
Меня в клиенте крайне поразили несколько вещей:
1) Для поддержания апплета в запущенном состоянии он создаёт отдельный тред и делает там sleep на нереальное количество времени. Почему не использовать простой цикл? (или я что-то не понимаю?)
2) Для создания двойной буферизации (насколько я понял из кода), он вместо того, чтобы держать битмап с предыдущим кадром, зачем-то использует два контекста... Специфика swing'а или говнокод?
Помнится, ковырял я как-то GDI+ (редкостно косая штука, btw) на винде и WinCE - самым экономичным методом как раз было держать битмап для буфера.

А вообще мне стало интересно...

В x64 яве массив объектов по сути массив long — указатели на объекты, а адрес объекта — long. Т.е. уже 4 байта.
В x64 яве каждый объект содержит заголовок из целых (!) 16 байт.
Поле short для ID — 2 байта
Дата, свет — 3 байта в сумме
Lock для поршней — 1 байт
Ссылка на объект тайла — 4 байта

Итого 4 + 16 + 2 + 3 + 1 + 4 = 30 байт + 2 байта для кратности 8 байтам. Итого 32 обязательных байта вместо 3,1. На чанк получается 32 х 32768 = 1048576 байт = ровно 1 мегабайт. Т.е. на 30000 тысяч чанков ушло бы более 30 гигабайт памяти. А у нас на при 300+ расход примерно 8Гб в нижнем пике GC.


Razer, по твоим вопросам ответить не могу. По второму - не знаю графики, по первому - сама не поняла.

Ну даете,я ни одного словечка не понял D:

Если убрать Sleep то ничто не будет ограничивать число кадров в секунду и он будет делать более 1000, что загрузит процессор на 100% обязательно.

Тыкни Джебу по яйцу!