Board.KolibriOS.org

Ты наверно свои модули дописывал?

Пришлось написать только функцию trunc - больше я ничем из модуля system не пользовался.

А как ты прогу на паскале откомпилировал для МЕОС ?

Об этом я написал статью http://menuet.homelinux.net/Ru:Dev:Free_Pascal
В кратце - я компилирую программу free pascal'ем в ассемблер, потом с помощью специальной программы (довольно простой) удаляю из полученного листинга все лишнее и привожу к синтаксису FASM'a, так же добавляю включаемые файлы на ассемблере c необходимыми
функциями для работы с MeOS и функциями из библиотеки system (пока мне понадобилась лишь одна). Остается передать управление
на точку входа программы из ассемблера.
Таким же способом можно компилировать и модули на паскале. В общем вполне реально написать одну половину программы на паскале, а вторую на ассемблере.

halyavin
Понятно. Наверно это нелегко, хотя я и не любитель паскаля, но на нем много интерестных примеров есть... =)

Про движок: Портировал пример с TP7 В асм, перевел цвет в 24 бита, оказалось тоже самое г... что я и делал
в slope движке "только вид сбоку" там просто скан линия вертикальная, а не горизонтальная, хоть код на TP 7
был почти ни как не оптимизированн, всетаки там есть парочка задоумок, что касается правильного текстурирования
то мой метод не подходит (как ново), понял природу появления искажений, но идеии еще остались, точнее одна
описывать ее сдесь не буду, много писать придется... вообщем работа пока идет...

Результаты моих последних трудов
http://www.cyberdeck.fatal.ru/3DLAST.rar

Уезжаю в Ялту до 25 августа, но я еще вернусь засим всем до встречи.

Вопрос, как сделать буферизацию определённого участка экрана (изображения)
например что бы реализовать прокрутку в контроле?

АУ НАРОД, что никто не знает? не может быть..
у меня подозрения что можно это сделать через прямой доступ к видеопамяти (хотя думаю это не оптимальный вариант)..
я так понимаю что в [gs:0000] хранится цвет пикселя в координатах (0,0)
я так думаю что (GS=Y; [GS:X])будет храниться пиксель по координатам (х,у)? Если нет, то подскажите как организовать
виртуальное окно (что бы обрабатывать прямоугольную часть изображения как в scrollbox например? - т.е. прокручивать изображение в
выделенном участке на форме)... с помощью этого думаю реализовать листбоксы, комбобоксы и доделать эдиты до ума...
или хотя бы ссылочку, где мона почерпнуть инфы по этой тематике

А рисовать только в буфер и выводить его потом на экран слабо?

а как?!

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

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

http://www.deck4.narod.ru/3DNG.rar

П.С. Пока немогу заниматься МЕОС пишу систему тестирования для своего уч. завед. на BCB6
эх были бы в меос компаненты...

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

Игры нужны Трехмерные,причем сетевые(друг против друга играть интересней).
Надо будет HEXа подключать к делу.

а у меня безумная идея - может быть интегрировать 3д движок в систему (в ядро)?
и гуи будет не просто оконным а поистине трёхмерным

FreGL
Кхм.
Парень я позволю себе напомнить, что ты уже заявлял, что сделаешь новые ГУИ компоненты для существующего интерфейса, и что мы видим?
А ничего! Только один раз появился и сказал что тебе не до этого. А раз у тебя нет времени и желания делать даже более простые вещи, то дальше пусть читающие делают выводы сами.

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

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

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

FreGL Мене тоже в голову приходила пару раз идея портирования процедур в ядро... но пока она кажется до безобразия безумной)) Что касается 3D GUI для начала нужно сделать хоть какое нибудь GUI)) и это будет не целесообразно. GUI это вообще больной вопрос я уже к нему подходил два раза первый с Nemom Ratasyevim когда он писал NoBody Basic , а второй раз сам, чтобы сделать GUI нужно плотно работать с ядром... а это не просто.

andrew_programmer может быть... тока нужен процессор помощнее да и с сетью я пока работать не умею...

Mario79Ок! Буду доводить до ума.

Мощный процессор необязателбно.
Текстурирование можно производить одноцветными треугольниками(например для модели танка или самолета),а это внесколько раз быстрее,чем накладывать картику.Я видел на 100MHz компьютере 3D игры.В сетевой игре "NETWAR" (можете скачать с http://www.dosgames.ru) использовалось текстурирование одноцветными треугольниками(игра сделана для режима 640*480).А вообще,игры типа DOOM,Quake хорошо идут на слабых машинах(в них вектора нормалей полигонов пересекаются под прямым углом,а это здорово упрощает текстурирование и разгружает процессор).Думаю,что для реализации в Колибри игр такого типа вполне достаточно процессора на 300MHz.