Пишу под винды на ассемблере . Есть програмка- каркасик для обработки BMP файлов. На данный момент открывает файлики и даёт возможность рассматривать их на экране с увеличением 16 раз. Разрабатывалась для создания и управления некоей базой картинок, являющих собой модель объекта в трёх мерном пространстве, по плоскостям . Теоритически можно создать и записать модель любого предмета с разрешением 2 в n степени по трём плоскостям измерения.Работы встали от пропажи интереса (финансового). Если есть кто по теме работает , кому интерестно направление симуляторов пространства, пишите .буду рад. Если есть идеи кому это можно продать тоже выслушаю. В настоящий момент занят переводом хелпов..файл win32.hlp. И кстате говорят на С это легче писать .. но мне почему то легче его не учить .а писать как могу, к тому же есть подозрение что на селероне 1700 программа на С не будет так же быстро работать как на ASM, хотя мне будет интерестно со спецыалистами пообщаться ... если найдутся.   

я писал нечто подобное под ДОС (обработка bmp), а под WIN там же всё парой AIP функций, на счёт пространства, это уже погоже на 3D-движок. на эту тему общайся на фарумах разр. игр



так обычно горорят пограммисты С , т.к. не видят смысла писать на АСМ.
 в большенстве случаев компилятор С обгонит "обычную" программу на асм.

так что нужно хорошо знать архитектуру процессора, и использовать оптимизацию для конкретной задачи, только тогда есть смысл написания программы на АСМ.

например на том же форуме разр. игр проводился тест по скорости сортировки из С++ библиотеки, и "моей" сортировки на АСМ, и только в некоторых случаях сортировка на АСМ выигрывала. 

P.S. поищи по форуму, скорей всего и здесь проводилось сравнение языков. 

ds29, 

Понятно .... я API функции использую только для открытия файла закрытия ....позыционирования указателя резервирования области памяти ....остальное всё моё , есть алгоритм .по которому можно машину заставить области изображения понимать и теоретически заполнять базу данных на их основе ...такое движение в сторону искуственных мозгов(тема искуственный интелект).
Конкретно спрашиваю : есть желание поучавствовать в доработке продукта ? чтобы вырисовалось нечто , что можно продавать ?
  
 ты пишешь под винды на ASM?
я пишу на ASM потомучто не могу на С писать .....но точно знаю что си компилятор что то ищё вставляет в прогу ....не могу судить хорошо это или плохо (я не особо разбираюсь в С), но обём файла увеличиваеться.точно ...вообще как то было желание разобраться с заголовочными файлами си языка...но как то всё затухло ...пытался соответствие вывести ....программу каркас на си и на ASM..зделать стопорнулся уже не помню на чём )

ну это не игра точно ... и очень надеюсь что 3D движок не только для игр требуеться ...а например для моделирования предметов пространства или если пофантазировать то и для создания некоего полигона для отработки алгоритма функционирования искуственных мозгов(мечта моя)
хотя конечно спасибо за наводку ..будет время и там наслежу )   

Я программирую на Assebmler под DOS & WIN32. , сейчас использую MASM32

Когда пишешь код на С, ты можешь видеть и листинг на АСМ.

p.s. не совсем понял твою идею 

Не так давно тоже писал на ASM под Винду, потом надоело и перешел на С. На нем побыстрее будет, хотя кастинг и откровенная тупость компилятора иногда сильно раздражают.

