Подскажите пожалуйста, На каких языках пишутся игры.

[psb]

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

а научиться можно на ... демках! и себе польза, и ААА радость! попробуешь чего-нить такого по экрану погонять, сразу поймешь кучу фишек и осознаешь что можно потянуть, а что не очень.

[Advertiser]

[Spectramine]

Я не против ассемблера, просто возражаю против того, что на нем легче программировать, чем на бейсике.

Новичку точно не легче. Да и вообще программирование на ассемблере более трудоёмко. Исключение - случаи, когда задача хорошо укладывается в имеющиеся ассемблерные наработки в виде готовых процедур и макросов.

Ассемблер ничем не лучше бейсика с этой точки зрения. А даже и хуже. В бейсике есть хотя бы именованные переменные, массивы, строки, циклы наконец. Они придают программе и данным хоть какую-то структуру.

Ассемблер дисциплинирует мышление в плане структурирования программ лучше, чем бейсик, потому что без процедурного структурирования даже небольшую игру на ассемблере просто не напишешь. На бейсике - вполне. Мало того, в плане визуального структурирования ассемблер лучше бейсика - отступы, пустые строки, комментарии-шапки процедур и циклов. На zx-бейсике длинные строки, без которых чаще всего не обойтись, визуально рвут текст программы, делая отступы бесполезными (к тому же пробелы и комментарии в тексте тормозят выполнение). Так что в целом бейсик всё-таки больше, чем ассемблер, поощряет неупорядоченный стиль программирования. По крайней мере zx-бейсик, очень близкий к чистому бейсику. Я сужу по себе - какие хитрозаплетённые и трудночитаемые программы я когда-то писал на бейсике, и как естественно приходилось структурировать программу на ассемблере.

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

[psb]

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

просто ты не писал хитрозаплетенных программ на ассемблере, вот и вся разница. если говорить о структурном программировании, то ассемблер - это зло злейшее! он разрешает делать вообще ВСЁ, что только можно, и неокрепший ум и будет делать ВСЁ. никогда у него не будет хорошо структурированной программы, ибо поймет он прелести экономии кода, прыгая в кусок другой процедуры, мухлеж со стеком, патч кодом самого себя (как минимум хранение переменной в самой команде) и т.д.

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

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

[Lethargeek]

Я вообще-то имел в виду не кросс-компиляцию, а работу с ассемблером в эмулируемой системе (или на реале)

А зачем? Вот сегодня, начинающему - зачем?

Но даже если писать программу с прицелом на эмулятор: видишь, ты сам описал, сколько всего нужно. Какие-то bat-файлы создавать, стыковать ассемблер с эмулятором.

Ну не создавай, не стыкуй. Ручками грузить снапшот все умеют.

С бейсиком проще. Там всё сразу есть.

Даааа, все сразу? Как насчет локальных переменных? Структур? Указателей?

И программа на бейсике (если только она не делает какие-нибудь POKE или USR) не может привести к сбою компьютера.

Еще как может, например из-за неаккуратного обращения с каналами
Но чем, собс-но, так страшен сбой виртуального компа в эмуляторе?

И опять-таки: допустим, произошел сбой при пробном выполнении программы на ассемблере. Как в этом случае можно проследить его причину, если память перепахана? Бейсик же обычно останавливается с ошибкой

...проследить первоначальную причину которой ничуть не проще
Самые поганые логические ошибки приходится ловить трассировкой
А на бейсике? Стопы с ремами ручонками забивать?

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

При отладке в эмуляторе это попросту НЕ НУЖНО (хотя можно) - И ТАК ВСЕ ВИДНО

Видишь ли, я имел в виду такие ошибки, которые не сами по себе приводят к сбою, а портят где-нибудь содержимое памяти, так что программа сбивается спустя долгое время в другом месте

Так на бейсике ровно то же самое с переменными

При программировании на бейсике вероятность подобных ошибок уменьшается, так как во-первых, имеются именованные переменные, и при присвоении переменной A нельзя испортить переменную B.

Ты не поверишь, в ассемблерах они тоже есть
А еще там есть именованные процедуры, структуры, макросы...

Во-вторых в бейсике постоянно происходят проверки на предмет выхода за пределы диапазона и другие ошибки времени выполнения

Ну забей в макруху явную проверку диапазона
Или точку поставь контрольную

Это смотря какую игру. Начинающий программист, думаю, не потянет работу класса Sea Dragon, например

Ну ты хватил, начинающий даже маникмайнера ниасилит, пусть питона пишет

