Конструктор (ZX SDK) - Speccy

CityAceE · 30th November 2005, 09:33

Раньше на Спектруме я сталкивался с такой проблемой, что когда в голову приходила какая-то идея, то основную часть времени для её проверки тратилась на обвязку программы, интерфейс и т.д. У каждого автора нарабатывалась какая-то библиотека процедур, алгоритмов, заготовок и т.д., которыми автор пользовался при написании своих программ. На память сразу приходят программы Сергея Ханциса (кстати, не так давно Сергей зарегистрировался на этом форуме) Screen Manager и другие, названия которых я запамятовал. Программы Сергея были полезны, удобны и при этом внешне похожи между собой (как собственно и подавляющее большинство программ, написанных под Windows) из-за того, что в каждой своей программе автор использовал свои библиотеки процедур. Вспоминая график выхода программ Сергея, я предполагаю, что на написание каждой последующей программы у её автора уходило меньше времени, так как процедуры интерфейса были написаны и отлажены, а автор бросал свои главные усилия не на организацию интерфейса, а на логику работы самой программы. Помню потом в электронных изданиях были призывы делиться своими процедурами и создать некий банк таких процедур. Как я понимаю, эта идея по ряду причин так и не получила большого развития и заглохла. Позже я попробовал программировать на ассемблере под PalmOS. Это был мой первый опыт программирования не на Спектруме и под настоящую операционную систему. На Палме я увидел, что мне нет надобности самому рисовать окна, отслеживать нажатия на кнопки и т.д. - всё это делает за меня операционная система, а мне необходимо лишь вовремя вызвать нужные процедуры с требуемыми параметрами. Что и говорить - удобно! Как я понимаю, именно такой подход к программированию осуществляется в любой полноценной операционной системе. Похожую идеологию я увидел и в Aqua/Doors на Спектруме. Мне очень понравилось грамотное описание самой системы и её элементов на домашней страничке Aqua/Doors. Подозреваю, что и другие операционные системы, которые писались, пишутся или ещё только будут писаться используют аналогичные методы. Но так уж получается, что как и прежде у нас TR-DOS является тем стандартом, который уже вряд ли удастся свергнуть. И поэтому, как и прежде, каждый автор продолжает заново изобретать велосипед, начиная писать ту или иную программу. Многие идеи так и не воплощаются в законченную программу, оседая на дискетах в виде исходников, так как их авторы не желают связываться с написанием интерфейса и другими трудностями программирования оболочки. С другой стороны есть и такая категория людей, которые может быть и хотели что-то написать под Спектрум, но их пугает ассемблер и тот факт, что всё придётся делать самому и с нуля...

А теперь я помечтаю...

"Я включаю свой Скорпион и вставляю в него дискету подписанную как ZX_SDK, а рядом с собой кладу стопку отпечатанных листов, имеющих аналогичный заголовок. Так-с... Ну что ж, сегодня пожалуй для разминки напишу текстовый вьювер... Итак, приступим... Грузим с дискетки ALASM... Так, готово.. Ну-ка, где тут у нас файлик MAIN.H? Есть, загрузили... Ага, вот в файлике и список инклудов... Так, в нашей программе клавиатуру опрашивать будем, так что INCLUDE "KEYS.H", оставляем, а вот работа со спрайтами сегодня не предвидится, так что строчку INCLUDE "SPRITES.H" прячем точкой с запятой, или нет, лучше сотрём, сэкономив место в исходнике. А для вывода текста мы будем использовать 64 и 40 символов в строке, так что INCLUDE "TEXT64" и INCLUDE "TEXT40" оставляем... Смотрим дальше... [ПРОШЛО НЕСКОЛЬКО МИНУТ] Ну вот, вроде бы все нужные процедуры отобраны... Перемещаемся ниже по MAIN.H... Ага, стоп, вот он главный цикл программы! Стек, пожалуй, поднимем чуть повыше... Так, с IM2 сегодня не работаем, так что этот блок отделяем точками с запятой... Эти несколько строк тоже удалим, так как в этом проекте они нам не потребуются... А сюда мы вставим вывод окна... Как там у нас называется эта процедура? Ну-ка откроем нашу распечатку... Ага, вот они процедуры отвечающие за вывод окон, а вот и нужная процедура WIN_DRAW с описанием вводных данных... Так, загружаем регистры, вставляем WIN_DRAW... [ПРОШЛО НЕСКОЛЬКО ЧАСОВ] Уф, ну что ж, отладка программы закончена... Идем на начало листинга MAIN.H и меняем кое-какие флаги, чтобы получить готовый проект. Жмём "А", ждём минуточку, пока программа откомпилируется, скомпрессируется и к ней будет добавлен BASIC-загрузчик. Ну вот, у нас на диске программа, готовая к распространению..."