2 РАЗДОЛБАЙ:
ИМХО, новый 3d MAX (моделирование 3d-объектов) навряд ли напишешь. А вот доработать\переделать проект до игрового движка - вполне можно было бы. Главное чтобы в нем была своя "изюминка", которой нет в существующих движках.
Что касается продаж, то здесь, увы, иного выхода, кроме как переписать хотя бы большую часть кода на том же С, лично я не вижу. Потому что ни одна компания, будучи в здравом уме, не станет связываться с полностью ассемблерным движком по двум причинам:
1. Его очень сложно модифицировать. Сколько в проекте строк кода? Полагаю, не менее 5000? Даже если все они четко структурированы и разделены по отдельным модулям, модифицировать такой проект будет достаточно затруднительно.
2. Как уже говорил ранее ds29, современные С'шные компиляторы выдают весьма неплохо оптимизированный код. Да, ручная оптимизация всегда будет лучше, это несомненно! Но для нее нужно больше времени (написать неоптимизированный код, написать несколько вариантов оптимизированного кода, посчитать время выполнения и выбрать лучший вариант). Кроме того, при ручной оптимизации есть маленькая хитрость, про которую обычно напрочь забывают - разница в устройстве процев. Грабли в том, что одна и та же последовательность команд на разных процах может выполняться с разной скоростью (причин много - длина конвеера, алгоритм выборки и пр.). И код, который на одном проце работает с огромной скоростью, на другом проце будет выполняться довольно посредственно. С'шный компилятор не только выбирает наиболее оптимальный вариант, но и позволяет вручную задать оптимизацию под конкретный проц (если нужно) - и это, подчеркну, всего лишь заданием дополнительного ключа командной строки (в то время, как ассемблерный код придется переписать заново, что при его количестве будет весьма трудоемко). 

ds29


Я лично не считаю себя глупее компилятора, хотя и пишу обычные программы на ассемблере.


rsm, когда скорость приложения критична и ты имеешь довольно большой опыт(который опять же может быть повышен при изучении алгоритмов оптимизации компиляторов) разработки программ на ассемблере и С, то как бы там ни было ты не доверишь критичные участки кода компилятору, или же обызательно убелишься в том, что компилятор оказался "умнее" тебя, под отладчиком. И что твоя программа делает и как она это должна делать, больше тебя ни один компилятор не знает, поэтому всё-таки не стоит ставить под сомнения свои возможности и превозносить компилятор выше себя Поэтому любой из нас в состоянии написать код на ассемблере, который минимум не хуже Сишного. 

ds29, 
понятно ... я работаю с TASM5.0 макросы можно не использовать ...и в принцыпе можно добиться совместимости между ними. тем более TASM может работать в режиме MASM.
Вообще конечно С подучить тоже есть у меня желание , но пока дальше чем модификации каркаса программы выдаваемой Application Wizard пакета Visual Studio 7.0 не идёт...
даже как то уроки делал от Alex Soft но хватило сил ток на первый урок ..(там примеры отсканированны с листа и текст программы не узнаваем, приходиться востанавливать его применяя свои скудные познания языка С, например функцыи с косинусами и синусами... приходилось искать заголовочный файл где они описанны .нашёл(обычным поисковиком по ключевым словам в заголовочных файлах) , но такой это геморой востанавливать исходник )дальше вообще тёмный лес...хотя обработчики сообщений там мне видны и я могу их изменять...осмысленно . Также понимаю что большая часть кода скрыта от глаз.например создание окошка ...не знаю какая например функция используеться при создании растра совместимого с контекстом устройства ....на ASM всё понятно ..CreateDIBSection создаю область памяти в которую можно рисовать и которая выводиться в окно по приходу сообщения паинт ))...(можно перекидовать изображение кстате где то 70 раз в секунду)..но эт так отступление ..понятно что и в С можно где то найти описание обработчика сообщения WM_CREATE

 Ну идея такова : создать движок 3D если не на ASM то на С...и использовать его для отработки модулей программных продуктов по управлению реальными аппаратами и машинами,  при условии что для управления этими устройствами изначально нет заданной карты местности(виртуальной местности ) , т. есть первое что нужно отработать это восприятие машинами этой местности ....создать алгоритм дающий возможность асязать местность)).
