Отправляет email-рассылки с помощью сервиса Sendsay

Программирование. Форум !!!

За 2005-03-23

Re[2]: 3D на С или Delphi

Glad to greet, Шматко!

You seem to have written (Tuesday, March 22, 2005):

ШАА> А если без них, то придётся стать специалистом в областях матричной алгебры
ШАА> (для рендера 3D обстановки в 2D экран монитора), кинематике (для анимации),

ШАА> оптике (для моделирования освещения в невакуумных средах), теории материалов
ШАА> и поверхностей - как она там по-научному называется - (для просчёта
ШАА> отражений, преломлений и бликов на гранях и рёбрах) и как минимум основы

ШАА> обработки изображений (для всяких там улучшающих картинку алгоритмов, как-то
ШАА> текстурирование, anti-aliasing, bump-mapping, z-buffering итд итп). Страшно?

Вай-вай, зачЭм девушка пугаешь, да? Куда-то, тебя в сверх
фотореалистичный ray-trace понесло с продвинутой кинематической
моделью.
Для пирамиды с Ламбертовским освещением надо: школьное понимание
векторов (даже можно без матриц для проецирования обойтись, просто
деля на Z-компоненту. Вращение же вокруг Z тоже из учебника по
геометрии стянуть можно); растеризация полигона - никакой науки,
одна-то лишь линейная интерполяция (или вообще плюнуть и рисовать
ребра линиями); сортировка граней по Z (да хоть пузырек, ей богу).

Если речь о книжках, то Боресков, Шикин "Комп. графика: полигональные
модели"- так сказать, библия.
Отличный FAQ по 3д в софте на www.enlight.ru

ШАА> PS. Новый движок изобретаем? Дык все движки сейчас на OpenGL либо Direct3D
ШАА> делают. Зачем возвращаться к технологиям, почившим 9 лет назад?

А чтобы понимать творящееся за ширмой. Очень полезно представлять как
оно устроено. Это помогает и с новыми технологиями разобраться и
использовать всё тебе данное в харде более эффективно.

Alles Gute!

...In Code We Trust...

   2005-03-23 22:37:25 (#338679)

Re: Анализатор спектра

Glad to greet, Vovus!

You seem to have written (Sunday, March 20, 2005):

V> Я столкнулся со следующей проблемой:
V> нужно промоделировать работу анализатора спектра (делаю это с
V> использованием OpenGL в VisualC++6.0), требуется проанализировать
V> спектр звука приходящего из другой программы. Никакой инфы по этой

Clipboard - всему голова ;) . Как-то приходилось решать обратную
задачу - передача своего звука другим приложениям. В принципе в MSDN
неплохо написано (раздел "Clipboard","CF_WAVE","").
Последовательность действий примерно такая:

OpenClipboard(NULL);
HGLOBAL h = GetClipboardData(CF_WAVE);
LPBYTE p;
if ((h) && ((p = (LPBYTE)GlobalLock(h)) != NULL))
{
DWORD MemSize = GlobalSize(h);
// p - указатель на WAVE файл в памяти (можно читать хидер,
// чтобы узнать о формате звука)
// MemSize - длина файла
// делай что надо
...
GlobalUnlock(hCpy);
}
CloseClipboard();

V> И еще: каким образом можно определять и подсвечивать трехмерные
V> объекты на которые указывает курсор мыши?

glInitNames, glLoadName, glPushName, glRenderMode, glSelectBuffer.

Alles Gute!

...In Code We Trust...

   2005-03-23 22:36:37 (#338677)

Re: 3D на С или Delphi

Glad to greet, Galina!

You seem to have written (Monday, March 21, 2005):

G> На чем лучше всего писать программу по 3D (Delphi, Borland C++ Builder, Turbo

На чём удобнее, но с прицелом на будущее советую с++ (Microsoft Visual C++).

G> C)? Может кто подскажет где можно взять литературу с хоть каким-то описанием,

Для начинающих в 3д очень полезен туторил на
http://nehe.gamedev.net/ (OpenGL + MS VC++), если проблемы с
английским - есть переводы (кажися, сайт программирование магических
игр. Не найдешь - напомни, скажу точно). Хочется бумагой шуршать -
книг не много, но есть. Правда, от города сильно зависит (тиражи
малые).

G> как это все делать? (сколько искала в интернете, не смогла найти, может конечно
G> не так искала) Потому что просто даже не знаю с чего начинать ... :)

