Оке, оке, Благодарю!
А как лучше строить?
Каждая кривая в одной клетке?
Похоже я чего-то не понимаю, но подсознательно думаю, что это не так.
И ещё один момент, я может что-то прослушал и не понял, как их в редактор сам задавать?

Правильно думаешь, не так. Вот на твою картинку достаточно 4-5 кривых 4 степени. А ты опять предлагаешь наплодить под сотню.

Кривая Безье строится по точкам. Кривая 3 степени имеет 3 вершины, 4 степени 4 вершины и т.д. Тебе нужно разместить только эти точки, остальное построится само. Потом только, зная Х персонажа и расположение точек кривой, по уравнению находим У. Profit!

Добавлено (03.03.2010, 01:05)
---------------------------------------------
Просто открой любой векторный редактор, да попробуй нарисовать кривую по картинке. Обычно они называются path (пути), но может и bezier-curves.

Отличненько, знал, что есть не такое громозкое решение.

Понял, тогда я сделаю так, допустим подгрузили картинку, и теперь нам вдруг захотелось построить кривую, выбираем когого порядка она будет, жмакаем на экран, и потом издеваемся над ней, механизм нахождения кривой в определённой клетке как-нибудь придумаю.

Да!

Добавлено (03.03.2010, 01:12)
---------------------------------------------

Корел сойдёт?
или не дело?

З.Ы.: О, нашёл, там есть инстумент безе, и сразу задается, но явно не кривая первого порядка.

З.Ы.:
Ко мне снова пришла эврика, я просто невнимательный, бяка =-(
Пойду строить кривые =-)

З.Ы.З.Ы.З.Ы.:
Сижу и не понимаю, как их можно построить.
Ну если найдёшь, выложи пример, не помешал бы, так быстрее разберусь.

Вот примерно так будет выглядеть:

Рисуем карту.
Делаем кривую безье (поверхность по которой будет ходить персонаж) по этой карте.
Находим высоту персонажа.

т.е. персонаж будет ходить не по картинке как ты задумывал в начале, а по заранее построенной линией. Можно прямыми, как ты уже сделал, а можно кривыми, как предстоит сделать. Это решает проблему с производительностью. Кстати, если найти Y пола, то при падений рассчитывать положение персонажа можно как y = max(floor_y, y); , тогда он никогда не будет проваливаться и не надо никаких коллизий. Это будет работать с 1 "этажом", с более надо думать...

Ну я сразу сообразил, правда сначала ну врубился как строить эти кривые, немного пошаманил и оно заработало.

Добавлено (03.03.2010, 04:24)
---------------------------------------------
Немного пошаманил, и оно получилось, точнее построение безье третьего порядка.
На это не стоит обращать внимание, ну всё равно, подтверждение тому:
Link 10кб

Bercut, теперь нужно от X найти Y.

Отказались от кривых безье, так как распределение идёт неравнономерное:
Link 18 kb
Попробуй сильно растянуть линию
Будем юзать линии.

Bercut, это не проблема Безье, это проблема незаконченной программы.

Если(угол между соседними точками > 10*) то падаем.
Если(угол между соседними точками < 60*) идём по холму.

Угол может быть только [0; 90), иначе нет смысла обрабатывать.

Заметим, что если мы не идём по холму и угол от 10 до 60, то мы всё равно падаем, точнее сползаем с холма (точнее двигаемся вниз по кривой).

И не надо мне показывать проблемы, лучше покажи их решение!

Добавлено (05.03.2010, 20:34)
---------------------------------------------
Или можно арктангенс от разницы расстояний по Y.

Ну ты не о этом, как объяснить, например рассмотрим такой случай:

В этом случае персонаж будет бегать гораздо быстрее слева, чем справа, хотя логично, если бежать с горки, то так быстрее.

Bercut, да лан, бросай эти Безье. Делай по-обычному.