Вообщем :
1. нужно создать 3D движок, с свозможностью достаточно быстро модифицировать виртуальное пространство .
2. при разработке способов описания виртуального пространства наверняка выявяться способы пригодные для достаточно эфективного (с точки зрения производительности ) асязания этого пространства электроникой и своевременной подачи приказа на позиционирование некоего аппарата в пространстве (виртуальном пространстве)
3. учытывая что изначально объект не знает карту местности , то соответственно он должен её воспринимать и адекватно реагировать на неё с целью выполнения некоей задачи , запоминать полученные данные и при необходимости менять свою реакцию.

в принцепе в общем всё ...если удастся такое зделать то даже отдельные части проекта сами по себе ценны..(предпологаю). в свою очередь готов поделиться своими наработками в этой области и обеспечить посильный вклад в этот проект ...с целью воплощения его в реальность. 
если нужно подробное описание проекта .то готов его зделать (понимая что достигаемые цели должны быть хорошо обозначенны). 

BUGOR, всегда должен быть разумный компромис между оптимизацией и скоростью разработки. Если я буду полгода писать ультра-супер-мега-быструю программу, а конкурент за полчаса слабает тормозную, но худо-бедно рабочую программу, то я окажусь в проигрыше. 

rsm, 
 тебе такое же предложение )
Вообщем :
1. нужно создать 3D движок, с свозможностью достаточно быстро модифицировать виртуальное пространство .
2. при разработке способов описания виртуального пространства наверняка выявяться способы пригодные для достаточно эфективного (с точки зрения производительности ) асязания этого пространства электроникой и своевременной подачи приказа на позиционирование некоего аппарата в пространстве (виртуальном пространстве)
3. учытывая что изначально объект не знает карту местности , то соответственно он должен её воспринимать и адекватно реагировать на неё с целью выполнения некоей задачи , запоминать полученные данные и при необходимости менять свою реакцию.

в принцепе в общем всё ...если удастся такое зделать то даже отдельные части проекта сами по себе ценны..(предпологаю). в свою очередь готов поделиться своими наработками в этой области и обеспечить посильный вклад в этот проект ...с целью воплощения его в реальность. 
если нужно подробное описание проекта .то готов его зделать (понимая что достигаемые цели должны быть хорошо обозначенны).   

К сожалению вынужден отказаться - заоптимизировать что-нибудь это я еще могу, но вот в 3d-графике не понимаю ничего, даже шарик с DirectX не нарисую  

BUGOR, 


под компилятором стоит понимать работу очень многих высококвалифицированных программистов, которые изучали мануалы разработчиков прицессоров не один месяц.

что бы тягатся с копм. ты как минимум должен хорошо знать размер и колво тактов выполнения команд процессора , для которого ты пишешь, а так же мн-во алгоритмов оптимизации. + как уже упоминал rsm, при переходе на другой процессор, тебе придётся переписать оч. большое кол-во кода, иначе твоя программа будет намного отстовать от Сишной., ....

 на многих форумах, или сайтах про программирование, проводятся куча тестов, которые, ты вообщето, можешь провести и сам.



p.s. в данный момент я и сам пишу коммерческие приложения на Ассемблере под Окна 

p.p.s. поищи сам тесты, их достаточно много, насколько я помню, что то подобное было и на этом форуме. 

