Разработка программ и игр для ZX Spectrum на языках Оберон-семейства

[Andrew771]

Oleg N. Cher, ну всё-таки ЯВУ на Спектруме, ИМХО, в наше время нужен в подавляющем большинстве случаев для написания игр. Софт на нем будет сложно написать, не экономично по памяти и так себе по быстродействию. К тому же, вряд ли новый софт для Спека кто-то будет писать. Остаются игры.
В играх важны в первую очередь: вывод спрайтов, вывод текста, реагирование на клавиатуру и джойстик, обработка двумерной карты/полей. Не важны: числа с плавающей точкой, обработка строк, многомерные массивы. Можно обойтись без записей. Плюс в Спектруме выгоднее делать умножение/деление и размерности массивов на кратные 2 числа. Вот это я и хочу реализовать, отбросив всё лишнее, оставив только важное и нужное.
Т.е., язык будет подогнан под архитектуру Спектрума и не более, будет урезанным по сравнению с оригиналом, но за счет этого оптимизирован для Спектрума. Поэтому SDCC и другие существующие компиляторы не подходят - они не оптимальны конкретно для Спектрума, т.к. универсальны и хотят быть совместимыми со всем и вся. И вызывает сомнение компиляция через промежуточный язык С - могут добавиться к изначальной универсальной кривости Оберона/Паскаля ненужные извращения С.
В общем, я за узкую локальную задачу - оптимизированный язык-инвалид для единственной платформы Спектрум.

[newart]

В общем, я за узкую локальную задачу - оптимизированный язык-инвалид для единственной платформы Спектрум.

Ну инвалидность же нисколько не мешает существованию компилятора скажем под PC?

[Oleg N. Cher]

Andrew771, делать высокодинамические или большой сложности игры на Паскале для Спектрума – это ещё бОльшая идея фикс чем компиляция через Си. Дело в том, что если в технологии высокоуровневого клея (в Обероне, Си или Паскале) для Спектрума будет накоплено много разнообразных и очень оптимизированных асм-библиотек (ессно не вшитых в компилер), то сама суть клея – клеить – будет помогать быстрой разработке (причём софта тоже, не только игр. А в чём ты видишь преграду для этого?), а непосредственно высокий уровень останется для скорого макетирования или, скажем, разработки утилит (типа конвертеров), для которых не столь уж важно быть написанными именно на асме, главное чтобы они были написаны быстро и без ошибок. И код имел бы хорошую наглядность, необходимую для дальнейшего наращивания функционала утилиты.

SDCC подходит для Спектрума чудесно. Лучшего кодогенератора с ЯВУ, чем SDCC, для Z80 нет и процентов 99, что никогда не будет. Поэтому можно спокойно игнорировать этот факт, а можно и нет.

В играх важны в первую очередь: вывод спрайтов, вывод текста, реагирование на клавиатуру и джойстик, обработка двумерной карты/полей. Не важны: числа с плавающей точкой, обработка строк, многомерные массивы. Можно обойтись без записей. Плюс в Спектруме выгоднее делать умножение/деление и размерности массивов на кратные 2 числа. Вот это я и хочу реализовать, отбросив всё лишнее, оставив только важное и нужное.

Вот поэтому и нужно сделать библиотеки (а не вшивать весь функционал внутрь компилера раз и навсегда), которые будут реализовать вывод спрайтов, вывод текста, реагирование на клавиатуру и джойстик. И все эти функции будут доступны из всех языков среды. Т.е. кроссъязыковость и кроссплатформенность. Вот что я предлагаю.

Числа с плавающей точкой, обработка строк, многомерные массивы должны быть обязательно реализованы на уровне языка, и они никак не помешают. Это дополнительные возможности, и когда уровень технологии будет расти, будет расти и круг задач под неё. Нельзя обойтись без записей. Это конструирование пользовательских структур данных, делать без записей что-то серьёзное сложно. Эмулировать записи через массивы – тоже не фунт изюму. Умножения и деления, кратные 2, – частный случай остальных умножений и делений. Надо реализовать все деления и все умножения, но кратные двум будут просто оптимизированнее. И ессно при программировании под Спектрум все будут этим фактом активно пользоваться.

Вобщем, язык-инвалид это конечно хорошо, но тогда проект делаешь чисто для себя. Я бы предложил тебе максимально ориентироваться на совместимость с Turbo Pascal (и по библиотекам, но с поправкой на кроссплатформенность). Я вот тоже хочу понять, для себя я делаю ZXDev, или же это интересно и ещё кому-то. Если за несколько месяцев не будет очень ярко выраженного интереса и помощи, забью конечно.

Alex Rider, прошу прощения, исправлюсь.

[Andrew771]

