Эксперимент: 2D отрисовка на pentium 100 mhz

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

Пишу в Visual Studio 2022. Компилирую:

Thread model: win32
gcc version 4.7.1 (tdm-1)

Екзешник запускается и работает от Windows 95 до Windows 11. Хотел измерить скорость отрисовки 2D примитивов на cpu без gpu. Пока рисует просто белый фон.
Старого железа нет запускал на 86Box Windows 95 pentium 166 mhz 128 mb S3 Vision 864 2mb на Ryzen 5 3500u 8 гб озу
Вот с чем столкнулся. При разрешении 800х600 и 32 битном цвете выдает 12 кадров в секунду и это я просто вывожу буфер озу на экран. При 640х480 и 32 битном цвете выдает 17 кадров в секунду.

Отсюда и вопрос Прошу проверить на разных конфигах процессоров, сколько выдает fps программа. Разрешение 640х480 32 бит цвета. В заголовке окна показывает fps.

При разрешении 640х480 и 8 битном цвете выдает 36 fps. Как раньше писали игры то? 30 фпс это минимум для кофортной игры. Остается 6 фпс на логику, геймплей и т.д При чем это Petium 166. Возможно эмулятор не справляется с железом. Чуть позже вылоу на гит хаб код. Возможно, я что не так накодил.

Вот функция вывода

void LDL::Graphics::Canvas::Present()
{
ZeroMemory(&_BITMAPINFO, sizeof(_BITMAPINFO));
_BITMAPINFO.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
_BITMAPINFO.bmiHeader.biWidth = _Size.PosX();
_BITMAPINFO.bmiHeader.biHeight = -(int32_t)_Size.PosY();
_BITMAPINFO.bmiHeader.biPlanes = 1;
_BITMAPINFO.bmiHeader.biBitCount = 32;
_BITMAPINFO.bmiHeader.biCompression = BI_RGB;
SetDIBitsToDevice(_HDC, 0, 0, _Size.PosX(), _Size.PosY(), 0, 0, 0, _Size.PosY(), &_Pixels[0], &_BITMAPINFO, DIB_RGB_COLORS);
SetWindowText(_HWND, _Title.c_str());
}
Сам экзешник
game1.exe

Как выглядит у меня

 

Сссылка на GitHub: GitHub - JordanCpp/Little-Direct-Media-Layer

 

Насколько помню те времена, комфортная игра тогда начиналась от 16 fps...

 

@Jordan 63, Pentium 166 c полноэкранным программным рендерингом это разрешение порядка 320x200 - 480x360 с частотой кадров 15-25 в секунду.
24 кадра в секунду считалась очень хорошей частотой.
Чтобы скрыть недостаточную аппаратную производительность использовали множество "трюков" - уменьшали обновляемую площадь экрана, применяли аппаратный сколлинг, чередование страниц, изменение палитры и т.д.

Лет 20 назад делал тестовую программу для 486 с ассемблерными вставками. Нормальная скорость была при выводе десятка спрайтов размером 16х16 (если правильно помню).

CD-Man Version 2.0 (1992, DOS) практически предел для 486 80 МГц.

 

Спасибо за ответ. Я как то не подумал, что игры в то время на половину состояли из хаков
и костылей, что бы запускаться на всех возможных конфигурациях.. К примеру берём fallout 2, разрешение 640 на 480 но 8-ми битный цвет. Скорость на моем эмуляторе о котором я писал нормальная тормозов нет. Я даже выставлял частоту 100mhz изменений нет. Игра идёт плавно. Специально поставил win 98, directx 8.1 и оригинальный английский disciples 2 на двух дисках. Фпс не знаю как посмотреть но скорость примерно ФПС 10. В системных требованиях указан как раз pentium 166. Даже ставил arcanum, редактор запустился игра нет. Черный экран и закрывается.

--- добавлено 17 дек 2021, предыдущее сообщение размещено: 17 дек 2021 ---

320x200 это всё-таки больше dos. На Винде минимум 640x480

 

@Jordan 63, вот, для примера, более производительная система с графическим ускорителем. Без ускорителя примелемая скорость игры при разрешении 320x200 или чуть выше.
Via vs Intel.

Еще пример - Tomb Raider 1996. Программный рендеринг с разрешениями 320x200 и 640x480. 486DX2 нормально работал только при 320x200.
Vodoo 1/Voodoo 2 выдают 20-25 кадров в секунду при разрешении 640x480. И только начиная с Voodo 2 SLI скорость игры упирается в ограничение 30 кадров в секунду.

В Doom при разрешении 320x200 ограничение 35 кадров в секунду. Думаю, на сложных уровнях даже Pentium 100 не дойдёт до этого ограничения (В 2019 выпустили SIGIL, карты на столько сложные, что буфера не хватает - "R_Draw Planes: visplane overflow (130)").

Кстати: Ретро-ноутбук Roverbook Voyager MT4, режим 320х200 в играх

 

А разве fallout 2 работает без dx?
Во-первых dx и без аппаратного ускорения - это нужно как-то специально заморочиться и суметь отследить.
Во-вторых у меня на п1 120MHz (видиокарта смутно припоминаю слово вирдж - не супер аппаратное но какое-то ускорение было) он местами хорошо так подтормаживал. Эмулятор в этом плане плохой референс.

Ну и к слову, я тут решил ради интереса раскрутить механику спековского скролл-шутера Xecutor, который в свое время выглядел супер плавным. Первое, что с удивлением обнаружил - обновление экрана 10фпс.

 

Ф2 требует dx5. Но из dx используется аппаратное ускорение вывода, кадрового буфера. Вся графика рисуется в буфер озу, а вывод ускоренный сразу мину проц летит на видеокарту. Что заметил. Фол на новой установленной системы с драйвером VGA без ускорений и т.д Работает так же, не тормозит. Нужно потестить.

--- добавлено 19 дек 2021, предыдущее сообщение размещено: 19 дек 2021 ---

Скорей всего так и есть. Просто мне казалось, что на пентиуме 166 можно было на цпу нормально выводить картинку в разрешении 800x600. Оказывается он был не таким быстрым. Память подвела))

--- добавлено 19 дек 2021 ---

Товарищи, очень прошу протестить екзешник на реальном старом железе. Не бойтесь, это не вирус. Хочется на реальном железе увидеть количество фпс.

 

Ну так это самое главное. Если с отрисовкой местами можно схитрить, то вот возможность мгновенно переключать (или хотябы быстро копировать) буфер экрана - абсолютно необходимый пункт для "плавной" картинки.
Кроме того именно он и дает не 36-30=6фпс на отрисовку, а все 36.

 

Pentium III 366x66 (заторможенный 733x133), 3dfx Velocity 100 AGP, Win XP SP3, 32 bit
84 в среднем
Pentium III 366x66 (заторможенный 733x133), S3 Trio 3D/2X AGP 4M (стандартный VGA), Win XP SP3
28 в среднем
Pentium III 366x66 (заторможенный 733x133), S3 Trio 3D/2X AGP 4M (driver version 5.30.05 Engineering Release), Win XP SP3, 24 bit
86 в среднем

AMD Geode LX 500x33, AMD Geode LX Video Adapter, Win XP SP3
140 в среднем
Процессор "в себе". Windows работает весьма неспешно. Перемещение окна загружает процессор на 70-80%.

 

Спасибо. Теперь стало понятно. Если 366 mhz выдает 84. Кадров 50 на геймплей, то уже реально творить.

 

На процессоре UMC 486 U5S 33 Mhz при разрешении рабочего стола 640x480x32 выдает 15 fps

Видеокарта S3 Trio64DX 2Mb.

--- добавлено 20 дек 2021, предыдущее сообщение размещено: 20 дек 2021 ---

Странно, при 8 и 16 битном цвете выдает 8 FPS

 

У меня есть стойкое подозрение, что у SetDIBitsToDevice большой оверхед, и рисование записью значений прямо в память, используя, например, CreateDIBSection, будет быстрее (пример - https://stackoverflow.com/a/57045140)

 

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

--- добавлено 21 дек 2021 ---

Нужно попробовать. Я как раз запили поддержку изображений. В ближайшие дни выложу на гит хаб.

 

Рисовать через GDI и плакаться, что медленно.
Удивительно.

И на кой ляд 32 бита на Win9x? Там ещё и растеризация проходит, пускай её и не видно на полностью белом фоне.

 

Если заморочиться, то можно и через GDI быстро рисовать. Зато работать точно везде будет, даже в 3.11.

Набросал версию с CreateDIBSection + BitBlt. Используется двойная буферизация и перерисовка из буфера на окно только того, что нужно (по WM_PAINT). Должно быть быстро. В архиве исходники (с проектом на OpenWatcom) и exe, можно потестить.

 

@Jordan 63, тоже разрабатываю игровой движок. Буду рад конструктивной критике.
Ссылка на код - GitHub - PopovEvgeniy/eugenegdk: Eugene game development kit is an ultra-fast 2D game engine for Windows XP or higher. It uses OPENGL for render

 

Приветствую.

Если актуально.

1. Я бы вынес каждую сущность в отдельный файл.
2. Использовал бы namespace.
3. Юзал бы свои типы или stdint.h
4. Вернул бы поддержку старых ос win 9x и win 2000.
5. Добавил бы тесты.
6. Сделал бы реализацию более модульной. Пример паттерн SOLID (не обязательно делать классы строго виртуальными, так как снижает производительность)
7. Перешел бы на лицензию boost.

Пример моего проекта GitHub - JordanCpp/Lt: Free cross-platform library. (Проект не буду развивать, перенесу наработки в GitHub - JordanCpp/LDL: Little DirectMedia Layer c поддержкой C++ 11, свои контейнеры оставлю как доп фичю, главная идея создать аналог SDL на С++ с поддержкой всех старых платформ)

Как будут новости, обязательно создам тему. Так как требуется тестирование на реальном железе, пока запускаю в 86box.

 

@Jordan 63, здравствуйте. Спасибо за отзыв. Отвечаю по пунктам.

1. Авторы stb_image и olcpixelgameengine убедительно доказали что можно не плодить кучу файлов без ушерба для понятности кода.
2. namespace уже активно используется.
3. Использую несколько своих типов наряду со стандартными.
4. Поддержка Windows 9x и Windows 2000 существует в рамках отдельных форков.
5. Признаю преимущество тестов и признаю собственную несовременность. Мне удобнее тестеривать систему как единое целое вместо тестов активно используя отладчик.
6. Модульность обеспечивается вложенными пространствами имен и продуманной иерархей классов. Преимущества такого подхода схожи с упомянутым вами паттерном.

Про лицензию хотелось бы узнать подробнее. Чем Boost лучше zlib?
Так же желаю вам успехов во всех начинаях. От чисто технических до сугубо личных.

 

Извиняюсь не внимательно посмотрел. Думал, что лицензия собственная. Да, zlib. Сразу полез в код

Думаю, лучше добавить лишний #ifdef, чем отдельный проект. Это на ваше усмотрение.

Так и у меня все тесты интеграционные. И по прохождению всех тестов я уверен, что вся система в целом протестирована. Без смс и отладчика

Благодарю. И вам успехов в ваших.