куда я спешилApromix писал(а):Пришлось для твоего примера качать Rtl60.bpl и Vcl60.bpl, но оно того, хе-хе, стоилоОстался СИШАРП

вот этот должен просить только dll-ку по идеи через LoadLibrary должно работать везде.
Модератор: Apromix
куда я спешилApromix писал(а):Пришлось для твоего примера качать Rtl60.bpl и Vcl60.bpl, но оно того, хе-хе, стоилоОстался СИШАРП
Код: Выделить всё
BOOL WINAPI ReadConsoleOutput(
__in HANDLE hConsoleOutput,
__out PCHAR_INFO lpBuffer,
__in COORD dwBufferSize,
__in COORD dwBufferCoord,
__inout PSMALL_RECT lpReadRegion
);
Код: Выделить всё
extern "C" __declspec(dllimport) void __stdcall GenMap (int,int,int,char**,int);
Вполне допускаю, но...Apromix писал(а):генератор карт должен генерить карту только в базовом виде, как есть сейчас
Получается, игра, выцепив из генератора почти готовый уровень (а у вас, извините, хоть сразу на экран вставляй), должна вычислять границы комнат-переходов, расставлять высоты холмов и прочую информацию, которая уже была вычислена на стадии генерации? Вычислять с неизбежными ошибками. Цвет и тайл -- черт с ними, это очевидно, я имел в виду информацию, которая потеряется в ASCII и для восстановления которой необходимо будет применять алгоритмы порядка распознавания изображения. Мы же со случайными числами работаем, какой алгоритм определения важности тайла не применяй, рано или поздно артефакт таки будет поставлен не стой стороны стены.Apromix писал(а):Уже сама игра должна по этой карте определять важность тайла, его тип, подтип и цвет <...> расставлять объекты
Примерно про это я и говорил. Реализация объектов, разумеется -- это в самой игре. Но что это за тайл и зачем он тут нужен, можно описать и поподробнее.Apromix писал(а):Так я сейчас делаю в HoD'e. Там есть только массивы из структур (слоев на карте) из целых чисел (номера объектов).
Практически это я и имел в виду. Если учитывать и количество чего-то на карте (комнат, озер, башен), то получается, что для каждого типа карты необходимо что-то типа структуры параметров. Что приводит к...JustHarry писал(а):Параметризация генератора зависит на мой взгляд только от типа карты(город может быть разрушенным\целым, лес густым\редким, река глубокой\иссушенной и т.д)
Когда руки дойдут до параметризации, будет "слава богу, получилось, часть вторая". Имхо надо придумать это сейчас, но на саму реакцию со стороны генератора на эти параметры пока действительно можно смело бить болт.JustHarry писал(а):Все это очень важно, но не первостепенно сейчас. Слава богу, получилось хотя бы обеспечить более-менее стабильную работу dll.
Это кому-то нужно? Мы же делаем генератор в первую очередь для того, чтобы хоть как-то облегчить вот эту вот реакцию первых разработчиков рогаликов:должна вычислять границы комнат-переходов, расставлять высоты холмов и прочую информацию, которая уже была вычислена на стадии генерации?
с моим знанием этих странных инструментов от MinGW было бы ровно столько-жеApromix писал(а):Думаешь меньше было бы вот этих странных проблем, если бы либа изначально была бы написана на С?
Код: Выделить всё
extern "C" __declspec(dllimport) void GenMap(int,int,int,char**,int);
typedef _stdcall void (*TGenMap)(int, int, int, char**, int);
TGenMap GenMap1;
int main()
{
GenMap1 = (TGenMap)GenMap; //это явно плохо пахнет
int width = 25;
int height = 25;
char *test = new char[width*height];
for (int i = 0; i < width*height; i++) test[i] = 0;
GenMap1(width,height,3,&test,width*height);
for (int y = 0; y < height; y++)
{
for (int x = 0; x < width; x++)
{
printf("%c", test[x+y*width]);
}
printf("\r\n");
}
delete[] test;
return 0;
}
Код: Выделить всё
LIBRARY BeaRLibMG.dll
EXPORTS
GenMap @1
Забавно, ведь это тот самый метод, с помощью которого "подгружаются" расширения OpenGL. Определяется указатель на функцию, посредством вызова wglGetProcAddress драйвер возвращает адрес функции, он присваивается указателю, вуаля.Jesus05 писал(а)://это явно плохо пахнет
Код: Выделить всё
// BeaRLib.h
#include <windows.h>
#define SOME_MAP_TYPE 3
typedef _stdcall void (*GenMapProc)(int,int,int,char**,int);
GenMapProc GenMap;
void InitializeBeaRLib()
{
HMODULE BeaRLib = LoadLibrary(TEXT("BeaRLibMG.dll"));
GenMap = (GenMapProc)GetProcAddress(BeaRLib, "GenMap");
}
// main.cpp
#include <stdio.h>
#include <stdlib.h>
#include "BeaRLib.h"
int main(int argc, char *argv[])
{
InitializeBeaRLib();
int width = 25, height = 25;
char *test = new char[width*height];
GenMap( width, height, SOME_MAP_TYPE, &test, width*height );
for ( int y=0; y<height; y++ )
{
for ( int x=0; x<width; x++ ) putchar( test[x + y*width] );
printf( "\r\n" );
}
delete[] test;
system( "pause" );
return 0;
}
ты видимо не понял чего я пытался добитсяCfyz писал(а):Забавно, ведь это тот самый метод, с помощью которого "подгружаются" расширения OpenGL. Определяется указатель на функцию, посредством вызова wglGetProcAddress драйвер возвращает адрес функции, он присваивается указателю, вуаля.Jesus05 писал(а)://это явно плохо пахнет
Насколько мне известно, искажение имен используется сборщиком вовсе не просто так, например для различения перегруженных процедур с одинаковыми идентификаторами. Просто проигнорировать наверняка будет неверно. В случае со сгенерированным ручками .def, неверные индексы процедур дадут еще и ошибки в импортированных адресах и неочевидные падения программы.
Имхо здесь два варианта.
1. Забить на name mangling совсем и сделать a la OpenGL вызовы по указателям.
2. Распространять в дистрибутиве .lib для всех популярных компиляторов.
....
И никаких гвоздей .def с .lib, проверено на Dev-C++ 5.0.0.2 (если бы не вы со своим MinGW, я бы еще сто лет не знал, что Dev-C++ к жизни вернулся =) ).
можно реализовать так думаю на любом языке на котором есть вызов ВинАпи функций, а я пытался сделать через lib что-бы загрузкой библиотеки занималась таблица импорта которую создал бы линкер. но мне не удалось ему обьяснить что мне нужна функция которая вызывалась бы как stdcall но которая в библиотеки называется GenMap (по каким-то тампо любому можно писать через LoadLibrary и GetProcAddr с ними все нормально работает
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость