Gyre! [2D rlg/trpg]
Модераторы: Sanja, Максим Кич
Re: Разработка [пока-что-без-имени] рогалика
Ну, накосячить наверняка можно. Томе4 вот тоже тормозит на старых компах.
Но все-таки 80*40 полигонов для современной видеокарты это не цифра. Может логика, физика или какая-то постобработка тормозит?
Но все-таки 80*40 полигонов для современной видеокарты это не цифра. Может логика, физика или какая-то постобработка тормозит?
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: Разработка [пока-что-без-имени] рогалика
Берем Qt.
Берем QGraphicView
Зафигачиваем в него 45 000(150х150 х 2 слоя (земля и юниты)) тайлов и он начинает благополучно тормозить.
Берем QGraphicView
Зафигачиваем в него 45 000(150х150 х 2 слоя (земля и юниты)) тайлов и он начинает благополучно тормозить.
Re: Разработка [пока-что-без-имени] рогалика
тайлы - 32 на 32? А если зафигачить картинку 4800*4800 + 22500 тайлов (земля стала одним куском) - не тормозит?Jesus05 писал(а):Берем QGraphicViewЗафигачиваем в него 45 000(150х150 х 2 слоя (земля и юниты)) тайлов и он начинает благополучно тормозить.
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: Разработка [пока-что-без-имени] рогалика
А где собирать эту картинку? если в QPicture\QImage то тогда алгоритм сборки большой картинки из тайлов тормозить начинаетkipar писал(а):тайлы - 32 на 32? А если зафигачить картинку 4800*4800 + 22500 тайлов (земля стала одним куском) - не тормозит?Jesus05 писал(а):Берем QGraphicViewЗафигачиваем в него 45 000(150х150 х 2 слоя (земля и юниты)) тайлов и он начинает благополучно тормозить.
в общем от графики в Qt я решил отказаться разве, что в прототипе. (а в конечном варианте перенести это все на QGLWidget)
Re: Разработка [пока-что-без-имени] рогалика
Хехе, по сходной причине мне и показалось хорошей идеей собирать из тайлов в текстуру единожды.Jesus05 писал(а): А где собирать эту картинку? если в QPicture\QImage то тогда алгоритм сборки большой картинки из тайлов тормозить начинает
в общем от графики в Qt я решил отказаться разве, что в прототипе. (а в конечном варианте перенести это все на QGLWidget)
Хотя тесты я еще не проводил - что быстрее, собрать и отрисовать маленькую текстуру или отрисовать рект из большой? Подозреваю, второе быстрее. Ну и в целом дружелюбнее к оптимизации.
Алсо, графика на Qt - просить себе проблем. Почему бы не сделать на нормальном решении, если уж брать готовое?
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: Разработка [пока-что-без-имени] рогалика
Мне Qt-шка нравится, когда писал тот движок на котором выяснил эти проблемы хотел все на Qt сделать.Venom писал(а):Хехе, по сходной причине мне и показалось хорошей идеей собирать из тайлов в текстуру единожды.Jesus05 писал(а): А где собирать эту картинку? если в QPicture\QImage то тогда алгоритм сборки большой картинки из тайлов тормозить начинает
в общем от графики в Qt я решил отказаться разве, что в прототипе. (а в конечном варианте перенести это все на QGLWidget)
Хотя тесты я еще не проводил - что быстрее, собрать и отрисовать маленькую текстуру или отрисовать рект из большой? Подозреваю, второе быстрее. Ну и в целом дружелюбнее к оптимизации.
Алсо, графика на Qt - просить себе проблем. Почему бы не сделать на нормальном решении, если уж брать готовое?
счас Qt-шную графику использую что-бы быстро что-то отрисовать не заморачиваясь со своим рендером, пока отрабатываю внутренние структуры и взаимодействия.
Если единожду то все было-бы нормально, но мир хотелось сделать побольше чем 150х150 и замкнутый (уходишь вправо выходишь слева), поэтому эту большую картинку приходилось периодически пересобирать.
Re: Разработка [пока-что-без-имени] рогалика
Чем вы мне нравитесь, ребята, в отличии от геймдева и /agdg - отсутствием ответа "возьми готовое и не парь нам мозг" =)Jesus05 писал(а): Мне Qt-шка нравится, когда писал тот движок на котором выяснил эти проблемы хотел все на Qt сделать.
счас Qt-шную графику использую что-бы быстро что-то отрисовать не заморачиваясь со своим рендером, пока отрабатываю внутренние структуры и взаимодействия.
Если единожду то все было-бы нормально, но мир хотелось сделать побольше чем 150х150 и замкнутый (уходишь вправо выходишь слева), поэтому эту большую картинку приходилось периодически пересобирать.
Так вот, о рендере - у нас разные задачи, собственно, и решения у нас разные.
У меня относительно маленькие пространства - think of Alien Shooter 2 - поэтому нужно внимание к деталям. Вместо того, чтобы каждый раз дергать объекты во время рендера, проще нарисовать один раз, дорисовывая потом поверх кровь, обломки, битое стекло, етс. Это, правда, накладывает свои ограничения - невозможность эффективно снести уровень до состояния "пол и небо", но это и не нужно, в принципе.
В любом случае, рендерер у меня скрыт за интерфейсом и с остальным кодом не пересекается, так что его внутреннее устройство можно в любой момент поменять.
Как вариант, рисовать всё-таки tile-by-tile, но эффекты - кровь, стекло и всё остальное - всё-таки рендерить в текстуру и хранить.
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: Разработка [пока-что-без-имени] рогалика
Нас мало и мы рады любому начинанию. а на ГД.ру начинаний много, и спамеро\критиков много.
под OpenGL запросто можно рисовать и tile-by-tile, и одной текстурой, там мощностей по любому хватит даже на какой-нить дохлой intel.
под OpenGL запросто можно рисовать и tile-by-tile, и одной текстурой, там мощностей по любому хватит даже на какой-нить дохлой intel.
Re: Разработка [пока-что-без-имени] рогалика
+1, а для оптимизации не передавать каждый кадр статические данные а использовать VBO. Правда у автора SDL2, как там сделано не знаю, но можно же и напрямую к OpenGL обратиться.Jesus05 писал(а):под OpenGL запросто можно рисовать и tile-by-tile, и одной текстурой, там мощностей по любому хватит даже на какой-нить дохлой intel.
А насчет 150*150 не совсем понятно - ты все время рисуешь всю карту? Нужно рисовать только то что влезает в экран. Или у тебя экран с нереальным разрешением и туда столько влезает?
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: Разработка [пока-что-без-имени] рогалика
рисовал то что влезало на экран + по одному тайлу с каждой стороны (когда делал большой картинкой).kipar писал(а):+1, а для оптимизации не передавать каждый кадр статические данные а использовать VBO. Правда у автора SDL2, как там сделано не знаю, но можно же и напрямую к OpenGL обратиться.Jesus05 писал(а):под OpenGL запросто можно рисовать и tile-by-tile, и одной текстурой, там мощностей по любому хватит даже на какой-нить дохлой intel.
А насчет 150*150 не совсем понятно - ты все время рисуешь всю карту? Нужно рисовать только то что влезает в экран. Или у тебя экран с нереальным разрешением и туда столько влезает?
а когда делал тайлами тогда рисовал все. (но там QGraphicView сам отрезает лишнее по идеи, выводил их с помощью QGraphicsPixmapItem там сам класс довольно тяжелый)
Re: Разработка [пока-что-без-имени] рогалика
У автора SDL2 сам цепляется к тому, чему найдет - DX, OGL, OGL ES, если не найдет ничего - есть фолбэк в виде довольно шустрого софтвара. Некоторые на этом софтваре пишут порты всяких там Doom-ов, выдающие играбельный фреймрейт.kipar писал(а): +1, а для оптимизации не передавать каждый кадр статические данные а использовать VBO. Правда у автора SDL2, как там сделано не знаю, но можно же и напрямую к OpenGL обратиться.
Я сторонник YAGNI, так что буду напрямую цеплять OGL только если того, что есть не хватит. Обильных эффектов или трансформаций над спрайтами мне не нужно, так что это можно считать эффективным "никогда".
Алсо, трачу рабочее время в личных целях - господа, кто-нибудь гугловские Protocol Buffers пробовал для хранения даты использовать? Выглядит как идеальное решение - быстрое, дружелюбное к машине, стабильное и надежное. Человекочитаемость не нужна - зачем бы это человекам читать мою дату?
Запилил анимацию, возник вопрос - как вы решаете вопрос со слоями при ренедере? Как Нинтендо решала с незапамятных времен: enum Layers {Background, Middle, Front, etc} ?
И очередной вопрос про заветный UX - мне одному обилие черноты на экране кажется отталкивающим? При достаточно мелких тайлах на достаточно большом экране крайне насущный вопрос. В TOME решен увеличением тайлов, но всё равно, ситуация, когда 3\4 экрана залито чернотой - норма. В остальных рогаликах ситуация сходная, если не хуже.
- Максим Кич
- Администратор
- Сообщения: 1642
- Зарегистрирован: 03 дек 2006, 20:17
- Откуда: Витебск, Беларусь
- Контактная информация:
Re: Разработка [пока-что-без-имени] рогалика
Обычно проблема в том, что человекам надо её писать.Venom писал(а):зачем бы это человекам читать мою дату?
Dump the screen? [y/n]
Re: Разработка [пока-что-без-имени] рогалика
Я из мира несколько другой разработки прибыл, так что задам вопрос о том, что мне кажется очевидным:Максим Кич писал(а): Обычно проблема в том, что человекам надо её писать.
Что, при разработке рогаликов вы контент набиваете руками через блокнот? Серьезно?
Я привык для таких задач использовать тулзы, всё-таки.
- Максим Кич
- Администратор
- Сообщения: 1642
- Зарегистрирован: 03 дек 2006, 20:17
- Откуда: Витебск, Беларусь
- Контактная информация:
Re: Разработка [пока-что-без-имени] рогалика
«…как у вас там пьют какаву: с сахарином, али без?»Venom писал(а):Я из мира несколько другой разработки прибыл, так что задам вопрос о том, что мне кажется очевидным:Максим Кич писал(а): Обычно проблема в том, что человекам надо её писать.
Что, при разработке рогаликов вы контент набиваете руками через блокнот? Серьезно?
Я привык для таких задач использовать тулзы, всё-таки.
Чтобы для таких задач использовать тулзы — надо эти тулзы сначала написать. В играх с предопределённым контентом — редактор однозначно нужен. В рогаликах — по ситуации. Кто-то делает себе дополнительный инструмент, кто-то — нет. В моём мире на разработку ещё и редактора времени катастрофически не хватает — роскошь править две программы вместо одной я могу позволить себе только в коммерческих проектах, и только там, где под это выделены отдельные часы и средства. И я хочу отбыть в тот мир, где часов и средств на разработку всегда хватает.
Поэтому в моём случае — JSON и редактор с подсветкой синтаксиса. Серьёзно. Под тайлсеты полно готового инструмента, который на выхлопе выдаёт опять таки JSON и тайлсеты. Если мне припрёт рисовать предопределённые карты под это, внезапно, тоже есть готовые редакторы, способные выдать на-гора JSON. А имена монстрам мне проще накидать в Notepad++, чем городить под это отдельный софт.
Dump the screen? [y/n]
Re: Разработка [пока-что-без-имени] рогалика
Если мне не показалось - no offense was intended.Максим Кич писал(а): Чтобы для таких задач использовать тулзы — надо эти тулзы сначала написать. В играх с предопределённым контентом — редактор однозначно нужен. В рогаликах — по ситуации. Кто-то делает себе дополнительный инструмент, кто-то — нет. В моём мире на разработку ещё и редактора времени катастрофически не хватает — роскошь править две программы вместо одной я могу позволить себе только в коммерческих проектах, и только там, где под это выделены отдельные часы и средства. И я хочу отбыть в тот мир, где часов и средств на разработку всегда хватает.
Поэтому в моём случае — JSON и редактор с подсветкой синтаксиса. Серьёзно. Под тайлсеты полно готового инструмента, который на выхлопе выдаёт опять таки JSON и тайлсеты. Если мне припрёт рисовать предопределённые карты под это, внезапно, тоже есть готовые редакторы, способные выдать на-гора JSON. А имена монстрам мне проще накидать в Notepad++, чем городить под это отдельный софт.
Да, несложно заметить, что большую разработку я видел только в условиях коммерческих продуктов. Часов и средств всегда не хватает, не в стране эльфов живем.
Ну, для кустарных целей - например, заполнения своего формата описания мобов - проще за пять часов накидать на шарпе простую тулзу, чем крутиться с блокнотом. Вкусовщина.
Имена монстрам - да, тут ты прав, проще руками.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 45 гостей