В VV в разделе Options...Mouse можно на любую кнопку мыши и даже на вращение колеса повесить обработку любой векторовской клавиши, а вот на перемещение курсора к сожалению нельзя.
Вид для печати
Ramiros, спасибо за информацию - это уже хоть какой-то прогресс...
А если сделать по другому (думаю это совсем просто должно быть для того чтобы включить в эмулятор) - например назовём опцию в эмуляторе "БУДУЩАЯ МЫШЬ" :)
мышь USB которую подключат к Вектору в будущем, но уже сейчас она доступна в эмуляторе.
Так вот (при включении опции "МЫШЬ") эмулятор будет выдавать в определённые ячейки памяти "эмуляции Вектора"
координаты мыши X (0-255) Y (0-255), если курсор мыши вне поля эмуляции то выдаёт 0,0 .... также ещё в другой ячейке памяти будет информация о нажатии левой и правой кнопки мыши. Например это можно заносить в ячейки 7FFD-7FFF. Понятно что при включении этой опции некоторые программы могут не работать, однако эта опция не для тех программ которые написаны в прошлом, а для новых программ, которые можно написать уже сейчас используя эмулятор. К тому же опцию всегда в любой момент можно отключить.
Эта опция - это возможность сделать более удобные программы ведь мышь в своё время была "скачком" в отношении удобства использования программ. И эта опция немного "развяжет руки" некоторым творцам кода :)
В том числе и Бейсик на Векторе уже будет с супер возможностью.
Пока я видел только PS/2 мышь KTSerg-а. Попытки договориться о том, как должна работать какая-то другая будущая мышь пока ни к чему не привели, потому что каждый хочет изобрести именно свой велосипед. Я лично прохладно отношусь к поддержке мыши на Векторе, поэтому пока просто жду, пока один из велосипедов не получит общественное признание и богатую библиотеку поддерживающего его софта.
Не обязательно что эта "будущая мышь" когда-нибудь вообще появится. Скорее всего она будет "жить" только в эмуляторе. Я в большей мере имел ввиду иметь возможность уже сейчас создавать программы для Вектора, в которых можно удобно что-то делать с помощью мыши. Скорее эта опция не "будущая мышь", а "виртуальная мышь".
Продолжаю подбирать крошки за комодорщиками. Подсмотрел у того же чувака (это не он нашел, он в данном случае популяризатор) такую оптимизацию:
вместо
IF сравнение1 AND сравнение2 THEN
заметно быстрее делать
IF сравнение1 THEN IF сранение2 THEN
Фишка в том, что IF IF быстрее даже если выполняются оба условия.
Пожелания к авторам конвертеров BAS/CAS<->TXT
1. Простое - выдавать лог с номерами строк, длина которых больше стандартной допустимой в бейсике.
2. Посложнее - реализовать перенумерацию. Тогда с чистой совестью можно было бы выпилить из бейсика RENUM и использовать освободившееся место для чего-нибудь более полезного.
3. Сложное - расширить диапазон поддерживаемых бейсиков. Кроме 2.5-2.99 есть куча потомков MS Basic 3.2 на множестве компьютеров, у которых формат программы одинаковый, но различаются коды токенов и файлы-контейнеры. Или вынести из программы в некие редактируемые конфиги коды токенов и описания контейнеров или хотя бы поддержать некоторые другие бейсики. Сейчас например в РЕТРОГРАДе добавился специалист, но нет средств для конверсии его программ. Редактировать в самом бейсике конечно можно, но это значительно менее удобно.
ivagor, привет. Думаю смогу добавить, нужно только знать какие операторы (все случаи) работают с номерами строк. Помню в каких-то бейсиках можно было писать if ... then number, в некоторых были on error goto. Иметь бы такой список - без проблем бы добавил в свой конвертер перенумерацию. Насчёт других бейсиков нужно глянуть как там обстоят дела с пробелами между операторами.
Список токенов, после которых RENUM проверяет наличие номера строки
88h - GOTO
89h - RUN
8Bh - RESTORE
8Ch - GOSUB
A1h - THEN[свернуть]
С пробелами во всех потомках MS бейсика 3.2 все одинаково, т.е. как в 2.5. Отличаются коды токенов и форматы файлов, да и то многое совпадает. Тут надо ждать инициативы от желающих добавить тот или иной бейсик. Требуются соответственно список токенов (код - оператор/функция) и формат файла.
- - - Добавлено - - -
Кстати, желательно еще добавить функцию автоматического удаления всех незначащих пробелов и (наверно отдельно) комментариев. В составе сервисной утилиты для РК были такие функции.
К этому списку я бы ещё добавил:
CEh -- EDIT
CFh -- DELETE
98h -- LIST
D8h -- LLIST
как команды, использование которых не возбраняется в тексте программ на бейсике.
- - - Добавлено - - -
Да, и стоит упомянуть, что GOTO и GOSUB могут иметь несколько номеров строк в виде списка в случае их использования с оператором "ON [выражение] GOTO/GOSUB".
Привет всем...
Вот нарисовал я спрайты на Спектруме для конкурса...
Как их через Bload - на Вектор загрузить?
На Спектруме формат - name.$C...
Тут появляется вопрос про формат данных сделанный на Спектруме, как они расположены ?
Для Вектора в игре сколько будет использовано плоскостей ?
Если всё соответствует Векторовскому расположению графики, то похоже самый простой способ
зайти на "Прекрасный Ассемблер" вот пример использования
https://svofski.github.io/pretty-808...BkYiAxLDIsMyw0
и там вставить свои данные
.org $8000 (здесь указываем нужный адресс куда будет загружаться картинки)
db 1,2,3,4..........(здесь наша графика)
и выгрузить их кнопкой "TAPE" в формате .CAS
далее в своей основной программе через BLOAD"" загружаем то что записали через TAPE в "Прекрасном Ассемблере"
Далее (кадры анимации например) командой GET запоминаем данные с экрана
(при этом запоминать можно из одной плоскости или из всех 4-х это регилируем командой SCREEN 2,N)
Далее стираем экран и выводим меню игры
и далее можно использовать PUT, выводя запомненую графику на экран.
В таком случае можно использовать следующий вариант:
10 SCREEN 2,15:CLS:SCREEN 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0:REM очистка всех плоскостей видео ОЗУ и гасим все цвета
20 HIMEM &9FFF:REM память для программы и данных на Бейсике увеличивается до 24 Кб
30 CLEAR: DIM A(NNN),B(NNN),C(NNN),......: REM инициализация места хранения графики
40 SCREEN 2,0:CUR 24,1:BLOAD "":REM загружаем графику в экран
50 SCREEN2,7:REM запрет обращения к плоскости 8000-9FFF
60 PLOT 0,0,2:GET 16,16,ADDR(A(0)).......: REM запоминаем с экрана в память графику (кадры анимации например)
65 CLS
70 SCREEN 0,0,0,1,2,3,4,5,6,7,0,0,0,0,0,0,0,0:REM установка палитры цветов под режим SCREEN 2,7 вместо 1-7 цвета палитры.. в итоге восемь цветов вместе с фоном
110 REM ВЫВОД МЕНЮ
Есть предложение продолжить обсуждение деталей преобразования картинок в теме например про "Картинки для вектора" или в теме конкурса "РЕТРОГРАД".
Обновил "Новое описание Бейсика" (добавил таблицы для оператора SCREEN, исправил всякие ошибки....)
скачать здесь https://zx-pk.ru/threads/30566-bejsi...=1#post1191025
metamorpho, таблицы красивые, информативные, здорово. Если возможно предлагаю "Таблицу кодов физических цветов" (SCREEN 0) переделать как у b2mа
И желательно бы еще пробежаться по тексту, осталось много мелких ошибок OCR. Если соберусь, то составлю перечень, но не могу твердо пообещать.
ivagor, а ведь таблицу b2m-а можно дополнить текстом с кодами цветов. Я имею ввиду программно.
Можно любую картинку, в т.ч. и коды цветов, но почему-то никто не сделал, наверно не чувствовали необходимости. clrs это образец стиля b2mа, самодокументированная - коды цветов от 0 до 255 в порядке чтения слева-направо и сверху-вниз.
ivagor, да согласен у b2m более лучший вариант - нагляднее и практичнее если использовать оттенки цветов. Поставлю себе в список на обновление.
Насчёт ошибок - да их там наверно ещё хватает, но я ошибки скорее всего сам отловлю вскоре, а вот если бы ты посмотрел на описание команд Бейсика и сказал мне где исправить (или дополнить) их неточное описание которое есть в оригинале - то было бы здорово.
Например недавно увидел в описании команды COLOR "цвет изображения","цвет фона","цвет бордюра" и в "цвет изображения" в оригинале написано от 0 до 255, но ведь их всего 0-15.
Вот это было бы здорово...
Да мне тоже, но вроде и так было понятно, где какие цвета. С напечатанными номерами быстрее и удобнее, но вряд ли программу использовали бы как справочник, хотя кто знает.
Это сложнее, тем более обещать не могу, но если что, то конечно выложу сюда.
Про "цвет изображения" в COLOR - там от 0 до 255 для символов. Младший полубайт - цвет символа, старший полубайт - цвет фона символа. А для графики от 0 до 15, да.
Вот это открытие, я этого не знал. Странно почему создатели оригинального руководства по Бейсику не разъяснили про старший и младший полубайты, а просто написали: "<цвет изображения> - это арифметическое выражение, определяющее математический цвет изображения и подложек под символами."
Посмотрел, может в уроках бейсика про это писали, но нет. Кстати, имеет смысл упомянуть серию уроков бейсика в руководстве. Например в 8 уроке самая векторозависимая информация (знакогенератор, ячейки таймера и т.п.). Ошибки там тоже есть, никто не идеален.
Так или иначе, но программисты про цвета символов знали и в некоторых программах использовали.
Ещё одно обновление "Нового описания Бейсика".
Решил не откладывать в долгий ящик и прошёлся орфографией по тексту и исправил штук 50 (или больше) OCR ошибок, также добавил инфо про уроки по Бейсику и
заменил таблицу цветов в операторе SCREEN и ещё добавил дополнительное инфо по команде COLOR.
скачать здесь
https://zx-pk.ru/threads/30566-bejsi...=1#post1191025
metamorpho, в главе "Некоторые важные моменты" заметил такую фразу:
В описании CLOAD указано ограничение в 6 символов, но, насколько я помню, на самом деле имя может быть до 127 символов, и при чтении выводится полностью, как было до этого записано, т.е. не игнорируется. А при явном задании имени при чтении по команде CLOAD "<имя>" можно задать только первые несколько символов, тогда будет загружена первая запись с совпадающим началом названия.Цитата:
Имя загружаемой программы ограничено до 11 символов, остальные игнорируются.
Есть ограничение программы Монитор-Отладчик при чтении данных, записанных в Бейсике по BSAVE, там да, до 11 символов, хотя сам Бейсик нормально принимает в BLOAD до тех же 127, но Монитор не игнорирует имена больше 11 символов, а выдаёт ошибку... Или указанное ограничение относятся к программам-конверторам в bas и cas?
И ещё, в "Разном полезном":
Эта функция явно указана в описании команды PRINT, если что...Цитата:
Функция @ преобразует dec->hex. <...>
Очередное обновление "Нового описания Бейсика". Ещё понаходил (и подсказали) несколько ошибок OCR, также привёл в порядок (выровнил) кавычки и некоторые строчки, а то они всякие разные были. Сделал (по совету) для примеров кода моноширинный шрифт, однако мой PDF вьювер отображает их некорректно (кернинг - расстояние между символами нарушается буквы слипаются), я так и не понял почему поэтому сделал откат и вернул старый шрифт.
скачать здесь
https://zx-pk.ru/threads/30566-bejsi...=1#post1191025
svofski нашел еще один трассировщик лучей, а я адаптировал. Время рисования за счет оптимизации и использования 2.991 сократилось с 17+ часов на спеке до 4 часов 45 минут на векторе. Нельзя сказать, что это однозначный шаг вперед по сравнению с сферами. Там отражения и при более низкой сложности картинка (на мой субъективный взгляд) получается круче. Зато у этого трассировщика за счет выбора цветов и штатного дизера большой потенциал портирования на разные компы (со сферами намного сложнее). Для примера портанул еще и на корвет.
Вложение 80227
Upd 18.02.2024: rt9v06c - время рисования сократилось до 4 часов 3 минут (basic 2.991), картинка не изменилась.
Upd 16.03.2024: rt12v06c - 3 часа 23 минуты 10 секунд (в 2.993)
Еще изменил дизер. Слева старый, справа новый.
Вложение 80226Вложение 80511
Upd 03.05.2024: rt14v06c - 3 часа 17 минут 31 секунда (в 2.995)
Upd 20.05.2024: rt15v06c
2.5 - 8 часов 33 минуты 39 секунд
2.891 - 7 часов 4 минуты 2 секунды
2.995 - 3 часа 9 минут 44 секунды
2.996 - 2 часа 56 минут 37 секунд
Все уже было - трассировщик(и) для амстрада cpc. Сферы с отражениями, шахматное поле - явно источник вдохновения был то же, что и у меня.
Почитал, что пишут умные люди и оптимизировал трассировщик без отражений (только векторовскую версию, корветовскую можно оптимизировать по аналогии).
А вот еще сферы с отражениями и шахматной доской на bbcbasic. Получается как минимум на 3х 8-битках есть подобная штука: CPC, BBC и 06Ц.
Один из вариантов, как в крайнем случае сэкономить немного памяти. Если в игре элементы игрового поля (стены, лестницы, предметы и т.д.) разных цветов, то их можно попытаться разнести в разные плоскости. Если они двухцветные, то можно одним GETом запомнить в памяти сразу 4 картинки:
1. SCREEN2,15
2. Нарисовали в одной позиции, но в разных плоскостях соответствующие картинки
3. GET
А потом когда нужно вывести один элемент - SCREEN2,1:PUT. Когда второй - SCREEN2,2:PUT и т.д. Понятно, что можно комбинировать и например 4+4 цвета или 2+8 цветов. Не очень желательно использовать это для движущихся объектов, т.к. SCREEN2 не самый быстрый оператор (но и не самый медленный).
вариант 1.
D=148:G=12
....
34 SCREEN 0,0,0,D,G
....
GOTO 34
вариант 2.
....
34 SCREEN 0,0,0,148,12
....
GOTO 34
Какой вариант будет выполняться быстрее ?