Бейсики для Вектора-06Ц и клонов

[ivagor]

Есть очень простой вариант использования микрософтовского компилятора BASCOM в сочетании с графикой (правда специфической - ч/б высокого разрешения) - надо запускать откомпилированную программу в CP/M-39. А для вывода графики используем POKE в диапазоне &HA000-&HDFFF. Вариант очевидный и простой, но неудобный, наверно поэтому таких программ не написали. Но надо отметить, что при использовании целых компилятор покает весьма шустро.
Попутно выяснил, что МикроДОС 28 при наличии (и только при наличии!) кваза прячет видео под него, как и "обычные" досы.

[ivagor]

Я тут подумал - а зачем откомпилированной BASCOMом программе дос, если она не пользуется его возможностями? И действительно, берем откомпилированную программу после этапа инициализации, меняем два байта начального перехода и все, можно запускать из начального загрузчика (дос или эмуляторы дос или кваз не нужны, только голый вектор!). Чтобы запускать из любого окружения, а не только из начального загрузчика, надо добавить программирование палитры, но для чистоты эксперимента я не стал.
В качестве подопытной программы выступил многострадальный рейкастер. После почти полного перевода на фиксированную точку текстуры стен несколько расколбасило, зато рисует за 32.3 секунды. И таким макаром можно пользоваться BASCOMом не только для вектора.

[ivagor]

Хорошая новость - svofski недавно завел в картотеке карточки для бейсиков 2.891 и 2.99x, за что ему большое спасибо!
Теперь про 2.994 (финал ветки 2.99x, если не найдутся ошибки). Начиная с 2.98 заменил рисование линий на быструю и компактную процедуру. Но у этой процедуры есть недостаток - она рисует "стандартные" линии, а в 2.5 (и до 2.97 включительно) при маленьких наклонах было нечто нетрадиционное. И некоторые программы пользуются своеобразием линий при маленьких наклонах, поэтому скрепя сердце решил вернуть линии в духе 2.5. Максимально оптимизировал по сравнению с 2.5, но все равно нормальным линиям несколько уступает.
Для "старых" линий не хватало места, поэтому пришлось поджать и микроскопически замедлить (в некоторых случаях) умножение. Замедление (там где оно есть) порядка долей процентов, невооруженным взглядом незаметно.
Если все будет хорошо, то планирую начать ветку 3.x, где наконец уберу все, что считаю лишним (принтер, RENUM), верну быстрые линии и умножение, сделаю некоторые оптимизации.

[ivagor]

Извините, еще одна версия в ветке 2.99x
Началось с того, что полез проверять высказанное на стриме конкурса предположение, что вывод листинга с длинными строками, вызывающими переполнение, приводит к порче бейсика. У меня не получилось испортить бейсик длинными строками и не придумал, как это сделать, если у кого-то получилось, то напишите, постараюсь разобраться и исправить. Зато заметил, что в отличие от 2.5 в 2.9+ не получается редактировать и выводить на листинг без сообщения о переполнении строки по 127 символов. Сейчас авторы набирают и редактируют тексты вне бейсика (и получаются строки по тысяче символов), поэтому никто не замечал, поправил этот момент.
Дальше больше, заметил, что можно сократить фрагмент связанный с автоповтором на несколько байтов, потом еще нашел что оптимизировать по размеру. В итоге вернул скорость умножения на уровень 2.993. И линии немного ускорил, но до показателей нормального Березенхэма не дотянуться. Так и не нашел, в отличие от CIRCLE, откуда авторы 2.5 позаимствовали такие своеобразные линии.

[ivagor]

Посмотрел, как lafromm31 проходил CORPSE и под впечатлением попробовал оптимизировать рисование уровней. Время рисования заставки и первого уровня сократилось с 24-25 секунд до 15 секунд. Полное прохождение модифицированной игры не проверял, прошел только два уровня. Если автор против, то уберу этот вариант.

[ivagor]

