01 сентября 2000

                                         
   ВНУТРЕННЯЯ СТРУКТУРИЗАЦИЯ   
        ВАШИХ ПРОГРАММ         
                                         
(С) 2000 Макс/Compu-Studio Ltd           
-----------------------------------------
              Пути кодера неисповедимы...
                                         
   Привет всем! Сегодня продолжу "страда-
ния" на тему "КАК ДЕЛАТь ПРОГРАММЫ", что-
бы  было приемлемо и вам, господа молодые
программисты, и нам - пользователям. Тема
по-прежнему актуальна, т.к. отчасти из-за
глубокой лени, отчасти из-за незнания по-
являются программы, демки и пре-релизы на
игры в убогом внутреннем виде. Да и к уже
законченным проектам иногда остаются пре-
тензии.                                  
   Суть "проблемы" такова, что программа,
находящаяся  на диске, получается непере-
мещаемая. У некоторых товарищей.  Не буду
показывать  пальцем - обидятся, но в сле-
дующий раз, если он вообще когда-нибудь у
вас будет, просьба сделать так, как я вам
предлагаю. Здесь имеется ввиду перемещае-
мость на разные треки и сектора по диску.
Другими  словами - перенос с одного места
диска на  другое.  Согласитесь, что очень
часто встречаются ситуации, когда скинешь
с дискет друга, на которых всё читается и
запускается, себе на диск несколько прог-
рамм, а потом выясняется, что находясь не
"на своём месте", они отказываются загру-
жаться, чем сильно напрягают. Ладно, если
программа должна быть самой первой на ва-
шем диске - выполнил это условие и чёрт с
ней.  Но  мне попадались игры, которые по
замыслу их авторов должны находиться сов-
сем даже не с начала. И даже не на втором
треке, а чёрт знает где.  Вот и гадай по-
том - куда её надо записать,  чтобы зара-
ботала? Опытный или настойчивый пользова-
тель попытается это выяснить, разобрав на
запчасти загрузчик.  А  как же быть всем,
кто "не шарит" в ассемблере?  Стереть на-
хер эту хреновину или заново переписать у
друга программу трековым методом? Хорошо,
если друг живёт в  соседнем  подъезде, но
если по почте получил такой облом? Убедил
я вас в необходимости заниматься правиль-
ной  внутренней структуризацией программ,
дабы у конечного потребителя не возникало
подобных проблем?                        
   Самое  интересное, что и сам создатель
ПО лишится некоторых проблем, связанных с
загрузкой файлов программы. Я приведу для
примера алгоритм загрузки третьего номера
моего журнала.  Этот номер получился сво-
бодно перемещаемый по диску благодаря ал-
горитму, который я специально разработал.
   Итак, любая программа начинается с то-
го, что  её нужно загрузить в ОЗУ компью-
тера. Обычно несколько файлов надо считы-
вать с диска, а потом запускать на выпол-
нение основной алгоритм.  Я принял за ус-
ловие, что  все файлы запакованы програм-
мой HRUST любой версии. Без распаковщика.
Это  важный момент - короче программа бу-
дет, да и работать легче. Также принято в
условии, что все файлы начинаются с круг-
лого шестнадцатиричного адреса. Например,
с адресов #6000, #8000, #F000 и т.д. Тоже
принципиальный момент - проще работать. А
теперь смотрите, как я реализовал загруз-
ку журнала:                              
                                         
