Вид для печати
Железобетонный вариант можно будет попробовать для демки, если когда-нибудь дойдут руки.
Пока же на очереди другое твое предложение, отрендерить игровое поле с кирпичами во внутренний монгольский буфер и брать оттуда натуру для рендера мячика и прочих спрайтов.
1) Видел у svofski в Рива Рейде отладочные полоски на бордюре, сделал себе такие же, чтобы хоть примерно представлять, сколько отъедает процессинг разных частей.
http://sensi.org/~tnt23/ok240/palettedebug.png
Вложение 78773
Белая полоса - мячик, красная - ракетка, зеленая - бонусы, черная - idle.
2) Спрямил циклы в выводе битмапа, стало 799 тактов вместо 1073.
Самый зыкий способ отлаживать такты. Но не пойму - ¿куда смотреть? – тут всех полосок по много раз. Или ты возвращаешься к вопросу по нескольку раз за кадр? Получается, что мяч отъедает процентов 60 всего времени?
На картинке с эмулятора смотреть сложно, там нет битика ГК и поэтому попытки синхронизироваться по лучу мгновенно получаются всегда. Попробую снять картинку с тринитрона.
В целом да, мячик самый прожорливый, особенно в зоне, потенциально кишащей кирпичами.
А какая разница сколько кирпичей? Что ты с ними делаешь?
Я представлял себе так: при выводе мячика, для каждого его байтика при выводе проверяем, случилось ли наложение. Если да, то уже ответвляемся и начинаем разбираться, об Гоголя, или об Пушкина. Это может показаться накладно, зато монотонно, что для расчета времени исполнения на кадр важнее. Немного толку от быстроты процедуры, которая обычно супер быстрая, но иногда вдруг становится медленной и срывает собой всю оркестровку.
Или я вообще не о том?
Примерно так же (дьявол в мелочах) делаю и я. После приращения координат мячика смотрим, не приехал ли он в клетку, где уже есть кирпич. Если да, приходится ответвляться, используя терминологию Фангорна, и разбираться.
Разница в том, что кирпичи не встречаются в нижней половине экрана, и мячик не тратит время на ощупывание воздуха вокруг.
Просто у меня еще не все заоптимизировано. Например, стирание мячика и рисование его в новом месте происходит всегда, независимо от того, перебрался он в новый узел кирпичной сетки (8х16) или нет. Далее, все отрисовки (стирание выбитого кирпича, стирание-рисование мячика) производятся прямо где нужда застигла. Хотя правильнее было бы ставить отрисовки в очередь и обрабатывать ее первым делом после синхронизации по лучу.
почитал тему и...:v2_dizzy_facepalm:
что вы хотите сталкивать на пиксельном уровнеЦитата:
Сообщение от tnt23
и главное зачем?.:v2_dizzy_facepalm:
не сдержался
сильно все на никаком уровне...
Не хочу слишком под руку говорить и перебивать творческий процесс, но все же. Это по-моему тот случай, когда оптимизация выходит очень обманчивой. Вот ты оптимизировал внизу, у тебя все очень быстро пока мячик там. Мячик прилетел вверх и все стало медленно. Получается, что если ты то выгаданное время подо что-то использовал, то это что-то уже не может работать, когда мячик вверху. И какой тогда смысл? Реальный критерий оптимизации -- это самая пессимистичная оценка времени обработки мячика и исходя из нее уже надо строить основной цикл.Цитата:
Сообщение от tnt23
Кроме того:
* мячика может быть три
* есть уровни, где кирпичи заходят ужасающе далеко вниз, например третий
* летающие шапки залетают даже под ракетку, а с ними коллизии тоже нужны
svofski, я примерно это тоже понимаю про ненужную оптимизацию. Уберу со временем.
Про троемячие пока намеренно забыл. Чтобы его сделать, нужно сделать мячик каким-то частным случаем генерализованного спрайта.
а как щас происходит детекция касания мячиком чего либо?