VB1 Мышь

[Alprog]

Откопал себе Visual Basic 1 for DOS. Не знаю чем, но нравиться мне на нём писать. Думал даже маленькую игрушку сделать, но в полноэкранном режиме никак не могу задействовать мышь. Можно ли вообще это сделать?

Код: Выделить всё


screen.HIDE    'Убрали формочки
SCREEN 12      'VGA, 640x480, 16 цветов

LINE (0,0)-(POS(1), CRSLIN) 'Это координаты вывода текста
                                           'нам они не подходят.
LINE (0,0)-(POINT(0), POINT(1)) 'Координаты вьюпорта, тоже не то.

'MouseMove и тому подобное естественно в полноэкранном
'режиме тоже нельзя использовать.



Больше ничего в голову не лезет. Но может всё-таки есть способ

[Хакер]

LOL.

Автор, игруке нынче пишут под DX.
Игрушки под DOS пишут пожалуй только фанаты DOS.

Так что советую не заниматься ерундой, и увеличить номер версии эдак на 5 единиц.

[Alprog]

Я пишу на VB6 под DirectX 8.1, причём уже давно.

Сейчас в моде стилизация игры под дос.
Ещё моднее сделать полностью дос-игру, что я и пробовал сделать.

И совсем не понимаю в чём тут лол.

[Хакер]

Лол в том, что под DOS мышка, вообще говоря, необязательно должна быть.

Мода -- это такое массовое явление. Его сложно не заметить. Вот, например, была дурацкая мода стилизовать свои интерфейсы под MacOS. И это было буквально заметно.

Моды, заключающейся в стилизации игры под вымерую ОС, я не заметил. Либо это мода распространяется на какие-то узкие круги лиц, либо она каким-то чудесным образом прошла мимо меня.

[Alprog]

Мне следовало взять слово мода в кавычки.
Если уж придераться к словам, то я должен был написать так:

"Стилизация игры под дос - это круто.
Ещё круче сделать полностью дос-игру".

"Круто" - это понятие субъективное, поэтому обсуждать его, я думаю, нет смысла. Лучше вернуться к сути проблемы.

Лол в том, что под DOS мышка, вообще говоря, необязательно должна быть.

Тем не менее, без неё очень плохо.

[Alprog]

Впрочем я уже нашёл пару статей по работе с координатно-указательным манипулятором типа "Мышь"
Надеюсь, это то, что мне надо.

Правка: Получилось! Стало быть, вопрос исчерпан.

[Mikle]

Про СОБЫТИЯ придется забыть. Опрашиваем в цикле СОСТОЯНИЕ мыши с помощью прерываний (примерно то же, что API для Windows).
Вот пример, тут есть и модуль для работы с мышью:

[Alprog]

Mikle
А за пример спасибо, только я уже разобрался.

Почему сразу забыть события? Можно же рассматривать экран, как один объект . Я вот тут поковырялся в чужих примерах, и сделал себе практически события MouseDown, MouseUp и KeyPress (с учётом Shift и кнопки мыши). Пока эти события просто выводят текст, но потом можно будет сделать их отдельными функциями.
Саму проверку, было ли событие, я делаю в теле основного цикла, по аналогии с DoEvents. Вот что получается:
http://slil.ru/25890674

Впринципе, можно сделать круглые спрайты с полной или частичной прозрачностью. Их вращение и масштабирование. Вот только отрисовка изображения по пикселям очень долгая. Даже если рисовать только обновившиеся участки.
Гораздо быстрее закрашивать области на экране, но тогда и детализация меньше.

[Mikle]

Я имел ввиду события уже готовые, а сымитировать можно и ООП на ассемблере , согласен.
Пример посмотрю обязательно, я до сих пор сохраняю интерес к VB1 (QB), хотя тут и нет уже никакой практической пользы.

отрисовка изображения по пикселям очень долгая

Ты в каком режиме экрана работаешь? Если в Screen13, то гораздо быстрее кидать пиксели прямо в память через Poke, предварительно задав DEF SEG = &HA000.

[Alprog]

Ну для тебя в примере врят ли есть что-то интересное

Я колебался между Screen 12 и 13.
Хочется и цветов и разрешение по больше.
Но думаю, всё таки 13 режим выберу.

[Alprog]

Mikle
Poke отлично работает. Сделал спрайты.

Кстати, ты когда делал ещё софтварную версию движка, как делал смешение цветов?

Я попробовал сделать нечто подобное (для полупрозрачности). Насколько я понял 216 из 256 цветов представлены в виде HSV. Где H - 24 оттенка цвета, S - 3 уровня интенсивности и V - три уровня ярокости.

Пытался выбирать результирующий цвет, как среднее этих значений, с учётом того, что оттенки зациклены (то есть самые близкие цвета для 0 - это 1 справа и 24 слева).

Но что-то я сомневаюсь в правильности такого подхода, так как если верить законам смешивания Ньютона, то результирующий цвет должен быть менее интенсивным, чем хотя бы 1 из смешиваемых.

Может перевести в RGB и брать среднее от этих компонент, а потом обратно в HSV?

[Mikle]

Альфасмешение для палитровых цветов - процесс довольно ресурсоемкий. В моем движке ARGB цвет, там все проще, а под ДОС лучше обойтись ColorKey.
А набор цветов в палитре ты можешь сам менять как хочешь.

[Alprog]

Мне хочется уже по полной программе. "А" составляющую, конечно, прикручивать не буду, но некоторые пиксели сделать полупрозрачными (смешивать с фоном в равным пропорциях) думаю можно. По формуле:
R = (R1 + R2)/2
G = (G1 + G2)/2
B = (B1 + B2)/2
Ну или хотя бы затемнение/осветление сделать.

Правда у меня новая проблема
Я чтобы через poke не рисовать всю сцену, храню в 2-х массивах старый и новый кадр, сравниваю их и посылаю через poke только изменившиеся пиксели. Но на второй массив не хватает памяти.
Приходится экономить память на том, чтобы записывать в одну ячейку Integer 2 пикселя. Однако из-за вычисления старшего и младшего байта теряю скорость... Да и потом памяти на спрайты может не хватить. Где брать память?

[Mikle]

Делай динамические массивы, которые задаются redim m().
Можно задать свою палитру из 16 основных цветов, у каждого 16 градаций яркости. При такой системе затемнять\осветлять несложно.
А вот полупрозрачность легче сделать, если задать палитру так - три бита R, три G и два B, можно считать среднее не раскладывая на RGB.
В некоторых ДОС играх, например в DOOM, использовалось несколько индексных таблиц по количеству степеней освещенности, в таблице берется уже номер цвета в основной палитре для текущей освещенности.

[Alprog]

Про RGB что-то не понял.

Если брать среднее между 179 и 111 не раскладывая на составляющие, то получается 145. Это (5, 5, 1) в RGB

Если разложить на отдельные цвета, то получается (5, 4.5, 4):

Код: Выделить всё

    R     G    B            R     G     B                 R       G     B
   101   100   11    +     011   011    11       =       100     100    11
    6     5     4           4     4      4                5      4.5     4


[Alprog]

Делай динамические массивы, которые задаются redim m().

Пробовал, не помогает. Делал так:

Код: Выделить всё

REM $DYNAMIC
COMMON SHARED GR() AS INTEGER
COMMON SHARED GR2() AS INTEGER
COMMON SHARED GR3() AS INTEGER
COMMON SHARED GR4() AS INTEGER

SUB InitGraphic
       REDIM GR(319, 99) AS INTEGER
       REDIM GR2(319, 99) AS INTEGER
       REDIM GR3(319, 99) AS INTEGER
       'REDIM GR4(319, 99) AS INTEGER
END SUB


Такая запись работает, но стоит раскомментировать последнюю строку и получаем Out of memory.

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

[Mikle]

Можно хранить элементы в массивах, как байты, а извлекать через PEEK, чтобы не преобразовывать Integer в два байта, вдвое выигрываешь по памяти, весь экран так влезет в один массив.
Я, когда нужно было много памяти, использовал подкачку из XMS через интерфейсы Himem.sys.
Вообще VB1 сам занимает памяти, видимо, побольше, чем QB, которым пользовался я, попробуй обойтись без форм.

[Alprog]

По-моему PEEK/POKE не самая быстрая операция. Но попробую.

А формы я не использую, так что запросто перейду. Не знаю как там с памятью, но екзешник точно весит меньше.
Правка: всё-таки IDE у QBasic ужасно неудобное. И как я понял, к тому же нельзя подключить одновременно несколько модулей, всё приходится делать в одном.

[Mikle]

Alprog
В QB можно работать с несколькими модулями (не QBasic, входящий в DOS, а QuickBasic). Самый большой недостаток - отсутствие Option Explicit. Я под конец нашел полумеру - задавал DEFSTR A-Z, тем самым почти заменяя Option Explicit.