;Загрузчик журнала "Чёрная Ворона #3".   
;(С) 2000 Михаил Максименко.             
;Автоопределение размеров загружаемых    
;файлов. Паковать всё HRUST`ом без рас-  
;паковщика! Последовательность файлов:   
;В_CROW   .В    бейсик-загрузчик         
;ВС_loader.С    этот файл, что в asm`е   
;$ВС_SCR  .С    заставка                 
;ВСЗ_DB00 .С    осцилограф в page 7      
;ВСЗ_8000 .С    костяк журнала           
;$ВСЗ_FON .С    фоновая заставка в page 6
;ВСЗ_MUS  .С    музыка в page 6          
;ВСЗ_data .С    все данные для журнала   
;далее тексты журнала. Их начало опреде- 
;ляется здесь автоматически.             
;Всё, кроме фонового screen`а, распаковы-
;вать!                                   
;in: Н=адрес загрузки файла, L=номер page
;    файла, куда загружать.              
                                         
        ORG  #BD00                       
START   LD   HL,#8010;адр. #8000 page #10
        CALL LOADER  ;заставка           
        LD   HL,#8000                    
        LD   DE,#4000                    
        LD   ВС,6912                     
        LDIR         ;на экран           
        LD   HL,#DB17;music bank в #17   
        CALL LOADER                      
        LD   HL,#6010;костяк журнала     
        CALL LOADER                      
        LD   HL,#F016;титульный лист     
        CALL LOADER1 ;без распаковки     
        LD   HL,#С016;музыка             
        CALL LOADER                      
        LD   HL,#AA10;данные журнала     
        CALL LOADER                      
;ЧИТАТЕЛь! ОБРАТИ НА ЭТО ВНИМАНИЕ!       
        LD   HL,(#AAO2);адрес таблицы    
                       ;size/sect/track  
        LD   DE,(23796)                  
        INC  HL      ;пропуск "size"     
        LD   (HL),Е  ;первый сектор      
        INC  HL      ;залегания txt      
        LD   (HL),D  ;и трек             
        JP   #8000   ;старт журнала      
                                         
;точка входа с распаковкой после загрузки
                                         
LOADER  LD   DE,DEHRUST                  
        PUSH DE      ;start распаковки   
                                         
;загрузить, но не распаковывать файл.    
                                         
LOADER1 LD   ВС,#7FFD                    
        OUT  (С),L                       
        LD   L,0     ;целый адрес #xxOO  
        LD   В,1     ;считать с диска    
        CALL LOADER2 ;один сектор        
        PUSH HL      ;начало файла, запа-
        PUSH HL      ;кованного HRUST`ом!
        РОР  IX                          
        LD   A,(IX+4);длина упакован-    
        LD   В,(IX+5);ного файла         
        OR   A       ;кратен сектору?    
        JR   Z,LOADER3                   
        INC  В       ;размер файла,      
                     ;кратный сектору    
LOADER3 DEC  В       ;минус загруженный  
        INC  Н       ;сектор и next адрес
        CALL LOADER2                     
        РОР  HL      ;начало file        
        LD   Е,L     ;for deHrust        
        LD   D,Н     ;адрес загрузки сов-
        DI           ;падает с адресом   
        RET          ;распаковки         
                                         
;Обращение к tr-dos. Можно заменить на   
;свой loader, если это не критично.      
                                         
LOADER2 PUSH HL                          
        LD   DE,(23796)                  
        LD   С,5                         
        CALL 15635                       
        РОР  HL                          
        RET                              
                                         
;Это распаковщик, поставляемый с HRUST.  
                                         
DEHRUST INCBIN  "DEHRUST"                
SIZE    EQU     $-START ;определить раз- 
                        ;мер файла.      
                                         
   Теперь объясняю все тонкости.  С ввод-
ными, надеюсь, всё ясно. Сначала нам надо
считать с диска один сектор с загружаемо-
го файла, чтобы  определиться с размерами
этого файла.  Учтите,  что в примере я не
делал проверку на "размер 1 сектор", поэ-
тому, если надо - сами её поставьте.  Чем
прекрасен файл, упакованный HRUST`ом, так
это  тем, что все данные о файле зафикси-
рованы  в его  начале, включая маркировку
"HR", как  признак  файла из-под HRUST`а.
Так вот, берём данные о размере файла, не
забывая при этом отминусовать один сектор
от размера, который  уже считан, и загру-
жаем весь файл. Если надо - распаковываем
его.  Мне, например, фоновую заставку для
журнала нет смысла распаковывать, поэтому
предусмотрена загрузка файла без дальней-
шей распаковки.                          
   Теперь о том  месте в алгоритме, где я
просил обратить ваше внимание на непонят-
ную  закладку данных в только что считан-
ный файл. Это тоже принципиальное место в
программе, так как определяется следующий
трек/сектор на диске за вашей программой.
Эти  данные  вам нужны в случае необходи-
мости  дальнейшего  чтения дополнительных
уровней игры, спрайтов, таблиц и т.д.    
   У меня в журнале для определения  мес-
тонахождения  файлов статей и музыки спе-
циальная таблица, в которой указаны: раз-
мер файла в секторах, а также первый сек-
тор и трек, где лежит файл.  Чтобы каждый
раз не определяться с началом этой табли-
цы  в памяти, я сделал привязку к опреде-
лённому адресу в одном из файлов - #AAO2,
где лежит адрес её начала.  Вот  по этому
адресу +1 я и закладываю следующие трек и
сектор, которые  идут за программой после
загрузки. Таблица имеет следующий вид:   
                                         
TABLES DEFB #1Е,0,0 ;файл номер 0        
       DEFB #0A,0,0 ;-----/-----1        
       DEFB #27,0,0 ;-----/-----2        
                                         
И так далее...  Конец таблицы можно обоз-
начить нулями, чтобы потом не потеряться.
Здесь первое значение равно размеру файла
в секторах, а последующие нули зарезерви-
рованы для значений сектор/трек на диске.
   А дальше всё просто - произвожу расчёт
следующих значений трек/сектор по размеру
файла, которые находятся в таблице. Таким
образом получается привязка к конкретному
месту на диске  всей программы, включая и
её дополнительные файлы.                 
   Итак, в  загрузчике сделана закладка в
таблицу значений для первого файла. Оста-
лось сделать для всех остальных:         
                                         
;расчёт следующих трека и сектора        
;по размеру файла в секторах.            
                                         
DATAS   LD   IX,TABLES                   
        INC  IX      ;пропустить размер  
        PUSH IX      ;файла              
        РОР  IY                          
        LD   Е,(IX)  ;начальные сектор   
        INC  IX                          
        LD   D,(IX)  ;и трек             
        INC  IX                          
DATAS1  LD   (IY),Е  ;sector             
        INC  IY                          
        LD   (IY),D  ;track              
        INC  IY                          
        INC  IY                          
        LD   A,(IX-3)                    
        OR   A       ;нули - конец табл. 
        RET  Z       ;exit               
        INC  IX                          
        INC  IX                          
        INC  IX                          
        LD   С,A                         
        LD   A,Е                         
        ADD  A,С                         
        LD   L,A                         
        RRA                              
        RRA                              
        RRA                              
        RRA                              
        AND  #1F                         
        ADD  A,D                         
        LD   D,A     ;track              
        LD   A,L                         
        AND  #0F                         
        LD   Е,A     ;sector             
        JR   DATAS1                      
                                         
   М-да, убогая процедура вышла, но рабо-
чая. Что ещё нужно? Если есть желание, то
перепишите её заново. Моё дело рассказать
теорию...                                
                                         
   Дальнейшая работа программы заключает-
ся в организации загрузки файлов по номе-
ру залегания в таблице. Например, надо из
трёхбайтовой таблицы извлечь данные о за-
гружаемом файле:                         
                                         
        LD   A,номер файла в таблице     
        LD   L,A                         
        ADD  A,A                         
        ADD  A,L     ;3-байтовая таблица 
        LD   HL,TABLES                   
        ADD  A,L                         
        LD   L,A                         
        JR   NC,LABEL1                   
        INC  Н                           
LABEL1  LD   В,(HL)  ;размер файла       
        INC  HL                          
        LD   Е,(HL)  ;сектор             
        INC  HL                          
        LD   D,(HL)  ;трек               
        RET                              
                                         
   И всё! Можно спокойно работать и боль-
ше не  отвлекаться на смену значений таб-
лицы  при перемещении группы файлов. Даже
если  какой-то файл будет вами переделан,
то  достаточно изменить (при необходимос-
ти) его размер, а всё остальное программа
сделает за вас при старте.               
                                         
   Есть много способов "привязки" к диску
программы или файлов, но этот самый прос-
той, на мой взгляд. Более изощрённый спо-
соб  реализовал у себя в игре Славик Мед-
ноногов - диск  разбит на логические сек-
тора. Файлы в этом случае располагаются в
виртуальном  пространстве  от нулевого до
2544-го сектора или,  если  нестандартный
формат диска, до последнего доступного из
общего  количества  секторов. Получается,
что файл, например,  десятый находится на
142 логическом секторе.  Таблица располо-
жения файлов в программе получается одно-
байтовой, но процедура получения реально-
го трека и сектора,  равно  как и размера
файла,  немного  больше  из-за проводимых
расчётов и преобразований. В таблице ука-
заны только номера логических секторов, с
которыми потом делается следующее: берёт-
ся  нужный номер логического сектора, за-
тем  по следующему номеру определяется их
разница. Это и будет размер файла.  После
производится  расчёт  физического трека и
сектора  из  данных, представляющих собой
объём диска вцелом, т.е. сколько секторов
на треке отформатировано.  Диск, по усло-
вию, должен  иметь одинаковый формат тре-
ков.  Кстати, для определения номера сек-
тора в пределах 0-2544 одним  байтом Сла-
вик сделал  контроль перехода с #FF на 0,
а значит учитывается переполнение.  Таким
образом этим методом доступно любое коли-
чество логических секторов в одном диско-
вом пространстве - хоть миллион! Не напо-
минает ли вам это ПиСишку?               
   Примеры реализации этого метода приво-
дить не буду, т.к. на тырдосе большое ко-
личество секторов не актуально. Хотя, ес-
ли писать  программу, широко использующую
винчестер, этот метод может пригодиться. 
                                         
                  -----                  
                                         
   Думал на этом закончить статью, но где
там... Кодеры продолжают кодить, а значит
и темы для разговоров не исчерпаны!      
   В последнее время стали плодиться вся-
кие программы и оболочки, в которых пред-
усматривается, что оверлеи могут делать и
пользователи, а не только их авторы. Даже
очень  хорошо, что такая возможность пре-
доставляется - захотел к графическому ре-
рактору типа GRAPHIC STATION сделать свой
оверлей, реализующий ЗD-эффект - пожалуй-
ста! Без проблем - сиди и кодируй.       
   Как правило, в комплекте с такой прог-
раммой  идёт листинг с адресами и точками
входа для того, чтобы программист мог сам
ориентироваться в кодах. Хорошо организо-
вана и продумана  работа с ZX-ASM`ом, где
идёт обращение к ядру редактора через RST
#10 плюс номер функции. Помните мою винду
во втором номере "Вороны"? Там тоже прин-
цип  работы с оболочкой точно такой же. И
в знаменитом IS-DOS`е именно так реализо-
ван интерфейс с программистом.  Многое из
того, что делалось  серьёзными  группами,
использует этот метод. Он является наибо-
лее простым по реализации. Хотя в процес-
се отладки программы при помощи STS`а бу-
дут  наблюдаться  неудобства, связанные с
невозможностью трассировки команды RST 16
плюс номер функции в пошаговом режиме. Но
это не страшно - зачем  тебе трассировать
оболочку? Как правило она обезглючена.   
   Ещё немаловажным фактором является са-
мая полная свобода действий как для авто-
ров  оболочек и программ, так и для прог-
раммистов, делающих свои оверлеи, с точки
зрения  совместимости последующих версий,
т.к. отпадает  самое  неприятное - адреса
подпрограмм больше не имеют значения! Они
заменены на  "сухой" номер функции, кото-
рой  наплевать на всё: указал номер - по-
лучи результат...                        
   Вот здесь, на этом месте, на разработ-
чиков программ  и  оболочек ложится самая
большая ответственность - надо ВСЁ проду-
мать  так, чтобы в последующих версиях не
пришлось менять ВВОДНЫЕ на функции!!! Ес-
ли  ваше воображение не позволяет вообра-
зить  невообразимое, то хотя бы проведите
опрос среди пользователей или (что лучше)
программистов и поинтересуйтесь - что они
хотели бы видеть в будущих версиях вашего
программного чуда? Результаты этого опро-
са вовсе не следует воспринимать, как зе-
лёный свет к действию по немедленной реа-
лизации. Они и сами это сделают, если за-
хотят. Но о способах решения этих задач в
вашей оболочке надо хорошенько задуматься
и предусмотреть пути их реализации. Тогда
и вам будет легче - не  будут  упрекать в
недальновидности, ламерстве и т.д.  И для
программистов со стороны чем больше будет
свободы действий - тем лучше! И совмести-
мость  старых и новых версий останется на
должном уровне.  Короче, продумай всё ос-
новательно, а  потом только садись за ас-
семблер!                                 
   А я тебе помогу. Немного. Для наиболее
детальной и полной информации прочитай во
втором номере "Вороны" мою статью-Help на
WindoWs.                                 
   Здесь же я расскажу о способе работы с
функциями через RST #10.                 
   Итак, все и так уже это знают,  но на-
помнить считаю не лишним:  для привязки к
RST #10 надо  занести в системную бейсика
#5С51 адрес своей системной, где находит-
ся  адрес программы, отвечающей за работу
с функциями и вызываемой через RST #10. В
этом замысловатом действии есть необходи-
мость  из-за особенностей работы ПЗУ-шной
процедуры.  Сама процедура имеет примерно
следующий вид:                           
                                         
;Запуск функции через RST #10.           
;Вводные любые, ничего не нарушает, кроме
;альтернативной пары DE.                 
                                         
RST_16  РОР  HL     ;RET из ПЗУ          
        РОР  HL     ;HL` альтернативный  
        ЕХ   (SP),HL;next адрес после RST
        LD   Е,(HL) ;номер функции с #40!
        RES  6,Е    ;Почему - читай ниже!
        RLC  Е      ;разделить на 2      
        LD   D,#00                       
        INC  HL     ;адр. после номера ф.
        ЕХ   (SP),HL;выход после функции 
        PUSH HL     ;HL`                 
        LD   HL,таблица адресов функций  
        ADD  HL,DE                       
        LD   Е,(HL) ;взять адрес функции 
        INC  HL                          
        LD   D,(HL)                      
        РОР  HL     ;HL`                 
        PUSH DE     ;для запуска функции 
        EXX         ;это нагадила RST #10
        RET         ;запуск функции.     
                                         
   И вновь об особенностях работы ПЗУшной
подпрограммы обработки команды RST #10. И
какой  дурень написал так, что в процессе
работы грохается значение альтернативного
регистра DE? Вернее: регистровой пары DE.
Приходится с этим мириться...  Но это де-
лать вовсе не обязательно! Можно написать
другую процедурку, которая ничего не гро-
хает! Вот она:                           
                                         
NO_RST  LD   (REG_A),A                   
        ЕХ   (SP),HL                     
        LD   A,(HL)                      
        INC  HL                          
        ЕХ   (SP),HL                     
        PUSH HL                          
        PUSH DE                          
        LD   HL,таблица адресов функций  
        SUB  #40                         
        ADD  A,A                         
        LD   Е,A                         
        LD   D,#00                       
        ADD  HL,DE                       
        LD   A,(HL)                      
        INC  HL                          
        LD   Н,(HL)                      
        LD   L,A                         
        РОР  DE                          
        LD   A,#00                       
REG_A   EQU  $-1                         
        ЕХ   (SP),HL                     
        RET                              
                                         
   Принцип  работы аналогичен предидущему
алгоритму, поэтому комментарии излишни. Я
только хочу отметить, что данный алгоритм
следует  вызывать  через CALL NO_RST плюс
номер функции:                           
                                         
        CALL NO_RST                      
        DEFB номер функции.              
                                         
   Теперь расскажу о том, почему я приме-
