Критика KolibriOS

Find out what others think about your ideas
  • Pathoswithin
    Извините, мне не до экспериментов
    Я искал OS для загрузки с флэшки и восстановления документов Windows (гадская система все трет при перестановке)
    Пока остановился на Puppy Linux
    Сделайте свойства папки и дисков, юзабилити же 0, посмотрите хоть на Windows XP
  • pascualle
    Да уж, не могли портировать хотябы MesaGL, о драйверах для видеокарты уж не говорю
    Еще браузер свой собираются писать, конечно на ассемблере
  • 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, а не сборник компонентов.
    to infinity and beyond
  • 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
  • Who is online

    Users browsing this forum: No registered users and 3 guests