Board.KolibriOS.org

лично мне, имхо, не хватает opengl, хотя бы 1.1, но стабильный

Pathoswithin
Извините, мне не до экспериментов
Я искал OS для загрузки с флэшки и восстановления документов Windows (гадская система все трет при перестановке)
Пока остановился на Puppy Linux
Сделайте свойства папки и дисков, юзабилити же 0, посмотрите хоть на Windows XP

pascualle
Да уж, не могли портировать хотябы MesaGL, о драйверах для видеокарты уж не говорю
Еще браузер свой собираются писать, конечно на ассемблере

Сначала поищи, потом пиши

ftp://ftp.kolibrios.org/users/Serge/new/Mesa3D/

ftp://ftp.kolibrios.org/users/Serge/new/Gallium3D/

Wildwest
ok, молодцы

Есть свойства папки, третий раз повторяю — основной файловый менеджер сейчас Eolite.

pascualle wrote:лично мне, имхо, не хватает opengl, хотя бы 1.1, но стабильный

Есть же tinygl, чем он не нравится? Он возможно не все функции поддерживает из 1.1, но для большинства программ того что есть хватает.
Если не секрет, то для чего не хватает, что планируется сделать?

osmesa даёт glapi 2.1. Тормозит конечно, зато драйверы не нужны.

Serge, IgorA

оно то да, признаю, какой-то opengl есть, но более "теоретическая" модель, я лично так и не нашел нормального примера, в каждой демке придумывается свой велосипед, микс драйвера и логики, что не есть хорошо.
я ожидаю что-то типа такого, именно что-то типа kolibrios_gl api
- инит opengl, идеально бы тут проверить если нет аппаратной поддержки, включить софтоверный режим
- инит окна, связывание gl и оконного контекста
- что-то типа swapBuffers/glFinish функции в mainloop
- деинициализация контекстов и самой подсистемы

как я вижу, c-layer на подходе, потому считаю тема единого функционала с/asm для платформенной части рендера -- вопрос актуальный и востребован, более того, это позволит более гибче менять внутренности (меса, галиум, тайни) не ломая уже написанные приложения.

В детстве я молил Бога о велосипеде. Потом понял, что Бог работает по-другому. Я украл велосипед и стал молиться о прощении. (c) Аль Капоне

Приведи пример, который реально мешает счастливой жизни.

pascualle wrote: как я вижу, c-layer на подходе, потому считаю тема единого функционала с/asm для платформенной части рендера -- вопрос актуальный и востребован, более того, это позволит более гибче менять внутренности (меса, галиум, тайни) не ломая уже написанные приложения.

Думаю с c-layer проблем особо не будет, а вот для остального нужно писать нормальную замену box_lib, причем нормальный widget toolkit, а не сборник компонентов.

pascualle
Не уверен, что получится соединить osmesa и "железный" GL в одной программе.

Serge, а почему нет, нельзя у драйвера спросить? Тут я не компетентен, но интересно.
Ну если точно нет, то можно поступить как ты сделал в fplayer, там же две реализации рендера если я не ошибаюсь. Обкрутить все это понятным и что главное, единым, интерфейсом и пусть люди используют.

infinity звуковое апи вон хорошо обернуто и описано, почему то же не сделать для gl

pascualle
Посмотрел внимательней osmesa, это сам себе драйвер. Так что соединить можно. Но всё равно в программе надо будет делать две разных инициализации для hw и sw. Может для самых простых демках получится спрятать мусор под ковёр и сделать некоторый общий api, но в сложных приложениях не уверен.

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

Для этого надо делать гибрид eglut и pixlib-3.

Serge,
не совсем понял, почему в "сложных" приложениях что-то не взлетит, вот мои доводы:
- gl сам по себе самодостаточный, можно узнать это за версия, например, glGetString(GL_VERSION), вспомнил первое попавшее, не суди строго, главное что можно узнать и в зависимости от версии писать платформенно независимый код. Самое важное то, что платформенно независимый код не знает что он запускается на kolibrios, все что ему нужно он получает через opengl api.
- Вся платформенная, чисто kolibrios часть реализовывается, например с помощью адаптации egl, но уверен что лучше его обернутть в некое koliblios gl api, как это сделано, например, в windows, чтобы не торчало наружу куча ненужного, только 3-4 функции инициализации и деинициализации.
- hw и sw спрятать в реализацию koliblios gl context, и работать с ним в зависимости от того как проинитился gl, тут тоже можно по аналогии с windows, некий
kosGlCtx = kosglCreateContext(wndId);
kosglMakeCurrent(kosGlCtx);
создать контекст можно только после инита gl

Замечание только одно, в самом начале нужно сделать проверку, совместим ли код с версией текущего gl