Отвечаю, хоть и несколько запоздало (у вас тут дискуссия уже далеко зашла). По Вашим, Barmaley_m, ответам вижу полное непонимание написания программы на ассемблере. Все время проекция оного с метода написания на бейсике. Я ж написал, что принцип одинаков. Но нельзя понимать это буквально. Одинаков подход к написанию, но методы отладки и использования дополнительных процедур разные. Итак, по порядку:Сообщение от Barmaley_m
Во первых, я не имел ввиду написание программы на асме в магнитофонном варианте, хотя и так я писал года до 1994-го. В Gens3 потом в 4-м. И ещё в Zeus. Сохранял на кассету текст перед компиляцией и запуском. Да. Думать приходилось сильнее, а не тут же жать на кнопку запуска. Я далее это поясню.
Совершенно несогласен. Во первых, в отладчиках (под которыми предполагается отлаживать программу которую мы пишем) есть режим эмуляции кода. Есть точки останова. Хотя я в 1992-1994гг ими не пользовался, а пользовался (как тут уже писали) монитором прошивки "турбо-90", вывел себе проводок от 17-й ноги Z80 и быстро проводил проводком по радиатору БП. Комп вылетал в монитор. Вот вам и прерывание. Да, иногда все напрочь висло (о этом случае я писал в Ревюшке'93), но это не смертельно. А вот с бейсиком беда. остановить его мы можем (хотя используя несложный прием мы это можем отключить), но как посмотреть состояние программы? Нужно проверять значения всех переменных (глобальных) вводя кучу команд... Сложнее чем в отладчике.
Вот тут вообще не понял. С моей т.з. в этом отношении и бейсик и асм одинаковы. Ведь как пишется программа? Мы продумываем структуру, блоки, их взаимосвязь, а потом уже начинаем реализовывать задуманное. Грубо говоря приводя программу к структурированному виду, когда вся программа это иерархическая система "черных ящиков". У каждого ящика есть вход и выход. Нам надо реализовать функционал, потом о реализации можно забыть. Важно что бы ящик делал то, что нам надо. Делаем "внутренности" раскладывая сложные алгоритмы в набор более простых, вернее пишется скорее всего наоборот (уже когда структура программы проработана) пишем сначала базовые процедурки, потом на их основе более сложные и т.д. В бейсике процесс написания абсолютно аналогичен. И в паскале также. Предвижу возражения, что дескать "мы так не писали, писали как получится". В том то и дело, что если делать так, то ничего серьезного не напишешь. Это обычная тактика новичков, кто учится программировать. Бейсик для этого и предназначен, но и на нем можно писать так как я описал выше.
Тут согласен, но отчасти. Разборщик выражений в бейсике логической ошибки в программе не увидит и будет сидеть начинающий проггер и тупить над программой, а ошибка может быть и в алгоритме вычислений и в логике, да где угодно. А в асме без библиотки арифметических функций делать нечего. Нужен набор процедур, или самописный (что лучше всего, сначала писать их, учить асм, учить команды проца) или чей-то. Здесь ещё хочу сказать, что нужны базовые знания по программированию, в области арифметики. Т.е. точное представление двоичной и шестнадцатеричных систем исчисление, представлять себе деление, вычитание, сравнение, умножение, деление чисел. Знать алгоритмы быстрого деления и умножения сдвигом. В бейсике это не нужно, но знать программисту это всё равно надо. Такое мое мнение.
Можно пользоваться подпрограммами ZX-Basic, или опять же иметь свои наработки. Это полезней со всех сторон. Необходимо понимать как работает машина. Начинающие писать на бейсике этого сознательно лишаются. Они изучают некую абстрактную бейсик-машину. Со своим экраном, клавой и памятью в виде переменных и массивов. С одной стороны в этом и был смысл бейсика, абстрагировать обучающихся от железа, что бы они учили процедурное программирование. Но в этом и грабли на будущее. Т.е. зацикливаться на чем то одном не надо. Пописал человек 2-3 месяца на бейсике, более-менее изучил его и надо двигаться далее. Изучать в первую очередь архитектуру машины, основы программирования на асме (то что я выше описывал) и примерно через полгода уже можно приступать к написанию первых процедур. И уже позднее программ. Т.е. смысл сказанного мной таков. Имея знания о архитектуре компа, имея опыт написания программ процесс написания на бейсике и на асме будет похож. Примерно как снимать очень дорогой камерой изменяя и контролируя несколько десятков параметров и телефоном, нажимая на одну кнопку. Получаем и соотв. результаты.
Нужно не только изучать сам бейсик или асм, а изучать программирование, архитектуры проца, конкретной машины, видоподсистемы. Представлять себе как можно реализовать алгоритмически аркадную игру (типа Exolon, R-Type, River Raid, Crazy Cars). Как написать движок. И уже потом можно браться за инструмент. Бейсик, Паскаль, Си или асм. Есть примеры игр совершенно другого плана, изометрия, 3D (Dark Side и прочие), адвентюры с графикой и без и т.д. И каждый тип имеет свой движок, свои особенности. Не зная их, не понимая даже при идеальном знании Паскаля или Си игру не напишешь. Поэтому вопрос заданный в теме мне не понятен. Вернее понятен, что автор некорректно поставил вопрос из-за не понимания вопросы программирования игр вообще.
А ещё хотелось бы сказать, что проблемы освоения асма, паксаля или Си возникали ранее у тех, кто начинал с бейсика из-за скомканности обучения всему что связано с компьютерами. То кидаются в сторону алгоритмов, то учим бейсик, то устройство компа обзорно. В этом проблема. Масса отрывочных сведений, мало связанных между собой. Человеку который видит это всё впервые сложно усвоить всю инфу и адекватно её воспринять. Однобокое, неполное понимание в дальнейшем создает проблемы. Некоторые люди в упор не воспринимают hex числа, при том пишут программы на асме. Вот вам привет из zx-бейсике (в других реализациях бейсика hex числа есть). Т.е. если изучать всё планомерно и последовательно, что из себя представляет компьютер и с чем его едят, то и проблем будет меньше.
Ответить с цитированием