<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
	<title type="html"><![CDATA[Авионика и Софт &mdash; Неделимый пиксель]]></title>
	<link rel="self" href="http://www.forum.aviosoft.ru/extern.php?action=feed&amp;tid=52&amp;type=atom" />
	<updated>2017-01-17T19:54:16Z</updated>
	<generator>PunBB</generator>
	<id>http://www.forum.aviosoft.ru/viewtopic.php?id=52</id>
		<entry>
			<title type="html"><![CDATA[Re: Неделимый пиксель]]></title>
			<link rel="alternate" href="http://www.forum.aviosoft.ru/viewtopic.php?pid=175#p175" />
			<content type="html"><![CDATA[<p>Здравствуйте! Приносим свои извинения за задержку с ответом.<br />Нет, пиксель вовсе не обязан быть целым. В своё время мы думали над этим и выбрали целочисленное представление координат. На то были следующие причины.<br />Процессоры современных персональных компьютеров давно имеют встроенные средства (сопроцессоры) для выполнения операций с числами с плавающей точкой. Скорость таких операций сопоставима со скоростью целочисленных операций. В результате, на персональном компьютере, созданный в САПР программный код, будет одинаково быстро выполняться не зависимо от типа использованных в нём значений и операций с ними.<br />Но программный код, созданный в САПР, должен иметь возможность отрабатывать и в разнообразных системах отображения информации. До сих пор львиная доля их реализуется на недостаточно производительной, а порой и просто на морально устаревшей элементной базе. Речь идёт в первую очередь об отечественных разработках. Например, в недавнем прошлом нам встречались МФИ созданные на intel 486 микропроцессорах без блока сопроцессора или процессоры, созданные на ПЛИС, в которых присутствовали только целочисленные операции и для работы с плавающей точкой приходилось подключать к исходному коду библиотеки программной эмуляции данных операций. Ни о каких аппаратных ускорителях графики при этом в подобных разработках не стоит и говорить. Вся рисующая аппаратная часть до сих пор реализуется исключительно на целочисленной арифметике.<br />В дополнение к этому мы убеждены, что для человека гораздо комфортнее использовать привычные нам целые типы данных. Они обеспечивают более однозначный и предсказуемый результат. Также не бойтесь использовать смещение и поворот локальных систем координат, это абсолютно никак не сказывается и не может влиять на скорость прорисовки OpenGL.<br />В настоящее время уже начинают появляться разработки систем индикаций с применением современных аппаратных ускорителей и рисующей частью на основе OpenGL. Мы следим за этим и, возможно, в ближайшем будущем издадим версию САПР с float значениями в качестве координат вершин примитивов. А пока, как и задумывалось нами изначально, пользователю для всех нужд прорисовки необходимо использовать имеющиеся виды примитивов.</p>]]></content>
			<author>
				<name><![CDATA[Admin]]></name>
				<uri>http://www.forum.aviosoft.ru/profile.php?id=2</uri>
			</author>
			<updated>2017-01-17T19:54:16Z</updated>
			<id>http://www.forum.aviosoft.ru/viewtopic.php?pid=175#p175</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Неделимый пиксель]]></title>
			<link rel="alternate" href="http://www.forum.aviosoft.ru/viewtopic.php?pid=174#p174" />
			<content type="html"><![CDATA[<p>Здравствуйте! Действительно ли пиксель должен быть целым? Когда нужно отрисовать какую-нибудь хитрую (овальную) шкалу, проще задать координаты формулами, но из-за округления до целых пикселей? шкала получается пляшушей. В приложении пример обычной круглой шкалы, заданной координатами. В случае если её же нарисовать через поворачивающуюся группу, всё выглядит нормальным</p>]]></content>
			<author>
				<name><![CDATA[gluhow]]></name>
				<uri>http://www.forum.aviosoft.ru/profile.php?id=45</uri>
			</author>
			<updated>2017-01-13T13:19:07Z</updated>
			<id>http://www.forum.aviosoft.ru/viewtopic.php?pid=174#p174</id>
		</entry>
</feed>
