• avatar VBI
  • 0
я делал проще — отрезал голову, тело на сковороду в ковокс и вперёд :))
  • avatar aa-dav
  • 0
Ааа… У WAVE не заголовок — там RIFF-формат у которого замороченная древовидная структура может быть со всякими опциональными блоками типа названия авторов и тому подобное — сам код парсящий вынужден быть потому рекурсивным в обработке этих блоков.
  • avatar VBI
  • 0
заголовок Wav ;)
  • avatar aa-dav
  • 0
Всмысле слить в одну статью? Ну я начинал делать на жж где есть ограничение на размер поста и мне кажется тут оно тоже должно быть.
  • avatar VBI
  • 0
может я невнимателен, но — почему просто не отрезать заголовок вавки и потом читать их в массив?
  • avatar aa-dav
  • 0
Тем не менее, если смотреть в доки от самого ARM, то там написано: infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0210c/CACBCAAE.html
"...ideally suited to embedded applications with restricted memory bandwidth, where code density and footprint is important". Поэтому я нисколько не отклоняюсь от официальной точки зрения на вопрос. :)
Всё же термин «плотность кода» относится к размеру довольно крупных осмысленных фрагментов, а не размеру опкодов отдельных команд; первое со вторым необязательно сильно связано, и необязательно однозначно положительно во всех случаях. Thumb понадобился не для уменьшения статического размера кода (для чего эффективнее программные методы), а в основном, действительно, во избежание двукратной потери скорости на 16-битной шине, весьма распространённой в нише встроек и мобилок (особенно в те года). Вот для Thumb-2 уже соображения экономии размера кэша играли роль.
Божественная эстетика.
  • avatar aa-dav
  • 0
Проблема теста из этой главы в том, что он использует вещественное деление чтобы вычислить фпс, а это на данной платформе чрезмерно щедрый шаг, могущий это самое фпс уронить. Насколько — мне уже правда неинтересно, ибо 3Д на этой платформе был как раз ровно в той эпохе (по мощности аппаратуры) когда даже захудалое 2D уделывало даже крутое 3D по эстетике. А 2D здесь разумнее реализовывать через «аппаратно ускоренные» тайловые видеорежимы о которых следующая глава. На GBA реально были 3D-игры в пиксельных видеорежимах, но они были не очень в принципе все.
Ну естественно, вещественными лучше не пользоваться, они ж там программные. Не пойму, правда, какая связь sincos и заливки. Как пример, вот на что способен был ARM2 8мгц в двухмерных игрушках без какой-либо аппаратной помощи:
www.youtube.com/watch?v=t4hfPKWM4Mk

Doom в уменьшенном примерно до gba-шного размера окошке сносно шевелился на 386DX40. По моему опыту, уже самые первые армы примерно в 2+ раза эффективней по тактам были. Так что в «ужасном качестве» я склонен виноватить кривые ручки (программистов Дума, компилятора, или разработчиков железа геймбоя). В архимедовских демах, вон, даже воксельный ландшафт бодро бегал:
www.youtube.com/watch?v=bLdpCIfOqmw (с 17:50)
  • avatar aa-dav
  • 0
Когда я дошёл до вращающихся фонов и спрайтов, то обнаружил, что вычисление двух sincos не пролазит в стабильные 60 кадров в секунду. Вещественными лучше вообще не пользоваться и картинка должна несколько улучшится. Но в любом случае — например Doom на этой платформе шевелится еле-еле в ужасном качестве.
можем наглядно увидеть, что пиксельные видеорежимы 16-мегагерцовым ARM-ом GBA заливаются довольно медленно и их реальное применение в играх очень сильно ограничено

Что-то здесь не то. Такой арм, навскидку, должен в кадре успевать залить такой маленький экранчик несколько раз. А тут либо компилятор сосёт, либо дикие задержки доступа к видеопамяти. Во всяком случае, причина явно не в 16 мегагерцах.
  • avatar Shiru
  • 6
Доку на 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/
  • avatar aa-dav
  • 0
А есть ссылки на офдоки от SMD и SNES? Вот реально гуглил много и часто, но не видел.
До сих пор грызёт любопытство как же в 80-х эти игры создавались, даже после прочтения пары статей на эту тему.
Такое ощущение, что шансы войти в этот рынок тогда не являясь разрабом под игровые автоматы был минимальным.
  • avatar VBI
  • 2
ничоси жесть
  • avatar VBI
  • 0
Спасибо за ссылку!
  • avatar Shiru
  • 1
Официальные доки очень давно доступны как минимум для Atari 2600, Atari 7800, Sega Genesis, SNES, Neo-Geo.
  • avatar aa-dav
  • 1
P.S.
Качество видео отстойное и что-то не могу найти лучше на ютубе. Лучше посмотреть на эмуляторе хотя бы взяв образ картриджа отсюда: www.pouet.net/prod.php?which=19030
  • avatar aa-dav
  • 1
Тем не менее для демосцены он довольно любопытный зверь — тут вмешивается фактор портативности. т.к. он портативен и должен питаться от батареек, то серьёзно отстаёт своим нутром от своих лет. фактически он реально что-то типа i386 без сопроцессора и Doom в убогом разрешении еле шевелится. При этом пикантности добавляет то, что «давить соки» реально можно — разные виды памяти с разной шириной шины заставляют проворачивать такие трюки, как пропихивание быстро работающих куском ARM32-кода в 32-битное внутреннее ОЗУ и так далее — это довольно всё любопытно с точки зрения демосцены.
Например вот:

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