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

[Andrew771]

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

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

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

[Advertiser]

[Error404]

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

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

[Eltaron]

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

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

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

[Oleg N. Cher]

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

Неа, пользователями этого языка, вероятнее всего, будешь только ты один. Я тут такую привлекательную картинку нарисовал: программь под что угодно на чём угодно, и то подавляющее большинство оппонентов против, а не за. Чего уж сказать про Паскаль. Кроме того, человек, который не знает асма Z80, вероятно, не будет писать игры для Спектрума ни на чём. И я предлагаю знатокам асма не замену асму, а просто способ увеличить собственную производительность там, где это можно без потерь (или с малыми).

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

Андрей, но ведь запись X*2+X это реверанс в сторону тупого компилятора, а запись X*3, которая, кстати, нагляднее для понимания (и проще), но которую умный компилятор может перевести в сложения и сдвиги, что, кстати, SDCC делает. Что подтверждает и Eltaron:

sdcc команды умножения очень элегантно заменяет сложениями

Универсальность языка ведет к потере быстродействия и памяти. Для PC это не важно, т.к. там и того, и другого выше крыши. А для Спектрума это существенно. И тут нужно всё подгонять под него.

Есть такая библиотека KOL, Владимир Кладов написал. Так она уже занимает больше мега исходников. Туда можно очень много добавить. Но программы, которые делаются на этой библиотеке, преимущественно размером < 100 Кб. Это очень реальный даже для Спека размер. Всё дело в подходе, потому как из KOL берётся только то, что используется. Примерно также можно сделать и с универсальностью. Да, у Спека экран устроен иначе, но в некоторых случаях для универсальности этим можно пренебречь. И пренебрегают, отсюда клэшинг атрибутов. Или ч/б вместо цвета. Всё можно продумать и сделать. Но очень трудно найти хотя бы 2 человека, которым на 100% понравятся все твои (или мои) идеи. Проблему я вижу именно в этом. А не в чрезмерной универсальности. Ну вот, спрайты Даша прекрасно себе чёрно-белые на Спеке и цветные под досом. Логика игры этот факт игнорирует, оставляя реализацию графической подсистеме. Разрешение экрана устройства она тоже игнорирует, манипулируя разрешением лабиринта. И так далее.

А писать процедуру вывода спрайтов на ЯВУ они не будут - это неработоспособно.

Я разве где-то предлагал такое делать? Всякому овощу свой сезон, а всякой задаче свой язык.

Ладно, давай искать точки соприкосновения дальше. Ты собираешься реализовывать ReadLn для строк и чисел? Если да, любопытно было бы взглянуть. Я сделал такую процедуру ещё на языке Coloss, и она позволяла редактировать введённое число только полным затиранием и перенабором, сейчас полагаю, это надо исправить. Нервы юзеров дороже. Нужно обязательно реализовать забивку (Backspace), курсор влево-вправо. Ещё есть идея реализовать память для прошлых введённых значений (вдруг новое число проще получить из старого путём изменения одной цифры) по клавишам вверх-вниз (примерно как было в досовской проге Doskey, очень удобно). Функционал буфера прошлых введённых значений можно сделать опциональным (нетрудно придумать задачу, где он не нужен). Согласен или предпочитаешь что-либо попроще (или другое)?