Это был 686 проц (166MHz, если мне не изменяет память).
Тогда уже много было вокруг процов с MMX, и многие игры его уже требовали.
И часть из за этого не шла, и я был в большой печали.
Неа — x86
В середине-второй половине 90х IBM делала процы для Cyrix и часть продавала под своей маркой.
Вообще грустная штука была — тормознутая, mmx не было :(
пока что моя цепочка процессоров в домашних настольных ПК такая — IBM->Intel->AMD->AMD->Intel
сэнди бридж склонил в этот раз в свою сторону
а вот с выбором видеокарты долго колебался, выбирал и то и другое, вобщем чуть ли не бросанием монетки склонился в сторону Nvidia в этот раз, хотя по обзорам мне не казалось что АМДшные видяхи как-то хуже — вот просто так получилось :)
У меня с играми так было — после переустановки винды решил поставить лицензионные фолаут 3 и ньювегас.
После установки ини тот, ни тот не запустились.
Причём вегас ещё и обновления со стима стянул (хотя игра с диска, оба — подарочные издания).
Вобщем полечилась пиратской версией третьего фола, и патчем с пиратского сайта для вегаса.
Сначало написанно что «этот коэффициент показывает, насколько сильно значение амплитуда несущего колебания в данный момент отклоняется от среднего значения»
а потом «Основная спектральная составляющая — несущая, не несет полезной информации»
Почему так? Я, честно говоря, думал что у несущей меняется аплетуда, и это изменения несущей потом на приёмнике преобразуется в информационный сигнал (например звук в AM радио).
А то в википедии также скупо и нифига не понято.
Огда я прикручивал Доуг Ли аллокатор к одной из своих либ, то читал что это стандартный маллок, используемый в гцц. Возможно поэтому на линуксах все нормально отработало.
Мне по тексту показалось «пользуйтесь готовыми библиотеками, вместо закатывания солнца вручную» что ребята тоже придерживались такой логики, только не там где это стоило делать.
Холод из окон проблема. У меня похожая конструкция давно, и зимой, особенно при сильном ветре (а у меня дом так стоит, что ветра порядочные и как раз с той стороны, где компьютерный стол) в итоге я забросил эту затею и перехал в угол комнаты на обычный стол, а конструкцию со столом и полками завалил книгами.
Когда вы у себя делали такой «кабинет» я думал что одному мне не повезло, что оказалось холодно от окон.
Похоже сама по себе идея для зимних вариантов не ок.
Они для каждой фразы собирают атлас заново? Или всё таки у них по мере встречи новых букв они кэшируются в атласах, и через время он уже не меняется, когда там набираются все буквы?
Вокруг ЧАЭС тридцати километровая зона.
Там реактор заворотило и всё его содержимое по прилегающей територии раскидало — это пострашнее натовских боеприпасов.
Вобщем выигрыш просматривается тогда, когда нет возможности скормить ограниченное количество мешей, с большим количеством треугольников, а надо мелкими порциями скармливать, когда вызовы к драйверу просто всё убьют.
Если игра 2д с кучей спрайтов, которые каждый кадр меняют своё положение — то да ваш способ действительно имеет смысл.
У меня и мысли не было что кому то в голову придёт скармливать видяхе по одному спрайту.
2д считаем на cpu, складываем в буфер и пачкой засылаем в GPU.
Но если игра 3д — то там же нет необходимости по паре полигонов гонять — засунули большой меш в GPU, оно его переварило и нарисовало.
Наверно я не совсем правильно воспринял, для чего всё это вы задумали. Пример со спрайтами должен был это подсказать :)
Всё таки не увидели в конце результата — на сколько это даёт прироста по филрейту.
На сколько раельные сцены можно считать на CPU.
Мы некогда делали гонки под iPhone 3g ещё.
Там после всех отсечений скармливалось видяхе 20к поликов.
У вас обсчёт их обсчёт (считаем спрайт как два треугольника) сьел 18-20% CPU.
Но сегодня бы я не стал делать в 3д игре 20к поликов — т.к. это выглядит довольно деревянно, по современным меркам.
А увеличить кол-во поликов — и процессор будет только этим и занят, а надо ещё физику считать, и ещё отсекать от огромной сцены обьекты, чтоб не кормить видяхе лишнее, иначе она тоже захлебнётся, иногда успевать декодировать музыку, считать звук и прочее.
Вот физику посчитать на неоне — это наверно самое то было бы.
Кстати сам pvr — это тоже «формат для упаковки хардварных форматов» — просто контейнер, а в нём может быть и pvrtc и etc и др.
Мы все форматы в pvr храним.
Статья для програмеров — про устройство формата, как с ним работать.
В статью картинки в формате JNI вешать безсмысленно — всё равно броузер не поймёт.
А на code.google.com помимо примеров программ я закомитил и тестовую картинку, над которой можно поэксперементировать.
Word меня не спас — текст писал в нём, в надежде что это поможет избежать ошибок, но похоже я безнадёжен в вопросе грамматики :(
Была мысль сделать примерчик на GL ES, но подумал что двух примеров просто загрузки будет достаточно.
В примерах показанно как загрузить картинку в буфер, а что с ней дальше делать — это уже несколько за рамками описания формата JNG.
Тогда уже много было вокруг процов с MMX, и многие игры его уже требовали.
И часть из за этого не шла, и я был в большой печали.
В середине-второй половине 90х IBM делала процы для Cyrix и часть продавала под своей маркой.
Вообще грустная штука была — тормознутая, mmx не было :(
сэнди бридж склонил в этот раз в свою сторону
а вот с выбором видеокарты долго колебался, выбирал и то и другое, вобщем чуть ли не бросанием монетки склонился в сторону Nvidia в этот раз, хотя по обзорам мне не казалось что АМДшные видяхи как-то хуже — вот просто так получилось :)
После установки ини тот, ни тот не запустились.
Причём вегас ещё и обновления со стима стянул (хотя игра с диска, оба — подарочные издания).
Вобщем полечилась пиратской версией третьего фола, и патчем с пиратского сайта для вегаса.
Сначало написанно что «этот коэффициент показывает, насколько сильно значение амплитуда несущего колебания в данный момент отклоняется от среднего значения»
а потом «Основная спектральная составляющая — несущая, не несет полезной информации»
Почему так? Я, честно говоря, думал что у несущей меняется аплетуда, и это изменения несущей потом на приёмнике преобразуется в информационный сигнал (например звук в AM радио).
А то в википедии также скупо и нифига не понято.
Красиво получилось!
Когда вы у себя делали такой «кабинет» я думал что одному мне не повезло, что оказалось холодно от окон.
Похоже сама по себе идея для зимних вариантов не ок.
Там реактор заворотило и всё его содержимое по прилегающей територии раскидало — это пострашнее натовских боеприпасов.
У меня и мысли не было что кому то в голову придёт скармливать видяхе по одному спрайту.
2д считаем на cpu, складываем в буфер и пачкой засылаем в GPU.
Но если игра 3д — то там же нет необходимости по паре полигонов гонять — засунули большой меш в GPU, оно его переварило и нарисовало.
Наверно я не совсем правильно воспринял, для чего всё это вы задумали. Пример со спрайтами должен был это подсказать :)
На сколько раельные сцены можно считать на CPU.
Мы некогда делали гонки под iPhone 3g ещё.
Там после всех отсечений скармливалось видяхе 20к поликов.
У вас обсчёт их обсчёт (считаем спрайт как два треугольника) сьел 18-20% CPU.
Но сегодня бы я не стал делать в 3д игре 20к поликов — т.к. это выглядит довольно деревянно, по современным меркам.
А увеличить кол-во поликов — и процессор будет только этим и занят, а надо ещё физику считать, и ещё отсекать от огромной сцены обьекты, чтоб не кормить видяхе лишнее, иначе она тоже захлебнётся, иногда успевать декодировать музыку, считать звук и прочее.
Вот физику посчитать на неоне — это наверно самое то было бы.
Кстати сам pvr — это тоже «формат для упаковки хардварных форматов» — просто контейнер, а в нём может быть и pvrtc и etc и др.
Мы все форматы в pvr храним.
В статью картинки в формате JNI вешать безсмысленно — всё равно броузер не поймёт.
А на code.google.com помимо примеров программ я закомитил и тестовую картинку, над которой можно поэксперементировать.
Была мысль сделать примерчик на GL ES, но подумал что двух примеров просто загрузки будет достаточно.
В примерах показанно как загрузить картинку в буфер, а что с ней дальше делать — это уже несколько за рамками описания формата JNG.