Black Crow
#04
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. В приложение включайте не только свои собственные разработки, но и других авто- ров. Найдите себе партнеров, которые мо- гут раздобыть прекрасное приложение, ведь приложение - это лицо вашего журнала, не забывайте об этом! И на последок, хочу пожелать всем редакциям электронных изданий успешной работы над своими изданиями, чтобы читатели уважали и читали ваши издания, чтобы никогда у вас небыло информационного голода, а в приложении были отличные программы! От редакции: аминь...
Другие статьи номера:
Похожие статьи:
В этот день... 21 ноября