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

>Вопрос - почему принцип Оккама не работает?

Он говорит не заморачиваться с методами класса там, где можно обойтись простыми функциями, потому что это изъ*бство.

У тебя же простая оптимизация. То, что ты выполнил её в виде отдельных модулей, не говорит что ты притянул за уши лишнее.

Почему самым лучшим решением не является самое простое?

Физиков позапрошлого века обслушался?

решаешь неправильно

Вначале что-то делать, считать метрики, а потом прикручивать кэш - это сложное решение

Простое - посмотреть, какие решения считаются хорошими (кэш будет среди них) и тупо их использовать

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

> Если бы проценты не прижали, я бы и не стал над ней думать.

О половине вещей имхо можно вообще не думать :)
Может, и придумывать ее не надо было даже - скомуниздить откуда-нибудь с митовской лицензией, код заобфускачить, копирайты выкинуть и готово :)


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

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

Да и маркетолог об этом потом думать не будет - скомуниздит из каких-нибудь стибренных отчетов конкурентов ;)

Ты путаешь бритву Оккама с чем-то другим

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

бритва Оккама - инструмент построения теорий а не кода.

Например, Deus Ex: Human Revolution. Графика трехлетней давности даже на максималках, тормозит ппц на i7+r5870, сэйвы грузятся по минуте. И чо? Все схавали.

Самое просто это OpenGL и VSync => 1-2% CPU load => PROFIT!

>Вопрос - почему принцип Оккама не работает?

А кто сказал, что кэширование - лишняя сущность? Оно может существенно уменьшаить вычислительную сложность задачи

> Изначально был выбран неверный принцип - рисовать всё софтом. Нужно было взять OpenGL

... об который после софта можно мозг сломать.

Во, первых, принцип звучит не:
«Не следует привлекать новые сущности»
,а
«Не следует привлекать новые сущности без самой крайней на то необходимости»

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

> ... об который после софта можно мозг сломать.

Ну, если мозга не хватает, всегда можно взять готовый движок.

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

Вопрос - почему принцип Оккама не работает? Почему самым лучшим решением не является самое простое?

Потому что то, что ты посчитал самым простым решением, на самом деле решением не является.

> Ну, если мозга не хватает, всегда можно взять готовый движок.

Вращающийся кубик с текстурой всё равно них сложнее сделать, чем с нул написать в софте -> не нужно.

>Вращающийся кубик с текстурой всё равно них сложнее сделать, чем с нул написать в софте -> не нужно.
http://irrlicht.sourceforge.net/docu/example001.html Вот вращающаяся анимированная фигура. Сможешь сделать проще на софте, флаг тебе в руки.

>А кто сказал, что кэширование - лишняя сущность? Оно может существенно уменьшаить вычислительную сложность задачи

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

Во-вторых, что за квадратное освещение,

Когда я только начинал делать освещение, наименне «жрущим» был способ хранить степень освещения для отдельного блока, а не делать пост-эффекты. Сейчас, после кеширования, возможно, вернусь к более «натуральным» кругам.

> Философ-тред

Я думал это будет тред про ДТ.

Могу и сделал: http://www.cyberforum.ru/beta-testing/thread340775.html

Оккама не работает...

Предлагаю вернуть статью за тунеядство

>Могу и сделал: http://www.cyberforum.ru/beta-testing/thread340775.html
Сравнил, колеблющиеся синусоиды и расчет освещения + двойная буферизация.

Когда я только начинал делать освещение, наименне «жрущим» был способ хранить степень освещения для отдельного блока, а не делать пост-эффекты. Сейчас, после кеширования, возможно, вернусь к более «натуральным» кругам.

Если степень освещения хранится для отдельного блока, то где возникают тормоза? Максимум же нужно где-то 255 вариантов освещения для такого блока, они с легкостью влезут в видеопамять, а рейтрейсинг для двухмерной картинки 100х100 блоков обсчитываться может на среднем мобильнике.

Могу и сделал: http://www.cyberforum.ru/beta-testing/thread340775.html

Сравнил, колеблющиеся синусоиды

А вы дальше темку почитайте. В районе 6-8-й страниц.

Если степень освещения хранится для отдельного блока, то где возникают тормоза?

Тормоза из-за того, что FPS=20. Этот тот минимум, который не режет глаза.

Максимум же нужно где-то 255 вариантов освещения для такого блока

Стоит 16, если ставить больше, то память жрется на раз - ведь здесь блок со степенью освещения F и блок, со степенью освещения 8 - это две разные текстуры - опять таки из-за того, что постэффекты жрут много.

