возврат из подпрограмм

Афтар жжот, аж жуть. Не зависят. Ага. IE6.x only и не зависят. Или мозилла-тормозила. Но с глюками и без звука. Как оттуда достучаться до порта (COM, USB) вообще загадка. Впрочем как и отчепятать бумажку. Вывод более-менее скоростной графики, использование сторонних библиотек

-- всё идёт в сад. И ещё много проблем.

WEB-интерфйс требует как минимум специального сервера под него. И имеет весьма узкую область применения. Нет, я понимаю, что абсолютно всё можно водрузить на тот сервер...

Reply to
Kirill Frolov
Loading thread data ...

У них canvas для этого есть. Игушки пишут. Да примеры, примеры просто посмотри.

Svgalib по очевидным причинам (найди сейчас hercules монитор!) использовать не стоит. У всех давно никакой не (s)vga, а x11 over хрен знает что. Всё насквозь етевое и виртуальное.

xlib переносим только в рамках x11 и достаточно сложен (как для освоения, так и воообще...)

SDL -- вполне вариант. Ещё allegro.

Reply to
Kirill Frolov

Hello Kirill.

17 Aug 06 23:33, Kirill Frolov wrote to Jurgis Armanavichius:

Sergey

Reply to
Sergey Davydov

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Jurgis Armanavichius on Thu, 17 Aug 2006 19:21:42 +0000 (UTC):

JA>>>> Логично. Я, помнится, скачал этот компилятор, но еще не применял. JA>>>> Полюбопытствую. Если что получится - обязательно сообщу.

DT>>> Кстати, есть ещё бесплатный микрософтовский, тот, что в DDK лежит. DT>>> Я им свой VDD компилировал. :)

KF> Осталось понять накойхер он нужен. Против того же gcc. Последним KF> хоть есть что собирать.

А на кой хер этот gcc нужен?

JA>>>> Hе знаю, возможно-ли вообще профессиональное решение с JA>>>> применением очень простого (простейшего!) класса работы с JA>>>> COM-портом.

DT>>> Вот-вот, давайте не будем путать разные задачи.

KF> Для этого нужна ОС реального времени. Вроде QNX. Или хоть линух KF> который с патчем.

Не нужен для этого никакой ни линух ни qnx, прекрасно все под виндой работает. Если в винде непринужденно можно в реальном времени кино в mp4 смотреть, то уж несколько байт за десяток миллисекунд переслать - и подавно. Даже у меня, весьма далекого от программирования винды (и компьютеров вообще), это получилось.

dima

formatting link

Reply to
Dmitry Orlov

Hello Alexey.

Четверг Авгyст 17 2006 21:00, you wrote to Dimmy Timchenko:

AB> Дяденька шутит, MFC никакого отношения к компилятору не имеет. Это AB> просто библиотека, причем морально устаревшая.

А что есть более современное, желательно в основном совместимое с MFC?

Leha

Reply to
Leha Bishletov

AS> Если бы - микрософтовый С++ имеет спецподдрежку для MFC - на другом AS> компиляторе не AS> скомпилится - там спецовые типа ключевые слова добавлены. классика жанра блин

Reply to
Dmitry E. Oboukhov

Если бы - микрософтовый С++ имеет спецподдрежку для MFC - на другом компиляторе не скомпилится - там спецовые типа ключевые слова добавлены.

Reply to
Arcady Schekochikhin

Привет!

Thu Aug 17 2006 23:21, Kirill Frolov wrote to Jurgis Armanavichius:

:-) Мы с тобой об этом уже спорили. Я говорил, что люблю нормальные, удобные в использовании IDE. Хотя gcc тоже уже много лет пользуюсь. Причем, этот микрософтовский компилер - вполне качественная вещь. Я читал, что он порождает в среднем лучший код, чем gcc (но сам я этого не проверял).

Hе согласен. Как же мой проект передает от 4 до 8 МБ/сек при полной загрузке процессора без потерь данных? В принципе я согласен, что почти любую систему можно поставить раком, но если таким мазохизмом не задаваться, то работать будет вполне приемлемо. Об этом можно судить по мультимедийным приложениям, которые работают и никакой (разумной) загрузки процессора не боятся.

А почему у меня работает? ;-) Причем, на разных компьютерах, и никакой своп ничего не ломает. Hет, если задаться целью сломать - тогда, ясен пень, сломать можно, не спорю! :-)

Hе думаю. Другое дело, что с этого толку, если остальное приложение квантуется в среднем по 10 ms...

Hесколько знакомых букв нашел... Вот я и говорю: не выдают свою тайну! :-) (Hе серчай, шутка :-)

Юргис

Reply to
Jurgis Armanavichius

Привет!

Thu Aug 17 2006 23:42, Kirill Frolov wrote to Jurgis Armanavichius:

Да, спасибо, попробую посмотреть. Я так, вообще, зрею потихоньку... ;-) Процесс небыстр...

Я на SDL посмотрел. Что-то там темно... В одном месте пишут, что работают через OpenGL, в другом - напрямую через буффер. Тутор там видел, но, как и во всех других туторах, графика 2D сводится к показу картинки из файла BMP... А мне быстро надо... Видать, придется изобретать персональный велосипед. Hо так не хочется...

А кто такой allegro?

Юргис

Reply to
Jurgis Armanavichius

Привет!

Fri Aug 18 2006 20:23, Anatoly Mashanov wrote to Olga Nonova:

ON>> Последние тенденции таковы, что FrontEnd-ы теперь грамотные люди ON>> строят на базе средств macromedia, которые вообще не зависят от ON>> операционки и броузеров, например, на базе flash-проигрывателя. AM> Окей. URL исходняка или спецификаций, достаточных для написания AM> opensource исходняка средств Macromedia, либо URL загрузочного AM> плугина под FreeBSD - в студию.

Ты что, смеешься, коллега?! Если коллектив авторов приведет хоть что-то практически полезное - пол-эхи со стульев попадает! :-) Чаще всего члены коллектива не имеют зеленого понятия в обсуждаемых вопросах. Hапример, вышеотквоченный бред про flash :-)

Юргис

Reply to
Jurgis Armanavichius

Hello Olga!

17 Aug 06 19:09, you wrote to Dmitry Ponyatov:

DP>> в местном книжном видел две книги по Qt -- библиотека классов ON> Последние тенденции таковы, что FrontEnd-ы теперь грамотные люди ON> строят на базе средств macromedia, которые вообще не зависят от ON> операционки и броузеров, например, на базе flash-проигрывателя. Такми

Окей. URL исходняка или спецификаций, достаточных для написания opensource исходняка средств Macromedia, либо URL загрузочного плугина под FreeBSD - в студию. Вариант плугина под пингвинячий софт, запускаемый под линуксолятором, а также поделки из портов меня почему-то не устраивают.

Anatoly

Reply to
Anatoly Mashanov

Hello Jurgis.

Thu Aug 17 2006 19:37, Jurgis Armanavichius wrote to me:

JA>>> Просто с ООП начинающему проще, не нужно вникать в сложности (если он JA>>> вообще хоть что-то понимает в программировании). DT>> Hе представляю, как с ООП может быть проще. :) По-моему, его DT>> придумали, чтоб программы мышкой писать. ;)

JA> А мне нравится понятие объектов. Как-то оно органично и завершенно...

А мне нравятся типы и модули. :) Hу, о C++ vs Ada здесь уже трёп был...

JA> Опять же, конструкторы/деструкторы. Можно не беспокоиться о закрытии JA> используемых ресурсов.

А зачем их "закрывать"? Есть объект - статический или динамический, и есть процедуры/функции/операции, которые к этому объекту можно применять. Объект не в смысле ООП, а, например, переменная.

Dimmy.

Reply to
Dimmy Timchenko

SDL независима от прослойки между железом и самой SDL. Где-то через svgalib, где-то через X11, где-то через win32, где-то есть OpenGL.

Ты вначале определись, что понимаешь под 2D графикой. А то я и postscript посоветовать могу. Графика бывает, как минимум, векторная и растровая.

В какой-то мере аналог SDL.

Reply to
Kirill Frolov

Привет!

Sat Aug 19 2006 00:31, Kirill Frolov wrote to Jurgis Armanavichius:

Так я-ж десяток раз говорил уже... Я формирую картинку в памяти, т.е. имеется прямоугольный массив байтов. Один байт - одна точка на экране. Картинка черно-белая (градации серого). Вот ее мне и надо вывести. Из моего массива - в окно на экране. Желательно быстро, чтобы оставалось время готовить следующую картинку. Частота кадров - до 60. Сейчас я использую DirectX, но хочу попробовать альтернативы. Также хотелось бы научиться делать то же самое под Линуксом.

Спасибо, понял.

Юргис

Reply to
Jurgis Armanavichius

Привет!

Fri Aug 18 2006 19:51, Dimmy Timchenko wrote to Jurgis Armanavichius:

JA>> Опять же, конструкторы/деструкторы. Можно не беспокоиться о закрытии JA>> используемых ресурсов. DT> А зачем их "закрывать"? Есть объект - статический или динамический, и DT> есть процедуры/функции/операции, которые к этому объекту можно применять. DT> Объект не в смысле ООП, а, например, переменная.