Наверное примерно так мог бы выглядеть процесс создания программы, если бы в распоряжении программиста был бы пакет необходимых процедур и заготовок, с подробным описанием и примеры готовых проектов. Безусловно, с таким подходом не добиться оптимальности (фреймовости, компактности и т.д.), но тем не менее такой подход в большинстве случаем оказался бы вполне приемлемым. Возвращаясь к PalmOS, при более мощном процессоре, тем не менее многие популярные программы не стесняются перерисовывать окна и выводить надписи прямо на глазах пользователя. Конечно, для спектрумиста это выглядит несколько непривычно, но я бы лично предпочёл видеть вот такую новую программу на нашей платформе, чем никакую! Кто знает, может быть если бы было создано такое средство разработки, то и программ стало бы выходить больше? А?

Мне кажется, что этот форум - хорошее место для рождения и поддержки подобного проекта. Здесь на форуме присутствует достаточное количество людей, которые написали не одну добротную программу и каждый их них решал множество задач по созданию оболочки программы и т.д. и т.п. Этот опыт очень ценен!

Здесь можно было бы создать список самых востребованных процедур по работе с клавиатурой, мышью, дисководом, жестким диском, памятью, часами, выводом текста, символов, спрайтов, всякого рода окон, кнопочек, чек-боксов и т.д. и т.п. Определиться с наиболее универсальными и удобными методами вызова этих процедур и хорошо их задокументировать. Нужно сделать несколько демонстрационных проектов начиная с "Hello, World!" и заканчивая какой-нибудь простенькой игрушкой типа "Сапёра". Кто-то один будет координатором этого проекта, аккумулировать все процедуры и регулярно обновлять образ диска на этом форуме. Нужно пытаться делать так, чтобы этот конструктор был совместим снизу вверх, то есть чтобы программа написанная под такой "конструктор" версии 1.00, прекрасно компилировалась и работала скажем в версии 1.50. И т.д. и т.п.

Основная идея: Создать здесь на форуме некий конструктор, состоящий из процедур, заготовок и документации, который поможет быстро создавать качественные программы.

Вот мои мысли.

Или моя идея, как обычно будет задушена?

P.S. Если эта идея будет поддержана то можно подумать об организации специального раздела на форуме для удобства ведения этого проекта.

Sinus · 30th November 2005, 12:22

фз.
у меня пока есть чутка времени, поэтому смогу помочь.

однако моё чистое имхо по поводу полезности оставлю при себе.

valker · 30th November 2005, 13:47

Поддерживаю идею.

Думаю, что первым шагом в создании подобного банка будет очерчивание границ применимости, как то:
1. Конфигурация компьютера (ZX48; ZX128; S256;...),
2. Модель памяти (SOLID; CODE_IN_LOW_MEMORY_DATA_IN_BANK; CODE_AND_DATA_IN_BANK;...),
3. Доступные внешние устройства (DOESNT_USE_EXTERNAL; FDD; HDD_SCRP; HDD_NEMO; KEMP_MOUSE;...),
4. Зависимости от системных библиотек (DOESNT_USE_SYSTEM; ...),
5. Режимы работы прерываний (INT_MUST_BE_DISABLED; INT_CAN_BE_ANY; HAVE_ISR;...).

Список, естественно, примерный.

Каждая единица (модуль, процедура, библиотека), снабжается метками, указывающими на границы применимости.

Например:
ZX48 SOLID DOESNT_USE_EXTERNAL DOESNT_USE_SYSTEM INT_CAN_BE_ANY - Процедура удовлетворяет требованиям ZX-Spectrum 48, при этом не требует ни внешних устройств, не использует процедуры из ПЗУ, не зависит от режима прерываний.

Это позволит тщательнее подходить к вопросу совместимости различных модулей, и выбору "платформы" для программы.

IMHO...

fk0 · 30th November 2005, 18:03

Quote:

Originally Posted by valker

Поддерживаю идею.

Думаю, что первым шагом в создании подобного банка будет очерчивание границ применимости, как то:

Вторым. Первым -- определённые соглашения о вызове и загрузке.
Иначе две программы из банка не подружишь. Если они в ассемблере,
конечно немного проще. Лишь немного. Потому как любой программный продукт имеет срок жизни до тех пор пока он
сопровождается и поддерживается. Что невозможно без динамической компоновки практически. На FreeBSD до 5.0 посмотрите -- у них на всё make world. У нас world на дискетку
не поместится...

Позарез как нужна ДИНАМИЧЕСКАЯ КОМПОНОВКА. Ибо те
же драйвера cmos, hdd, модема -- у всех свои и несовместимые.
Несовместимые по интерфейсу. Функции одни и те же практически.
Нужен некий стандарт как на "дизайн интерфейса", не знаю как
это назвать, вроде соглашения о передаче параметров, техники
собственно вызова и т.п. Нужен унифицированный способ
динамической загрузки и статической компоновки расширений.
И наконец нужен какой-то способ идентификации интерфейсов,
что-то вроде COM и виндов.

Quote:

1. Конфигурация компьютера (ZX48; ZX128; S256;...),
2. Модель памяти (SOLID; CODE_IN_LOW_MEMORY_DATA_IN_BANK; CODE_AND_DATA_IN_BANK;...),
3. Доступные внешние устройства (DOESNT_USE_EXTERNAL; FDD; HDD_SCRP; HDD_NEMO; KEMP_MOUSE;...),
4. Зависимости от системных библиотек (DOESNT_USE_SYSTEM; ...),
5. Режимы работы прерываний (INT_MUST_BE_DISABLED; INT_CAN_BE_ANY; HAVE_ISR;...).

Список, естественно, примерный.

Каждая единица (модуль, процедура, библиотека), снабжается метками, указывающими на границы применимости.

Например:
ZX48 SOLID DOESNT_USE_EXTERNAL DOESNT_USE_SYSTEM INT_CAN_BE_ANY - Процедура удовлетворяет требованиям ZX-Spectrum 48, при этом не требует ни внешних устройств, не использует процедуры из ПЗУ, не зависит от режима прерываний.

Это позволит тщательнее подходить к вопросу совместимости различных модулей, и выбору "платформы" для программы.

IMHO...

Да. Но возможно и немного наоборот, когда выбирается
версия процедуры применимой в указанных условиях.
Или выбирается ошибка.

newart · 30th November 2005, 13:56

Quote:

Originally Posted by CityAceE

Основная идея: Создать здесь на форуме некий конструктор, состоящий из процедур, заготовок и документации, который поможешь быстро создавать качественные программы.

У любого програмера кто не первый год кодит на спектруме процес создания новой проги происходит на 50-90% так же как ты описал.
Причем зависит это от организованости кодера, мне например всегда было лень создавать бибилиотеку процедур. Я их всегда копировал из старых проектов.
А по началу и вовсе переписывал каждый раз с 0.
А с чужой библиотекой скорее всего не стал бы связываться, пока с ней разберешся можно свою успеть написать. Да и отлаживать всегда проще свое.

CityAceE · 30th November 2005, 14:56

Quote:

Originally Posted by newart

А с чужой библиотекой скорее всего не стал бы связываться, пока с ней разберешся можно свою успеть написать. Да и отлаживать всегда проще свое.

Тут нужно отталкиваться от того, что все библиотеки уже будут хорошо оптимизированы, отлажены и протестированы, а кроме того будут не менее хорошо описаны. Эти бибилиотеки будут призваны облегчить труд программиста, а не усложнить его! Нужно стермиться к тому, чтобы программисту было проще освоить требуемую библиотеку, чем написать свою процедуру с нуля.

