ВНУТРЕННЯЯ СТРУКТУРИЗАЦИЯ
ВАШИХ ПРОГРАММ
(С) 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:
