Showing posts with label Eureka. Show all posts
Showing posts with label Eureka. Show all posts

Thursday, February 8, 2018

Игра

Это идея компьютерной игры в стиле пост-модерн.
Сначала игра выглядит как платформер или метроидвания, но потом она открывается новыми гранями.

Кратко: песочница с открытым миром, сценой которой являются уровни видеоигр.

Sunday, January 8, 2017

Краткое изложение Policode

Имел глупость опубликовать описание Поликода на некоторых русскоязычных форумах и получил массу негативного фидбэка.
Как я понял, основная причина в том, что я недостаточно кратко и структурированно описал, что такое Поликод и для чего он нужен.
Поэтому я подготовил вот такое краткое тезисное описание.

Тезисы 

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

1. Вместо фиксированных кодов символов из диапазона 0..0x10ffff вводятся имена переменной длины, количество которых не лимитировано.

2. Вводятся пространства имен — алфавиты (латиница, польский, древнеславянский).
Один и тот же символ может иметь разные смыслы в разных алфавитах.
Алфавиты также задаются именами их может быть сколько угодно.

В компьютере установлен некоторый набор поддерживаемых алфавитов.
Алфавит (его еще можно назвать языковой культурой) - это программный модуль, выполняющий над текстами:

  • разные семантические операции,
  • сортировку,
  • озвучивание разными голосами,
  • визуализацию разными шрифтами и т. д.

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

Символ опознанный алфавитом отображается и обрабатывается этим алфавитом.
Алфавит может трактовать символ как отображаемый, модифицирующий или управляющий.

Текст может состоять из множества фрагментов, написанных разными алфавитами.

Символ не опознанный алфавитом отображается дефолтным (fail-safe) рендерером.
Это возможно потому, что имена символов — это не строки текста, а команды рисования.
В вышеприведенном примере на моем компьютере была установлена только общелатинская культура, поэтому я увижу:
— пометку, что текст древнегерманский,
— обычные латинские буквы,
— несколько странных угловатых древнегерманских букв (отображенных дефолтным рендерером).

3. Имена символов являются командами рисования и задают их внешний вид, и для этого существует две нотации:
— условное грубое начертание — оно компактно и пригодно для 99% случаев,
— полиграфически аккуратное начертание — позволяет кодировать многоцветные комбинации полигонов, заданных сплайнами, но занимает немного больше места.

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

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

5. Работа с именами символов вместо кодов — затратное дело. Они занимают много памяти, и их приходится искать в хеш-мапах.
Поэтому существет таблица на 252 элемента, которая строится автоматически в процессе парсинга текста.
Благодаря этой таблице последние 252 символа или имени языковой культуры использованные в тексте могут быть закодированы одним байтом и обработаны без поиска текстовых строк.

Все детали и технические подробности можно найти в оригинальном посте

Sunday, June 21, 2015

Чехол-геймпад для телефона

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

Saturday, June 20, 2015

Чем плох Юникод и как его можно улучшить.

Предлагается замена Юникоду - новый формат кодирования текста со следующими свойствами:
  • Кодирует все теоретически возможные виды символов.
  • Не требует централизованного стандартизирующего органа.
  • Позволяет увидеть текст на любом языке даже при отсутствии подходящих шрифтов.
  • Раздельно сохраняет визуальную и лингвистическую информацию о символах, позволяя приложениям игнорировать те части, которые им не нужны.
  • Позволяет включать в текст индивидуальные авторские символы и рисунки.
  • Обратно совместим с ASCII.
  • Поддерживается всеми приложениями, которые работают с однобайтными строками с 0-терминированием.
  • Может быть конвертирован из Юникода без ограничений и конвертирован в Юникод в той части, которая поддерживается Юникодом.
  • Обеспечивает быстрое декодирование во внутренний формат приложений и быстрое кодирование.
  • Компактен.

Под катом - детали и пример реализации.

Sunday, February 23, 2014

Бинарный формат для сериализации объектов

