Видеокарта занимается этим за тебя, перерисовывай всё заново каждый кадр. В документации SFML так и советуют делать.
Тормоза из-за алгоритма видимо.
Тормоза из-за алгоритма видимо.
Даже не знаю что может быть не так в алгоритме...
for (y = 0; y < height; y++)
{
for (x = 0; x < width; x++)
{
if (field[y][x] == true)
rect.setFillColor(C_CELL);
else
rect.setFillColor(C_BACKGROUND);
rect.setPosition(x size_cell, y size_cell);
window.draw(rect);
}
}
window.display();
>window.draw(rect);
Нахуя ты это в цикле-то вызываешь, еблан? Не знает он, блять. Глаза бы разул сначала и подумал хоть 5 минут.
А где вызывать? У меня rect это один объект, который каждый раз меняет свое положение во время отрисовки кадра.
У меня подозрение, что у тебя rect - на самом деле никакой не rect, а битмап, и ты их хуячишь сотнями штук. От этого и тормозит.
Что значи не объект? sf::RectangleShape rect(sf::Vectror2f(size_cell, size_cell)); его объявление (инициализация).
Отрисовывай array пикселей через VetexArray, а не каждый по отдельности
ебанутый спамлист
>debug
Макака, почисти ебучий спам-лист.
Короче, с другими настройками собирай.
>создать VertexArray на 1 лям вершин?
Можно, но лучше засунь свое говно в текстуру и рисуй один квад с ней.
Решил я пока по своему сделать, выделить память 250к объектам класса VertexArray. Но не получается обратится к position. Что делаю не так?
Короче, сделал через текстуру и вершины, но один хуй лагает.
Сделал через мильон вершин с одним вызовом draw(), стало 10 фпс. Но все равно мало... Анон, выручай(((999(((99(((
Обрабатывай данные отдельно, рендери отдельно. Заведи отдельный тред для модификации данных, отрабатывающий раз в секунду. А основной тред пусть просто их рисует.
Типа параллельно обрабатывать и рисовать? Многопоточность? Думаю дело не в этом, слишком простая задача для того, чтобы мудрить потоки. Если смотреть время отработки функции paint() в отладчике visual studio, то это около 100мс... Многовато, а ведь это по сути только рисование. Проверка каждого элемента массива field на true/false на самом деле занимает не более 5мс точно, так что поток тут роли не сыграет ощутимой. Надо что-то другое делать...
скомпилируй не с дебуг-настройками, епта
Я думаю охуевшее количество конструкторов Vector2f играет роль.
Блджад, во всех руководствах ко всем графическим библиотекам чёрным по белому написано: не ебитесь с пикселями, оптимизаторы хуевы, не пытайтесь закрашивать и стирать, а перерисовывайте весь кадр целиком.
Епта, анон как в воду глядел хыыыыы махафака. И вправду надо было в релиз перейти, какого хуя? Почему релизная сборка влияет так на производительность?? Сейчас у меня 60+фпс, как у уважающего себя пекаря.
Да понял я это, прочитал уже сам... Это моя первая по сути графическая библиотека после борландовской графики bgi (там для повышения производительности нужно было сохранять как можно больше пикселей, которые на следующем кадре не менялись).
Кстати, тут тоже на этот счет сомневался, но решил попробовать после твоего совета. Итог: с конструкторами работает в 2 раза быстрее (по замеркам времени в дебаге), чем с обращением на прямую position.x = ... positition.y = ... Но на практике разница всего около 5 кадров.
Может потому что в дебажной конфигурации выключены оптимизации, и в реализации стандартной библиотеки еще куча отладочных действий делается?
Ты так думаешь? Хммм...
п.с. Пишу игру жизнь (клеточный автомат) и на поле с 250х250 клетками жуткие тормоза из-за этой полной перерисовки кадра.
п.с.(2) До этого писал на чистом си с древней библиотекой graphics.h, там я мог отрисовать только изменившие свое состояния клетки, а не все поле заново, что позволяло ускорить производительность в раз 10 по сравнению с работой в sfml на c++.