Важная информация

User Tag List

Страница 1 из 5 12345 ПоследняяПоследняя
Показано с 1 по 10 из 121

Тема: Конструктор (ZX SDK)

Комбинированный просмотр

Предыдущее сообщение Предыдущее сообщение   Следующее сообщение Следующее сообщение
  1. #1
    Administrator Аватар для CityAceE
    Регистрация
    13.01.2005
    Адрес
    г. Москва
    Сообщений
    4,574
    Записей в дневнике
    7
    Спасибо Благодарностей отдано 
    399
    Спасибо Благодарностей получено 
    1,207
    Поблагодарили
    394 сообщений
    Mentioned
    48 Post(s)
    Tagged
    0 Thread(s)

    Exclamation Конструктор (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. Если эта идея будет поддержана то можно подумать об организации специального раздела на форуме для удобства ведения этого проекта.
    Последний раз редактировалось CityAceE; 30.11.2005 в 14:09. Причина: очепятки
    С уважением, Станислав.

  2. #1
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  3. #2
    Veteran Аватар для Sinus
    Регистрация
    29.01.2005
    Адрес
    Belarus, Grodno
    Сообщений
    1,279
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    1
    Поблагодарили
    1 сообщение
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

    однако моё чистое имхо по поводу полезности оставлю при себе.
    [target] [zemu] [js8x] [pouet] KAY-1024, 5''FDD, 3''FDD, HDD

  4. #3
    Member
    Регистрация
    27.01.2005
    Адрес
    С.-Петербург
    Сообщений
    93
    Спасибо Благодарностей отдано 
    7
    Спасибо Благодарностей получено 
    0
    Поблагодарили
    0 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

    Думаю, что первым шагом в создании подобного банка будет очерчивание границ применимости, как то:
    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...

  5. #4
    Activist Аватар для fk0
    Регистрация
    18.02.2005
    Адрес
    St. Petersburg
    Сообщений
    415
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    0
    Поблагодарили
    0 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от valker
    Поддерживаю идею.

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

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

    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...
    Да. Но возможно и немного наоборот, когда выбирается
    версия процедуры применимой в указанных условиях.
    Или выбирается ошибка.

  6. #5
    Guru Аватар для newart
    Регистрация
    19.01.2005
    Адрес
    Санкт-Петербург
    Сообщений
    11,441
    Спасибо Благодарностей отдано 
    192
    Спасибо Благодарностей получено 
    147
    Поблагодарили
    62 сообщений
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  7. #6
    Administrator Аватар для CityAceE
    Регистрация
    13.01.2005
    Адрес
    г. Москва
    Сообщений
    4,574
    Записей в дневнике
    7
    Спасибо Благодарностей отдано 
    399
    Спасибо Благодарностей получено 
    1,207
    Поблагодарили
    394 сообщений
    Mentioned
    48 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

    Цитата Сообщение от daniel
    и получиться очередной велосипед под названием Язык высокого уровня плюс компилятор на базе асма!
    А пусть так! Но что в этом плохого, если это повысит скорость программирования и явится неким катализатором для выхода нового софта?
    С уважением, Станислав.

  8. #7
    Guru Аватар для newart
    Регистрация
    19.01.2005
    Адрес
    Санкт-Петербург
    Сообщений
    11,441
    Спасибо Благодарностей отдано 
    192
    Спасибо Благодарностей получено 
    147
    Поблагодарили
    62 сообщений
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от CityAceE
    А пусть так! Но что в этом плохого, если это повысит скорость программирования и явится неким катализатором для выхода нового софта?
    Я бы просто не стал тратить время на изучение исходников. Новички может и стали бы узать.

  9. #8
    Administrator Аватар для CityAceE
    Регистрация
    13.01.2005
    Адрес
    г. Москва
    Сообщений
    4,574
    Записей в дневнике
    7
    Спасибо Благодарностей отдано 
    399
    Спасибо Благодарностей получено 
    1,207
    Поблагодарили
    394 сообщений
    Mentioned
    48 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

  10. #9
    Activist
    Регистрация
    23.03.2005
    Адрес
    г. Чернигов, Украина
    Сообщений
    477
    Спасибо Благодарностей отдано 
    15
    Спасибо Благодарностей получено 
    1
    Поблагодарили
    1 сообщение
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

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

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

  11. #10
    Alexander Bondarenko (500:3432/3)
    Гость

    По умолчанию Конструктор (ZX SDK)

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

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

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

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

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

Страница 1 из 5 12345 ПоследняяПоследняя

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •