Фрагмент из работы 2002 года. Софтовый рендеринг с аффинным текстурированием, растеризацией по сканлайнам, Z-буфером и расчетом освещенности по удалению от камеры. Больше десятка 3д-сцен. 3д-сцены полностью сгенерированы триангуляцией параметризованных геометрических примитивов.
320х200 с палитровым режимом (256 цветов). Большая часть 3д шла в градациях синего, чтобы можно было применять освещение, а grayscale смотрелся уж больно печально. Для фона или огня оставшаясь часть 256 цветов заполнялась палитрой конкретной картинки.
Результат прочтения известного 3D FAQ'а Андрея Аксенова и размышлений с бумажкой над тем, как заместить те части, которые я не понял (например, реализацию аффинного текстурирования из туториала я не понял и в результате велосипед был изобретен заново).
Были мысли захватить кусочек в видео, но работает все это дело под dosbox ужасающе медленно. Под оригиналом, без эмуляции работало довольно шустро.
Сейчас, наверно, никого не впечатлит. 8 лет назад возможность создать своими руками маленькое чудо радовало...
Специалисты из Оксфорда и университета Овьедо провели 8 миллионов тестов по технологии Speedtest.net, чтобы оценить качество каналов интернет-связи. Первое место в рейтинге заняла Япония, Швеция и Нидерланды оказались на втором и третьем месте соответственно.
Примечательно, что США оказались на 16-ом месте, а РФ - на 17-ом. Т.е. у нас в России интернет лишь чуть-чуть похуже.
Получается, что российские туристы, рассказывающие о фантастическом интернете в США, просто давно не пользовались отечественным? :)
Четвертой интересной особенностью OGL3.0 является стремление разработчиков стандарта сделать решительный шаг в сторону эффективно распараллеливающихся драйверов OpenGL на многоядерных процессорах.
Это важно, т.к. я наблюдал в профайлере, что драйвера видеокарты съедают 20-30% процессорного времени. Это довольно много. Если драйвера смогут эффективно использовать многоядерность, выйгрыш в скорости будет ощутимым и, что главное, абсолютно бесплатным для разработчика GL-приложений.
Так, помимо откровенно устаревших функций, устаревшими (deprecated) функциями были объявлены и некоторое количество функций, мешающих эффективно распараллелить работу драйвера. Вместо них предложены аналогичные функции, не имеющие подобных недостатков.
В практическом плане ничего страшного. Например, если раньше сначало надо было установить активную текстуру, а потом последовательно устанавливать ей свойства, то теперь в каждом вызове установки свойств необходимо указать, для какой текстуры проставляется свойство.
В противном случае драйверу необходимо было бы синхронизировать установку текущей текстуры среди параллельно работающих потоков. А любая синхронизация в мультитредовой архитектуре пока что зло для общей производительности.
С точки зрения разработчика, изменения не очень страшны, т.к. во-первых, в OGL3.0 старые функции все еще работают. Во-вторых, развести старые функции с новыми (чтобы можно было скомпилировать как OGL2.1-совместимое, так и OGL3.0-совместимое приложение) - работа на пару часов. Возможности современных языков программирования это вполне позволяют.
Во-первых, несколько экспериментальных расширений отдельных вендоров вошли в стандарт.
Во-вторых, ввели так называемые "устаревшие функции". Часть функций, которая в настоящее время плохо коррелирует с современной аппаратной реализацией объявлены устаревшими. Они будут работать в OGL 3.0, но в будущих версиях API будут убраны.
Такая ситуация объясняется тем, что OpenGL родился еще в 1992 году и с тех пор API ни разу не очищался от откровенно устаревших функций. Лишь добавлялись новые.
Особой необходимости не было, ведь даже в OGL образца 1992 года было многое из того, что появилось в DirectX лишь 5-10 лет спустя.
С другой стороны, нельзя резко отказываться от обратной совместимости. Каждая новая версия DirectX - это катастрофа, потому что она несовместима с предыдущей. С этой точки зрения, OpenGL 3.0 - это промежуточная версия, которая дает время (год-два) до выхода новой версии OpenGL, чтобы разработчики убрали устаревший функционал из своих приложений.
В-третьих, нововведение - это профили. С одной стороны, с помощью профиля можно будет регулировать совместимость / несовместимость с прошлыми версиями. С другой стороны профиль будет более точно налагать определенные требования на реализацию OpenGL. Что в частности, подразумевает, что если поддерживается определенный профиль, то поддерживаются всего его функции.
Новый API и тенденции его развития мне понравились.
By complexity I do not mean just the asymptotic complexity but the machine cycle count. In order to learn about it, it is necessary to acquire a habit of writing benchmarks. Time and time again I discovered that my beautiful designs were totally wrong after writing a little benchmark. The most embarrassing case was when after claiming publicly on multiple occasions that STL had the performance of hand-written assembly code, I published my Abstraction Penalty Benchmark that showed that my claims were only true if you were using a specialized preprocessor from KAI. It was particularly embarrassing because it showed that the compiler produced by my employer – Silicon Graphics – was the worst in terms of abstraction penalty and compiling STL. The SGI compiler was eventually fixed, but the performance of STL on the major platforms keeps getting worse precisely because customers as well as vendors do not do benchmarking and seem to be totally unconcerned about performance degradation. Occasionally there will be assignments that require benchmarking. Please do them.
Вы любите программировать? Давайте обсуждать
методы и технологии программирования, организацию работы над проектами
и новые идеи! Вас интересуют проблемы нашего родного образования? Подискутируем
на тему того, как и чему надо учить! Вы просто хорошо относитесь к Nappy? Тогда вам тоже
здесь самое место!