просто ты не писал хитрозаплетенных программ на ассемблере, вот и вся разница. если говорить о структурном программировании, то ассемблер - это зло злейшее! он разрешает делать вообще ВСЁ, что только можно, и неокрепший ум и будет делать ВСЁ. никогда у него не будет хорошо структурированной программы, ибо поймет он прелести экономии кода, прыгая в кусок другой процедуры, мухлеж со стеком, патч кодом самого себя (как минимум хранение переменной в самой команде) и т.д.

Ерунда. Выкрутасы в структурирующей части просто бессмысленны, в мелких процедурках - безвредны.
Главное, что в асмах ЕСТЬ достаточные средства структурирования, а в синклер-бейсике НЕТУ

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

"Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации" (c) Э.Дейкстра

Если уж приспичило учиться программированию с нуля непременно на Спектруме - начинайте хотя бы с бета-мега-бейсиков, а еще лучше - с Лого (тем более, что Инфорком, помнится, печатал в ZX-ревю перевод учебника), он куда удобней и дружелюбней. Да, они жрут память - но обычному-то бейсику все равно от свободной памяти проку мало, для больших проектов он практически непригоден.

[psb]

Даааа, все сразу? Как насчет локальных переменных? Структур? Указателей?

ничего такого в ассемблере НЕТ
а я и в спектрумовском бейсике могу сделать РЕКУРСИЮ, это не значит что он поддерживает рекурсии.

Еще как может, например из-за неаккуратного обращения с каналами

приведите-ка пример без poke и usr, убивающий все безвозвратно? ))))

Так на бейсике ровно то же самое с переменными

нет не то же самое. присваивая что-то переменной А, В никогда не попортишь. а в ассемблере не тока В испортишь легко, а еще и сам код! а на реалах было и диск убивался от случайного перехода не туда...

А еще там есть именованные процедуры, структуры, макросы...

слишком сложно... мощно, но сложно

Ну забей в макруху явную проверку диапазона

если писать все такими макросами, чем это будет отличаться от бейсика??? кому вообще такое надо?

[Lethargeek]

ничего такого в ассемблере НЕТ

Курим доки (вот хотя бы на SJasm)

а я и в спектрумовском бейсике могу сделать РЕКУРСИЮ, это не значит что он поддерживает рекурсии.

Он локальных переменных-то не поддерживает

приведите-ка пример без poke и usr, убивающий все безвозвратно?

LET a=5:CLOSE #a

нет не то же самое. присваивая что-то переменной А, В никогда не попортишь. а в ассемблере не тока В испортишь легко, а еще и сам код!

Ну давай, попорть что-нибудь, обращаясь к A или B по имени

A:	dw $0
B:	dw $0

...и потом, там речь совсем не об этом (а о том, что ошибочный результат вычислений точно так же может проявиться не сразу)

если писать все такими макросами, чем это будет отличаться от бейсика???

Уровнем абстракции и все так же скоростью, там запас огромный

кому вообще такое надо?

Начинающим - им пока не нужно выжимать из уродца максимум
Или при отладке - кому угодно

[Vitamin]

Что-то уже холиваром попахивает.

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

[psb]

Он локальных переменных-то не поддерживает

правильно, точно так же как и в асме нет ни структур, ни чего-то еще. это НАДСТРОЙКА, как макрос. а надстройку я сделаю в бейсике и у меня будет работать рекурсия. через жопу, но будет! рекурсия! самая настоящая! от этого бейсик не станет поддерживать рекурсии

LET a=5:CLOSE #a

шайтанама!
хорошо, можно к тому условию добавить неиспользование потоков где оно такое реально надо? у нас это не используется, а если используется, то это уже выходит за рамки обычного бейсика.

A: dw $0 B: dw $0

лучше так:
A: db $0
B: db $0
байты же у нас не запрещены? и опа: ld (A),hl...
и даже с тем примером, загрузив адрес А в hl, потом случайно изменив hl, попортишь память.

там речь совсем не об этом (а о том, что ошибочный результат вычислений точно так же может проявиться не сразу)

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

Уровнем абстракции и все так же скоростью

т.е. ты пишешь уже как бы не на языке нормального обычного ассемблера, а на каком-то новом, известном только тебе, диалекте птичьего языка так тогда не парь моск, пиши на си!

Начинающим - им пока не нужно выжимать из уродца максимум

думаю начинающим важно быстрее понять и научиться добиваться результата. ты же предлагаешь вместо простого понятного почти человеческого языка (basic) выучить ассемблер, как работает проц, какие точки входа есть в пзу, выучить макроязык... не слишком ли? синдром линуксоида налицо ))