rsm, 
)) если пространственное воображение присутствует то всё просто. есть поле 1024 *768 точек с глубиной цвета 24 бита...я его могу перерисовывать в окошко  70 раз в секунду (приблизительно ).задача проста сама по себе.. представь что смотришь в зеркало ...берёшь кубик и смотришь на него в зеркало ..представь зеркало это наше поле ...задача -трёхмерную картинку просто изобразить в духмерном поле..простым обрезанием того что не видно за передним планом фигуры ..подразумеваеться что фигура имеет изначально известную структуру (и внутреннюю)
Это например можно сделать приняв .за основу что вирт пространство как  и реальное имеет три координаты ...принимаем что одна из координат распространяеться от монитора на нас ....две других вверх - вниз....и влево -вправо. предмет имеет такую же структуру.. трёхкоординатную. для преобразования нужно знать угол наклона влево -вправо угол наклона вперёд-назад и угл поворота влево-вправо и преоброзовать изображение с простым правилом -передний план закрывает следующий за ним . всё  .Знаю что в С ...,там какие-то полигоны(плоские фигуры с немение чем тремя углами )нужно рисовать а для этого нужно создать массив хранящий набор полигонов ...после тоже всё преобразуеться по правилу передний план виден .всё что затеняеться им ..нет.) 
там конечно всякие прогрессии можно применять...что дальше находиться .то мельче рисуеться и т. п.
тени накладывать .но это уже детали ) главное что описание предмета , который рисуется в пространстве находиться в базе данных и дается тоже в трёхмерном пространстве ), являет собой трёхмерный массив цветных точек плюс масштаб.. я так всё вижу . Мне проще на асме написать чем OpenGl штудировать предварительно. Потом , если храниться всё не в сжатом виде ..то можно ожидать производительности системы ..достаточной, для функционирования в режиме реального времени. Ничиго нового не придумал))...люди тоже двигаясь в трёхмерном пространстве видят его двухмерным ...но используя свой опыт могут двухмерную картинку преобразовать к трёхмерной...и насколько мне известно свободно двигаются в трёхмерном пространстве.....я предлагаю лишь автоматизировать алгоритм ..тогда машина сможет это делать тоже . А потом глядишь начнёт сама картографировать местность ...)  
 

Прочтите следующий топик, извиняюсь, что даю ссылку на иной форум, но очень уж актуально сейчас:

http://wasm.ru/forum/index.php?action=vthr...amp;topic=14472 

ds29, 
ну вообщем ...я пишу на ASM  не потому что так программы быстрей выполняются )..а потому что не знаю как на С написать то что мне нужно ..и к тому же глядя на все эти изящества языков С++ др. Иногда складывается впечатление что например Open GL графика создавалась не для того чтоб трёхмерное пространство описывать и визуализировать ...а чтоб родить спрос на быстродействующие процессоры)) ...на это наводит тот факт почему то 3D объекты храняться в одномерных массивах. Это вызывает необходимость преобразовать пространство в пригодное состояние для сохранения на электронном носителе...а при выводе преобразуеться обратно...можно конечно предположить что это зделанно для экономи места жёсткого диска и увеличению скорости доступа к инфе на диске )...но если подумать файл можно прочитать один раз ....а потом сохранить .а графические преобразования выполняються постоянно )))...у меня вывод напрашиваеться однозначный)   

РАЗДОЛБАЙ, 


....



как я понял, то что ты хочешь написать, давным давно реализовано OpenGL(1992) (за основу взят сущ. до этого библиотека IRIS GL) и DirecX.
 
все объекты в 3D , "собраны" из Треугольников, а не из точек, (например квадрат - это два треугольника, а круг, некоторое мн-во).

так что теперь я вообще не пойму твоей задумки, есть два стандарта OpenGL и DirecX , и я не думаю что кто то захочет переходить с них.
+ существует ещё мн-вот графических библиотек с открытым кодом и распр. бесплатно. 

ds29,
да это верно 

ток вот дело в том что например для того чтоб обойти какое то препятствие в пространстве какому то модулю- механизму ..во  первых цвет точки ненужет вовсе ...а во вторых при движени в пространстве достаточна точность плюс минус 1 см ...можно масштабировать изображение ...
возьми кубик со стороной 32*32*32 получается 32768 варианта если чёрно белое изображение (вполне достаточное что  б принять решение есть проход или нет например чёрный нет прохода белый есть ..) если пондобится большая разрешаюсщая способность то пусть точка кодируется не одним битом  а 32 ...и пусть это не цвет будет а адрес ещё одной структуры 32*32*32 но с другим масштабом ...всего делов то ).....ты не заметил совсем ...я предлагаю новый подход к записи информации относительно пространства))....не плоские фигуры рисуют предмет а уже вполне реальное изображение ))сохраняем.. 
Вот на счёт что не захочет нихто с  OpenGL спрыгивать это другое дело )).вообщем так и происходит ...только любое животное на планете легко обходиться без 533 ГГц процессора .....и жёстких дисков огромного размера ))    

