Доступен исходный код Raptor: Call Of The Shadows для DOS

DemonStar - самая крутая! до сих пор играю!
в ней музыку делал bobby prince , это тот который делал музыку в DOOM1,2, wolf3d, DukeNukem3d

Поиск-2 слишком похож на XT.
Поиск-1 более экзотичный зверь)

Вообще-то, это была шутка.

Тем не менее, сильно сомневаюсь, что при портировани. На sdl сожрала бы 200

Бро, я писал подобные игры, и даже посложнее, что-то типа Дюны

Ну так покоммитили бы в OpenRakis. А то не осиливают они ремейк Дюны без вас (я серьёзно, проект стагнирует, а оч жаль).

К сожалению не будет, они были уничтожены в 2002 году вместе с компьютером в компьютерном кружке

Так а кто и зачем уничтожил компы в компьютерном кружке? И куда смотрела охрана клуба? :)

Зачем изучать программирование под видеоадаптер VGA ?

Ну хотя бы по тому, что плавный скроллинг сделать, без изучения внутренностей VGA - весьма проблематично на 386. А в этой игре он есть. Будешь на одних только меммувах весь проц просерать. А так - display_start сдвигаешь, и правишь только 1 небольшой прямоугольник в видео памяти. Не надо двигать весь буфер меммувами.

А никто весь буфер никуда и не двигал - это лишнее.

Я держал в памяти «виртуальную» карту объектов, там было что-то около 4096*4096. Размер кучи был вроде 64кб, поэтому приходилось извращаться с mem[сегмент:смещение] и подключать какой-то из драйверов, не помню какой, то ли himem.sys, то ли ems386 чо-то там .sys, уже не помню.

В этом массиве были абсолютные координаты моих жучков, стен, игрока, и их краткие характеристики большинство из которых boolean.

Изображение выводилось исходя из того, какой из участка «виртуальной» карты был активен на экране.

Там шото типа currentX, currentX+320, currentY, currentY+200.

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

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

О процах мы тогда не думали, потому что работало это все под досом, и переключиться альт+табчиком в диспетчер задач, посмотреть 70% юзает «меммув» или 10% как-то не было необходимости.

без изучения внутренностей VGA

Это не совсем VGA, если быть точным, то это называлось VESA. Тогдашняя организация памяти позволяла рисовать пиксели быстрым способом просто делая запись в определенные участки памяти, выделенной под видеопамять. 320х200х256 выбиралось неспроста, хотя мониторы уже тогда поддерживали 800х600. Все дело в том, что взрослые «драйверы», включая драйверы под винду, умели работать с конкретной видеокартой используя как трюки самой видеокарты, так и трюки с процессором, работали в защищенном режиме и могли себе позволить длинную адресацию.

Мы же использовали VESA-совместимое еще и в реальном режиме, в общем наш лимит на все про все, был 64Кб - и между высоким разрешением с 16 цветами, и низким разрешением с 256 цветами мы почти всегда выбирали второе.

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

Так при чём здесь ваша игра? Я про сабжевую игру говорю. Там идёт постоянный скроллинг всего экрана, по тому, что, типа, самолёт летит. Каждый фрейм перерисовывать - накладно, так как, по сути, фрейм почти не меняется, но из-за скролла, сдвигаются абсолютно все объекты. Именно в такой ситуации, а не в той, что вы описали, и применяли аппаратный скроллинг. Это позволяло обновлять фрейм минимально, игнорируя факт его общего перемещения - за это отвечала уже аппаратура.

Мы же использовали VESA-совместимое еще и в реальном режиме

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

О процах мы тогда не думали, потому что работало это все под досом, и переключиться альт+табчиком в диспетчер задач, посмотреть 70% юзает «меммув» или 10% как-то не было необходимости.

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

Опа, как давно SDL3 вышел?

Ещё не сказать что вышел, но живёт параллельно с SDL2, стоит рассматривать SDL3 как dev ветку которая при этом является ещё и master лул SDL2, поддержка у SDL2 активна, а новые фичи уже в SDL3, оно просто плааааавно так перетекает из одного в другое, sdl2-compat уже готов (вроде) так что переход будет вообще незаметным. Смещение акцента на разработку произошло в ноябре 22го года вроде как в этот момент master бранчем в гите стал SDL3, а SDL2 переехал пониже =)

• https://discourse.libsdl.org/t/sdl-3-0/40374

К слову Counter Strike 2 уже на SDL3 (или на неком его обрубке).

Ну и

• https://github.com/libsdl-org/SDL :)

О, я играл в этот гамес где-то в 2000. Отличная игра же.

программирование под видеоадаптер VGA

Это ты про перевел в режим 0x13, установил палитру (для спецэффектов ее можно периодически менять для определенных индексов цветов) и читаешь/пишешь напрямую в видимопамять с переключением страниц?

Спасибо за разъяснение. Похоже, новый софт сейчас лучше всего писать на версии SDL из master-ветки и постепенно обновлять до SDL3 по мере стабилизации API (есть вероятность, что вообще ничего править не придётся?)