Quote:

Originally Posted by daniel

и получиться очередной велосипед под названием Язык высокого уровня плюс компилятор на базе асма!

А пусть так! Но что в этом плохого, если это повысит скорость программирования и явится неким катализатором для выхода нового софта?

newart · 30th November 2005, 15:19

Quote:

Originally Posted by CityAceE

А пусть так! Но что в этом плохого, если это повысит скорость программирования и явится неким катализатором для выхода нового софта?

Я бы просто не стал тратить время на изучение исходников. Новички может и стали бы узать.

CityAceE · 30th November 2005, 15:45

Quote:

Originally Posted by newart

Я бы просто не стал тратить время на изучение исходников.

А и не нужно изучать исходники! Нужно знать основные процедруры и уметь ими грамотно пользоваться, как при программировани под какую-то ОС... К тому же я не призываю всех всё срочно бросать и начинать писать опираясь на предложенную систему. Но я не исключаю, что кому-то будет удобно писать именно так, как предлагаю я. Почему нет? Так же я отдаю отчёт в том, что какую-то аркадную игрушку с помощью предложенного метода написать не удасться, а вот головоломку пожалуйста.

К тому же от всех автором проекта потребуется не так много времени. Самое главное выработать общую концепцию и определиться со стандартами.

Знахарь · 30th November 2005, 18:04

Нет, народ, ну, правда ведь, как всегда, не в ногах, а где-то между... Но, действительно, идея неплохая и даааавняя. И NewArt, никого не заставляют сие юзать. Но вот еще пример: надо быстренько конвертор какой забацать... и начинается: из асма с геморойчиком...

Давайте хотя бы попробуем оттолкнуться от такого уровня что-ли...

(mac_lib библиотечка+txt описание. остальное - примеры использования)

Брать пример с BGE! там именно так плуги делать: окно задал, открыл - всё ОК (что там при этом - особо не ебб...) onkey проверил - меню выбрали/нет и т.п. Уж если я там раздуплился - так вы уж, люди добрые извольте. Сомневаюсь, что тут есть кто-то, хуже меня втыкающий в чужие СОРЦЫ. Единственное, в BGE всё этак глобально... Но можно дойти и до такого глобализма.

Alexander Bondarenko (500:3432/3) · 5th December 2005, 01:16

*Здравствуй, Вячеслав!*

Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в 30 Nov 2005 твоя портянка к тов. All.

Quote:

Я бы просто не стал тратить время на изучение исходников. Hовички
может и стали бы узать.

Да кpyт ты, Славка, кpyт. %)
С дpyгой стоpоны, сам-то небось библиотеками собственной ваpки пользyешься? А чё бы с дpyгими не поделиться - это-то yже дpyгой вопpос!

/Вот и всё, Вячеслав, можешь листать дальше.../

... Чувство меры есть у меньшинства. Иначе в нём нет смысла.