[Spectramine]

просто ты не писал хитрозаплетенных программ на ассемблере, вот и вся разница. если говорить о структурном программировании, то ассемблер - это зло злейшее! он разрешает делать вообще ВСЁ, что только можно, и неокрепший ум и будет делать ВСЁ. никогда у него не будет хорошо структурированной программы, ибо поймет он прелести экономии кода, прыгая в кусок другой процедуры, мухлеж со стеком, патч кодом самого себя (как минимум хранение переменной в самой команде) и т.д.

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

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

Я имел ввиду не строгое следование канонам структурного программирования, а естественную неоходимость разбиения программы на асме на более-менее автономно написываемые и отлаживаемые блоки. Человеческий разум имеет ограничение на объём одновременно отслеживаемых объектов, именно это естественно заставляет структурировать программы на асме. Конечно, хакерские трюки ассемблер позволяет как никакой другой язык, но на одних трюках более-менее сложную программу не напишешь. Злоупотребление переходами и трюками на асме моментально выливается в очень тяжело отлаживаемые участки кода, что также приводит к осознанию необходимости писать проще.

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

[Barmaley_m]

лучше так:
A: db $0
B: db $0
байты же у нас не запрещены? и опа: ld (A),hl...
и даже с тем примером, загрузив адрес А в hl, потом случайно изменив hl, попортишь память.

Я примерно то же самое хотел сказать. В ассемблере постоянно возникает необходимость пользоваться косвенной адресацией, то есть указателями. А где указатели - там и их неправильные значения, выход за пределы диапазона, перепахивание памяти. Ставить везде макросы и проверки надо вручную. Для этого новичок в ассемблере должен как минимум озаботиться проблемой постоянных проверок времени выполнения. В бейсике все проверки происходят автоматически, и начинающему программисту не надо об этом беспокоиться.

Ассемблер сам по себе ничего не может, даже такой простой вещи, как вывести сообщение на экран. Все это надо делать через вызов подпрограмм из библиотек. То есть с самого начала надо понять, что такое подпрограммы и с чем их едят. При изучении же бейсика подпрограммы проходятся далеко не на начальном этапе. Первые программы новичков обычно настолько просты, что не содержат операторов GOSUB и RETURN. Встроенные средства бейсика позволяют и без подпрограмм добиться интересных результатов (текст, графика, ввод-вывод). Всего этого достаточно даже чтобы написать простую игру.

То же касается, между прочим, изучения паскаля и других языков высокого уровня при первоначальном знакомстве с программированием. Вызов процедур/функций проходится далеко не на начальном этапе.

ты же предлагаешь вместо простого понятного почти человеческого языка (basic) выучить ассемблер, как работает проц, какие точки входа есть в пзу, выучить макроязык... не слишком ли? синдром линуксоида налицо ))

Угу, это точно. Тут можно еще добавить изучение библиотек (арифметика, графика, ввод/вывод). То, что библиотеки существуют, еще не значит, что их не надо изучать.

---------- Post added at 16:01 ---------- Previous post was at 15:49 ----------

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

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

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

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

Я вот еще на что хочу обратить внимание. Всякие редакторы к играм, которыми пользуются разработчики. Это программы, которые предназначены для того, чтобы единожды их использовать и забыть. Скорость в них не важна, важен только результат (уровни). Взять хотя бы Монти-редактор или редактор уровней Sea Dragon. Разработчик, опытный программист на ассемблере, предпочел написать эти редакторы на бейсике. Догадайтесь, почему

---------- Post added at 16:15 ---------- Previous post was at 16:01 ----------

"Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации" (c) Э.Дейкстра

Эта цитата относится к обучению структурному программированию, концепции которого разработал и проповедовал Дейкстра. Именно такое программирование в данном контексте называется "хорошим". Одним из условий этой "хорошести" является отказ от инструкции GOTO. С этой точки зрения ассемблер даже хуже бейсика, потому что там постоянно приходится пользоваться аналогами GOTO, да и остальные средства структурирования программ, такие как локальные переменные, циклы и четко выделенные подпрограммы, отсутствуют.

Если уж следовать заветам великого Дейкстры, то можно начать с обучения программированию на Turbo Pascal под CP/M. Но тогда не будет графики. В бейсике есть графика, и она одна из фактороы, которые очень подогревают энтузиазм начинающих. Ну и средств отладки, изучения состояния программы при останове тоже нет, ведь турбо паскаль - это компилятор.