Внутренности программ

[svofski]

Супер, еще бы управление удобное сделать. Или wasd или курсор+пробел, но не asd+пробел

Если думать по геймпадному, asd + пробел становится понятней. Но конечно стрелочки я добавлю, тут я даже не подумал написать про управление -- думал не об этом.

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

Приблизительные идеи о достижении плавности:
1. враги становятся спрайтами
2. координаты потапа и врагов обретают дробную часть
3. тайлы, которые используются для определения коллизий, остаются, но заменяются пустышками

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

[ivagor]

Я не против плавности, но это будет уже несколько другая игра.
Что можно было бы улучшить в ремейке потапа для вектора:
1. Свести к минимуму тиринг. Скорость классической векторовской версии вполне достаточная, но главгерой при движении помаргивает. Ну и в векторовской версии есть недоработка - если задеть exit боком, то он частично сотрется и так останется, это тоже можно поправить.
2. Попробовать реализовать на бейсике. Вот тут конечно тяжко. Или свести функцию бейсика к вызову подпрограмм на асме или что-то такое сделать с бейсиком, чтобы он сам что-то мог. Кстати, есть версия на бейсике и для советского компа на ВМ80 - ПК8002. Правда там аппаратные тайлы и спрайты и портированный туда msx basic.

[svofski]

Было бы интересно понять, насколько другая. Пока это в Godot, цена эксперимента не так велика. Тут еще не знаю как оценивать. Сам я тот еще игрок к сожалению: когда начинаются уровни с пролетом над огнем итд у меня терпение лопается очень быстро.

Тиринг в Векторовской версии никогда меня не напрягал. Кстати в эмуляторах MSX мельтешня заметна гораздо сильнее, но оно и понятно. Вот идея перенести целиком на бейсике забавная, но боюсь, что тут самый простой способ -- это перенести сначала соответствующий бейсик. Ну и я не знаю, что именно в бейсике вызывает такие атомные тормоза (похоже, что правильный ответ "всё"), но если не переделывать в нем что-то радикально, шансов догнать оригинал тут по-моему никаких нет.

[ivagor]

Ну и я не знаю, что именно в бейсике вызывает такие атомные тормоза (похоже, что правильный ответ "всё"), но если не переделывать в нем что-то радикально, шансов догнать оригинал тут по-моему никаких нет.

Могу только согласиться

[svofski]

Могу только согласиться

У тебя большой опыт ковыряния в бейсиках. Что в них так тормозит? Например, они правда парсят каждую строчку по мере исполнения и никак этому нельзя помочь? Токены ок, но кроме токенов остаются аргументы функций и арфметические выражения, они видимо вычисляются каждый раз на ходу? Если попробовать на миг забыть наследие Альтаира с 8К памяти, что можно в бейсике изменить, чтобы сделать его быстрее. Объективно, не примериваясь на собственные ресурсы, но и не меняя язык, не превращая его в компилятор итд, а вот именно в рамках того, чем он является.

[goodboy]

на ZX есть `компиляторы` которые на самом деле не переводят строку в маш.код,
а конвертят её в формат более быстрый для передачи в интепретатор.
например Tobos

[svofski]

на ZX есть `компиляторы` которые на самом деле не переводят строку в маш.код,
а конвертят её в формат более быстрый для передачи в интепретатор.
например Tobos

У меня тоже была мысль первая -- зачем останавливаться на подмене операторов на токены, если можно все прожевать в деталях (но так, что бы потом можно было восстановить). Для листинга и редактирования можно потерпеть как фарш проворачивается назад, а для исполнения все же иметь то, что легко исполнить, а не легко отредактировать. Но пока я не знаю что на самом деле там происходит, так что это все так, слова и жестикулирование.

Константы можно было бы хранить в обработанном виде. Тут правда трудно соблюсти однозначное соответствие между текстом и внутренним представлением. Как отличить 0003 (ну захотелось мне так написать) от 3. Например так: токен "const-int", 3, индекс строки "0003" в таблице строк. Больше памяти нужно, ну и что.

А выражения как обрабатываются? Каждый раз строится дерево с нуля (наверное на ходу прямо исполняясь) ?

[ivagor]

В "постмикрософтовских 3.2" бейсиках, крайне популярных на советских компах с ВМ80:
1. Каждое обращение к переменной приводит к ее поиску по имени в области переменных
2. Константы каждый раз переводятся во внутреннее представление
3. Каждый переход/вызов подпрограммы приводит к поиску строки с требуемым номером по всей программе
4. Отдельно можно отметить наличие только 4х байтной плавучки (хотя и довольно хорошей в своем классе) при отсутствии 8-16 битных целых. Тут более поздние микрософтовские бейсики (в т.ч. msxный) отыгрываются, у них есть целые.

- - - Добавлено - - -

Ну и можно вспомнить микрософтовский компилятор бейсика для CP/M. На нем в принципе можно писать программы для вектора, но это отдельная история.

[svofski]

Да тут вообще непочатый край. Отсутствие целых это особенно ржавые вилы. Я наоборот предпочел бы целочисленный бейсик.

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

[ivagor]

Если правильно помню, то строка -- это два байта номер строки, байты токенизированной строки, 0. Длины нет.

Перед этим идет адрес начала следующей строки, т.е. все плохо, но не совсем. Переход на строку резво скачет от строки к строке, проверяя только номер.