Главное начать ;)

Alles Gute!

...In Code We Trust...

   2005-03-23 18:52:24 (#338552)

Re[5]: Delphi координаты ярлыка

Здравствуйте !

> VVV> там надо > в другой процесс
> VVV> внедряться и через что то (способов много) > взаимодействовать,
> VVV> передавать > VVV> данные).
> Если Вас не затруднит.

Вобщем, технология такова.
Сначала надо в адресном пространсте чужого процесса (том, чьим окном надо
управлять, или собирать о нем инфу) заиметь свой исполняемый код.
Засунуть код в чужой процесс можно несколькими способами.
Самый легкий - хуки.
Есть еще, конечно Debug API (WriteProcessMemory) + VirtualAllocEx + RPC.
Или можно в Win2000 в каком то параметре реестра прописать ключик
(это искать надо в каком - сейчас не помню) прописать свою dll и она
будет подгружаться ко всем процессам в системе.
Но хук - это классика. Правда есть ограничения - в процессы, где нет
очереди сообщений, dll с хуком не загрузится (например в консольные).
Так вот...

Допустим, написали мы dll с хуком. В делфи, кажется, есть для этого даже
какие то развитые средства.

В этой dll при загрузке надо проверять в какой она процесс загружена.
И если загружена туда куда надо - пытаться связаться с другим приложением -
сервером.

То есть надо писать приложение-сервер, которое будет получать инфу у
внедренной dll или заставлять код той dll выполнять какие то действия.

О том, как передавать информацию между процессами.
Я просто опишу несколько способов - выбор за Вами (некоторые упомяну
просто потому что они есть). Итак. Средства Interprocess Communication:

Clipboard - (ведь передается через него инфа между
процессами?).
MMF - Memory Mapped Files (файлы, отображенные в
память)
Shared Sections - общие области памяти в dll, например.
Pipes - пайпы
Sockets - сокеты
Mail Slots - почтовые слоты
RPC - удаленный вызов процедур
COM - ком - он и есть ком с его маршалингом. Ныне
оно
базируется на RPC
WM_COPYDATA - сообщение есть такое. Как раз для
копирования данных
между процессами. Работает через MMF.
DDE - технология старая.
WriteProcessMemory - Debug API. Для простых задаяч его
использовать не стоит.


Для задачи управления иконками на рабочем столе я бы (если прога только для
себя пишется),
я бы выбрал взаимодействие через сообщения. Для передачи блоков данных
использовал бы
WM_COPYDATA. Это просто и привычно.

То есть в своей проге создается невидимое окно. Имя класса окна -
уникальное.
Когда dll с хуком грузится в процесс, она смотрит, а не explorer.exe ли этот

процесс ?
И, если да, то делает FindWindow - ищет окно того самого класса
(уникального).
Если находит, что делает что там надо. Получает координаты иконок, и.т.д.
и.т.п.
Кладет все это в буффер и шлет через WM_COPYDATA основному твоему
приложению.
В твоем приложении ты эту инфу достаешь и делаешь что там надо.
Усе.

dll, кстати, может в другом процессе запустить поток, создать также
невидимое окно
(или присоединиться к пайпу/засинхронизироваться для чения MMF/открыть
сокет, и.т.д.)-
короче, также создать некоторое средство для получения команд от сервера.


Кстати, м MSDN где то была статья (кажется, автор Paul DiLascia) - так вот
там как раз
какие то манипуляции с десктопом производились через dll с хуком.

--
С уважением, Вахтуров Виктор.

Номер выпуска : 4172
Возраст листа : 549 (дней)
Количество подписчиков : 530
Адрес в архиве : http://subscribe.ru/archive/comp.soft.prog.prog/msg/338101
Получить правила : mailto:comp.soft.prog.prog-rules@subscribe.ru
Формат "дайджест" : mailto:comp.soft.prog.prog-digest@subscribe.ru
Формат "каждое письмо" : mailto:comp.soft.prog.prog-normal@subscribe.ru
Формат "читать с веба" : mailto:comp.soft.prog.prog-webonly@subscribe.ru

   2005-03-23 00:38:44 (#338101)