Передача координат спрайта для вывода?

[Keeper]

Предистория:

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

Вопрос:

В каком виде движок игры передаст координаты спрайта в процедуру вывода спрайта на экран? Клиппинг выполняет процедура вывода.

Зачем задаю этот вопрос: Нужен ли спеку графический ускоритель?

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

Я додумался только до двух вариантов:

1. Отрицательные координаты, например х = -4, у = -2, соответственно спрайт залазит на 4 пикселя влево и на 2 вверх.

2. Смещение точки с координатами 0,0 (для спрайта!!!)

Например, если разбирать случай из варианта 1:

Передаем координаты спрайта для вывода: х = 0, у = 0;
Передаем смещение точки с координатами 0,0 (для спрайта!!!) dx = 4, dy = 2, т.е. считаем что левый верхний угол спрайта имеет координаты 4,2.

Для меня второй способ кажется более предпочтительным т.к. координаты спрайта можно задавать двумя байтами, если же спрайт вылазит влево и\или вверх тогда передаем один или два дополнительных байта со смещением точки 0,0

Жду ваших мнений. Спасибо.

[Advertiser]

[TomCaT]

отрицательные координаты чаще всего, при этом часто не имеет принципиального значения точность задания координат до пиксела. Координата тогда задает смещение от 0-ой точки (например, слева вверху) в четверть-знакоместах (с точностью до 2х пикселов) или даже в полузнакоместах. Code Masters вроде бы делали так и в Super Robin Hood, и в Dizzy. Тогда однобайтового знакового числа вполне достаточно, а если 0 при этом глобально сместить ближе к центру экрана, то можно будет задавать частичный или полный уход спрайта за любые края

[GriV]

байт? 1 байт? координата?
а почему не двухбайтовое знаковое?

[Serdjuk]

Зачем задаю этот вопрос: Нужен ли спеку графический ускоритель?

Вот это вот вообще к чему???
тоесть я понимаю если бы спекки имелы бы в настоящие врема популярность "ибиэма",то да,это было-бы необходимо....
Я тут просто поспрашал .... где спек взять? А мне в ответ ... да на он тебе нужен,есть же эмуль!!!
А мне вот эмуль как раз на ненужен... Мне бы спека....
(причем это говорил человек,который музу на спекки пишет (в эмуле))
Ище я понял что щас спекки трудно достать.... вот собственно и возник вопрос нахрена ??(извиняюсь)
Что бы делать графические ускорители,надо сначало возобновить количество спеков 1982-2000гг. и соответственно столько же юзеров!!!

Добавлено через 1 минуту
пустая трата времени.... хотя возможно хобби....

[Keeper]

Координата тогда задает смещение от 0-ой точки (например, слева вверху) в четверть-знакоместах (с точностью до 2х пикселов) или даже в полузнакоместах

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

байт? 1 байт? координата?
а почему не двухбайтовое знаковое?

Я по-думаю, возможно что это и не критично два байта передавать или четыре...
Я исходил из того что ускориель будет поддерживать два видео режима
256х192 native и 256x192 16c тогда вывод спрайта выглядел бы так:

1. Выводим в порт id спрайта, при этом происходит сброс dx и dy (см. первый пост) в ноль

2. Выводим в порт координаты вывода спрайта, два байта (беззнаковые)

2.1 Если спрайт вылазит влево и/или вверх то выводим еще один или два байта dx и dy

3. Выводим в порт команду Blt в которой указывается операция наложения ( OR, AND, XOR, Copy )

Итого от 4 до 6 байтов на спрайт

Вот это вот вообще к чему???

Прошу эту тему не засирать! Все эмоции сюда: Нужен ли спеку графический ускоритель?

[TomCaT]

аппаратный движок - в разделе программирование o_O
...
извиняюсь, плохо читал первый пост, я действительно не по теме постил.
Я не могу и не хочу, расписываться за всех за нас, программистов, но мне, программисту, удобнее передавать поменьше байт (тем быстрее, проще, и меньше места на регистрах). Но если движок аппаратный на все случаи, тогда, конечно, приходится передавать минимум 9 бит для каждой координаты вместо удобных 8. 2 лишних бита(знаки) можно передавать одним байтом для быстроты передачи, но это страшно неудобно.
А что, если поддержать кроме 4-байтовой системы координат и упомянутый мною выше режим непопиксельной точности? Или это будет огромный ненужный гемор?

[Keeper]

аппаратный движок - в разделе программирование o_O

Именно тут, я ведь спрашиваю как вам, программистам, удобней передать координаты

А что, если поддержать кроме 4-байтовой системы координат и упомянутый мною выше режим непопиксельной точности? Или это будет огромный ненужный гемор?

А можно какой нибудь абстрактный пример, хотя бы в псевдо-коде?

[TomCaT]

ну, экран тогда можно разбить так, по горизонтали например
Экран (знакоместо-пиксел):0-0, 0-2, 0-4, 0-6, 1-0, 1-2, ... 31-4
Координата: 0, 1, 2, 3, 4, 5, 6, 7... 126, 127

Как видно, координата для 31-6 отсутствует - в доп. коде нет 128. Поэтому центр, точку (0;0) уже приходится смещать хоть на 1 пиксел... или пользоваться отриц координатами, 0, -1, -2, -3 в чем, собственно, ничего страшного нет, страшно непривычно только.
А если точку с к-тами (0;0) положить, ну, где-нибудь в левый верхний угол знакоместа 8,8 : (8-0; 8-0), тогда часть экрана слева и сверху имеет одну или обе отриц. к-ты, часть - положительные, и при этом немалый кусок заэкранной области со всех краев тоже "размечен" координатами. Тогда у программиста сложности только с привычкой к тому, что 0,0 в углу, а еще с незначительными усложнениями алгоритмов проверки выхода за экран, т.к. они по большей части соптимизированы на проверку переноса и равенства нулю.

[Keeper]

Ужос А в чем выгода от использования такого метода?

[NovaStorm]

Мне кажется просто нужно увеличить размер виртуального экрана до width+spr_max_width*2 и с высотой также. И аппаратно резать нужный кусок в центре.