Я просто недавно заинтересовался визуализацией 3D-моделлей и нахожусь немного в смятении, потому что в 3D куча всяких сложностей: vertex colors vs face colors, materials, textures, animations… Последнее я вообще не представляю, как хранить и передавать, наверное, есть какой-то формат, но я о нём не в курсе. Форматов вообще куча, но все они крайне тупорылые: STL, OBJ, DAE, PLY…

Я просто недавно заинтересовался визуализацией 3D-моделлей

А зачем вам для этого SDL? Он же, в основном, для 2D.

есть вероятность, что вообще ничего править не придётся?

Конкретно для твоей хотелки с 3D вообще пофиг какой сдл брать, от него ты возьмёшь GL контекст и всё. Так что чисто как самому захочется то и выбирай.

визуализацией 3D-моделлей и нахожусь немного в смятении

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

Вот например Corange выделяет память под данные вершин в которой будет

• xyz позиция
• xyz нормаль
• xyz тангенс - рассчитанная отдельно
• xyz бинормаль - рассчитанная отдельно
• xy текстурная координата
• xyzw цвет
• ``

  /* Position Normal Tangent Binormal Uvs Color      */
  /* 3        3      3       3        2   4     = 18 */
  float* vb_data = malloc(sizeof(float) * m->num_verts * 18);

Затем имея дело с тем или иным форматом ты этот массив заполняешь парся формат OBJ например. Затем ты загружаешь эти данные в GPU, просто как есть копируя заполненный массив из RAM

glBindBuffer(GL_ARRAY_BUFFER, s->vertex_vbo);
glBufferData(GL_ARRAY_BUFFER, sizeof(float) * s->num_verticies * 18, vb_data, GL_STATIC_DRAW);

И удаляешь нафиг vb_data оно больше ненужно.

Затем ты в рендере передаёшь эти данные попутно сообщая шейдеру где что лежит в этом блобе данных который ты загрузил (ты можешь хранить всё в отдельных массивах данных если хочется)

glBindBuffer(GL_ARRAY_BUFFER, s->vertex_vbo);
    
    shader_program_enable_attribute(shader, "vPosition",  3, 18, (void*)0);
    shader_program_enable_attribute(shader, "vNormal",    3, 18, (void*)(sizeof(float) * 3));
    shader_program_enable_attribute(shader, "vTangent",   3, 18, (void*)(sizeof(float) * 6));
    shader_program_enable_attribute(shader, "vBinormal",  3, 18, (void*)(sizeof(float) * 9));
    shader_program_enable_attribute(shader, "vTexcoord",  2, 18, (void*)(sizeof(float) * 12));
    

И рисуешь! (до этого установив шейдер, задав текстуры и прочее прочее)

glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, s->triangle_vbo);
glDrawElements(GL_TRIANGLES, s->num_triangles * 3, GL_UNSIGNED_INT, (void*)0);

Ой а чёита за triangle_vbo? Аааааа? А его ты создаёшь на этапе когда vb_data живой это индексы (буквально индексы массива) в массиве vertex_vbo указывающие какие вершины образуют треугольнички. Хотя можно и по другому, главное знать разницу

• http://www.gamedev.ru/code/forum/?id=67255

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

• Левая нога

* включаешь шейдер
* передаёшь текстуру 1
* передаёшь параметры шейдера (юниформы)
* передаёшь вершины (атрибуты) левой ноги
* рисуешь
* отключаешь вершины
* отключаешь шейдер
-------------------
* включаешь шейдер 
* передаёшь текстуру 2
* передаёшь параметры шейдера (юниформы)
* передаёшь вершины (атрибуты) правой ноги
* рисуешь
* отключаешь вершины
* отключаешь шейдер

А если бы текстурка была одна то было бы

* включаешь шейдер 
* передаёшь текстуру
* передаёшь параметры шейдера (юниформы)
-------
* передаёшь вершины (атрибуты) правой ноги
* рисуешь
* отключаешь вершины
* передаёшь вершины (атрибуты) левой ноги
* рисуешь
* отключаешь вершины
--------
* отключаешь шейдер

Как одна модель может состоять из нескольких частей (буферов отрисовки) так и каждая часть может иметь один общий материал (набор текстур и параметров шейдера) или уникальный.

Вслепую с нуля оч сложно, смотри на готовое (частично)

• https://github.com/orangeduck/Corange/blob/master/src/assets/renderable.c
• https://github.com/orangeduck/Corange/blob/master/src/rendering/renderer.c

Ну и никто не отменял =)

• https://love2d.org/wiki/Love3D

Может взять привычный тебе lua и готовую нашлёпку для 3D, а в плане визуализации моделей работать только с шейдерами?

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

vertex colors vs face colors

Первый раз слышу про face colors, цвет может быть у вершины (а может и не быть), а как красить решает уже твой код шейдера. Это наверное из редакторов всяких блендеров и прочего, типа разукрашка цветом per faces =)

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

Вот я пейшу, пейшу, а вдруг ты Vulkan хочешь? Тогда ой, вам в другую палату товарищ :D

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

Кто играл в Автослалом на Электронике, тот оценит по достоинству эту игру).

P. S. Doom 64 - навсегда!

выпущенный в 1994 году для операционной системы MS-DOS.

Очень своевременно. Не прошло и 30 лет.