нил нумерацию функций с #40, а не с нуля.
Дело в том, что можно любой номер ставить
для  функции, вот только откомпилируйте и
посмотрите на результат.  Всё, что разме-
щается  после номера - слилось в едуную с
ним кашу. Не всегда, правда, но настолько
часто, чтобы сделать просмотр STS`ом уто-
мительным делом.  Трудно будет отлаживать
творимую программу! А вот номер с #40  до
#С0  можно свободно применять из-за того,
что это коды однобайтовых команд и значит
визуального  слияния со следующими коман-
дами не произойдёт.                      
   Таблица функций представляет собой са-
мый что ни есть заурядный список подпрог-
рамм, набранных под DEFW. Всё, кодируйте!
   Оп, нет!  Ещё забыл пару слов сказать.
Все перечисленные алгоритмы, естественно,
для внутреннего использования в оболочке,
а для  пользователей и программистов надо
сделать  две точки входа: через RST #10 и
какой-нибудь  адрес, где будет находиться
подобие резидента. Можно сделать так, как
я сделал в своём WindoWs`е - начало кодо-
вого блока и есть точка входа в оболочку.
Самым же приемлемым решением, на мой при-
страстный  взгляд, является организация в
теле оболочки специальной инсталляционной
функции, которая  помимо теста устройств,
доступной памяти и т.д., будет заниматься
подключением  канала  для  RST`шки. Тогда
нужна только одна единственная точка вхо-
да. Естественно, что желательно иметь так
называемую "заключительную" функцию,  ко-
торая  будет "тушить" AY8910/12, устанав-
ливать IM 1, реставрировать все системные
переменные, включая каналы и потоки после
работы  твоей оболочки через RST #10. Од-
ним словом - приводить в порядок всё, что
не совсем соответствует состоянию компью-
тера после его инициализации.            
   А  как быть с системными оболочки, ко-
торые используются из вне и как к ним по-
лучить доступ? Не такое сложное это дело,
как  может  показаться в первый момент. Я
предлагаю сделать функции многоуровневые.
Такое  решение,  например, реализовано во
всеми любимом журнале ZX-FORMAT.  Там всё
сделано примерно так, хотя в деталях могу
ошибаться:                               
                                         
        RST  #10                         
        DEFB номер функции               
        DEFB тип функции                 
        DEFB данные, данные...           
                                         
   Получается так, что попав в определён-
ную функцию, происходит изъятие из памяти
следующих  байт, которые могут быть ввод-
ными для функции. Да чем угодно!  Всё за-
висит от установленых вами правил. Теперь
применительно к системным переменным, ко-
торые надо изменять. Рекомендую всем сис-
темным в оболочке, к которым  предполага-
ется  иметь доступ из вне, присвоить свои
порядковые номера. Также, как и функциям.
Реализовать на практике это можно так:   
                                         
        RST  #10                         
        DEFB функция установки системных 
        DEFB номер корректируемой систем-
             ной переменной              
        DEFW двухбайтовое значение       
                                         
   Можно немного усложнить операцию и оп-
ределять  размерность системной на 1-бай-
товость или 2-байтовость. Или сделать це-
почку  вводных, если это, например, обра-
щение к дисковой функции. Только не забы-
вайте, что в моих примерах на стеке лежит
адрес  возврата из функции! Этим же адре-
сом  можно  пользоваться  для дальнейшего
изъятия вводных. Аналогично можно органи-
зовать изъятие любой системной переменной
из списка.                               
                                         
   Теперь следует немного поагитировать к
освоению аппаратных возможностей, которые
широко  используются в последнее время на
Спектруме. Речь идёт о поддержке кэша. Из
всех многочисленных  схем этого потрясаю-
щего устройства рекомендую для начала де-
лать программы под стандартный кэш на 16К
с  расчётом на то, что это наиболее легко
реализуемая схема, к тому же является ро-
дителем  дальнейших разработок в этой об-
ласти:  кэш на 32К, эмуляция 128-го ПЗУ и
так далее. Рекомендую всем создателям бу-
тов, оболочек, редакторов и другого софта
поддержать эту схему!  Ну посуди сам, до-
рогой автор некоего виндовса - практичес-
ки вся память компьютера, вне зависимости
от её объёма, отдана пользователю и прог-
раммисту, что несомненно поднимет рейтинг
твоей ОС, а также  упростит до минимума в
будущем адаптировать уже существующие или
разрабатываемые программы.  Решать, в ко-
нечном  счёте, тебе и возможностям твоего
компьютера. Если проблема в последнем, то
может стоить её решить и тогда твоя прог-
рамма не будет выглядеть так убого...    
                                         
    Ну-с, пока всё. Желаю удачи! Надеюсь,
что эта статья поможет вам в работе.     
                                         
                                         
     ДИЗАЙН НАШИХ ПРОГРАММ     
     =====================     
                                         
(С) 2000 Мг.Beeper/Last Masters          
-----------------------------------------
 Глава I                       
                                         
   Жаль мне тех людей, которым слово "ди-
зайн"  - пустой звук. Ведь написать прог-
рамму  - это одно, а красиво её оформить,
придумать оригинальный дизайн к ней - со-
вершенно  другое.  Вот  почему  некоторые
личности,  пытаясь внедрить  на Спектруме
свои  идеи, сталкиваются с этой проблемой
и,  к  сожалению, не найдя выхода из неё,
часто  бросают свои работы не доведёнными
до  конца.  Некоторые  делают без какого-
либо дизайна... Конкретные примеры приво-
дить я небуду, хотя почему бы и нет?  Вот
один из них.                             
   Помните демоверсию игры под названием,
если  я  не ошибаюсь - "ROBO". Смысл игры
таков:  управляя  неким  персонажем  (вид
сверху),  вы блуждаете среди всяких лову-
шек  и  неожиданностей.  Демоверсия  была
просто потрясная. В игре были замечатель-
ные оцифрованные звуки, и это было, я вам
скажу - круто.                           
    Прошёл некоторый промежуток времени и
появилась полная версия игры... На рынках
родного  города она продавалась в больших
количествах, и как были разочарованны те,
кто  приобрёл  сей  продукт. Вся загрузка
производилась через бейсик, меню, как та-
кового, небыло. Была выборка только уров-
ня  - и только. Я лично опросил некоторых
таких обиженных юзеров и мои ожидания оп-
равдались.  99%  опрошенных забросили эту
игру на самую верхнюю полку после увиден-
ного. А где же те оцифрованные звуки, из-
за  которых  возвысился  рейтинг этой иг-
ры?                                      
    Да  их просто заменили на AY`ковские.