Трям!
Доброго дня всем!
Наконец-то проснулся, там сессия и бла-бла-бла, теперь третий курс ждёт.
Так вот в тот раз мы остановились на линиях, для того чтобы делать практически любые поверхности, а не складывать из уже созданых блоков, работающих по заранее задным законам, как это было у Дрима.
Ну то есть, для каждой клетке координаты меняют своё положение (y = f(x)), будь то передвижение по дуге, хоть под углом и т.д.
Так вот у меня практически тоже самое, но всё такое чудо состоит из линий, и эти линии могут лежать в клетках, так вот, так как размах велик, то
есть вопрос.
Если клетки небольшого размера (36 х 36), то можно спокойно разместить все эти линии таким образом, что в одной клетке будет хранится одна прямая, но не всегда, возможно, что будет переход.
А можно и увеличить клетки, тогда в одной клетки будет больше линий, но количество самих ячеек уменьшится. От сюда следует, что надо делать сложную структуру данных, то есть каждая клетка сетки хранит список прямых.
Как это скажется на производительности, и как лучше хранить списки?
Просто допустим на Си можно было храниить указатель на первый элемент в списке.

Буквально на днях думал над этой проблемой. Ща попробуй примерчик накатать про хранение данных.

Здесь тоже можно так, это индекс структуры, допустим. Но как они будут хранится в самой структуре? Вот на этот вопрос постараюсь ответить.

Как сделать зум?
Я конечно понимаю, что можно взять несколько суфров и их растягивать, но как же быть с проверками координат (там же всё уменьшается или увеличивается)?

все проверки так и останутся в 1:1, просто ты приблизишь отрисованный сурф. Конечно если ты при этом хочешь тыкать мышой в экран, то может проще через изменение размера вида?

Да дело в том, что у меня есть рабочая область и меню с кнопочками
В этом случае задавать два вида?

И ещё один вопросик =-)
Рыскал рыскал на просторах интернета один алгоритм, короче надо чтобы (желательно эффективно) искались номера прямых, которые лежат в той или иной клетки.
То есть существует сетка, размер каждой клетки 64Х64.
Имеется список прямых, мы знаем их порядковые номера и принадлежность к тому или иному объекту.
Короче я сделал массив списков, который равен размеру всего поля.
Нужно, чтобы туда правильно записывались номера прямых и т.д., потому что встречаются разные случаи, мб вы с таким сталкивались и находили подобные алгоритмы.
Если же нет, то какие возможны идеи?
Писать за меня что-то и так далее не надо, не хотелось бы вас отвлекать по пустякам.
Заранее спасибо!

Нарисуй, пожалуйста. Я не вкурил с второго раза.

Тут всё видно =-)

З.Ы.:
Вопрос отпал, но всё-таки актуален.
Я же сделал так:

Код мб вам будет неочень понятен, но попытаю объяснить, рассматриваем множ-во прямых, которые лежат на сетке, для каждой прямой сначала записываем какие точки начала и конца отрезка, а потом находим точки пересечения с линиями сетки ( в ограниченном пространстве), вроде много не хапает (у меня постоянный 100 фпс и загрузка проца 4-6%, оччень радует посравнению с прошлой версой, где всё хапапло 50%!.
Если есть ещё более быстрые варианты, то предлагайте.
Собственно, если интересно, то вот можете ознакомится(код сороват конечно -_-):

Это вроде интерполяцией называется

А как сделалать изменяющаяся строку, ну допустим выделение переметров мышью (ну как в чате, однострочная штука), просто прописывать не хочется, мб есть где-то библиотека?
Вообще ща посмотрюб пример чата -_-

Наконец-то сделал отладочный пример.
Его конечно можно подуменьшить, но мне это не особо надо это делать.
Решил добавить ещё разные примитивы, будут идти как отдельные модули.
Круги и всякие кривые (например Безье) упрощать до совокупности прямых, нa память не тестировал, но думаю немного будет занимать, хотя
будут большие уровни -_-
Первую вершину передвигать (w, a, s, d), а вторую стрелками.