Ну естественно, вещественными лучше не пользоваться, они ж там программные. Не пойму, правда, какая связь sincos и заливки. Как пример, вот на что способен был ARM2 8мгц в двухмерных игрушках без какой-либо аппаратной помощи:
www.youtube.com/watch?v=t4hfPKWM4Mk

Doom в уменьшенном примерно до gba-шного размера окошке сносно шевелился на 386DX40. По моему опыту, уже самые первые армы примерно в 2+ раза эффективней по тактам были. Так что в «ужасном качестве» я склонен виноватить кривые ручки (программистов Дума, компилятора, или разработчиков железа геймбоя). В архимедовских демах, вон, даже воксельный ландшафт бодро бегал:
www.youtube.com/watch?v=bLdpCIfOqmw (с 17:50)

Когда я дошёл до вращающихся фонов и спрайтов, то обнаружил, что вычисление двух sincos не пролазит в стабильные 60 кадров в секунду. Вещественными лучше вообще не пользоваться и картинка должна несколько улучшится. Но в любом случае — например Doom на этой платформе шевелится еле-еле в ужасном качестве.

можем наглядно увидеть, что пиксельные видеорежимы 16-мегагерцовым ARM-ом GBA заливаются довольно медленно и их реальное применение в играх очень сильно ограничено

Что-то здесь не то. Такой арм, навскидку, должен в кадре успевать залить такой маленький экранчик несколько раз. А тут либо компилятор сосёт, либо дикие задержки доступа к видеопамяти. Во всяком случае, причина явно не в 16 мегагерцах.

Доку на SMD нагуглить очень легко, её ещё HWM переводил на русский лет 15 назад. Называется Genesis Technical Overview, в любительских кругах наиболее известна под названиями sega2.doc в оригинале и Sega Tech в переводе:

www.genny4ever.net/g4e_modules2/download.php?file=genesis_technical_overview
tv-games.narod.ru/hard/Sega_Tech_Rus_1_5b.rar

До кучи:

segaretro.org/Mega_Drive_official_documentation

Дока для SNES более редкая, долгое время её передавали из под полы, вероятно боясь гнева Nintendo. Состоит из двух книг, циркулирующих под названиями snes_book1.pdf и snes_book2.pdf. В одной описана сама SNES, в другой сопроцессоры:

archive.org/details/SNESDevManual

Касательно вхождения на рынок, ну, 99% всех европейских разработчиков не являлись разработчиками под игровые автоматы, да и вообще опытными разработчиками. В интернете множество интервью с ними, тем более сейчас, и узнать, как создавались игры, несложно. Не знаю, например самое известное:

games.greggman.com/game/programming_m_c__kids/
dutycyclegenerator.com/

А есть ссылки на офдоки от SMD и SNES? Вот реально гуглил много и часто, но не видел.
До сих пор грызёт любопытство как же в 80-х эти игры создавались, даже после прочтения пары статей на эту тему.
Такое ощущение, что шансы войти в этот рынок тогда не являясь разрабом под игровые автоматы был минимальным.

ничоси жесть

Спасибо за ссылку!

Официальные доки очень давно доступны как минимум для Atari 2600, Atari 7800, Sega Genesis, SNES, Neo-Geo.

P.S.
Качество видео отстойное и что-то не могу найти лучше на ютубе. Лучше посмотреть на эмуляторе хотя бы взяв образ картриджа отсюда: www.pouet.net/prod.php?which=19030

Тем не менее для демосцены он довольно любопытный зверь — тут вмешивается фактор портативности. т.к. он портативен и должен питаться от батареек, то серьёзно отстаёт своим нутром от своих лет. фактически он реально что-то типа i386 без сопроцессора и Doom в убогом разрешении еле шевелится. При этом пикантности добавляет то, что «давить соки» реально можно — разные виды памяти с разной шириной шины заставляют проворачивать такие трюки, как пропихивание быстро работающих куском ARM32-кода в 32-битное внутреннее ОЗУ и так далее — это довольно всё любопытно с точки зрения демосцены.
Например вот:

SMS мне понравилась тем, что в отличие от всех остальных 8/16-битных консолей можно нагуглить: официальную документацию от производителя (а не изучать только доки создателей эмуляторов). И что характерно — в документе, то есть как бы полном описании всего «API» консоли от ввода и графики до звука — всего 44 страницы из которых последние 14 — это приложения и примеры тестового кода. У DirectX под XBox One этого наверное и на оглавление то не хватит…

он 2001 года, а в плане фрога по очищению русской демосцены до 1991 года платформы

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

Рекомендую также обратить внимание на Sega Game Gear. Это почти то же самое, но ещё плюс сотня-другая игр. Только придётся заморочиться с расширением отображаемой части уровня, но это многократно делалось любителями, они нередко адаптировали игры, в обе стороны.

