Deja Vu #0A 30 сентября 2000

Пресса

__________________________________________

(C) Cardinal/PGC/BDA
__________________________________________

     ТЕОРИЯ ЖУРНАЛОСТРОЕНИЯ

                  part 2

                    - Может хоть эти скалы
                      его остановят?
                    - Вряд ли...

                                (C) SPRITE

   Ну, для  начала привет, уважаемые чита-
тели! Меня побудили накорябать данную ста-
                  тью  несколько серьезных
                  обстоятельств.Во-первых,
                  хочется  изложить  мысли
                  Daniel'а в своей  интер-
                  претации, т.к. его  ста-
                  тья, помещенная  в  5-ом
                  номере, уже устарела, да
                  и информация,которая бы-
                  ла в  пункте "ze оптими-
                  зация" является, как бы,
                  не совсем "ZE" и не есть
рулез.Чем сразу ехидно воспользовался ува-
жаемый  ERASER/Delirium Tremens, дав в Fu-
neral 1.5 свой  подход к данному вопросу.
   Во-вторых,дабы не упасть в грязь лицом,
мне хочется полностью  опровергнуть  и  те
сведения, потому что они тоже не есть  ру-
лез.
   В-третьих, мной, не без помощи MAX/CBX/
BDA, весь код журнала Deja Vu был  полнос-
тью переписан с нуля еще с 9-ого номера, а
в этом номере я умудрился поддержать  ани-
мацию, и как енто дело стало выглядеть, вы
видите сами. В связи с этим  читайте далее
мою версию "ТЕОРИИ ЖУРНАЛОСТРОЕНИЯ". В хо-
де своего повествования я приоткрою  внут-
реннее содержание нашего журнала,чтобы вам
было понятнее. Итак, поехали...

         Бредовая идея.

   Допустим, вы  захотели  выпускать  свой
журнал. Что  для  этого  нужно. Для начала
очень сильно захотеть, потому что без  же-
лания и с сильной надеждой на получение  с
него финансовой прибыли  у  вас  ничего не
получится. Особенно, если вы и впрямь меч-
таете получить с него денежки:-) Хе-хе, не
те времена, братишка! Спектрум  уже  давно
андеграундная машина, и почти никто не же-
лает платить за софт бабки. Все  уже давно
привыкли получать софтинку в почтовом ящи-
ке и бесплатно. Ну, что ж, я  вижу  вы уже
наморщили носики, мол, нафига задарма нап-
рягаться лишний раз,а вдруг народу не пон-
равится, так сразу зафакают, нафиг (бывает
и такое, не все коту масленница, бывают  и
постные дни). Допустим, получение денег не
является целью, тогда все проще.
   Итак,вы все равно хотите делать журнал,
тогда необходимо подобрать команду,которая
будет непосредственно заниматься кодингом/
графингом / музингом / текстингом и просто
критингом новоявленного издания. Сразу даю
совет, если в вашей команде менее  полуде-
сятка человек, завязывайте  с потрясающими
проектами типа: Звездное Наследие 3; Белый
Удав; НЛО 3; Дети подземелья; ELITE 4; Лю-
ди как Боги, и  тому  подобное, потому что
у вас все равно не  будет  хватать времени
на их реализацию. Не правы те,кто говорит,
что журнал делать легко. Его  делать очень
легко, а  вот  сделать  достойный журнал -
- большой напряг.
   В вашей команде может не быть музыканта
или художника, главное, чтобы  был хороший
кодер  и  человек  с  отличием по русскому
языку в  роли главного редактора. А музыку
и графику вам сделают посторонние люди, не
бесплатно, конечно же... хотя, как догово-
ритесь:-)
   Самое время подумать над названием  ва-
шего творения. Нужно, чтобы оно было лако-
ничным, легко произносилось, не  нагружало
мозги, подходило по смыслу к самому содер-
жанию. Вы можете  возразить, что  название
Deja Vu не подходит по смыслу к содержанию
нашего журнала. Вы правы, но зато  оно ла-
конично и легко в произношении. Вообще,De-
ja Vu в переводе с  французского  означает
дословно "уже виденное", учебник по парап-
сихологии гласит, что "дежа вю" это  фено-
мен, когда человек, оказавшись в новой об-
становке осознает, что он уже там уже ког-
да-то побывал: астральное  или  ментальное
перемещение во времени и пространстве(зна-
комые предметы, запахи, ощущения). А с ва-
ми такого не бывало? Приходишь куда-нибудь
в новое место, или просто сидишь  дома  на
диване, и вдруг раз, и понимаешь, что где-
-то это видел (чувствовал), но  не помнишь
где, видимо во сне... Ну, я отвлекся. Наз-
вание вы придумали, приступайте к работе.
   В журнале важно все, даже мелочи. Опре-