Это называется "фотография". Нарисуй в 3d (DirectX или OpenGL) нужный объект и сделай скриншет с окна - задача решена без всяких мудрых алгоритмов.


OpenGL & DirectX были придуманы специально для того, чтобы избавить всех желающих заниматься 3d-графикой от проделанного тобой титанического труда по ручному преобразованию 2d в 3d и обратно. Фактически, можно сказать, что ты написал собственный OpenGL, заточенный под одну конкретную задачу.


Не опыт, а устройство глаза. Третье измерение (расстояние до предмета и его объем) добавляется за счет эффекта аккомодации с последующей обработкой изображения в мозге.


Разве что в полете. Созданная машина не сможет даже ездить по ей же составленной карте, потому как распознавание изображения - задача сложнейшая, над которой без особых успехов бьются с момента появления систем сканирования 3d-объектов. 

Только вот я не понял зачем обрабатывать области, которые не видимы? Т.е. грубо говоря нужно обрабатывать двухмерную картинку, так в принципе и делается. 

Весьма интересно, как ты собираешься узнать, видимы ли области, не перебрав все элементы массива? Или будешь угадывать? 

rsm, т.е. по-твоему для моделования куба размером 1024^3 действительно требуется  536 ГГц? 

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

Подобный "движок" можно написать на Java или C# за один день. Могу поспорить, будет быстрее вашего доморощенного на асме.  

в смысле Подобный "движок" , т.е. с использ. DX or OGL , тогда вермя написания будет примерно равно , если писать на Macro Assenblere.

а "твоих" движков на c# сейчас в сети море и открытыми кодами, так что его никто и писать не будет.

и давайте почитаем книжки 3D гарфики, а то сейчас пойдут споры о z-буФере, проэкциях и т.п. 

* 

Это сообщение отредактировал(а) ds29 - 2.6.2006, 10:57

Java быстрее чем ассемблер? Не смеши мои тапочки...    

Быстрее, чем самодельный движок, написанный не-специалистом. Читай посты внимательнее. 

 

Могу поспорить, что Ваш комплект разработчика на C# нелицензионный. Или што без движка Java/C# вообще ничего не запустицца. И о многом другом могу поспорить.

Имхо, такого рода наезды на ассемблер в данном контексте не вполне тактичны 

 

а бывают не самодельные, или говоря о написании движка на Java или C# за один день ты подразумевал модификацию какого либо движка с открытым кодом?

а где читать внимательнее, процетируй плиз где написано, что не-специалист
?  

Это сообщение отредактировал(а) ds29 - 2.6.2006, 20:45

Для рисования только кубов сойдет и такой алгоритм. Однако РАЗДОЛБАЙ еще в начале указал, что желает применять свою разработку для любых 3d-объектов любой формы. 

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


Написано - вашего [движка]. Вроде как не заметил, чтобы автор темы был специалистом в 3D.


С чего бы это, существует множество фришных либ.
Или ты о студии? Тогда огорчаю - она лицензионная, как и все на компе, включая виндозе  Как и у всех в компании.
 

Не понял.


Это не наезды на асм. Просто идеи, выдвинутые в этой теме (поточечное рисование итп) сделают такой асмовый движок медленнее любого, даже Java-движка, раз в нцать. Из-за незнания основ.  

Здесь я согласен с Domestic Cat. перегнать на асме компилируемые или даже интерпретируемые языки - это не жопки от морковок откусывать. MOV и CMP может написать каждый. Тут нужно специфику современных процессоров учитывать, которая еще постоянно развивается. 

