Тут автор реализовал подключение игровой библиотеки Raylib на ассемблер MASM, сделал это хакерским методом подключения dll к процессу, и своими настроенными функциями. Можете это увидеть в видео. Мне это не очень понравилось. И я решил по экспериментировать с этой библиотекой, но решил это сделать более стандартным способом, просто настройка заголовочного файла и файл raylib.lib версии 3.0. Сейчас в следствии спешки, сделал всего несколько функций, чтобы убедится что метод работает, и метод заработал! Но пока выкладывать не буду, надо нормально всё сделать. Всё будет сделано именно для ассемблера UASM !!! Для масма и фасма и др. я делать ничего не буду, если надо, всё сами сами. Вот, доделал. Так же пару примеров, один пример из видео питон против С++.
Пока ковыряю 3 версию, с более старшими проблемы с линкером, не находит uuid.lib, а если из СДК версии 7.0а подсунуть, то куча ошибок, в общем надо СДК по свежей. Но пока решил с 3 версией разобраться. Что интересно используется прототипы функций где тяжёлые данные типа структуры не по ссылке передаются, а непосредственно в стек помещаются, так же передаются и возвращаемые значения структур. Если размер структуры 4 байт, то передаётся в eax, если 8 байт то через пару регистров eax и edx. Более тяжёлый уже по указателю, который возвращается в eax, при этом не явно задаётся указатель на локальную структуру. Типа так: Код (C++): RLAPI Image LoadImage(const char *fileName); // Load image from file into CPU memory (RAM) На асме получается так: Код (ASM): LoadImage PROTO C (dword) res:ptr Image, fileName:LPCSTR ;// Load image from file into CPU memory (RAM) Из-за этого приходится делать почти всё вручную. h2incx.exe тут плохо помогает. Тут бы, этот самый питухон применить, но я не умею.
...а вообще странно сделано, некоторые структуры весят по 96 байт, и всё это запихивается в стек, что не очень хорошо, особенно если ассемблер используешь, да и вообще. Даже скриптовые луа с питоном структуры используют только по ссылке или указателю.
В общем, сделал, ещё вчера. Но программа запускается если dll только в самой папке с программой, надо как-то зарегистрировать raylib.dll, но таким образом чтобы программа искала СВОЮ версию. Прочитал, что если приложение возьмёт не свою версию, то возможен даже аппаратный сбой, не знаю, но в любом случае будет не хорошо. В общем, нужен метод, чтобы при запуске программы, та искала свою dll по конкретному адресу, который предварительно регистрирует/устанавливается. Типа переменная PATH, причём в файле который лежит с программой в месте. Во времена дос и Win32 это было не слишком сложно насколько помню. В общем, нашел способ, возможно не самый лучший, но работает. Запускаем через батник, где указанно переменная PATH с расположением нашей конкретной dll'ки Код (Text): @echo off REM путь где лежит raylib.dll set PATH=%PATH%;C:\assemblers\raylib_300\bin REM запуск игры raylib textures_bunnymark Файл удобно назвать run.bat, можно ещё зарегистрировать должным образом, но там будут проблемы с точкой входа, raylib.dll на это рассчитан... ЗЫ. Блин, не то нажал, ладно позже. В общем, добавил файлы в ТС. Один из способа запуска батником. Файл назвать run.bat Код (Text): @echo off REM путь где лежит raylib.dll set PATH=%PATH%;C:\assemblers\raylib_300\bin REM запуск файла start textures_bunnymark Настраиваем путь к raylib.dll, и вводим имя файла. Запускаем. Так же можно зарегистрировать дллку, и просто запускать файл, но как я понял, надо установить путь в PATH, но так, чтобы не затереть что-то нужное. Потом сделаю для более новых версий raylib, а так же для Win64. Ах да, там ещё пару файлов надо(macros.asm, include msvcrt.inc), их надо обновить, я там устранил несколько ошибок, и добавил функций.
Автор сделал вторую часть. А я отладил демку мандельброта, работает. И на 3600Х, выдаёт приличный ФПС, аж 455-460. Запуск через run.bat, пути к дллке настройте под себя.
Важно: функции GetScreenWidth и GetScreenHeight возвращает размер всего окна. У меня возвращает размер клиентской области окна, то есть той области в которой вы можете рисовать. Так что придётся ещё своими функциями дополнять. Получить это можно функцией GetClientRect, странно что в движке это не сделано.
линкер может ругаться на отсутствие uuid.lib в том случае, когда в сишных инклюдах была директива #pragma comment(lib,"uuid.lib") при этом не факт, что в остальном (вашем) коде кто-то ссылается на содержимое этой библиотеки можно попробовать закомментировать прагму и посмотреть, что дальше с "кучей ошибок" скорее всего можно порешать тоже, на уровне case sensitive link опции или use mangled names, нужно больше подробностей, что там сыплется
miilalex, я думаю рейлиб не нравится старый СДК, версии 7.0а. Может надо более новая версия, ещё там winmm.lib используется. Тут именно линкер не находит совместимых функций. ЗЫ Скорей всего надо СДК 8 версии установить.
Скорей всего баг выскакивает из-за старого линкера . В названии библиотеки(raylib-5.5_win32_msvc16) указано 16, значит надо VS 2019. Можно попробовать скачать эту студию и использовать линковщик, просто одного СДК мало. Правда мне не очень хочется качать кучу итак крайне громоздких студий. --- Сообщение объединено, 20 май 2025 --- Что-то вся равно не получилось, по ходу надо вс2022, если указать в батнике линковщик 2019, спрашивает uuid.lib, если указать ссылку на СДК 10, то сыпет кучей ошибок на не разрешенный внешний символ. Не понятно что надо, пока без проблем работает версия 3.0, даже версия 3.5 сыпет ошибками. Возмоно криво откомпилированы библиотеки с зависимостями.
что "это" не работает? любой *.lib это всего лишь имя библиотечного файла, который может содержать что угодно (код функций или гуиды например) для сборки exe линкеру не нужно имя как таковое или конкретный файл lib, но линкер хочет найти среди obj файлов в библиотеке те, которые разрешают внешние ссылки из кода программиста т.е. linker wants to resolve references to external code or data pieces то есть например программист в своем условном main вызывает printf, компилятор создает obj в котором в машинном коде у команды call [адрес] вместо адреса printf пока что нули, а до и после этого куска кода находятся записи с external именами и fixup записи, в частности упоминается _printf и компилятор линкеру оставил директиву, что вот эти 4 байта (для 32бит кода) надо при сборке exe заменить фактическим адресом кода библиотечной функции printf, когда линкер будет уже знать, в каком месте exe файла и соответственно в памяти при загрузке и выполнении программы окажется фактический код printf. соответственно если линкер просит uuid.lib это пока еще ничего не значит и не является ошибкой или сигналом проблем. потому что в любом исходнике на си и в любом хидере можно оставить линкеру директиву потребовать некую библиотеку, по имени файла, пофиг на его содержимое. но. если линкер при создании exe порылся в библиотеках и так и не нашел подходящей функции для каждой extern записи в obj файлах после компиляции, он напишет unresolved external [имя не найденного фрагмента кода или данных] и вот тогда надо начинать суету и беспокоиться а что ж пошло не так. возможно, проблема просто в именах - надо открыть свои объектные файлы в hiew (любом hex вьюере) и посмотреть, как выглядят имена импортируемых извне функций (с подчеркиванием или без, с декорированием @имя$pv.. и в таком духе) и попробовать этим же вьюером найти эти функции в библиотеках, которые принимали участие в сборке exe (неважно, был ли в итоге собран exe или нет) если функции как будто присутствуют, но декорирование имен различается, мы копаем в сторону совместимости, то есть, ищем опции, можно ли линкеру сказать чтобы он искал другие варианты оформления имён. если функций буквально нет, выясняем, почему (например, библиотека от другого фреймворка или разрядности) никто не мешает создать библиотеку uuid.lib самому и посмотреть, что в ней хотел в итоге найти линкер. если лень вычеркнуть соответствующую прагму из исходников.
Попробовал штатный ГПСЧ, вообще фигня. Сделал свой на базе кода с этого форума. Реализация теста генератора кроликов.
не вполне работает (raylib.dll в текущем каталоге, W7-64 i5-2400 интегрированная графика Интел, 8 Гб ОЗУ ) я не уверен, должно ли с точки зрения возможеостей железа работать, но наверное имеет смысл в коде приложения чекать, что библиотека что-то не смогла найти или проинициализировать в исходниках меня смущает множество директив EXITM до закрывающей макро ENDM с точки зрения организации кода это примерно как goto перед return то есть как будто неряшливо, возможно ) --- Сообщение объединено, 26 июн 2025 --- скопировал exe, подкаталог с текстурой и raylib.dll на условно пустой новый ноутбук Win11 Pro, Intel N95 ОЗУ 12 Гб там - ошибка при старте - отсутствует msvcr100.dll скопировал файл с семерки в текущий каталог на ноут, после этого выкинуло exception MsgBox но без текста в консольном окне и лыжи не едут ) в сторону я бы заметил, что нет причин устраивать мини dll hell в ехе ради сишного аналога WinApi ExitProcess и VirtualAlloc (и иных *Alloc) поскольку никто не мешает к полученному адресу выделенного блока памяти прибавить число вида 2^n - 1 и этой же маской очистить младшие биты адреса, получив выравненный теперь участок памяти естественно *Free для таких указателей нужно вызывать по оригинальному, не выравненному нами адресу
Библиотека требует OpenGL 3.3 а у тебя Intel HD 2000, версия OpenGL 3.1, чуток функций не хватает. У меня на старом компе без В/К тоже не работает и выскакивает похожее сообщение. Можно ещё самому dll'ку скомпилировать под каждую версию опенГЛки. Это надо чтобы макрос работал как функция, параметры задаются в скобочках.
для функций есть же PROC с передачей параметров списком, а ля INVOKE с возможностью создать в стеке локальные переменные и тд макро это аналог инлайн функций в си, причем "всегда" инлайн и штатно код инлайна заканчивается на слове ENDM причем это важно синтаксически т.к. компилятор может проверять правильность вложенности (парность MACRO/ENDM) а EXITM это своего рода аварийный выход из синтаксического древа анализа исходника и зачем хлопать именно этой дверью не вполне понимаю
