Пишу под винды на ассемблере . Есть програмка- каркасик для обработки 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 , и я не думаю что кто то захочет переходить с них.
+ существует ещё мн-вот графических библиотек с открытым кодом и распр. бесплатно.