Я уже говорил, что использую OGL or DX , написание движка занимает примерно равное время на любом языке, т.к. определённая часть кода это вызов функций из этих библиотек. 


S.A.P., в данном случае программирование на Ассемблере и заключается в оптимизации. 

Тема живёт своей жизнью.....наверно никогда согласия не будет что круче С или ASM....
Учу С...наверно это единственный способ не отвлекаться от работы)).....   

Не знаю, что круче, но знаю, что за C стоит садиться подучифф asm. А то будешь потом бряцать знанием основ линейной алгебры али цитировать "классиков" - "человечеству не дано обогнать компиллятор и т.п." ;)  

Это сообщение отредактировал(а) Chingachguk - 6.6.2006, 09:17

Chingachguk, 

Согласен ...ASM ..это основа..и я на нём давно пишу...и я не понимаю ., почему люди так чураются ASM..почему то все сразу спрыгивают на тему что разработка и воплощение проекта на ASM это узкозаточенная программа....
если не лениться .то и на асм.е можно быстро писать ...нужно только свои либы делать ...и тогда переносимость и повторяемость не хуже чем на С получается (или любом другом языке высокого уровня)..  
потом, знание Win API32 никому не мешало ..насколько я знаю...было бы желание способ найдёться)) 

всё же Си кросплатформенный, а АСМ нет. 

ds29,  а какая разница? что напишешь то и будет. К сведенью, ведь си все-равно переводится на асм. Как раз таки асм самый кроссплатформенный из всех. Ведь псевдокоманда ассемблера это машиинный код.

Добавлено @ 11:13 
А компу все-равно на чем ты пишешь. Главное - были бы машинные команды в результате. 

хм. в том то и дело, что на каждой платформе (и в зависимости от параметров) Си переводится в разные АСМ коды. 

С - не кроссплатформенный также, как и асм. 

Странный спор... Вы хотите сказать, что машинные команды - не кросплатформенны? Формат исполняемого файла - дело десятое, мы же говорим о языках, а не об особенностях операционной системы. 

Exekutor
Что ты подразумеваешь под платформой?



Конечно нет! Сколько процов, столько и наборов команд. 

хотим 

Ну, я так понимаю, что под кроссплатформенностью понимается различные операционные системы. Возможно, в разных процах добавляются команды (как в интелсовместимых - MMX) но основа (MOV, CMP, SUB и т. д.) одна для всех процов, даже для микроконтроллеров.  

Вики

 

от туда же:
 

Речь о них не шла вроде. 

Конечно общий фундамент есть, но те же мнемоники могут кодироваться по разному и регистры будут другой разрядности и т.п.

Exekutor
Этот кросс-ассемблер не настоящий ассемблер.     Хотя код будет выглядеть одинаковым, но команды в исполняемых файлах всё равно будут разными, под конкретную целевую архитектуру. В итоге получается аналогично Си.  

Добавлено @ 14:59 
Хе-хе, если так рассуждать, то ничего кроссплатформенного не существует.   
А если забить на всё, то кроссплатформенные: asm, c, c++, java, kylix, и даже .net частично...    

Exekutor, 

несколько не полная цитата


Под каждую архитектуру процессора и под каждую ОС или семейство ОС существует свой Ассемблер. Существуют также так называемые «кросс-ассемблеры», позволяющие на машинах с одной архитектурой (или в среде одной ОС) ассемблировать программы для другой целевой архитектуры или другой ОС, и получать исполняемый код в формате, пригодном к исполнению на целевой архитектуре или в среде целевой ОС.


http://ru.wikipedia.org/wiki/Ассемблер 

Вопрос конкрентный ..Есть умельцы..кому интерестно и кто в состоянии это делать ?Сколько денег нужно чтоб интерестно было ? а то никто никто не предложил ...такое впечатление что никому не нужно ...