Board.KolibriOS.org

http://fabrice.bellard.free.fr/TinyGL - opengl-подобная графическая библиотека.

Вот примеры на ее основе:

http://www.iadn.narod.ru/examples/triangle.7z Закрашенный треугольник
http://www.iadn.narod.ru/examples/cubeline.7z Куб из линий
http://www.iadn.narod.ru/examples/torus.7z Тор и шар
http://www.iadn.narod.ru/examples/pyramid.7z Пирамида
http://www.iadn.narod.ru/examples/gears.7z Шестеренки
http://www.iadn.narod.ru/examples/cubetext.7z Куб с текстурой
http://www.iadn.narod.ru/examples/md2View.7z Вьювер md2 файлов моделей игры Quake2 (в архиве 2 модели)

В Kolibri примеры с использованием текстуры запускать из KFar

Это просто здорово! Выглядит все очень хорошо. Пора делать 3д шутер

Хорошие демки.Особенно мне понравился трехмерный человек(или монстр ?).

В TinyGL используются простейшие 3D вычисления.Такого рода библиотеку можно и самому написать.Причем лучше писать на ассемблере.

Я ради интереса сравнивал скорость 3D вычислений написанных на C и скорость этих же вычислений,написанных мной на чистом ассемблере.Ассемблерный код был быстрее от 20% для самых простых вычислений(скалярное произведение векторов и длина вектора) и выше по мере возрастания сложности алгоритма.Поэтому лучше писать на ассемблере.

может просто си компилятор был далеко не самый лучший? или настройки? по статистике си-компилеры уступают самым лучшим из асемблерщиков на пару процентов

Victor
Я обгонял си компилер (со всеми оптимизациями) и в 1.8 раза. Тут ведь дело еще в том, что на ассемблере можно реализовывать алгоритм немного по-другому (при этом получающаяся программа на ассемблере не соответствует никакой программе на си), а си компилер должен следовать программе и к тому же не может производить оптимизации, которые используют специфику алгоритма.

Компилятор был GCC в режиме максимальной оптимизации по скорости.

Виктор,вообще полезно,хотябы для себя,просматривать ассемблерный код,который выдаёт компилятор.Тем более,что в GCC для этого не нужно дизассемблировать код - достаточно при компиляции вместо gcc -o ......... написать gcc -S .......

Внимательно посмотрев код,становиться понятным почему ассемблерный код ВСЕГДА быстрее.В языках высокого уровня НЕИЗБЕЖНО использование переменных,которые храняться в ОПЕРАТИВНОЙ памяти.Тоесть в самой медленной памяти.Когда же код пишет ассемблерщик,то он по МАКСИМУМУ использует все РЕГИСТРЫ или СТЕК FPU,которые являются САМОЙ БЫСТРОЙ памятью на компьютере.Поэтому алгоритм средней сложности ,написанный на ассемблере,может быть быстрее своего сишного аналога от 10%-5000%

>по статистике си-компилеры уступают самым лучшим из асемблерщиков на пару процентов

Я незнаю,что за НЕУЧ составлял эту статистику.Элементарное измерение скорости кода при помощи комагды RDTSC,которая позволяет измерять скорость кода в тактах(я всегда измеряю скорость ей),показывает,что ассемблерный код быстрее от 10%(но не как не 2%) и выше.Реально это выше может достигать 5000%

НЕ ДОВЕРЯЙТЕ НЕУЧАМ ! Они ВСЕГДА ерунду пишут.

Ну как бы эта статистика из неофициальных источников... Я вот на Serg посмотрел, где он писал что компилер как-то где-то что-то ему заоптимайзил и сделал выводы. Это не единственный пример, просто остальные не припомнишь?
P.S. andrew_programmer так понимаю что неуч это про меня, ну так ты и пиши что я неуч. Спорить не буду, все мы в чем-то неучи
P.P.S. бредом как пользоваться мне так никто не обьяснил кинтесь в меня ссылкой чтоли

Виктор - это я не про тебя.Эта проблема всего мира.Я цифру 2% слышал от многих.Причем эти многие вообще незнали ассемблера.

оффтоп: Да уж, лучше точно знать, прежде чем говорить Но очень многие так поступают, ничего не поделаешь!

Фпс жуткий...
Cubeline
В винде через эмуль 105-120 фпс, на полном экране около 22-28.
В колибри же обычное окно 15-20 фпс, развернутое - 9-10...

А кто в Колибри реализовал аппаратный PutImage ?

Ответ: аппаратный PutImage в Колибри не реализован.Значит процессор тратит часть времени на отрисовку кадра.Если бы кадры отрисовывались аппаратно,то процессор в этоже время мог просчитывать 3D графику,незаботясь о выводе кадров.Тогда бы FPS возрасло в несколько раз(в 2-3 раза).

TinyGL написана на Cи для GCC. Для сборки библиотеки и компиляции примеров использовались для сравнения два компилятора GCC и VC++ 2003.
В результате Cubeline
GCC 59Kb 297 fps
VC++ 2003 37Kb 398 fps

KCEOH
А какая конфигурация машины? TinyGL реализует минимум команд OpenGL и даже при этом выдает такой низкий результат. Правда в ней не используется MMX.
Но значит, в любом случае попытки переноса той же MESA не имеют смысла до тех пор, пока не будут реализованы хотя бы простейшие драйвера для аппаратного ускорения.

Не какую MESA ни в коем случае переносить не нужно.

У меня в Linux в качестве OpenGL драйвера стоит MESA.Я насмотрелся на FPS-ы выдаваемые ей,а также смотрел код MESA.Меня не устркаивают ни FPS,ни код.Если ещё учесть,что код написан на C,то понятно,что максимально возможные FPS в несколько раз больше.К примеру антианализинг - самая тормозящая часть вычислений.На ассемблере он в несколько раз быстрее работает.А MMX и SSE там используются только для работы с нормалями и для блендинга.

У нас будет своя OpenGL -на чистом ассемблере.Причём в двух вариантах.Одна для программирования на ассемблере и будет ввиде inc файла.А другая - ввиде библиотеки формата ELF,которая будет линковаться к сишной программе на этапе компиляции.

Про ускорение.

Вообще,ускорить саму библиотеку OpenGL в принципе невозможно.Потомучто в ней при помощи одной команды производится деиствие только над одним объектом - одним вектором или точкой.А SSE и 3D ускорение можно использовать только в случае,когда необходимо произвести однотипную операцию над большим массивом векторов или точек.Поэтому ускорять нужно библиотеку GLU(она как бы является частью библиотеки OpenGL).Кстати в MESA эта библиотека написана на C без васякого ассемблера(а заначит и без SSE).

Кто умеет это компилить под Колибри? Насколько я понял, на сайте просто выложены исходники библиотеки и примеров.

На сайте пока одни примеры. Исходники примеров, библиотеки и способ компиляции скоро будут.

diamond
Спасибо за хороший эмулятор , без него адаптация библиотеки под Колибри, создание, перенос и отладка примеров была бы просто невозможной, либо заняла бы раза в три больше времени. Вообще процесс сдвинулся с места после того как в одной из веток форума был обнаружен новый эмулятор.