А куда пропала статья DreamRunner'a про сетки?

столько обыскал, не нашёл...

http://forum.gmaker.su/forum/15-322-1
это?

Нет, не она, затерялась видать. =-(

Добавлено (01.03.2010, 20:28)
---------------------------------------------
Как сделать двумерный массив (например сетку), огромным размером и чтобы память сильно не хапала,
например 5000 на 5000(или ещё больше)?
Длл написать на асме? =-)
Создаю такую сетку на гамаке, хапает оперативки львиную долю, а мне там только хратить буленовский тип (0,1).
И есть ли альтернатива draw_getpixel(х, у); ?

Добавлено (01.03.2010, 21:51)
---------------------------------------------
Короче идея такая, у меня есть чёрно-белая картинка (да, всего два цвета), размер большой(разрешение), весит немного, максимум 20 кб, так вот, надо представить её в виде двухмерного массива, где белый цвет- нули, а чёрный- единицы.

Bercut, и в чём проблема?

Загружаешь картинку и циклом

или

если пиксель == c_black, то 0, а если == c_white, то 1.

Либо делаешь свой загрузчик картинки и запихиваешь сразу в массив, обходя *_getpixel. Хотя я не думаю что будет намного быстрее.

Капитан Очевидность хочет подчеркнуть, что хоть ГМ и тормознутый, но читать файл явно быстрее, чем юзать getpixel.
А если использовать для этих целей 39dll... PROFIT !

Хотя должно быть медленнее, потому как доступ к винчестеру медленнее чем к оперативной/видео памяти... Не проверял, не знаю.

А что там есть интересного?

Хм, ты прав, но было-бы интереснее увидеть реальные цифры.

Хехе, 39длл умеет работать с файлами и явно по человечески (можно даже указывать размер сколько байт считывать, не то что в стандартных недофункциях).

Создание массива (сетки) из картинки я ждал 3 минуты. =-(

На чём, хотя ладно, погуглю, как там можно на си напримере сделать.

Там есть интересные функции?

Научитесь уже правильно цитировать (без указания источника, если лень, как мне ).

Точно. Bercut, тебе ответственное задание! Узнать какой из вариантов быстрее и нам выложить результаты. Заодно и задачу свою решишь...

Да? Интересненько, интересненько...

Нет типов - нет таких функций.

А есть муналы, муналы?

Bercut, а почему из картинки?

Bercut, Есть википедия, википедия.

Чтобы было легко изменять, раз мазнул кисточкой и бац.
Короче, сегодня придумали такую фишку для платформера (я наконец-то разобрался):
Сделать сетку в один пиксель, чтобы была возможность делать совсем костумную землю (точнее тайлы),
пиксель движется по пикселям, ну и там идут вычисления для каждого шага.

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

То есть как и обычно, мы разбиваем карту на клетки, например 32 на 32, в определённых клетках есть тайлы, которые имею 2-4 координаты для столкновений, то есть получается некая прямая по х и у, для которой по всяким расстояниям находят координату игрока на поверхности, я такое видел у Дрима, но у него частный случай: для уклона и для спуска, там он заранее знает как должен зависить игрек от икс.
Чтобы было немного понятнее, вот:

Придётся делать инструмент, которым можно будет такой контур рисовать.
Добавлено (02.03.2010, 00:05)
---------------------------------------------

Так точно, командир!
Благодарю!

Добавлено (02.03.2010, 00:06)
---------------------------------------------

Я почему так ненормально?

Игры имеют 2 независимы части: внутреннюю и внешнюю. Именно об этом я долго и нудно писал здесь. И всё безуспешно. Я даже не знаю с какой стороны взяться за эту тему чтобы было понятно. Потому как это очень важная тема.

Ты пытался совместить внешнюю и внутреннюю, а точнее перекинуть внешнее на внутреннее (что делают 99.99% новичков, включая и меня). И потерпел поражение, т.к. программа была не эффективной, хотя и привлекательной. Затем ты перешёл на другую схему, сделал их независимыми. Как в принципе делают люди уже лет 30.

Т.е. передвижения обрабатывать по другой схеме, упрощённой, а на это накладывать изображение. Коллизия происходит более быстро, но картина зрелищности не теряет, т.к. пользователь не видит внутренние механизмы. Так делают все. Обработка столкновений происходит простыми фигурами (линиями, многоугольниками и т.д.). Да, определять придётся и изображение (грубо говоря, тайлы), и коллизию вручную. Но зато это будет быстро в процессе выполнения. Хочешь автоматически? Нужно будет подождать n минут. Не хочешь ждать? Не надо никаких инструментов, сделай заготовки. Не нравится блоки с уклоном в 45*? Сделай 30, 15. Можешь сделать круглые, полукруглые. Да, с блоками произвольного типа будут проблемы, но вот вопрос: а нужны ли они? Зачем тебе блоки с уклоном 1* или там 30.25? Слишком квадратично, не гладкая поверхность, не изящно? Так нарисуй сверху красивых, полупрозрачных тайлов (травки там, ещё чего), так чтобы не было заметно этого кубизма (или прямологизма? ). Я уверен если ты нарисуешь поверх красивую, изогнутую травку, 99% и не заметят что персонаж идёт не по гладкой поверхности с учётом каждого пикселя, а по прямому уклону в 15*.

Обмани зрение, будь фокусником в мире игр!

P.S.: Заметь, ты когда поверхность порезал на квадраты сразу выявились кандидаты на тайлы. Многие повторяются. А твои там +/- пару пикселей никто не заметит, игроки не будут мерить их линейками.
P.P.S.: Попробуй поиграй в другие платформеры и приглядись как там это происходит (завуалирование прямоугольных блоков).

Спасибо, что меня понял.
Обязательно почитаю твою статью, я раньше читал, но был глупым. =-)
Каприз немой, так что постараюсь наших дизов переубедить.
На счёт обмана зрения, так и хочу сделать.
Извини, что такой неразвёрнутый ответ, но главное ты меня понял.
Вот то, что сегодня задумал, но оказывается я ясно выражался, но всё же:
Link 30kb

И подумайте заодно как такую неровную землю заполнять тайлами. Шлёпать под разным углом короткие поверхности - не красиво. Так что лучше через тайлы. А в тайлах можно сделать несколько кривых и из них составлять уровень. Будет гораздо лучше.

Поэтому, либо они должны разбираться в среде разработки (т.е. GM), либо слушать тебя что делать можно, а что нет.

Ну вот. А поверх наворачиваешь красивые тайлы и будет вам счастье и профит!

P.S.: Для реализаций изначальной версий можешь использовать кривые Безье. Рисуется рисунок, на него вручную накладываются сшитые кривые, а затем находится координата Y персонажа от его X по кривой. В этом случае, действительно получится сделать так как ты хочешь.

Это уже придумал, каждый тип кривой имеет свой id и собственно спрайт.

Да, это увы так...

Если я правильно понял, то создать опредёлённый набор адекватных (всмысле чтобы они стыковались и т.д.) наклонных (или круглых например) тайлов,
из которых можно создать приятную картику, так же герой "подчиняется закону спрайта", то определяем как персонаж будет предвигаться по нему?

Переубедю, обязательно, то есть по части разработки. =-)

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

Ты хотел технологию - получай! Тебе же нужны были вариации? Там всего 2 уравнения, для кривой 3 и 4 порядка, остальные можно "сшить" из этих 2. Да даже с кривой 3 порядка можно сделать любую кривую. Это как с треугольником в 3д, можно сделать любую поверхность.

Желательно, но не обязательно. Тут уже были кривые Безье и даж не раз. Если не найдёшь, я выложу (если я найду... ).