Вычислениями в бейсике никто особо не увлекается, но с исторической точки зрения может быть интересно. Оказывается в вариациях микрософтовского basic8k крайне неэффективно реализованы преобразования десятичных дробей и экспоненциальных форм из символьного представления в двоичное. Положительные степени (например 1E10) побыстрее, а вот дроби (например 1.23) и отрицательные степени (например 1E-10) совсем плохо. Крайний клинический случай это когда длинная дробь с близкой к максимуму отрицательной степенью, например 1.2345678E-38. В 2.5 время преобразования такого числа - 0.2 секунды! И это на одно число, т.е. в секунду можно сделать всего 5 таких преобразований. Рецепт лечения тут один - если подобные константы активно используются, например в цикле, то надо до цикла поместить их в переменные. И у меня есть пример на эту тему - трассировщик с дизером, там в двух местах использовалась константа 1E10. После переделки на переменную ускорение на 6 минут.

[Advertiser]

[ivagor]

Посмотрел ролик про БК и мне там понравилась "объемная" синусоида на бейсике. Сначала повторил в бейсике-корвет, а потом подумал что с цветом лучше и сделал для 2.5+. Рисует быстро, 13.9 секунды в 2.5 или 7.1 секунды в 2.995

[ivagor]

Бейсики 2.5+ унаследовали от РКшного микрона неприятную особенность - после печати каждых 128 символов (если в конце PRINT стоит ";") происходит непрошеный перевод строки. А svofski нашел, когда это приводит к ошибке, но тот случай легко правится на уровне программы на бейсике. В качестве примера приложил простейшую программу, которая печатает "лабиринт" (на C64 гораздо больше похоже на лабиринт, т.к. там символы могут занимать все знакоместо без зазоров по горизонтали и вертикали). Если хочется без паразитных переводов строки, то можно попробовать эту программку в Basic-M
Это не все неприятности, касающиеся печати символов на экране. Дальше вспомнил, что функция POS() не соответствует описанию. Она не дает позицию курсора в строке, она возвращает номер напечатанного после перевода строки символа по модулю 128. Совпадение с позицией курсора будет при выполнении условий:
1. Был перевод строки и после этого печать с начала строки.
2. Напечатано не более 42 символов.
Это уже недоработка Темиразова и Соколова при адаптации микрона на вектор, в оригинальном РКшном POS() работает правильно. Проблема усугубляется тем, что авторы бейсика 2.5 в паре мест сами используют эти данные как горизонтальную позицию курсора.
В одном месте от РКшного бейсика-микрон осталась проверка которая не работает на векторе, т.к. не поменяли 64 символа в строке на 42.
В другом, там где обрабатывается запятая в PRINT, поменяли, но не совсем правильно.
Совокупность перечисленных причин приводит к довольно своеобразному "паттерну печати" при активном выводе символьной и числовой информации на экран с использованием разделителей "," и ";". Даже не знаю, стоит ли все это править в 2.9+ или считать все это фичами, а не багами. Или оставить доработки до гипотетического 3.0.
И еще нашел ошибку в 2.995 - не совсем корректно обрабатывается клавиша F5, это поправлю.

[metamorpho]

....Даже не знаю, стоит ли все это править в 2.9+ или считать все это фичами, а не багами. Или оставить доработки до гипотетического 3.0.
.....

На мой взгляд - пусть баги остануться фичами.
Ждём Бейсик 3.0 - версия без оглядки на совместимость со всеми предыдущими версиями

[ivagor]

3.0 - версия без оглядки на совместимость со всеми предыдущими версиями

Настолько экстремально все же не будет, считаю очень важным, чтобы классические программы работали. Пусть будут мелкие непринципиальные отличия в каких-то моментах, но от базы векторовских программ на бейсике отказываться никак нельзя.
Вот кстати один из спорных для меня вопросов - линии.
Слева "векторовская классика", справа - вариант который был с 2.98 по 2.993

Большинство бейсиков (да и практически все графические библиотеки) рисуют как справа. Но в некоторых классических векторовских программах своеобразные линии используются. Значимый пример - РЕКЛАМА, там можно заметить отличия на рисунке "киберзверя" ("киберволка"?). В disaster PPC тоже заметны различия в рисунке космического корабля. И пока полностью не определился, что важнее - сохранить идентичность рисунков или выиграть в скорости и размере процедуры.