делитесь сразу, как будет внешне выглядеть
ваше детище. Не стОит подражать другим из-
даниям, сделайте по-своему, оригинально  и
со вкусом, уверен, user не останется  рав-
нодушным. Далее информация будет по  пунк-
там, чтобы вы не запутались.

           Интерфейс.

   На пороге 21 век,поэтому избавьте поль-
зователя от необходимости выбирать  пункты
меню по цифровым клавишам, как в  Спектро-
фоне.Очень желателен стрелочный интерфейс.
Сделайте так,чтобы двигать стрелочкой мож-
но было как можно бОльшим количеством уст-
ройств: кнопки, синклер  и кемпстон джойс-
тики, кемпстон мышка, если  есть желание и
возможности, то можно попробывать  опраши-
вать AY-мышку, хотя это нестандартно. При-
чем, опрос всех устройств должен  происхо-
дить параллельно.Горячие клавиши тоже дол-
жны присутствовать, дабы  ускорить  доступ
пользователя к определенным функциям. Пре-
дусмотрите во  всех  действиях  отмену  по
клавише BREAK/EDIT: во  вьювере - выход  в
оболочку, в оболочке - откат на предыдущее
окно, во время загрузки данных - вынужден-
ный  останов (чтобы, например, при  плохом
чтении сектора, лоадер не "зависал", пыта-
ясь  его  считать).  В Deja Vu,  например,
можно прервать практически любую  операцию
с диском. Будет очень прикольно, если вы в
Set Up'е сделаете REDEFINE KEYS для  горя-
чих клавиш и даже для  клавиш  управления,
чтобы user мог их задать, как  ему удобно.
Между прочим,такое нигде не встречалось:-)

            Память.

   Забудьте про 48 килобайт,этот объем уже
давно умер. Сразу  ориентируйтесь  на  128
килобайт и  выше. Перед  запуском  журнала
обязательно тестируйте память  на  наличие
оной. Если в  машине, на  которой  запущен
журнал более 128 килобайт, постарайтесь ее
использовать, чтобы зря не пропадала. Нап-
ример, создайте RAM DISK, в котором держи-
те  дополнительные  сервисные  возможности
(различные шрифты, хранилки  экрана, наво-
роченный вьювер, движок анимации(???) и т.
д.) или даже частично  или  полностью  все
статьи, чтобы их потом не приходилось гру-
зить с диска.
   Как  быстро  и  легко сделать поддержку
RAM DISK'а для хранения там статей в  упа-
кованном виде? Очень  просто. Допустим, вы
протестировали память,и она оказалась объ-
емом 256/512/1024/...килобайта. Тогда соз-
даем  небольшую  табличку  с перечислением
доступных логических страничек памяти.Пос-
ле этого грузите в память  с  диска по по-
рядку те дорожки, в которых находятся ста-
тьи. Не важно, что в память все не  помес-
тилось, важно запомнить, на какой  дорожке
(на диске) процесс остановился. Далее,лоа-
дер должен быть такой: если на  входе трек
и сектор попадает в тот  диапазон, который
был уже загружен в память, значит  переки-
дываем информацию из  RAM DISK'а. Ваша пе-
рекидывалка данных из расширенной памяти в
обычную должна работать  с  блоками по 256
байт через буфер, говоря  простым  языком,
она должна эмулировать работу  с дискетой.
Программулька эта столь коротка  и  прими-
тивна, что приводить ее мне влом, да  вы и
сами без меня знаете, как все сделать.
   Очень важно правильно расположить  дан-
ные в памяти. В Deja Vu с адреса 39800  по
#FFFF (банк 0) располагается текст  в  не-
прерывном  виде. До  текста с адреса #6000
сидит  сам  код  с табличкой прерываний. В
1-ом банке  плейер музыки и сама музыка, а
также пара фонтов. В 3, 4 и 6 банке  нахо-
дится графика в виде спрайтов, которую  вы
видите в статьях. Остается только 7-я бан-
ка, в ней сидит еще один фонт, background,
спрайты стрелочек и, конечно, дополнитель-
ный экран. В 256-ой  оболочке  все  также,
только в банках  с 8 по 15  располагаются:
раскрученный фреймовый скроллер с  раскру-
ченными шрифтами, хранилка экрана, различ-
ные буферы и прочая гадость, не  поместив-
шаяся в основную  память. Заглянув  в  код
других электронных изданий, я окончательно
убедился, что только в Deja Vu под  статьи
с графикой выделяется такой  большой объем
памяти: полностью  4 банки + 9352 байта, а
в сумме 74888 байтов памяти! И это не счи-
тая еще одного  банка  с  музыкой. Поэтому
просто замечательно  смотрятся  такие ста-
тьи, как "Демосцена" от Daniel'а  и обзоры
игрушек от Ze Pagan'а с огромным количест-
вом графики.

         Упаковка данных.

   В вопросе о необходимости паковать дан-