Вот вам и весь дизайн! Ну, может быть ещё
один  вариант:  Автор  игры скоропостижно
скончался,  а в предсмертном сказании за-
вещал  эту  игру  своим предкам, а предки
эти  пропили эту программульку людишкам в
чёрном,  а людишки эти были ламерами, и в
лом им стало что-то делать над этим недо-
деланным  творением исскуства и стали они
кодить  на  Бейсике, и разразился гром, и
пустился проливной дождь. А лохи в чёрном
кодили  под старым дубом, на ветвях кото-
рого небыло ни единого листочка. И залило
комп ихний, но на последних секундах один
из этих, что в чёрном, успел сделать save
и тем самым подарил миру ЭТО.  Хоть верь-
те, хоть нет, а дело было именно так.    
                                         
 Глава II                      
                                         
    Давайте теперь по маленькой, ой, вер-
нее  по меленькому рассмотрим demomaking.
С  этим у нас всегда был порядок и лишний
раз писать неохота. Очень интересная ста-
тья по этому поводу была напечатана в Fa-
ultless`е  #9, хотя, по-моему, она скорее
всего  была  выдрана  с платформы РС. А я
хотел бы лишь напомнить вам, товарищи де-
момакеры, что:                           
                                         
1). Ваши творения смотрят не только прог-
раммисты, но и обычные юзеры, которые ни-
чего  не понимают в эффектах, и судят они
ваши демки не по быстроте выполнения того
или иного эффекта, а по его красоте и со-
четании с музыкой.                       
                                         
2).  Помните также, что некоторые из этих
юзеров  на своём телевизоре развертку эк-
рана  делают  так,  что  бордера как бы и
нет. Поэтому надо предупреждать приблизи-
тельно  так "Warning! NoW следует сделать
на your TV little изменения" (далее долж-
на  приводится схема развертки экрана как
аппаратно, так и при помощи  медитации на
все  виды TV). Вот тогда все увидят - что
надо сделать. А то как было у меня с дев-
кой или демкой - уже не помню - Rage, ко-
торую  я ни то снял, ни то списал с Е`97,
в которой, оказывается, был  скроллер  на
бордюре и узнал я об этом в декабре меся-
це.  Сразу же полез в свой мини TV set, а
там ни сказом сказать, ни пером написать.
Столько всяких крутящихся штучек. К концу
дня  я всё-таки сделал развертку нормаль-
ной. После этого случая развертку я боль-
ше не трогаю.                            
                                         
