Да, 64-х битная.Uvadzucumi писал(а):как я понимаю 64-х битная слакварь?
Кстати, по ссылке "билд под линукс" у меня скачивается архив с пустым каталогом.
Модераторы: Sanja, Максим Кич
Да, 64-х битная.Uvadzucumi писал(а):как я понимаю 64-х битная слакварь?
зы. как я понимаю, редактирование моего поста, предыдущего, ты не читал? просто только сейчас добрался до компа.Uranium писал(а):Кстати, по ссылке "билд под линукс" у меня скачивается архив с пустым каталогом.
Код: Выделить всё
1, 1, 1, 1, 1, 2, 1, 1,
1, 1, 1, 1, 1, 2, 1, 1,
1, 1, 1, 1, 1, 4, 1, 1,
1, 1, 3, 3, 3, 3, 3, 1,
1, 1, 3, 3, 5, 3, 3, 1,
1, 1, 3, 3, 3, 3, 3, 1,
1, 1, 1, 1, 1, 4, 1, 1,
2, 2, 2, 2, 2, 2, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1,
Код: Выделить всё
struct ....{
TileTypes tile_type. // enum типа тайла, дверь, стена, окно
СItemsList *items; // список предметов (4 байта)
СCreaturesList *mobs; // список предметов (4 байта)
СCreaturesList *mobs; // список предметов (4 байта)
unsigned char layer[3]; // тайлы для 3-х слоев, номер тайла из тайлсета. сразу рисуется 0, потом 1 (если задан) и т.д.
// обзая инфа для всех ячеек карты
bool IsViewed; // видел ли раньше персонаж эту ячейку карты
unsigned char IsCanMove; // проходимость (трудность перемещения на самом деле)
bool IsSkipLight; // проходит ли свет
// доп инфа, если есть
void *tile_data; // доп данные для конкретного типа тайла, если нужны (для двери, например, поломана, заклинена, заперта спец ключем, открыта, прочность ее и т.д. для стены - стены это у меня еще и руда по совместительству может быть, руда и количество этой руды)
}
Весьма любопытно, как ты это видишь. Регулярно мелькают ощущения мол о как можно было бы, но каждый раз спотыкаюсь на попытке визуально представить это.Uvadzucumi писал(а):хочу несколько этажей на одной карте
Честно не понял. Несколько раз перечитал, но все равно не понял >_<Uvadzucumi писал(а):тут просто у меня вторая мысль, но не знаю, нужно тестировать. <...> если непонятно написал, то задавайте вопросы, исправлюсь
Бытует подход держать строки в UTF-32 внутри программы (т. е. в памяти) и в UTF-8 — снаружи нее (файлы, сеть, etc.). Вот прямо по четыре байта на символ. Так как кромчить на строках давно уже бессмысленно, а работу с ними упрощает порядком.Uvadzucumi писал(а):у меня просто там реальный UTF8 юзается, анализ буков - еще тоот гемор
На всякий случай: ты используешь #pragma pack? И еще я запутался и не понял, как ты получил 28. В приведенной структуре 32 байта (если выкинуть дубль mobs), если с паддингом, и 22, если без паддинга.Uvadzucumi писал(а):хранятся данные примерно таким же образом: <...> на все про все - 28 байт на 32-хбитной системе. причем еще есть что резать.
Код: Выделить всё
struct ExctendedCell
{
int AnimationSequence;
int AnimationCounter;
void* tile_data;
};
struct RegularCell
{
CItemsList* items;
CCreatureList* mobs;
ExtendedCell* extended;
};
struct Cell
{
TileType tile_type;
uint8_t layer[3];
uint8_t IsViewed;
uint8_t IsCanMove;
uint8_t IsSkipLight;
RegularCell* regular;
};
разцмеется, только частные случаи при этом реализованы будут (будутли?).Cfyz писал(а):Весьма любопытно, как ты это видишь. Регулярно мелькают ощущения мол о как можно было бы, но каждый раз спотыкаюсь на попытке визуально представить это.
я потому и написал, "если непонятно..." так как сам при объяснении запутался объяснять. на самом деле все просто. сейчас как работает. если ячейка карты попала в FOV, т.е. находится на LOS-е. то автоматом выставляется флаг Viewed и отображается самым темным цветом уже всегда - даже когда игрок ее не видит. так вот, я, думаю, что не стоит так делать. а выставлять viewed только если находится на LOS и, одновременно, есть в ней свет. таким образом, если игрок стоит в комнате и открывает дверь. он видит начало коридора, потом нифига не видит и только в конце коридора видит другую комнату, которая также освещена. если двигаться по коридору - открываются ячейки на которые падает свет от факела игрока. картинка примерно такая:Cfyz писал(а):Честно не понял. Несколько раз перечитал, но все равно не понял >_<
Код: Выделить всё
#####
#...# ########...#
#........ ........@...#
#...# ########...#
#####
я представляю, но,подумаю - делать или нет... после того, как записались все интенсивности света и поссуировались - еще один проход по Viewport-у и сравнивать, если рядом светлая и темная клетки с разницей свечения какойто пороговой, то от светлой с затуханием добавить света к темной. типа отраженного света. но все это лишние проходы (ьез рендера правда, но все равно один лишний цикл на проход, или 2 - если x и y считать отдельно). в общем это решается... может быть и реализую.Cfyz писал(а): А вообще освещение опрятно смотрится. Разве что несколько неуютно "на стыке" освещенной и неосвещенной площади
... (хотя что с этим можно поделать — не представляю).
как бы работа со строками - это одно, а рендер этих строк, в частности поиск глифа, например, для текста, который меняется на каждом кадре рендера - станет проблемой. у меня сейчас просто сделано, так как в используемом фонте нет больше 2-х байт то первый байт считается номером слоя глифа, второй индексом глифа, в результате у меня 4 слоя по 256 элементов для глифов. при рендере геометрии текста читается первый байт из строки, сверяется - однобайтовый символ - слой 0, если нет, то первый байт считается за номер лоя. по списку слоев определяется индекс в массиве слоев, читается второй байт и берется глиф по индексу равному второму байту. потребуся симаолы 3-байтные - добавится уще один слой. в общем как то так я рендер текста у себя организовал. причем, есть возможность построить дисплейный список с текстом, после чего рендерить его просто $utf8_string->render() без всяких поисков глифов и парсинга конструкций вида "\n", "^ff00ee", расчета переносов и т.д.Cfyz писал(а):Бытует подход держать строки в UTF-32 внутри программы (т. е. в памяти) и в UTF-8 — снаружи нее (файлы, сеть, etc.). Вот прямо по четыре байта на символ. Так как кромчить на строках давно уже бессмысленно, а работу с ними упрощает порядком.
я просто помню что у меня 28 байт на ячейку, а структуру эту набирал прямо на форуме, без всяких копипаст.Cfyz писал(а):И еще немного побурчу, пока дают.
...как ты получил 28. В приведенной структуре 32 байта
Я когда размышлял и "игрался" со светом. пришел к тому что в подобной ситуации если ты находишься в темной комнате, или в комнате с очень слабым источником света, и смотреть будешь на комнату с очень сильным источником света, ты будешь видеть только "свет в конце туннеля" и не будешь видеть комнату которая там за светом, и так-же обратная ситуация если ты будешь стоять в комнате с сильным источником света, и смотреть в коридор в конце которого очень слабый источник света ты будешь видеть только темноту (эффект когда смотришь в пещеру в ней ничего не видно, а когда заходишь в нее там света хватает что-бы различить намного больше чем виделось вначале)Uvadzucumi писал(а): ...
я потому и написал, "если непонятно..." так как сам при объяснении запутался объяснять. на самом деле все просто. сейчас как работает. если ячейка карты попала в FOV, т.е. находится на LOS-е. то автоматом выставляется флаг Viewed и отображается самым темным цветом уже всегда - даже когда игрок ее не видит. так вот, я, думаю, что не стоит так делать. а выставлять viewed только если находится на LOS и, одновременно, есть в ней свет. таким образом, если игрок стоит в комнате и открывает дверь. он видит начало коридора, потом нифига не видит и только в конце коридора видит другую комнату, которая также освещена. если двигаться по коридору - открываются ячейки на которые падает свет от факела игрока. картинка примерно такая:в результате между тем что игрок видит вдали и перед собой - темная зона, где могут быть ответвления коридоров, но пока неосвещено светом - игрок не видит.Код: Выделить всё
##### #...# ########...# #........ ........@...# #...# ########...# #####
...
Мне кажется это правильный вариант. По крайней мере, это более интуитивно, нежели:Uvadzucumi писал(а):а выставлять viewed только если находится на LOS и, одновременно, есть в ней свет. таким образом, если игрок стоит в комнате и открывает дверь. он видит начало коридора, потом нифига не видит и только в конце коридора видит другую комнату, которая также освещена. <...> в результате между тем что игрок видит вдали и перед собой - темная зона, где могут быть ответвления коридоров, но пока неосвещено светом - игрок не видит.
потому что такие штуки будут работать только если пойти до конца и сделать привыкание к освещению: сначала ярко и ничего не видно, а потом постепенно норм и наоборот. Но здесь есть нюанс -- LOS, как правило ненаправленный. Т. е. персонаж смотрит как бы во все стороны разом и на границе яркой и темной областей (да и просто близко к такой границе) невозможно сказать к какой именно яркости нужно привыкать. А без привыкания область видимости станет неинтуитивной и будет вызывать недоумение. Впрочем, пока это лишь мои ощущения.Jesus05 писал(а):в подобной ситуации если ты находишься в темной комнате, или в комнате с очень слабым источником света, и смотреть будешь на комнату с очень сильным источником света, ты будешь видеть только "свет в конце туннеля" <...> думаю технически это не сложно сделать... надо делать видимым свет на основании интенсивности света в клетке в которой стоишь. если свет слишком яркий где-то то делать клетку засвеченной и не пропускать через нее FOV, если свет слишком тусклый по сравнению с тем в котором находишься то клетка становится просто не видимой.
Запросто не станет. "Преждевременная оптимизация -- корень всех зол" и с каждым годом это все вернее и вернее. Проиллюстрирую в цифрах. Возьмем Core i3 2100 и лично мною проведенный тест. Контейнер std::unordered_map<wchar_t, whatewer*> тратит на один lookup 5.5 нс (прописью: пять с половиной наносекунд). Следом за ним ванильный std::map<wchar_t, whatever*> с 62 нс на поиск. Даже если взять полный FullHD экран среднего такого текста (~10к символов) и неаккуратный алгоритм, требующий аж два поиска в мапе на один символ, это выходит порядка 0.2-1.2 мс на кадр. Смена текстуры может запросто съесть под миллисекунду. Если "слои" глифов -- это отдельные текстуры, то у меня для тебя плохие новости.Uvadzucumi писал(а):как бы работа со строками - это одно, а рендер этих строк, в частности поиск глифа, например, для текста, который меняется на каждом кадре рендера - станет проблемой.
Во-первых, ты же не считаешь постоянно все-все невидимые никем, кроме переменных, источники света на уровне? Во-вторых, даже 361*3*200 = ~200к. Если используются по делу, то даже задумываться не стоит.Uvadzucumi писал(а):зы. правда у меня сейчас на один только источник света отъедается 361*2 (или даже уже *3) байта <..> а на текущей карте их 200 штук.
Мне кажется не "забивают", а просто мысль такая в голову не приходит. Пластинчатый доспех по 'y' на протяжении всей игры? А в следующей уже не 'y'. И если новый пластинчатый подберу -- он же тоже уже не 'y' будет. Все равно придется каждый раз лезть и смотреть что там за буква. С точки зрения эргономики куда удобнее будет сделать хоткеи: или навешиваемые пользователем а-ля группы юнитов в RTS (нажал Ctrl+1 и теперь этот несчастный доспех будет на единичке) или, если слотов немного, сразу все на определенные клавиши повешены. Так что мой личный ответ -- выпиливай. Особенно если костыли. Дерево, бывает, пускает корни =)Uvadzucumi писал(а):нужно ли это вообще? или забить, почистить костыли и упростить себе жизнь... потому, что с инвентарь хоть и есть, но пока до конца не реализован и еще намучаюсь.
спрашиваю просто потому, что в куче рогаликов забивают на сохранность букв. может это только мне нужно?
Ну так в ангбанде сделано, и я также считаю что так правильно. Сделаю пока опцией в конфиге.Cfyz писал(а):Мне кажется это правильный вариант
Это тоже считаю уже как минимум перебором.Cfyz писал(а):...А без привыкания область видимости станет неинтуитивной и будет вызывать недоумение. Впрочем, пока это лишь мои ощущения.
разумеется текстура на весь шрифт одна. Причем вот такая 128x128:Cfyz писал(а):Если "слои" глифов -- это отдельные текстуры, то у меня для тебя плохие новости.
Именно для того, чтобы не считать на каждом кадре фов для источников (тех что рядом), мне и необходимы эти массивы предрасчитанных фов. которые пересчитываются только при изменении проходимости света в ячейке. сейчас только от открытия дверей нужно менять, позже, когда начнут троли бегать, придется чаще.Cfyz писал(а):Во-первых, ты же не считаешь постоянно все-все невидимые никем, кроме переменных, источники света на уровне? Во-вторых, даже 361*3*200 = ~200к. Если используются по делу, то даже задумываться не стоит.
Нет, следующий не будет на y (если предметы не стакаются), да и этот - если кинуть и поднять должен лечь в первую свободную букву инвентаря.Cfyz писал(а):Мне кажется не "забивают", а просто мысль такая в голову не приходит. Пластинчатый доспех по 'y' на протяжении всей игры? А в следующей уже не 'y'. И если новый пластинчатый подберу -- он же тоже уже не 'y' будет.
Вот для этого и не перепутывать буквы, а запоминать. Поднимаешь предмет - влог написано: ты поднял книгу заклинаний в слот b. Ты жмеш r(типа читать - буду стараться минимум кнопок для разного юзать, все что можно читать - будет на r). у тебя спрашивает что читать. жмеш букву b (или * для отображения списка - если не знаешь где что лежит. а потом уже b из списка того что может быть "прочитано" ) потом жмеш c. в результате выбираешь заклинание - "Охрипший дракон". Далее указываешь цель уже. Т.е. если буквы не путать, и инвентарь перетусовывается только игроком, то на комбинация будет только такая r-b-c для охрипшего дракона. для того чтобы эту книгу выкинуть - d-b без залазки в окно инвентаря и т.д. т.е. эта буква всегда используется для предмета в данном слоте инвентаря. такой механизм работы со всеми предметами. тут только одна проблема, что букв то не так уж много...Cfyz писал(а):Все равно придется каждый раз лезть и смотреть что там за буква.
Да бывает и пускает корним, поэтому, и спрашиваю - фигачить буквы или всеже оставить (мне, во всяком случае, обычно удобно, когда буквы слотов не путаются), а то во всяких там катаклизмах - нажал в инвентаре - отображать только свитки - и вот тебе раз, теперь не автомат у тебя на букве "a" а книга "о вкусной и здоровой пище". по хорошему, думаю оставить, но вот кастыли нужно выкашивать, именно это пока останавливает от того, чтобы можно было предметы бросать на пол. пока только одевать/снимать можно. нужно собраться с силами, сесть и перепистаь без костылей, но с возможностью привязки к буквенным слотам... просто думал, все скажут - "нафиг нужно!", и я с чистой совестью на каждую станицу инвентаря - новые буквы для предметов сделаю! т.е. от "a" и до скольки там влазит предметов на страницу, на следующей опять начинаем с "a" и т.д., типа для очистки совести моей....Cfyz писал(а):...Так что мой личный ответ -- выпиливай. Особенно если костыли. Дерево, бывает, пускает корни =)
Спасибо за тест. Выставлю. наверное, по умолчанию в 100.Apromix писал(а):У меня запустилось. Но не в какие двери попасть не смог с первой попытки. После настроек в конфиге movement_delay: 100 все пришло в норму.
Со светом думал что уже разобрался, но, оказывается, есть еще что улучшать. сейчас добавляю еще диффузный свет, чтобы были мягкие границы. Будет отключаться в конфиге, так как добавит тормозов.Apromix писал(а):Побегал. Красивая игра света и теней.
С факелом несколько беда. точнее не беда, но, по задумке, у игрока держаетльные слоты это:Apromix писал(а):Не нашел в инве факела, чтобы посмотреть, как герой держит факел и как меняется освещенность в темных корридорах.
Да. автооткрытие дверей добавлю обязательно (через конфиг), тем паче, что всего пару строк кода.Apromix писал(а): Показалось имхо несколько неудобным открывать двери клавишей "O", не лучше ли простым пинком или там чего-то особенного запланировано на будущее, но пока не реализовано ?
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 27 гостей