Пролистал книжку, исправил несколько страниц (21, 39, 79):
https://hdd.tomsk.ru/desk/trjoyosv
-=-
Интересно, что авторы говорят о трансляторе Бейсика размером 60 блоков, но с цветным курсором. Цветной (вместо мигающего подчерка) курсор был в моде бейсика от ALV. Но размер там был > 60 блоков. Вероятно, авторы книжки располагали какой-то ранней версией этого мода.
-=-
На 99 странице столкнулся с внутренним удивлением: тут авторы явно оказались несообразительными (несмотря на успешное решение других, гораздо более сложных задач):
"Задание: ...переделайте программу-тренажёр таким образом, чтобы секундомер не останавливался при нажатии на пробел...
Решение: ...поскольку оператор печати является медленным, по сравнению с другими операторами, практически любое нажатие на пробел останавливает программу..."
На самомо деле, кажется, даже документация на агат не скрывает, что пробел - это задержка вывода на экран. Просто, чтобы можно было успеть прочитать то, что компьютер быстро выводит, проматывая экран вверх.
Это было принято в всех ОС Агата: процедура перевода курсора на следующую логическую строку ("\n" - либо скроллинг либо переход на следующую физическую строку экрана) проверяет порт клавиатуры и если там висит код пробела - удаляет его, ждёт его повторного появления, после чего удаляет его вновь и продолжает работу.
Соответственно, избавиться от задержки программы при нажатии пробела можно гораздо проще, чем предлагают авторы (они там написали целую процедуру для прямого вывода в видеопамять): достаточно было в конце оператора PRINT добавить символ ";". Это "международный" ход, известный, пожалуй, всем версиям бейсика, который требует, чтобы PRINT не переводил строку в конце вывода (и да, в доках на агатовский бейсик это тоже упоминается и в конце этой книжки тоже).
( Ну а перевести курсор, при необходимости, можно операторами VTAB/HTAB. Разве что скроллинга экрана от них не получить. Но проблема, которую подняли авторы книжки, характерна для программ, использующих полноэкранный пользовательский интерфейс, а в нём скролинг, обычно, не используется. )
-=-
Стр 304: а вот тут у нас рождение мифа:
"Известная ненадёжность клавиатуры...может приводить к тому, что символы, находящиеся на экране и символы, попадающие в буфер клавиатуры, иногда не совпадают."
Увы, как бы клавиатура не ломалась, но её влияние на буфер ввода не больше, чем на содержимое экрана.
-=-
Стр 337: Wow! Ещё при моей жизни: человеческое и без ошибок описание оператора Wait!
-=-
А вообще, читая очередную книжку по основам компьютерной графики (а недавно ещё и почитав какой-то форум в инете, где преподаватели школ, ныне сидящие под линухом, интересуются: как бы так перетащить графические программы из книжек начала 90-х на Turbo Pascal'е в среду линуха (/в глубоких скобках замечу: да, это возможно, но прямой перенос - это плохая практика, по сути, опускающая графику линуха до уровня VGA/DOS/)), мне тут подумалось: а ведь не только в нынешних, но и в гораздо более старых, реально используемых прогах, вся эта графика почти никогда не используется.
Почему ?
Впервые я понял, что все эти построения точек, прямоугольников и линий имеют мало практического смысла, когда разбирался в возможностях редактирования уровней и - вообще - рессурсов игры Doom ][. Это было ещё в конце 90-х. Я был удивлён, когда среди спрайтов игры увидел не только фигурки монстров, игрока, оружия, боеприпасов также и все выводимые картинки с мордой игрока в нижней части экрана, а также и весь алфавит (знакогенератор), которым выводился как статус игрока так и экранные меню игры. Там же были и начальные/промежуточные/финальные экраны игры.
Действительно, а зачем этой игрушке рисовать отдельные линии, прямоугольники, круги? Допустим, прямоугольник, выраженный одним оператором bar(x1, y1, x2, y2) - это гораздо компактнее, чем растровая картинка. Но зачем он такой вообще нужен на экране? На экране, даже если вы рисуете какой нибудь игровой элемент, да ещё и в цветном режиме, гораздо проще вывести растр этого элемента - т.е. готовую картинку, чем старательно, комбинируя всякие COLOR= PLOT, рисовать что-то подобное ей. И дело даже не в скорости вывода, а просто в том, что растровую картинку вы можете отредактировать в любом графредакторе, визуально, т.е. сделать это может даже не программист, а именно художник или дизайнер.
Вашей программе не нужны спрайты, а просто нужно красиво вывести таблицу, например, чисел ?
И вы обдумаете, как операторами LINE сделать разграфку ?
Да давно уже написаны процедуры/библиотеки/объекты, которые сразу могут изобразить это всё. И вы даже знать не будете, как там рисуются тени и прочие красивости.
А если даже полезете внутрь, то обнаружите там столько слоёв рисования, что голова кругом пойдёт.
Потому что, наверняка, вывод будет не в пикселях, а в каких-нибудь процентах от размера окна или в каких-то ещё условных величинах. Под вашей прогой будет работать библиотека Cairo, она будет передавать вывод в куда нибудь в DirectX, тот будет передавать это всё драйверу видюхи, она аппаратно тоже что-то может пересчитать от себя.... В той же javascript банальный метод (или функция? или как там его принято называть ?) lineTo рисует не по пикселям экрана, а по условным виртуальным точкам, которые только при масштабе документа 100% соответствует по размеру физической точке (но, в силу работы алгоритмов сглаживания, эта точка может быть размылена на нескольких соседей).
Векторные шрифты рисовать через line() ? Всё уже есть и очень давно успешно работает.
Ну ладно, допустим, это всё - нынешняя реальность, в 80-е всё было по другому и вечность была поосновательнее. Но ведь вот что характерно: а в B- игрушках Агата разве точно также не использовались уже именно спрайты, а не отдельные линии ? Ну я допускаю, что сетка поверхности планеты в HORIZON реально расчитывалась как линии, но ведь остальное -то во всей этой игре - спрайты. В SHAMUS - наверняка - всё спрайты. Во FLY линия одна - остаток топлива (или времени до конца игры). Musiceditor - нотный спрайт, наверное, линии. Остальное - спрайты.
И вот я думаю: так может не так уж плохо, что в агатовком бейсике не было оператора рисования окружности ? Да и прямоугольника тоже ? Может быть нужно было как-то вообще по другому строить обучение графике ? И даже не столько на Агате, в школе, сколько на PC, в ВУЗах ? Почему все так уцепились в эти линии, прямоугольники ? (/В ещё одних скобках замечу: механника спрайтов, например, в том же Turbo Pascal существовала. Тормознутая, но всё таки она была: PutImage/GetImage. Но её не рассматривали как основу работы, а больше как прикольный, непонятно-зачем-нужный инструмент/)
-=-
На 233-й странице есть прекрасная фраза: "Далее мы увидим, что некоторые файлы одновременно являются и программами, и данными по отношению к другим программам. Из этого следует, что деление файлов на программы и данные несколько условно".
В общем-то, любой системный и просто опытный программист это знает.
Но в учебных книжках (во всяком случае книжках 80-90х годов) очень часто очень упорно пытались вводить как деление файлов на данные и программы, так и другие, не очень полезные, деления. Например, делить софт на на пользовательские программы и утилиты. Когда читаешь это, сперва реально начинаешь думать что пользовательские программы - это всё понятно, а утилиты - это что-то из другого измерения. И только со временем понимаешь, что деление это - чисто условное и никакого технического смысла не имеющее.
-=-
Ну а всё прочее в этой книжке интересно, забавно и - я бы даже сказал - увлекательно :)
Так что присоединяюсь к предыдущему оратору: жаль, что у меня не было такой же книжки где нибудь в конце 80-х.
Я тоже в те годы увлекался агатовской графикой.
ba.rar
