Тёмная тема
bw
>если бы ты сделал статическую библиотеку и предоставил возможность извне определять "контекст отрисовки"
Так ведь оно так и сделано. Еще раз говорю - порт, это только ПРИМЕР использования DLL, сама DLL всего лишь выполняет обработку изображений, получая указатель на них. Единственное требование к платформе - процессор с поддержкой MMX.
Если бы у меня не было разделения на платформозависимую и независимую части, я бы сделал ActiveX DLL, куда включил ВСЁ, и портирование бы не требовалось.
Возможно ReadMe несколько сбило с толку, оно относится не столько к DLL, сколько к порту.
Я совершенно незнаком с программированием под линукс и пр. не виндоус платформы. Может ли такая динамическая библиотека оказаться там нерабочей?
Arxon
> поэтому никаких портов
Ну в общем смысле. Функции управления памятью, потоками и т.д. Под каждой платформой они реализуются по своему и поэтому не могут быть "зашиты" в компоненты. Потребуется что-то вроде libc, который отдельно для каждой платформы будет реализовываться.
Mikle, DLL можно использовать только под виндой, либо в эмуляторах, либо в средах по типу Wine. Я говорил как упростить работу программистам, предоставляй свою библиотеку в виде .o (объектов, для линковки). Каким ты ассемблером пользуешься? Я думаю знаешь как это сделать.
..bw
bw
DLL скомпилирована в Power Basic, но написана полностью на асме, пробовал компилить в Delphi, но получается слишком большой файл, пробовал в СИ, но там ногу сломишь с этими "pragma", могу дать исходник.
bw,
>Функции управления памятью, потоками и т.д. Под каждой платформой они реализуются по своему и поэтому не могут быть "зашиты" в компоненты.
Согласен. Но стремление к максимальной минимизации кода порта здоровое стремление. Тем более что в компонентах которые я бы хотел порт вообще не требуется.
В томже компоненте скелетной анимации не будет работы с файлами например, и своего експортера из макса. Тоесть это не будет полностью готовая скелетная анимация, но будет набор деталей с помощю которой будет легко дописать экспортет из макса маи или еше чего, + надо будет дописать реализацию в движке, чтоб файлы читала итд.... Это своеобразная плата за то чтобы компонент был ЧИСТЫМ, мог заюзатся каждым. А если пойти путем создание собственной системы загрузки файлов системы потоков, и их портов, итд.... то дело придет в итоге к написанию нового движка. А этого совсем не хочется !
Но тот же компонент может проявить инициативу, например, выделить (запросить) память. Какой будет интерфейс этого метода? Linux, Windows и или свой? Подозреваю что свой. Значит потребуется портирование (я может не правильно использую этот термин, но надеюсь ты меня понимаешь) системной функции выделения памяти (буквально обертка её в интерфейс пригодныя для использования нашим компонентом). Затем будет компонент загрузки ресурса (опять без привязки к платформне), ему потребуется некий потоковый объект (файловый, возможно именованый). И опять этот потоковый объект будет реализовываться для каждой платформы отдельно.
Т.е. хочешь ты или не хочешь реализовывать платформозависимую функциональность, но интерфейсы (выделение памяти, работа с файлом), которые ведут к этой реализации, делать всеравно придется. Мы поняли друг друга :-) ?
Mikle, вышли на , покумекаю на досуге.
..bw
bw
>Т.е. хочешь ты или не хочешь реализовывать платформозависимую функциональность, но интерфейсы (выделение памяти, работа с файлом), которые ведут к этой >реализации, делать всеравно придется. Мы поняли друг друга :-) ?
Поняли :) Вопрос только в выборе функционала компонента и в определении его интерфейсов.
bw
Отправил.
Arxon
Под п.20 и я подпишусь.
Mikle, я отписал в http://www.gamedev.ru/projects/forum/?id=68589&page=2.
..bw
Тема в архиве.