Никак не получается скомпилить программу в Си++ исполнении =( Использую MSVC6.0. Взял пример из самого архива uFMOD (http://www.wasm.ru/src/4/ufmod.zip) Если расширение .c (test.c), то всё замечательно компилится. Но если поменять на test.cpp, то сразу же получаем: test.obj : error LNK2001: unresolved external symbol "void __stdcall uFMOD_SetCallbacks(void *,void *,void *,void *,void *)" (?uFMOD_SetCallbacks@@YGXPAX0000@Z) test.obj : error LNK2001: unresolved external symbol "int __stdcall uFMOD_PlaySong(void *)" (?uFMOD_PlaySong@@YGHPAX@Z) test.obj : error LNK2001: unresolved external symbol "void * __stdcall uFMOD_LoadSong(char *)" (?uFMOD_LoadSong@@YGPAXPAD@Z) test.obj : error LNK2001: unresolved external symbol "void __stdcall uFMOD_FreeSong(void *)" (?uFMOD_FreeSong@@YGXPAX@Z) Помогите, плиз, советом Заранее спасибо
Barracuda Afaik в test.h прототипы функций надо обернуть Code (Text): #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } #endif
q_q Огромное спасибо Уже как только не колдовал с настройками линкера, а поколдовать с препроцессором не догадался Вот что значит опыт Ещё раз спасибо! :]
Недавно попросили прикрутить uFMOD к одному прожекту. Подробно что к чему я не разбирал и исходников под руками щас нет, но запомнилось вот что: 1. Какой-то .inc тянет пару либ из \masm32\lib\xxx. В либу прописываются полные пути и если компилер проекта, к которому она прикручивается, на другом диске, то линкер обламывается найти эти либы. Самое смешное - они напрасно тянуться. Я их вообще закомментарил и пересобрал либу - стало всё ОК. 2. Как я понял, колбэки можно вообще не выносить из либы, т.к. я втупую взял их из примера. Т.е. если юзеру не нужен контроль над потоком, либа сама всё делает. Достаточно только LoadSong/PlaySong. Я бы сделал так: если колбэки не требуются, можно вообще не звать InitCalback или звать её так InitCalback(NULL,NULL,NULL...). Если какой-то колбэк нужен, то юзер его сам кодит и передает в InitCalback. 3. Что-то там у вас накосячено с проверкой ошибок. То ли если InitCalback два раза позвать падает, то ли что-то ещё... не помню.
> Что-то там у вас накосячено с проверкой ошибок. То ли если InitCalback два раза позвать падает, то ли что-то ещё... не помню. Падает что, тестовый пример или то приложение к которому ты прикручивал? У меня падает только в одном случае, если в win98! на Play нажать Enter и держать, тогда получается что мы заставляем прогу делать бесконечный рестарт проигрывания, после такого жестокого испытания через несколько секунд падает.
Four-F Правильно. Т.к. компилируется статическая либа, то линкер вообще не вызывается и kernel32.lib + winmm.lib на этом этапе не нужны. Убрал. Колбэки требуются всегда Некоторые из них действительно были лишними и были удалены из последней версии, но те, что остались действительно нужны. Ну... Зачем же его 2 раза звать? Хотя, если вспомните что там точно было я проверю. Спасибо!
Asterix Я тебе уже писал, что это связано с динамической памятью в недрах того исходника, что осталось перевести на асм Пора писать новый релиз...
Очень удачно подняли тему У меня появился ещё один вопрос к опытным людям После добаления подобного кода (т.е. любого кода с вызовом функции pow): Code (Text): double power(double x, double y) { return pow(x, y); } получаю ошибку: Code (Text): LIBC.lib(fpinit.obj) : error LNK2005: __fltused already defined in uFMOD.lib(music_formatxm.obj) Release/test.exe : fatal error LNK1169: one or more multiply defined symbols found Как можно устранить подобную неприятность? P.S. Quantum & Asterix Огромное спасибо за uFMOD
Barracuda Внутри music_formatxm.c есть такая строчка: Code (Text): extern int _fltused = 0; // disable FPU CRT Это удаляет из модуля какой-то код с использованием FPU, который генерирует компилятор VC. Если небольшое увеличение размера вам не помешает, можете удалить эту строчку и перекомпилировать (сначала ассемблерные модули, а потом сишные).
Интересно, почему это примерчик загружает процессор на 100%? winamp же при воспроизведении этого .xm вообще не нагружает проц. Может либа кривая?
cresta Прямо таки на 100%? Может. З.Ы. Уже исправил. Заменил Sleep(0) на Sleep(2) и максимальная загрузка упала до 0-1%.
<font color="gray][ Asterix</font><!--color--><font color="gray]: Это ты давно пробовал или проблемы с последней версией что сейчас лежит на сайте? ]</font><!--color--> Дело было неделю назад. <font color="gray][ Asterix</font><!--color--><font color="gray]: Падает что, тестовый пример или то приложение к которому ты прикручивал? ]</font><!--color--> То к чему прикручивали. Кажись я забыл про SetCallbacks и, на то ли LoadSong, то ли PlaySong оно упало. <font color="gray][ Quantum</font><!--color--><font color="gray]: Колбэки требуются всегда ]</font><!--color--> Я не это имел в виду. Я хотел сказать, что колбэки можно в либу перенести, если не требуется контролировать поток. Т.е. предусмотреть вариант по-умолчанию. Вот чтоб так можно было делать. Code (Text): void open(void){ hRes = FindResource(0,(char*)1,(char*)RT_RCDATA); memf.mem_length = SizeofResource(0,hRes); memf.mem_data = LoadResource(0,hRes); memf.mem_pos = 0; } uFMOD_SetCallbacks( &open, NULL, NULL, NULL, NULL ); hSong = uFMOD_LoadSong(0); uFMOD_PlaySong(hSong); И кстати, uFMOD_LoadSong(0) как-то не логично. Надо uFMOD_LoadSong(<что-то идентифицирующее xm>). Тогда колбэк open возможно вообще не нужен. <font color="gray][ Quantum</font><!--color--><font color="gray]: Зачем же его 2 раза звать? ]</font><!--color--> Ну я типа про защиту от дурака. С _fltused у меня тоже косяк был. Прикручивалось к MFC'ишному проекту и линкер ругался, что типа есть уже такое. Автор проекта божился, что сам не юзает _fltused. <font color="gray][ Quantum</font><!--color--><font color="gray]: Прямо таки на 100%? ]</font><!--color--> Ага Тот xm, что у вас в примере ещё более-менее, а то, что я из сети понатаскал на все 100%.
Four-F > Я не это имел в виду. Я хотел сказать, что колбэки можно в либу перенести Это я сразу понял. Прям P&P какой-то получится тогда > Кажись я забыл про SetCallbacks и, на то ли LoadSong, то ли PlaySong оно упало. Вот видишь - твоя вина оказывается
Four-F Это в примере ноль, а вообще этот параметр как раз и предусмотрен для "<что-то идентифицирующее xm>". Это "что-то" передаётся потом в open-callback. А можно как в minimal: Code (Text): uFMOD_SetCallbacks( &tell, &tell, &read, &seek, &tell ); Позволить передавать нули потребует ввести в код либы дополнительную логику, а это увеличит размер либы Нет, так оно работать не будет. Вызывать LoadSong без предварительного вызова SetCallbacks - это как вызывать sendto без WSAStartup Пока можно исправить так как я объяснил Barracuda, а потом, как только последний сишный исходник превратится в нормальный ассемблерный, мы уберём fltused. Да, это баг. Уже исправлен, но надо опять тестировать. Скоро выложим сервис пак на сайте
Quantum Спасибо за ответ. Я сначала просто открыл либу WinHEX'ом и заменил fltused на другое имя Всё стало компилиться, но я не был уверен в правильности и надёжности такого метода Теперь же я перекомпилил либу без строчки "extern int _fltused = 0;". Такое незначительное изменение размера для меня не помеха
Quantum > Возможны проблемы - под NT системами Sleep(2) даёт задержку ~15мс. Нужно добавить timeBeginPeriod(1) - это мистическим оброзом виляет на планировщик http://www.wasm.ru/forum/index.php?action=vthread&forum=4&topic=9034&page=1
<font color="gray][ Asterix</font><!--color--><font color="gray]: Прям P&P какой-то получится тогда ]</font><!--color--> Точно. IMHO, так и должно быть. Я бы хотел, в идеале, иметь всего две функции: ИграйПесню и НеИграйПесню <font color="gray][ Quantum</font><!--color--><font color="gray]: а это увеличит размер либы ]</font><!--color--> На сколько? На 38,5 байт? Ну и хрен-то с ним. А так мне колбэки в проекте определять нужно и суммарный размер остается тем же. <font color="gray][ Asterix</font><!--color--><font color="gray]: Вот видишь - твоя вина оказывается ]</font><!--color--> Бесспорно я накосячил, но помнится был эксепшн, а должна была вернуться просто ошибка без падения кода. Asterix и Quantum, проджект ваш - решать вам, но я бы сделал так (по аналогии с PlaySound): Code (Text): uFMOD_PlaySong The uFMOD_PlaySong function plays a song specified by the given filename or resource. BOOL uFMOD_PlaySong( LPCSTR pszSong, HMODULE hmod, DWORD fdwSong ); Parameters: [i]pszSong[/i] A string that specifies the song to play. If this parameter is NULL, any currently playing song is stopped. Two flags in fdwSong (SNG_FILENAME, and SNG_RESOURCE) determine whether the name is interpreted as a filename or a resource identifier. [i]hmod[/i] Handle to the executable file that contains the resource to be loaded. This parameter must be NULL unless SNG_RESOURCE is specified in fdwSong. [i]fdwSong[/i] Flags for playing the song. The following values are defined. Value Meaning SNG_FILENAME The pszSong parameter is a filename. SNG_LOOP The song plays repeatedly until uFMOD_PlaySong is called again with the pszSong parameter set to NULL. SNG_MEMORY The parameter specified by pszSong points to an image of a song in memory. SNG_RESOURCE The pszSong parameter is a resource identifier; hmod must identify the instance that contains the resource. Return Values Returns TRUE if successful or FALSE otherwise. Тогда всё становится гениально просто: Code (Text): // // Колбасимся // uFMOD_PlaySong( IDR_VERYCOOLSONG, hInstance, SNG_RESOURCE | SNG_LOOP ); // // Отдыхаем // uFMOD_PlaySong( NULL, NULL, 0 ); Ну а если юзеру нужен контроль над потоком, то пусть он уже париться с колбэками. Размер увеличится крайне незначительно, а главное, что это увеличение будет, IMHO, оправдано.
S_T_A_S_ Очень интересный топик. В minifmod на этом месте было Sleep(5-10). БОльшие задержки приводят к понижению качества звучания. IMHO, главное - чтоб качество не падало, а не точная продолжительность задержки в микросекундах. Ещё раз спасибо за ссылку! Four-F Не доводите меня до инфаркта такими цифрами Идея, безусловно, интересная. Принята на рассмотрение. Это мы исправим. Пару байт добавить - ещё куда ни шло.