ные солидарны все, поэтому  нет  необходи-
мости разъяснять столь банальную  вещь, но
на некоторых нюансах я остановлюсь. То что
депакер должен быть один на все файлы- это
понятно. А вот загрузку данных в память не
следует производить по  принципу "загрузил
один блок - распаковал", т.к. это  тормоз,
лишние  прокруты  диска  никому  не нужны.
Лучше делать так: "загрузил турбо-лоадером
все  сразу - распаковал", потому  что  так
быстрее. У  этого  метода есть недостаток:
необходимо  закручивать  два   независимых
цикла:цикл загрузки и цикл распаковки. НО!
Не важно сколько циклов,важно удобство для
пользователя!

       Оптимизация данных.

   Важную вещь вы должны уяснить,чтобы су-
меть сделать рулезный журнал:эффективность
и оптимальность алгоритмов  прямо  зависит
от оргаизации расположения данных в памя-
ти. А теперь по порядку.
   Чтобы сделать оконный  интерфейс, необ-
ходимо  разработать  формат   расположения
данных  в  памяти. Т.е. эффективно описать
все  менюшки, кнопочки  и функции, которые
за ними закреплены (открыть  подменю, заг-
рузить что-либо, запустить что-либо),чтобы
выполнять все действия  одной  процедурой.
Daniel/PGC/BDA предлагал за каждой кнопоч-
кой размещать отдельную  подпрограмму, ко-
торая бы делала что надо,т.е. сколько все-
го кнопок во всех менюшках, столько и под-
программ. Хммм... Я может быть  тоже  стал
так делать, если бы  сейчас  не  учился на
программиста и не изучал Базы данных.Пред-
ставьте себе, что кнопочек не 40(примерно,
как в Deja Vu), а 400. Представляете  себе
масштабы программы, состоящей из кучи  не-
зависимых  программулек:-) ERASER/Delirium
Tremens предложил использовать одну корот-
кую процедуру для обработки всех кнопочек,
важно только эти  кнопочки  правильно  за-
дать. По  моему  мнению  лучше это сделать
так:

;---------------------------------------------------------------
;описание адресов расположения в памяти менюшек

TABLE    DW MENU0                ;адрес меню номер 0
         DW MENU1                ;адрес меню номер 1
         ...                     ;и так далее
;---------------------------------------------------------------
;описание каркаса менюшек

TABLEX   DB X0,Y0,VAL0,LENМАХ0   ;x и y - координаты меню
         DB X1,Y1,VAL1,LENМАХ1   ;val - кол. кнопок
         ...                     ;lenmax - макс. длина кнопок
                                 ;в данном меню
;---------------------------------------------------------------
;просто для удобства восприятия

LDTXT    EQU #FF
LDGFX    EQU #FE
RUNBASIC EQU #FD
RUNCODE  EQU #C3  ;JP ADDR
;---------------------------------------------------------------
;сектор и трек самого первого файла-статьи на диске

FIRSTRSE EQU #XXYY
;---------------------------------------------------------------
;длины файлов-статей по порядку, координаты их расположения на
;диске вычисляется, маркер конца - 7_бит=1

LENFILES DB LEN0,LEN1+#80
         DB LEN2,LEN3,LEN4,LEN5+#80
         DB LEN6+#80
         ....
;---------------------------------------------------------------
;табличка банков, чтобы лоадер знал порядок загрузки данных в
;нужные банки

BANKS    DB #10,#13,#14,#16
;---------------------------------------------------------------
;описание кнопочек каждого меню

MENU0    DB "ТЕКСТ КНОПКИ1",LDTXT,0   ;грузим статью
         DB "ТЕКСТ КНОПКИ2",LDGFX,1   ;грузим слайд-шоу
         DB "ТЕКСТ КНОПКИ3",RUNCODE
                            DW ADDR  ;запускаем произвольный код
         DB "ТЕКСТ КНОПКИ4",1        ;вложенность на menu1

MENU1    DB "TEКСТ КНОПКИ1",LDTXT,2   ;грузим статью
         DB "ТЕКСТ КНОПКИ2",RUNBASIC,"GAME    ";запуск бейсика
