Почему вы пилите ни кому не нужную программу, игру, фреймворк, а не контрибьютите в опен сорс проект? (15 стр)

Вий
> Вот если тебе нужно будет поддержать только один формат, то было бы круто, если
> бы это был формат со сжатием и альфа-каналом. Типа png.
Bmp тоже умеет в альфу. Не думаю, что png будет прост для кодирования реализации.

Цель сделать минимальныую поддержку. Остальное в доп. библиотеки. К примеру использовать тот же stb_image и аналоги.

Вий
> Тогда зачем делать bmp? Его тоже умеет обрабатывать stb image
Минимальная версия библиотеки будет работать включая DOS 16/32. Туда проблемно портировать stb_image. На данный момент библиотека написана без внешних зависимостей. И так как она очень маленькая, она легко портируется. Цель сохранить простоту, а остальной функционал или разработчик реализует сам или использует дополнительные библиотеки.

JordanCpp
> Цель сохранить простоту, а остальной функционал или разработчик реализует сам
> или использует дополнительные библиотеки.
В этом случае я тогда предлагаю такой вариант — в самом твоём движке библиотеке оставить вообще только Один Канонический Формат (тот же КОЙ например), а у кого ассеты приходят в других — пусть конвертируют заранее на настоящих компьютерах отдельной оффлайн-утилитой.

Имбирная Ведьмочка
Не нужны никакие утилиты. Render умеет выводить массив пикселей, загружаем картинки любой библиотекой и выводим загруженные пиксели. Могу добавит из коробки и QOI, так как кода мало.

Загрузка картинок и вывод их на экран разделён.

Рендер уже в зависимости от define указывающий рендер, работает или софтварно или с аппаратным ускорением.

Есть 3 сущности в API.

Render, surface, texture.
Surface это массив пикселей.
Texture это текстура с аппаратным ускорением.
Render это всё рисует.

В софт версии рендера, texture = surface. И это позволяет не переписывать код.

Пример движка арканума, я использую только абстрактный  render и texture. Но при софт рендере, всё рисует ЦПУ, в OpenGL gpu.

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

Для этого и нужен единый API, для всех систем. Даже под dos.

Ещё добавляется сущность pallete. Используется опционально. В рендере в конструктор указываем палитру, в texture тоже передаем палитру.

Данный способ все используют. Те же движки, абстрагирующие 3d рендер, а под капотом gl, dx, mantle. Для простоты я абстрагирую только 2d функционал. Но так же есть возможность, нативно юзать OpenGL, в будущем добавлю vulkan.

2D рендер нужен для удобства. Можно будет юзать и палитры, если нужно. Ни всем хочется изучать 3D.

Я же говорю SDL на минималка.

Я посмотрел реализации простых форматов графики. Вполне можно поддерживать. Bmp, QOI, tga, pcx. Они очень простые и не занимают много кода.

JordanCpp
> И никаких дополнительных действий для разработчика это не требует, не требуется
> переделывать код.
Так во всех движках обычно и сделано. В Иррлихте было цать этих рендеров, Два директовских, софтовый, опенГЛ и еще какой то улучшенный софтовый, если бы там можно было легко приделать свой рендер, то я бы сделал в своё время, Для Опенг 3 или 4 версии и не бросил Иррл..

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

Ещё одна из главных целей библиотеки, это не навязывать разработчику своё видение.

Юзай любые библиотеки для звука, графики. Используй нативно графические API. Но если нужны простые механизмы для 2D графики, они есть у меня.

stratego
> если бы там можно было легко приделать свой рендер, то я бы сделал в своё
> время, Для Опенг 3 или 4 версии и не бросил Иррл..
В LDL это на изи делается. Просто реализуешь класс LDL_Render.

stratego
> Ка ты по шейдерам то будешь выкручиваться? Или предлагаешь делать современные
> игры без них?
Ни как. Если нужны шейдеры, Бери ogl и пиши. Именно абстракция графики есть только для 2D. Никто не мешает хоть свой 3D рендер реализовать, я просто не умею.

Можно вообще сделать так.

LDL_Render2D простой API для графики.
LDL_Render2DSuper - API для продвинутой графики с шейдерами и смс
LDL_Render3D - API для абстрактного 3D

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

Вий
> формат со сжатием и альфа-каналом
Альфа-канал не имеет смысла под ДОС, производительности не хватит. Так же имеет смысл использовать только индексированные цвета. И поскольку палитра должна быть общей, то и хранить палитру индивидуально с каждым файлом не имеет смысла.

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

В биосе есть SVGA режимы, высокого разрешения и 32 битного цвета. Если сделать поддержку, то пригодится.

http://www.faqs.org/faqs/pc-hardware-faq/supervga-programming/

Максимум 16.8M-colour. 32k-colour это 32 тысячи. Перепутал, не умеет DOS в 32 битный цвет.

Для порта DOS использую данную информацию. Пока не нагуглил как использовать vga 640x480 (256 цветов).

stratego
> В Иррлихте было цать этих рендеров, Два директовских, софтовый, опенГЛ и еще
> какой то улучшенный софтовый,

Надо будет посмотреть данный движок и портировать связанное с 3D.

Вопрос знатокам. Имеет смысл поддерживать нативное рисование в Linux(xlib) и Windoiws(GDI).
Не просто буффер в озу и потом вывод, со своей реализацией линий, кругов и т.д

Есть подозрение, что XlIb и GDI аппаратно ускорены под капотом.

JordanCpp
> со своей реализацией линий, кругов и т.д
Посмотри processing - движок 2d графики, на нем сделана http://nemehanika.ru/
Мне попалась его реализация на C++ и GL, скомпилировал, но не разбирался