Созданные ответы форума
-
Сообщения
-
RazorNd, хорошо, очень исчерпывающе
В другой раз прикладывайте код сразу.И помните, вы отвечаете не мне, а ТС.
Heisenberg, извините за оффтоп, меня побудило любопытство написать
А почему именно C++? Сам Google рекомендует прибегать к Android NDK только в редких случаях, для всего остального, как говорится, есть Java. Хорошо бы прошла сцепка Android SDK + JSFML (впрочем, эта библиотека уже не поддерживается разработчиком, но все же).
Я спрашиваю, потому что у меня тоже была мечта писать под Андроид на плюсах, но меня отговорили когда-то, сказали, что игра не стоит свеч
BunDem, привет.
А так ли это необходимо? Во многих браузерах клик средней кнопкой мыши (колесиком) по любой гиперссылке открывает оную в новой вкладке. В Хроме точно так можно, я проверил
RazorNd, код в студию
Alex, Привет.
SFML – OpenSource продукт. Все исходники есть на ГитХабе.
zelloooo1997, Здравствуйте!
У родительского класса Unit можно объявить protected поля health и damage, а также публичный метод attack:
123456789101112class Unit{public:void attack(Unit* attacked){attacked->health -= this->damage;}protected:int health;int damage;};Тогда, если player атакует enemy:
1234Unit* player = new Player();Unit* enemy = new Enemy();player->attack(enemy); // Игрок атакует врага, нанося ему уронОт себя могу добавить, что мой код не является исчерпывающим. Не хватает полей (вроде maxHealth и т.д.), необходимы полноценные конструкторы, которые будут инициализировать поля, проверка текущего здоровья атакуемого юнита после нанесения урона (чтобы знать о его смерти, если таковая случится). Одним словом, код требует вашей доработки
yaoleg_, вы уверены, что не вносили никаких изменений в исходный код урока?
А вообще, рисуйте пиксел-арт, как Pixel Dungeon, например! Там вообще все эти артефакты незаметны 😀
Smykov, “палец вверх – лучшее спасибо” 😉
Heisenberg, а я вот смотрю на название темы и вижу, что это не так
Вообще, эта тема достойна отдельной статьи. Вы не находите? Но чтобы не разводить срач, так и быть, изложу свои соображения:
Как сделать игру “разрешение-независимой”?
Вариант I(A). Как уже было сказано, масштабировать спрайты. Выбираем некоторое опорное разрешение (например, 1600х900) и рисуем текстурки под него. А далее уже меняем их размеры setScale‘ом.
1234const Vector2f defaultResolution = Vector2f(1600.0F, 900.0F); // Разрешение по умолчанию (под которое рисовались текстуры)RenderWindow window(VideoMode::getDesktopMode(), "SFML Test", Style::Fullscreen); // Окно в полный экранsprite.setScale(static_cast<float>(window.getSize().x) / defaultResolution.x,static_cast<float>(window.getSize().y) / defaultResolution.y); // Так считаем размер спрайтовСпособ, конечно, допустим, но далеко не идеален. На экране 800х600, например, изображение будет сплюснутым, а на 1920х1080 – пикселизированным.
Вариант I(B). То же самое, но с некоторой модернизацией: масштабировать изображение только когда разрешение монитора значительно отличается от дефолтного. Например, ширина экрана игрока в 2 раза меньше ширины разрешения по умолчанию, значит уменьшаем текстуры в два раза (и по оси ‘x’, и по оси ‘y’). А если разница невелика (например, монитор 1920х1080), то пренебречь масштабированием. Очевидно, что такой способ неточен, но зато даст недеформированную картинку. Тоже не рекомендовал бы им пользоваться (хотя, не возьмусь утверждать наверняка, кажется в Starbound используется именно этот метод).
Вариант II. Радикальный вариант: чтобы не масштабировать спрайты можно просто менять View под размер окна. Тогда на экране будет меняться количество тайлов, “попадающих” в экран. Этот метод из Террарии. Минусы: на больших экранах будет слишком много деталей, и они будут слишком мелкие; фон на большинстве мониторов будет не полностью умещаться на экран (а еще он должен быть достаточно большого размера).
Вариант III. Рисовать текстуры для нескольких разрешений:) Тут ничего комментировать не буду – и так все ясно.
Вариант IV. Комбинирование нескольких вариантов. Например, I(B) и III. Это обеспечит реальные размеры текстур близкие к требуемым и масштабирование не слишком исказит картинку, и в то же время рисовать придется меньше.
А вообще, смотрите сами, по ситуации. Идеального рецепта, как всегда, нет
P.S. Heisenberg, как Вы думаете, я разумно изложил?
Я вижу, что зверский некропостинг, но все же.
У ТС, вероятнее всего, не указан sfml-audio.lib в дополнительных зависимостях компоновщика, и реализации классов из Audio.hpp просто не видны. Подробнее на официальном сайте.
Heisenberg, если Вам интересно, создайте соответствующую тему на форуме
Может быть и поделюсь. Одна тема – один вопрос.Smykov, здравствуйте.
Для масштабирования объектов, унаследованных от sf::Transformable (коими и являются sf::Sprite и sf::Text) используется метод setScale(const sfVector2f& scale). По факту, setScale растягивает изображение до размеров <размер спрайта по умолчанию> * scale. Например, если указать scale = sf::Vector2f(0.5F, 0.5F), то изображение уменьшится вдвое по обеим координатным осям.
Впрочем, едва ли Вы найдете этот метод подгонки графики пригодным. Он порождает большое количество дефектов, например зубчатость контуров и сильная пикселизация (что естественно).
Для написания игр под разные разрешения экранов используются другие приемы.
Dench, приветствую.
Обратите внимание на блок отрисовки карты. В нем переменная ‘i’ соответствует координате ‘y’ (“высоте” карты), а не ‘x’, в то время как ‘j’ – напротив – отвечает за ‘x’, а не за ‘y’. А именно:
12345678910for (int i = 0; i < height_map; i++)for (int j = 0; j < width_map; j++){if (TileMap[i][j] == '0')s_map.setTextureRect(IntRect(63, 768, 32, 32));if (TileMap[i][j] == ' ')s_map.setTextureRect(IntRect(0, 480, 32, 32));if (TileMap[i][j] == 'a')s_map.setTextureRect(IntRect(65, 995, 32, 32));//256, 1088, 32, 32// s_map.setPosition(i * 32, j * 32); - Ваш вариант...s_map.setPosition(j * 32, i * 32); // - правильный вариантwindow.draw(s_map);}Давайте мыслить масштабно: эту девочку будем продавать за донат задротам. Ну типа как стиль в ММО.