30th November 2005, 09:33	#1
CityAceE Administrator Join Date: 13th January 2005 Location: г. Владивосток Posts: 2,247 Thanks: 49 Thanked 787 Times in 210 Posts	Конструктор (ZX SDK) Раньше на Спектруме я сталкивался с такой проблемой, что когда в голову приходила какая-то идея, то основную часть времени для её проверки тратилась на обвязку программы, интерфейс и т.д. У каждого автора нарабатывалась какая-то библиотека процедур, алгоритмов, заготовок и т.д., которыми автор пользовался при написании своих программ. На память сразу приходят программы Сергея Ханциса (кстати, не так давно Сергей зарегистрировался на этом форуме) Screen Manager и другие, названия которых я запамятовал. Программы Сергея были полезны, удобны и при этом внешне похожи между собой (как собственно и подавляющее большинство программ, написанных под Windows) из-за того, что в каждой своей программе автор использовал свои библиотеки процедур. Вспоминая график выхода программ Сергея, я предполагаю, что на написание каждой последующей программы у её автора уходило меньше времени, так как процедуры интерфейса были написаны и отлажены, а автор бросал свои главные усилия не на организацию интерфейса, а на логику работы самой программы. Помню потом в электронных изданиях были призывы делиться своими процедурами и создать некий банк таких процедур. Как я понимаю, эта идея по ряду причин так и не получила большого развития и заглохла. Позже я попробовал программировать на ассемблере под PalmOS. Это был мой первый опыт программирования не на Спектруме и под настоящую операционную систему. На Палме я увидел, что мне нет надобности самому рисовать окна, отслеживать нажатия на кнопки и т.д. - всё это делает за меня операционная система, а мне необходимо лишь вовремя вызвать нужные процедуры с требуемыми параметрами. Что и говорить - удобно! Как я понимаю, именно такой подход к программированию осуществляется в любой полноценной операционной системе. Похожую идеологию я увидел и в Aqua/Doors на Спектруме. Мне очень понравилось грамотное описание самой системы и её элементов на домашней страничке Aqua/Doors. Подозреваю, что и другие операционные системы, которые писались, пишутся или ещё только будут писаться используют аналогичные методы. Но так уж получается, что как и прежде у нас TR-DOS является тем стандартом, который уже вряд ли удастся свергнуть. И поэтому, как и прежде, каждый автор продолжает заново изобретать велосипед, начиная писать ту или иную программу. Многие идеи так и не воплощаются в законченную программу, оседая на дискетах в виде исходников, так как их авторы не желают связываться с написанием интерфейса и другими трудностями программирования оболочки. С другой стороны есть и такая категория людей, которые может быть и хотели что-то написать под Спектрум, но их пугает ассемблер и тот факт, что всё придётся делать самому и с нуля... А теперь я помечтаю... "Я включаю свой Скорпион и вставляю в него дискету подписанную как ZX_SDK, а рядом с собой кладу стопку отпечатанных листов, имеющих аналогичный заголовок. Так-с... Ну что ж, сегодня пожалуй для разминки напишу текстовый вьювер... Итак, приступим... Грузим с дискетки ALASM... Так, готово.. Ну-ка, где тут у нас файлик MAIN.H? Есть, загрузили... Ага, вот в файлике и список инклудов... Так, в нашей программе клавиатуру опрашивать будем, так что INCLUDE "KEYS.H", оставляем, а вот работа со спрайтами сегодня не предвидится, так что строчку INCLUDE "SPRITES.H" прячем точкой с запятой, или нет, лучше сотрём, сэкономив место в исходнике. А для вывода текста мы будем использовать 64 и 40 символов в строке, так что INCLUDE "TEXT64" и INCLUDE "TEXT40" оставляем... Смотрим дальше... [ПРОШЛО НЕСКОЛЬКО МИНУТ] Ну вот, вроде бы все нужные процедуры отобраны... Перемещаемся ниже по MAIN.H... Ага, стоп, вот он главный цикл программы! Стек, пожалуй, поднимем чуть повыше... Так, с IM2 сегодня не работаем, так что этот блок отделяем точками с запятой... Эти несколько строк тоже удалим, так как в этом проекте они нам не потребуются... А сюда мы вставим вывод окна... Как там у нас называется эта процедура? Ну-ка откроем нашу распечатку... Ага, вот они процедуры отвечающие за вывод окон, а вот и нужная процедура WIN_DRAW с описанием вводных данных... Так, загружаем регистры, вставляем WIN_DRAW... [ПРОШЛО НЕСКОЛЬКО ЧАСОВ] Уф, ну что ж, отладка программы закончена... Идем на начало листинга MAIN.H и меняем кое-какие флаги, чтобы получить готовый проект. Жмём "А", ждём минуточку, пока программа откомпилируется, скомпрессируется и к ней будет добавлен BASIC-загрузчик. Ну вот, у нас на диске программа, готовая к распространению..." Наверное примерно так мог бы выглядеть процесс создания программы, если бы в распоряжении программиста был бы пакет необходимых процедур и заготовок, с подробным описанием и примеры готовых проектов. Безусловно, с таким подходом не добиться оптимальности (фреймовости, компактности и т.д.), но тем не менее такой подход в большинстве случаем оказался бы вполне приемлемым. Возвращаясь к PalmOS, при более мощном процессоре, тем не менее многие популярные программы не стесняются перерисовывать окна и выводить надписи прямо на глазах пользователя. Конечно, для спектрумиста это выглядит несколько непривычно, но я бы лично предпочёл видеть вот такую новую программу на нашей платформе, чем никакую! Кто знает, может быть если бы было создано такое средство разработки, то и программ стало бы выходить больше? А? Мне кажется, что этот форум - хорошее место для рождения и поддержки подобного проекта. Здесь на форуме присутствует достаточное количество людей, которые написали не одну добротную программу и каждый их них решал множество задач по созданию оболочки программы и т.д. и т.п. Этот опыт очень ценен! Здесь можно было бы создать список самых востребованных процедур по работе с клавиатурой, мышью, дисководом, жестким диском, памятью, часами, выводом текста, символов, спрайтов, всякого рода окон, кнопочек, чек-боксов и т.д. и т.п. Определиться с наиболее универсальными и удобными методами вызова этих процедур и хорошо их задокументировать. Нужно сделать несколько демонстрационных проектов начиная с "Hello, World!" и заканчивая какой-нибудь простенькой игрушкой типа "Сапёра". Кто-то один будет координатором этого проекта, аккумулировать все процедуры и регулярно обновлять образ диска на этом форуме. Нужно пытаться делать так, чтобы этот конструктор был совместим снизу вверх, то есть чтобы программа написанная под такой "конструктор" версии 1.00, прекрасно компилировалась и работала скажем в версии 1.50. И т.д. и т.п. Основная идея: Создать здесь на форуме некий конструктор, состоящий из процедур, заготовок и документации, который поможет быстро создавать качественные программы. Вот мои мысли. Или моя идея, как обычно будет задушена? P.S. Если эта идея будет поддержана то можно подумать об организации специального раздела на форуме для удобства ведения этого проекта. __________________ С уважением, Станислав. Last edited by CityAceE; 30th November 2005 at 15:09. Reason: очепятки

