<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title><![CDATA[Авионика и Софт &mdash; Неделимый пиксель]]></title>
		<link>http://www.forum.aviosoft.ru/viewtopic.php?id=52</link>
		<atom:link href="http://www.forum.aviosoft.ru/extern.php?action=feed&amp;tid=52&amp;type=rss" rel="self" type="application/rss+xml" />
		<description><![CDATA[Недавние сообщения в теме «Неделимый пиксель».]]></description>
		<lastBuildDate>Tue, 17 Jan 2017 19:54:16 +0000</lastBuildDate>
		<generator>PunBB</generator>
		<item>
			<title><![CDATA[Re: Неделимый пиксель]]></title>
			<link>http://www.forum.aviosoft.ru/viewtopic.php?pid=175#p175</link>
			<description><![CDATA[<p>Здравствуйте! Приносим свои извинения за задержку с ответом.<br />Нет, пиксель вовсе не обязан быть целым. В своё время мы думали над этим и выбрали целочисленное представление координат. На то были следующие причины.<br />Процессоры современных персональных компьютеров давно имеют встроенные средства (сопроцессоры) для выполнения операций с числами с плавающей точкой. Скорость таких операций сопоставима со скоростью целочисленных операций. В результате, на персональном компьютере, созданный в САПР программный код, будет одинаково быстро выполняться не зависимо от типа использованных в нём значений и операций с ними.<br />Но программный код, созданный в САПР, должен иметь возможность отрабатывать и в разнообразных системах отображения информации. До сих пор львиная доля их реализуется на недостаточно производительной, а порой и просто на морально устаревшей элементной базе. Речь идёт в первую очередь об отечественных разработках. Например, в недавнем прошлом нам встречались МФИ созданные на intel 486 микропроцессорах без блока сопроцессора или процессоры, созданные на ПЛИС, в которых присутствовали только целочисленные операции и для работы с плавающей точкой приходилось подключать к исходному коду библиотеки программной эмуляции данных операций. Ни о каких аппаратных ускорителях графики при этом в подобных разработках не стоит и говорить. Вся рисующая аппаратная часть до сих пор реализуется исключительно на целочисленной арифметике.<br />В дополнение к этому мы убеждены, что для человека гораздо комфортнее использовать привычные нам целые типы данных. Они обеспечивают более однозначный и предсказуемый результат. Также не бойтесь использовать смещение и поворот локальных систем координат, это абсолютно никак не сказывается и не может влиять на скорость прорисовки OpenGL.<br />В настоящее время уже начинают появляться разработки систем индикаций с применением современных аппаратных ускорителей и рисующей частью на основе OpenGL. Мы следим за этим и, возможно, в ближайшем будущем издадим версию САПР с float значениями в качестве координат вершин примитивов. А пока, как и задумывалось нами изначально, пользователю для всех нужд прорисовки необходимо использовать имеющиеся виды примитивов.</p>]]></description>
			<author><![CDATA[null@example.com (Admin)]]></author>
			<pubDate>Tue, 17 Jan 2017 19:54:16 +0000</pubDate>
			<guid>http://www.forum.aviosoft.ru/viewtopic.php?pid=175#p175</guid>
		</item>
		<item>
			<title><![CDATA[Неделимый пиксель]]></title>
			<link>http://www.forum.aviosoft.ru/viewtopic.php?pid=174#p174</link>
			<description><![CDATA[<p>Здравствуйте! Действительно ли пиксель должен быть целым? Когда нужно отрисовать какую-нибудь хитрую (овальную) шкалу, проще задать координаты формулами, но из-за округления до целых пикселей? шкала получается пляшушей. В приложении пример обычной круглой шкалы, заданной координатами. В случае если её же нарисовать через поворачивающуюся группу, всё выглядит нормальным</p>]]></description>
			<author><![CDATA[null@example.com (gluhow)]]></author>
			<pubDate>Fri, 13 Jan 2017 13:19:07 +0000</pubDate>
			<guid>http://www.forum.aviosoft.ru/viewtopic.php?pid=174#p174</guid>
		</item>
	</channel>
</rss>