3).  В  общем, вывод таков - когда будете
делать демку, перед написанием её очеред-
ной части, не поленитесь пригласить своих
друзей,  знакомых или просто "отфонарных"
людей. Покажите им свои наброски, спроси-
те - как будет лучше или хуже. Думаю, что
после  этой маленькой показухи у вас поя-
вятся новые идеи, да и старые приведёте в
порядок.                                 
                                         
 Глава III                     
                                         
    О  электронных  изданиях  долгую речь
вести не стоит, так как каждый гл. редак-
тор  думает,  что его журнал самый ориги-
нальный  и самый лучший. И всем остальным
журналам надо подстраиваться под его тво-
рение.  Вот  поэтому я и не стал затраги-
вать эту тему более серьезно. Хотелось бы
просто дать парочку советов начинающим,но
не более того.                           
                                         
 Совет 1.                      
    Никогда  не  начинайте делать журнал,
если у вас нет хорошего кодера. Не следу-
ет надеяться, что он потом сам прийдет. И
музыканта надо найти хорошего.           
                                         
 Совет 2.                      
    Не бойтесь повторяться с дизайном ва-
шего журнала, ведь самое главное заключа-
ется не в оригинальности, а красоте офор-
мления. И пусть, к примеру, тот же интер-
фейс с окнами уже в каждом журнале имеет-
ся,  но посмотрите - это практически всем
нравится,  да и удобно очень. Многие жур-
налы  стремились сделать оригинальную ме-
нюху, листалку, а посмотрите, что из это-
го вышло...                              
                                         
 Совет 3.                      
    Пытайтесь  раздобыть интересные мате-
риалы, найдите себе партнеров по изданию.
Делайте всё  вместе. Время от времени же-
лательно производить опрос юзеров на тему
популярности вашего журнала, о его оформ-
лении и т.д. Это очень может помочь.     
                                         
 Совет 4.                      
    Никогда  не задирайте вверх свой нос!
Это  может негативно повлиять на вашу ре-
путацию и в конце-концов вас просто заки-
дают камнями. Или яйцами ;)              
                                         
 Совет 5.                      
    В приложение включайте не только свои
собственные разработки, но и других авто-
ров.  Найдите себе партнеров, которые мо-
гут раздобыть прекрасное приложение, ведь
приложение - это  лицо вашего журнала, не
забывайте об этом!                       
                                         
      И на последок, хочу пожелать       
   всем редакциям электронных изданий    
       успешной работы над своими        
    изданиями, чтобы читатели уважали    
      и читали ваши издания, чтобы       
          никогда у вас небыло           
         информационного голода,         
             а в приложении              
        были отличные программы!         
                                         
От редакции: аминь...                    



Other articles:


Темы: Игры, Программное обеспечение, Пресса, Аппаратное обеспечение, Сеть, Демосцена, Люди, Программирование

Similar articles:
Events - A report by visiting the St. Petersburg party CHAOS CONSTRUCTION'2000 from n00tr0pil.
Nemo open letters № 5.2

В этот день...   23 November