...
;---------------------------------------------------------------

   А сейчас небольшие пояснения. Обработка
всего  этого происходит следующим образом.
Допустим, первоначальное меню мы нарисова-
ли, далее расскажу как. Определяем в какую
кнопку попал пользователь: делается  это с
помощью 768 байтного буфера,в котором точ-
ная копия атрибутов  экрана, только вместо
атрибутов управляющие коды (номера кнопок,
код рамки - для  перемещения  менюшки, код
background'а - для  отката  на  предыдущее
меню и т.д.).Вычислить координаты стрелки,
где был нажат "огонь", и сопоставить с бу-
фером, чтобы вычислить  зону  попадания не
сложно. Можно обойтись и 384-х байтным бу-
фером, но тогда коды будут лежать  в поло-
винках байтов. Затем  по  таблице  TABLE и
TABLEX ищем адрес  описания данной менюшки
и ее параметры. Далее  идет самое интерес-
ное!
   Моя  программа  написана таким образом,
что ей не надо  на  входе  никаких  лишних
данных. Например, хоть в TABLEX и задается
максимальная  ширина текстового сообщения,
длина текста в кнопке может быть и намного
меньше.Текст в кнопке печатается до встре-
чи какого-нибудь управляющего кода, а len-
max необходим лишь для быстрого вычисления
габаритов всего окна.
   Управляющий код LDTXT, стоящий сразу за
текстом  в кнопке, служит для определения,
что за этой  кнопкой закреплена какая-либо
статья,LDGFX - слайд-шоу. После этих кодов
идет байт - номер группы файлов  в  списке
длин файлов, которые  нужно  грузить, т.к.
статьи в основном  состоят  из  нескольких
файлов, первый из которых сам текст,а пос-
ледующие содержат графику. Лоадер  сам вы-
числяет  координаты  расположения  нужного
файла на диске, если  известны  координаты
самого первого файла и  длины  в  секторах
всех файлов-статей, поэтому  нет необходи-
мости знать в каких  дорожках  и  секторах
находятся статьи. А  грузит лоадер в банки
в соответствии с табличкой  BANKS, причем,
первый  файл  грузится  всегда  под  адрес
39800 банка 0, остальные под адрес #C000.
   Управляющий код RUNBASIC и следующие за
ним 8 байтов дает  знать программе, что за
данной кнопкой  закреплена функция запуска
бейсик-файла,используется для запуска при-
ложения.
   Самым  интересным  является управляющий
код RUNCODE и  следующие  за ним два байта
адреса. Когда я писал  новую  оболочку, то
изначально заложил  возможность навешивать
на кнопки  произвольный код, который можно
запустить с корректным возвратом в оболоч-
ку. Удобным является в качестве  управляю-
щего кода  RUNCODE  использовать  байт #C3
(команда JP), чтобы можно было без проблем
сделать JP (HL). Но  данный  наворот  пока
нашел себя лишь в кнопках Set Up'а.
   Если после текста кнопки находятся бай-
ты от 0 до #C2, и от #C4 до #FC, то счита-
ется, что идет вложенность на меню с  дан-
ным номером. Вложенность может быть  абсо-
лютно любой (в пределах памяти). Здесь нет
проблем. Есть еще специальный стек, по два
байта на каждую вложенность, первый байт -
- номер  предыдущего  меню, второй - номер
нажатой кнопки в предыдущем меню.

            Музыка.

   Для проигрывания музыки лучше всего ис-
пользовать один плейер из ProTracker v3.xx
на всю музыку, так как он умеет играть му-
зыку и от некоторых других редакторов. Од-
нако, чтобы использовать  данный  плейер в
журнале, необходимо его подправить. В  из-
начальном варианте в нем сидит только  ка-
кая-то одна специальная  табличка  огибаю-
щих, а всего их должно быть 4. Если  этого
не сделать, то некоторые мелодии будут иг-
рать не так, как  задумывал  автор, за что
получите большую оплеуху:-).
   Также, дайте  возможность  пользователю
самому включать, отключать, сменять  музы-
ку. Музыку можно привязывать к  статьям, а
можно  и  нет. Например, в  MIRACLE 3 есть
выбор, что несомненно рулез. Если не буде-
те привязывать музыку к статьям,то сделай-
те это оптимально. Забудьте  про дорожки и
сектора, где  находятся музыкальные блоки.
Храните в памяти  лишь  первую  дорожку  и
сектор, где располагается самый первый му-
зон,а также длины в секторах всех музонов.
Отсюда несложно вычислить координаты любо-
го музона в списке, зная длины  предыдущих
и координаты первого. Это облегчит вам ре-
дактирование исходников, сие относится и к
алгоритму загрузки статей.

             Текст.

   Формат текста может быть любым, на ваше
