Если отбросить терминологию из штатного описания, то можно и так: индекс в палитре и содержимое палитры или цвет в видеопамяти и цвет в палитре.
Вид для печати
Если отбросить терминологию из штатного описания, то можно и так: индекс в палитре и содержимое палитры или цвет в видеопамяти и цвет в палитре.
Думаю, нет. Palette index это именно номер цвета в неизменяемой палитре из 256 цветов, иначе физический цвет. Можно было бы назвать 16 цветов отображаемых на экране, также палитрой (задаваемой) и ivagor выше это даже сделал. Но такой подход вносит путаницу, потому что о какой палитре мы говорим можно будет понять только из контекста. Проще считать что палитра одна - это все 256 физически доступных цветов.
Конечно. Я писал про доку в pdf созданную уважаемым @metamporho и выложенную здесь. Это ни в коем случае не критика, в той pdf проделана огромная работа по консолидации информации из разных мануалов, с любовью всё раскрашено, пользоваться этой pdf удобно. Считаю что она ключевая по 06Ц Бейсик. Но есть моменты вводящие в заблуждение и недосказанности, есть орфографические ошибки которые надо вычитывать. Поэтому просто подсвечиваю и предлагаю на обсуждение в теме.
Вопрос. Конструкция ON <var> GOTO/GOSUB ограничена 15 переходами. Плюс сверху ограничена длиной строки 127 символов (по крайней мере для отображения LIST).
Вычисляемые переходы типа M=<номер строки>:GOTO/GOSUB M в 06Ц Бейсик не работают. Как сделать более 15 переходов не вводя пачку IF..THEN ?
Сейчас выкручиваюсь такой конструкцией:
ON <var> GOTO/GOSUB <15 переходов>
<var2>=<var>-15:ON <var2> GOTO/GOSUB <15 переходов>
и т.д.
Но это времяёмкая шляпа.
Количество переходов в ON ... GOTO/GOSUB ограничивает только длина строки. При использовании для программирования на бейсике комбинации редактор+конвертер эта длина может быть очень большой. Пример с ретрограда - в игрушке CORPSE есть 2 штуки ON ... GOTO с примерно 40 переходами.
Возможно, на Векторе действительно принята такая терминология, т.к. Вектор физически даёт на выбор всего 256 цветов из-за ограничений ЦАП. На PC в эпоху VGA палитрой называли только те цвета, которые одновременно могли присутствовать на экране, т.к. говорить о "палитре" в 262144 (или сколько там позволял VGAшный ЦАП) цветов не было особого смысла ввиду того, что каждый из R, G, B компонентов занимал отдельный байт.
Как дело обстояло на PC в эпоху VGA не могу сказать. На Амигах, например, стандартно описывается экран как 32-256 цветов из палитры 4 096 цветов (в зависимости от всяких EHB, etc), а с включённым HAM8 как 262 144 цветов из палитры 16,7 млн. (24 бита). Это общераспространённая терминология и по-русски, и по-английски, например такая табличка:
Вложение 82648
- - - Добавлено - - -
Судя по всему из-за конвертора у меня эти баги и возникают. Причём они плавающие, но на момент написания поста была чёткая картина, что вот есть кусок кода в котором переходы начиная с 16-го не выполнялись. Можно было предположить, что это связано с хранением данных. В результате на какой-то итерации заработало. Да, можно. Да, ограничено только длиной строки. :rolleyes:
- - - Добавлено - - -
Спасибо за оценку и наводку. Свою демку закончил. Решил не использовать эту музыку в демке, так что если кому-то надо для этих целей, прилагаю полную версию "Полёта шмеля" Николая Римского-нашего-Корсакова (СС уже близко): Вложение 82649
Доделал тестовый вариант rtbasic. Это потомок 2.996, остались все ускорения которые там были, найденные ошибки исправлены. Есть и новые оптимизации.
Основное отличие - автоматическое удаление незначащих пробелов, что позволило упростить и ускорить парсер. Это приводит и к некоторой несовместимости и особенностям.
1. Программы с самомодификацией могут потребовать адаптации, если там были пробелы в строках до адреса модификации.
2. Если в INPUT A$ вводите строку с пробелами, то обрамляйте ее кавычками (аналогично для DATA). Но это желательно делать и в версиях 2.5-2.9x, чтобы обойтись без непрошенной токенизации.
Главный недостаток - убраны текстовые сообщения об ошибках, вместо этого можно распечатать файл Errors.txt и положить рядом на столе.
Поддержка принтера, RENUM/AUTO и @ были убраны еще в 2.996, здесь их тоже нет. Для перенумерации можно использовать 2.998, что не очень удобно, но вариант рабочий. В свою очередь rtbasic можно использовать как утилиту для удаления незначащих пробелов. Загрузили с пробелами, выгрузили уже без пробелов.
Есть отличия и в работе пары графических операторов.
Вернул быстрое и компактное рисование линий, которое было в 2.98-2.993.
Немного замедлена сравнительно редкая операция рисования дуг в CIRCLE, зато процедура компактнее.
Указанные два момента приводят к тому, что рисунки в классических версиях и в новой могут не совпадать точка в точку, но я решил пойти на это. Если нужно абсолютное совпадение графики используйте 2.998.
У меня была идея сделать 3D-тоннель по которому летит шмель под эту музыку, но в итоге сначала сделал что попроще (3 эффекта, 5 частей, будет на CC) и память закончилась. Так что дарю идею. Тоннель сделать просто, а спрайты в бейсике я не придумал как делать. Если знакогенератором, то там символы эти 5x8 не склеиваются, полоски по бокам. Не стал дальше голову ломать. Шатать шмеля можно было бы аппаратным скроллером. Если бы для Вектора было что-то типа zxart.ee, я бы туда загрузил и забыл. Кому-нибудь пригодилось бы. :v2_dizzy_army:
- - - Добавлено - - -
Использовал эту сравнительно редкую операцию в хвост и гриву.
У меня всё совпало с 2.997 и 2.998. Визуально не вижу отличий. Я использовал у себя "сравнительно компактный вариант определения версии", чтобы отшить V2.5. Отшил. Заодно отшил и эту версию Бейсика. Проверил, что если удалить определение, то моя программа работает как и задумывалось. Никакой разницы с 2.997/2.998 (судя по описанию думал что её должно страшно перекорёжить).
Тест версии определяет RT как 2.996. Учитывая неактуальность 2.996 (там несколько ошибок, в т.ч. одна довольно серьезная), можно забыть про 2.996 и определять именно RT.
Отличия в линиях и дугах незначительные, но при некоторых условиях они проявляются. Что касается скорости дуг - RT рисует их медленнее 2.998, но все же быстрее 2.5.