WLA DX конечно стандарт, и в общем-то хорош, но очень уж глючный, особенно в части редких процессоров. Так что его использования стараются избегать, и именно по причине проблем с WLA наделали немало альтернатив. Он с тех пор вроде как исправился, но осадочек-то остался. Сам до сих пор использую его для SNES (только для 65816), но это вынужденная мера, tcc-816 завязан на него (адски глючная связка).

Прикольно!

Кажется, у нас новая платформа-кандидат на победу в ZX Spectrum 640k demo compo 2019!

нашёл видео за эту систему:

Меня никогда не интересовало программирование само по себе — красота кода и прочие подобные штуки. Программирование для меня всегда остаётся просто необходимым инструментом — хочу делать игры, значит надо писать код. Вероятно поэтому разные процессоры не доставляют мне особых проблем, и я не заморачиваюсь размышлениями, где что лучше и где проще-сложнее, просто пишу на том, что есть. Сложность кода вообще штука такая — если для решения задачи нужен какой-то трюк (чтение стеком на Z80 или 16-битное сравнение со знаком на 6502), это не сложность и не неудобство, это один раз научился и дальше применяешь по необходимости, а то и просто заворачиваешь в макрос и забываешь. Сложность кода начинается скорее на алгоритмическом уровне, а на уровне реализации алгоритма на ассемблере это одинаково не сложно и не просто, это просто есть как есть.

Это к тому, что мне просто по образу мышления не приходят в голову абстрактные типовые задачи. У всех платформ помимо процессора также и своя специфика во всём остальном, в частности в видеосистеме, где в основном критична скорость кода. Где не критична, там я особо не оптимизирую, пока не возникает реальная необходимость, потому что важнее закончить проект в целом и не перегореть (make it work, make it pretty), чем закопаться с головой в несущественных для общей картины деталях. Как правило в целой игре не так уж много узких мест, где нужно выжимать максимум.

Наверное, для тестов производительности нужно придумать виртуальную систему, где всё железо одинаковое, разный только процессор. Например, для удобства, Pentagon (потоиу что полностью софтовая графика, есть необходимость жёсткой оптимизации, и нет торможения по всей памяти), но с 6502 на 1.75 МГц. Для начала можно посмотреть предельную пропускную способность, развёрнутый цикл, задачи максимально быстрой очистки экрана и максимально быстрого заполнения экрана произвольной графикой (как мы делаем во фреймовых листалках):

Очистка (lps — сколько раз выполнится такой за секунду на соответствующей частоте процессора):

ld sp,#5b00		;10
 ld hl,#0000		;10
repeat 3456
 push hl		;11*3456
endrepeat

=38036t (92 lps), 3462b

lda #0			;2
repeat 6912,N
 sta $4000+N		;4*6912
endrepeat

=27650t (63 lps), 20738b

Разница в скорости на треть. В размере очень большая, что ожидаемо — код на 6502 всегда заметно многословнее.

Зарисовка:

ld sp,#5b00		;10
repeat 3456
 ld bc,NNNN		;10*3456
 push hl		;11*3456
edup

=72586t (48 lps), 13827b

repeat 6912,N
 lda #NN		;2*6912
 sta $4000+N		;4*6912
endrepeat

=41472t (42 lps), 34560b

А вот в копировании разница уже не такая большая, всего 6 условных единиц.

Эти тесты не показывают ничего конкретного, кроме одного: не всё так однозначно, как кажется. Где-то проигрыш 6502 очень заметен, где-то результат очень близкий. По практическим задачам (эффекты на ZX и C64, порты биперных движков с ZX на Atari) мы давно уже знаем, что разница по мере роста сложности алгоритмов сводится к минимуму, всюду возможно примерно одно и то же.

Я не помню каких-то особых сложностей с 6502. Запомнились только программные проверки на коллизии из-за того что экран по горизонтали больше чем 256 и Х координата не влезвет в 8-бит :) Да и то нашёл решение в инете, самому лень было писать

Ну вот я в своё время искал как раз про это — мне не понравилось. :) Сложение 16-битных обязательно через CLC/ADC/ADC (8-битные), при том что расположение аргументов выше zero-page — нехорошо раздувает код (как всегда, впрочем), копирование произвольного региона памяти в два 8-битных цикла через медленную на этой платформе косвенную индексацию (поэтому если адреса регионов заранее известны или менее 256 байт, то нужно оптимайзить). Вкусовщина или нет, но на меня такое навевает уныние.
А вообще я тоже за подобные вводные уроки по «хитростям» 6502.

Да просто начни делать :) Я когда писал Alter Ego под комод через какое-то время просто грохнул исходник и со второго раза сделал так что заработало. Но тот первый раз вот и был поиском решений стандартных для игры задач. А в целом всё как aa-dev описал выше. Я использовал kickass IDE, там сразу и бэйсик стартер есть, редактор спрайтов, тайлов и.т.п. Один минус — большинство примеров под комод не под синтаксис kickasm, но это не особо страшно.

Жмах