Пользователями этого языка, судя по темам на форуме, будут те, кто не знает или не хочет изучать ассемблер. Они не собираются писать софт под Спектрум (тут без асма никуда), а только игры. Кто знает ассемблер, скорее всего, не будут использовать язык или будут ограниченно.
Для игр, как я уже написал, важны только некоторые составляющие языка: вывод спрайтов, вывод текста, опрос клавиатуры/джойстика, обработка двумерной карты. Остальное не важно и не нужно. Плюс, по своему опыту написания игр на асме, всегда идет подгонка под массивы с размерностью кратной 2 и умножение/деление кратное 2. Если, к примеру, X нужно умножить на 3, то я пишу на асме X*2+X, а не использую специальную процедуру умножения на произвольное число (умножение на 2 - это всего лишь сдвиг регистра влево на 1 бит).
Игры, где используются числа с плавающей точкой - обычно трехмерные, тут уже без асма не обойтись из-за быстродействия. Да и то, в них не происходит "честное" вычисление функций, а используются заранее вычисленные таблицы. Поэтому ЯВУ тут не нужен.
Записи - не очень нужны. На асме, как правило, разные поля записи в памяти размещаются своими отдельными массивами - так проще вычислять их адрес, чем лазить по целым записям, чтобы отыскать нужное поле.
Многомерные массивы - не нужны. Из-за ограниченной памяти. Трехмерную игру не напишешь на них, для двумерных - они не нужны.
Обработка строк (имеется в виду вырезание, склеивание, поиск, замена) - больше для софта подходит, чем для игр. Может только в каких-нибудь играх с искусственной речью нужны. Можно исключить.

Это дополнительные возможности, и когда уровень технологии будет расти, будет расти и круг задач под неё.

Да не будет уровень технологии на Спектруме расти, и будущего у Спектрума нет. Это ретро-платформа. Максимум технологии по быстродействию и памяти - это программирование на голом ассемблере табличными методами, таблицы подгоняются под удобные адреса, а не под удобную структуру объектов-записей.
Универсальность языка ведет к потере быстродействия и памяти. Для PC это не важно, т.к. там и того, и другого выше крыши. А для Спектрума это существенно. И тут нужно всё подгонять под него.
Повторяю. Люди, которые умеют программировать на ассемблере, будут писать на ассемблере, и даже в качестве "клея" им не понадобится универсальный ЯВУ, проще на ассемблере с макросами. Те, кто не умеет на ассемблере, будут пользоваться универсальным ЯВУ, если он будет намного лучше Бейсика по быстродействию и памяти, если в нем есть библиотека быстрых процедур вывода спрайтов, текстов и прочее. А писать процедуру вывода спрайтов на ЯВУ они не будут - это неработоспособно.

[newart]

Люди, которые умеют программировать на ассемблере, будут писать на ассемблере

Не пишу и больше не буду. Надоело. PureBasic развратил.

[Error404]

Пользователями этого языка, судя по темам на форуме, будут те, кто не знает или не хочет изучать ассемблер. Они не собираются писать софт под Спектрум (тут без асма никуда), а только игры. Кто знает ассемблер, скорее всего, не будут использовать язык или будут ограниченно.

Сразу видно игродела.
Вообще-то, все с точность до наоборот. Это игры еще как-то можно писать на асме, а вот сложные системы (ОС и утилиты, или тот же TCPIP) гораздо удобнее писать на С, тем паче что на С можно делать большие заимствования (портировать уже готовое) - это очень существенно в условиях когда поднять что-то большое с нуля уже ни у кого из форумчан не хватает потенции. И если говорить за пакет SDCC, то крайне необходима среда разработки на С с нормальным отладчиком (а не убогим SDCDB). Хотя бы как обертка над тем же SDCDB.
То, что вместе со средой разработки на C будут приятные плюшки в виде Оберонов, это только в плюс.

[Advertiser]

[Eltaron]

Если, к примеру, X нужно умножить на 3, то я пишу на асме X*2+X

Лол, распальцованным ассемблерщикам пофиг что (X << 1) + X выполняется МЕДЛЕННЕЙ, чем X + X + X?

sdcc команды умножения очень элегантно заменяет сложениями, проигрыш в производительности будет только если умножать на число чуть меньшее, чем степень двойки, типа 2^n-1. Потому что тут можно обойтись сдвигом и вычитанием, а sdcc все равно генерит сложение.

[jerri]

Error404, и много ты сложных систем на Спек пишешь?
я смотрю для спека все системные программы практически написаны

---------- Post added at 11:44 ---------- Previous post was at 11:42 ----------

Лол, распальцованным ассемблерщикам пофиг что (X << 1) + X выполняется МЕДЛЕННЕЙ, чем X + X + X?

really?

ld d,h
ld e,l
add hl,hl
add hl,de

VS

ld d,h
ld e,l
add hl,de
add hl,de

[Eltaron]

jerri, эээ, что-то старый я стал, сдвига не вижу

[jerri]

ld d,h
ld e,l
add hl,hl
add hl,de

чем тебе не сдвиг?
да да совсем старый на грязи надо ехать отдыхать - привыкать