Hе, я о другом. В сложном проекте приходится порождать множество разных ресурсов: память под что-нибудь запрашивать, ресурсы Win32 захватывать и т.п. Потом нужно не забыть все это хозяйство корректно возвратить. Hапример, породил таймер или какую кисть виндусовую - не забудь отдать. А с применением конструкторов/деструкторов такие вещи автоматически делаются: породил свою кисть, попользовался и выбросил не задумываясь. Hужно только деструктор правильно написать, чтобы он корректно вернул все взятое. Вот это мне очень понравилось :-)

Юргис

Reply to
Jurgis Armanavichius

Это и есть "BMP из файа". Релизуется средствами Xlib не слишком слонжно (если нужно только это). В любом тулките есть или аналогичные средства, или можно "handle" окна получить для прямых манипуляций.

Типичный видео-проигрыватель или эмулятор другого компутера. Посмотри, анпример, как это делает fuse (free unix spectrum emulqtor) -- у него несколько разных тулкитов использутся для вывода.

А ffplay из состава ffmpeg и вовсе использует SDL. Ибо интерфейс в том же окне рисовать не нужно, а SDL работает практически везде (и, возможно, даже через Direct-X в виндах -- не знаю).

Reply to
Kirill Frolov

Есть софт, который gcc собирает, в отличи от. Есть gcc -MM. Есть cpp вменяемый.

Автор жжот и путает дурацкие мегагерцы с временем отклика (которое у виндов -- в пределе бесконечность). В показе кина никакие миллисекунды не нужны. Знай успевай картинку перерисовывать. Потеряется кадр -- и хрен с ним, будет выкинут и дальше всё пойдёт. Юзер и не заметит.

Про десяток байт -- так известно, самый быстрый способ передачи информации -- камаз гружённый DVD дисками. Там за десяток миллисекунд столько будет... Тоьлко вот когда доедет?

Это ты ещё просто не понял, что работает оно по воле случая.

Reply to
Kirill Frolov

Это имеет смысл лишь при динамическом создании/уничтожении твоих объектов.

А деструктор -- он самим Биллом Гейтсом вызывается что ли? Автоматически...

Reply to
Kirill Frolov

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 19 Aug

2006 07:23:37 +0000 (UTC):

KF>>> Осталось понять накойхер он нужен. Против того же gcc. Последним KF>>> хоть есть что собирать.

KF> Есть софт, который gcc собирает, в отличи от. Есть gcc -MM. Есть KF> cpp вменяемый.

А есть софт, собираемый VC или BCB в отличие от.

KF>>> Для этого нужна ОС реального времени. Вроде QNX. Или хоть линух KF>>> который с патчем.

KF> Автор жжот и путает дурацкие мегагерцы с временем отклика (которое

Именно, что аффтар жжот.

KF> у виндов -- в пределе бесконечность). В показе кина никакие

Пределы - никого не интересуют, интересует нормальная работа и это не просто вполне реально, но и достаточно просто и _уже работает_.

KF> миллисекунды не нужны. Знай успевай картинку перерисовывать. KF> Потеряется кадр -- и хрен с ним, будет выкинут и дальше всё пойдёт. KF> Юзер и не заметит.

Еще как заметит.

KF> Про десяток байт -- так известно, самый быстрый способ передачи KF> информации -- камаз гружённый DVD дисками. Там за десяток KF> миллисекунд столько будет... Тоьлко вот когда доедет?

Совсем не самый быстрый. Трансфер по даже 100мегабитной сетке с винта на винт - существенно быстрей, чем запись dvd.

KF> Это ты ещё просто не понял, что работает оно по воле случая.

Работает в практически нужном количестве случаев. И этого вполне достаточно.

dima

formatting link

Reply to
Dmitry Orlov

JA> Я попытался посмотреть, как делают простые программные плееры JA> видеофайлов. JA> По-идее, это именно то, что мне и нужно (сформировать картинку и JA> вывести JA> ее в заданное окошко). Hо пока попадались только очень уж JA> навороченные... JA> Вот какой-нить простейший бы найти...

под винду самый простой (для меня) способ -- использовать OpenGL+GLU+GLUT качнув из инета redbook.pdf (manual на OpenGL), с созданием окошка и обработкой ввода запросто справляется GLUT

насколько это портабельно под Linux/MacOS не знаю 8-\, я бы начал c svgalib, если это спецкомпешник для одного приложения, или Qt если более-менее многофункциональная workstation

Reply to
Dmitry Ponyatov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.