Я уже пару месяцев использую CatML для сохранения данных приложения в файлы, передачи объектов по сети и даже для дампа объектов в лог.
Формат хорош. В своих проектах я отказался от XML/Json/Yaml и не жалею.
Но с ростом объемов данных все более заметными становятся фундаментальные недостатки текстовых форматов:
- они избыточно-огромные,
- они долго записываются и еще дольше парсятся.

Поэтому, в общем, вот новый бинарный формат BinaryCatML.

  • Он однозначно конвертируется в текстовый CatML и обратно. Для этого есть консольная утилитка. Вы можете открыть бинарный файл, просмотреть его содержимое, если надо исправить в любом текстовом редакторе и уаковать обратно в бинарный вид.
  • Как и текстовый CatML, он имеет в себе всю метаинформацию и умеет кодировать произвольные графы объектов. 
  • Он разумно компактен. Любое имя поля, имя структуры или объект присутствуют в файле ровно один раз. Это не компрессия, компрессия - убирает избыточность, а BinaryCatML просто не вносит ненужной избыточности.
  • Он быстро записывается и быстро загружается. Все идентификаторы - стркутур, объектов - просто индексы в массивах. Никих look-up-ов в словари, никаких сравнений текстовых строк.
  • Кодек по минимуму использует память и может работать даже на очень слабых устройствах.
  • Он не зависит от разрядности или порядка байт архитектуры, в нем нет ни одного зашитого в формат ограничения.
  • Его кодек занимает меньше 300 строк на Java и может быть портирован на любой язык буквально за день.

Thursday, October 24, 2013

Текстовое представление объектов

Почему XML и JSON – плохо, и как сделать хорошо.

Краткое резюме:

  • XML, JSON, YAML, SDL – плохо пригодны для описания произвольных иерархий типизированных объектов.
  • Но теперь у нас есть альтернативный формат CatML:
    • простой,
    • интуитивно понятный,
    • не допускающий неоднозначности,
    • удобный для парсинга,
    • кодирующий и строго типизированные данные,
    • кодирующий перекрестные ссылки,
    • кодирующий глобально именованные объекты и ссылки на них.
  • Можно прямо сейчас скачать и использовать его енкодер и декодер для Java, который поддерживает:
    • сериализацию объектов
    • и DOM-like способ доступа.
  • Java-библиотека занимает около 1 тыс. строк и может легко портироваться на любой язык.
Скачать Библиотеку энкодера и декодера CatML

Saturday, September 28, 2013

Файлы не нужны

Файлы не нужны.

(По крайней мере на несменных носителях).

Сколько себя помню, в компьютерах были файлы.
Мы храним в файлах всё — документы, программы, настройки, временные данные...

Что есть файл?
  • Массив байт.
  • Имя, по которому его можно найти и открыть.
  • Атрибуты доступа, чтобы его не открыл/не изменил кто попало.
  • Средства совместного доступа (или ограничения одновременного доступа).

Чего в файле нет?
  • Нет внутренней структуры. Файл — массив (последовательность) байт, чья интерпретация — полностью на совести открывшей его программы.
  • Нет строго заданного типа. Программы должны догадываться о типе данных по окончанию имени или по первым байтам данных.
  • Нет гарантии целостности. Любая программа может неправильно прочитать обработать и записать любой файл. Поэтому открыв собственный только что записанный файл, программа должна быть готова увидеть там мусор.
  • Нет высокоуроневого интерфейса к данным в файле. Например, если файл содержит презентацию, в нем нет доступа к слайдам и элементам оформления — только байты и байты.
  • Структуры файла неудобны для прямого обращения со стороны процессора. В худшем случае файл доступен приложению как байтовый поток, в лучшем — кусок файла маппится на адресное пространство, причем его редко удается маппить на одни и те же адреса. Да и форматы файла редко совпадают с режимами выравнивания, разрядностью, порядком байт и структурами данных целевой машины. Поэтому всякий раз при открытии файла, его содержимое должно конвертироваться во внутреннее представление, а при записи — конвертироваться обратно.

Файлы можно заменить объектами, которые хранятся в персистентной памяти.