30th November 2005, 12:22	#2
Sinus Veteran Join Date: 29th January 2005 Location: Belarus, Grodno Posts: 1,270 Thanks: 117 Thanked 189 Times in 87 Posts	фз. у меня пока есть чутка времени, поэтому смогу помочь. однако моё чистое имхо по поводу полезности оставлю при себе. __________________ [target] [zemu] [js8x] [pouet 1, 2] KAY-1024, 5''FDD, 3''FDD, HDD

30th November 2005, 13:47	#3
valker Member Join Date: 27th January 2005 Location: С.-Петербург Posts: 92 Thanks: 7 Thanked 6 Times in 4 Posts	Поддерживаю идею. Думаю, что первым шагом в создании подобного банка будет очерчивание границ применимости, как то: 1. Конфигурация компьютера (ZX48; ZX128; S256;...), 2. Модель памяти (SOLID; CODE_IN_LOW_MEMORY_DATA_IN_BANK; CODE_AND_DATA_IN_BANK;...), 3. Доступные внешние устройства (DOESNT_USE_EXTERNAL; FDD; HDD_SCRP; HDD_NEMO; KEMP_MOUSE;...), 4. Зависимости от системных библиотек (DOESNT_USE_SYSTEM; ...), 5. Режимы работы прерываний (INT_MUST_BE_DISABLED; INT_CAN_BE_ANY; HAVE_ISR;...). Список, естественно, примерный. Каждая единица (модуль, процедура, библиотека), снабжается метками, указывающими на границы применимости. Например: ZX48 SOLID DOESNT_USE_EXTERNAL DOESNT_USE_SYSTEM INT_CAN_BE_ANY - Процедура удовлетворяет требованиям ZX-Spectrum 48, при этом не требует ни внешних устройств, не использует процедуры из ПЗУ, не зависит от режима прерываний. Это позволит тщательнее подходить к вопросу совместимости различных модулей, и выбору "платформы" для программы. IMHO...

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)