> Почему самым лучшим решением не является самое простое?

Самым лучшим решением является самое простое.

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

Пограмист-велосипедист решил рассказать всем про его изыскания в области методологии науки. Получилось неплохо.

Надо ему предложить написать книгу по велосипедизму. Она просто обязана стать бестселлером.

>http://img683.imageshack.us/img683/756/58856691.png

Загрузка процессора: 99%

Супер-кривые руки detected

>А вы дальше темку почитайте. В районе 6-8-й страниц
По сочетанию простота_реализации/сложность_замысла не нашел ничего подходящего.

Тормоза из-за того, что FPS=20

А может FPS 20 из-за того, что тормоза?

Стоит 16, если ставить больше, то память жрется на раз - ведь здесь блок со степенью освещения F и блок, со степенью освещения 8 - это две разные текстуры

Да, но текстура 2000х2000 в 32 бита, весит всего 16 мегабайт.

> Да, но текстура 2000х2000 в 32 бита, весит всего 16 мегабайт.

Я боюсь, ТС хранит отдельное множество текстур для каждого блока.

>А может FPS 20 из-за того, что тормоза?

Нет, потому, что таймер настроен на 50мс.

Да, но текстура 2000х2000 в 32 бита, весит всего 16 мегабайт.

Сейчас реализовано 16 текстур (чисто для тестов), планируется минимум сотня.

100 текстур * 16 уровней света * 8 вариаций текстур * 16 х 16 размер * 4 байта (на цвет) = 25 мегабайт.

100 текстур * 256 уровней света * 8 вариаций текстур * 16 х 16 размер * 4 байта (на цвет) = 200 мегабайт. А еще хранить карту и разные ништяки.

>Я боюсь, ТС хранит отдельное множество текстур для каждого блока.
Хм, как-то это мне даже в голову не пришло)

Даже в таком случае, зачем для текстуры хранящей освещенность 4 байта на цвет, если достаточно 1?

> 25 мегабайт.

200 мегабайт.

Т.е. ожидается, что игра должна работать на 256 MB RAM? Ну тогда да, придётся городить оптимизацию. А вообще, степень освещения не должна храниться в памяти как отдельная текстура. Для этого можно lightmap считать - дешевле выйдет.

Режим 256 цветов? О_о

Или вы предлагаете дополнительно ввести 256 текстур от 000000 -> 010101 -> 020202 -> ... -> FFFFFF и накладывать их? Пробовал, для наложения придется расковыривать DIBBits, а скорость при этом падает, вместе с повышением загрузки процессора. У меня так инвентарь отрисовывается, процессор при этом жрется на раз, собираюсь отключить для него полупрозрачность.

http://img819.imageshack.us/img819/825/10092011141817.png

>ожидается, что игра должна работать на 256 MB RAM?

Вообще, как бы, планируемая ЦА - дядьки, которые играют в Df. Из-за сложности и смысла™. А у такой ЦА редко, когда есть игровой компьютер.

> А у такой ЦА редко, когда есть игровой компьютер.

Хотя бы 1 GB в современном мире у них должен быть. +SWAP никто не отменял, пусть малоиспользуемые текстуры свободно себе лежат в свопе/самодельной_структуре_на_диске, пока не юзаются.

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

Под герцами я имел в виду такты.

А, дошло. Ты имеешь в виду, что тебе наложить текстуру освещения на текстуру ячейки накладно. Это не так накладно, если это сделать грамотно.
Вообще я не понимаю, почему 2 прохода сделать так накладно. Обычно освещения накладывается во второй проход, просто сверху рисуешь квадраты белого цвета с заданной прозрачностью только там, где освещение изменилось. Там разных вариантов освещения в твоем случае вообще всего 255, а не для каждой текстуры свой вариант.

[ШОК!]Оккама не работает...

КГ/АМ

Рисуйте уже уровень целиком одной картинкой. Всяко меньше мороки. А с динамическими объектами уже развлекайтесь.

Дело в том, что ВСЕ объекты динамические. Статика не существует вообще.

> Дело в том, что ВСЕ объекты динамические. Статика не существует вообще.

Ещё один Minecraft? Это печально.

На практике он, похоже, не применим

Это легко доказывается теоретически, элементарным применением принципа Окамы к самому себе.

Keep it as simple as possible, but not simpler.

Ааааа. Так вот откуда берутся быдлокодеры! Они тупо используют булки Оккама от гвоздей «искусства программирования» Ричи!

Питон, кажись?

от/вместо

Это Эйнштейн. Только я неправильно процитировал, там не keep, а make things, но это не важно.