усмотрение,но лучше всего использовать 866
кодировку - стандартная альтернативная, но
со специальными  управляющими  кодами. Это
облегчит вам жизнь при редактировании ста-
тей.
   Лучше  всего  текст  в памяти хранить в
непрерывном виде,и уделить как можно боль-
ше места под него, ведь это как никак жур-
нал, а не дема, поэтому  освободите  место
от ненужных наворотов и займите его  текс-
том!
   Если у вас текст будет  цветным, много-
фонтовым, содержать спрайты, анимацию  или
даже гипер-текстовые ссылки, то  позаботь-
тесь о разработке специального  софта  для
этого случая, так сказать  home using. По-
тому что  вставлять  эту шнягу в текст из-
-под STS'а не очень удобно.Мы с MAX'ом еще
давно написали такую софтину, чем облегчи-
ли жизнь нашему главному  редактору, да  и
себе тоже.

   Драйвер дисковых операций.

   Подпрограмма  загрузки  статей   должна
быть одна, делать максимум полезных дейст-
вий и требовать  минимум  входных  данных.
Лучше всего использовать  TURBO LOADER, но
с небольшими оговорками. Дело в том, что в
последнее  время  много  людей  обзавелись
винтами,и эти турбо-лоадеры не хотят с ни-
ми работать. Поэтому придется как-то  вык-
ручиваться. Можно  использовать лоадеры по
#3D13 и тем самым  дать  возможность легко
жить человеку с винтом, и страдать челове-
ку без винта,коих подавляющее большинство.
Но лучше  дать возможность выбирать #3D13/
TURBO. У нас это пока  не  сделано, потому
что не вставала такая проблема, а в следу-
ющем номере я подумаю над этим.Это сделать
не сложно, просто влом напрягаться.
   Сделайте обработку ошибок в вашем  лоа-
дере, чтобы при нажатии на BREAK  не  было
BASIC RULEZ или цветных квадратиков.

        Листалка текста.

   Это  самое главное, потому что читатель
в ней проводит больше всего  времени. Сде-
лайте ее как можно быстрее и по возможнос-
ти без сильных мерцаний и подергиваний.Ни-
кто вас ругать не будет, если  сделаете in
one frame. Но сделайте это  так, чтобы  на
тормозных машинах это дело  не  зависало и
не  сбрасывалось.  Поддержите  многофонто-
вость: 32, 42, 64 символа в строке. О том,
что шрифты должны быть читабельными, и ежу
понятно.

                             Ну, за глюки!
                               (C) Михалыч

   Глюки - это самые отвратительные сущес-
тва, мочить их надо сразу, иначе  они  это
сделают с вами. Получите  нервный  срыв  и
отбросите копыта! Ну, а если  серьезно, то
чтобы выловить глюки  в  программе, одного
STS'а мало. Желательно иметь под рукой Те-
невик, и тогда вы не получите  смертельную
дозу нервного истощения. Учитывая  большие
габариты программы и ее сложность, то глю-
ки всегда будут вас  преследовать. Полнос-
тью избавиться от них можно лишь  формати-
рованием всех дисков  с  исходниками:-) Но
сократить число глюков реально. Для  этого
нужно чаще  запускать  ваши  исходники  на
компьтере другой конфигурации. Тогда  есть
надежда, что глюк  всплывет  раньше, а  не
укоренится в  программе окончательно. Если
глюк не выколупывается, то можно его доку-
ментировать,и тогда на все выкрики со сто-
роны отвечать, что так и должно быть,и все
претензии направлять в ООН по правам чело-
века!

           RELEASE!

   Тут я хочу полностью  процетировать Da-
niel'а, потому  что  лучше сказать не смо-
гу:-)
   "Это, конечно, самое приятное в  журна-
ломейкерстве! Когда  журнал  готов, и  все
глюки  выловлены,  самое  время  собраться
всем, кто принимал участие (в любом смысле
этого слова). Если зимой, то  на квартире;
летом - на природе. Хорошенько  затариться
всем необходимым,и осуществить самым диким
образом RELEASE! Если это первый номер, то
сие называется презентация! При этом  про-
цессе нужно произносить  приятные  слова в
свой адрес, т.к. это благотворно влияет на
пищеварение. И  только  после  RELEASE  вы
ощутите  великую  пользу журналостроения и
будете себя чувствовать прекрасно,по край-
ней мере до утра...;-)". Конец цитаты.

                Cardinal/PGC/BDA
------------------------------------------