Attempting to make SDL wrapper for QB64 - First hurdle!

SDL Development
1

I have Google’d myself silly trying to figure this out! Any ideas on what i might be doing wrong?

I am attemtping to make a dll that will provide access to functions for QB64 that it cannot currently access. Here’s my first function. It does not work!

Code:
SDL_LINK_API int SDL_Link_NumJoys(void)
{
if(SDL_Init(SDL_INIT_JOYSTICK)== -1)
{
return -1;
}
else
{
return SDL_NumJoysticks;
}
}

It returns error C2440: ‘return’ : cannot convert from ‘int (__cdecl *)(void)’ to ‘int’

I am using VC++2008, any help would be great. Thanks folks.

John

2

hey there,
I’m happy to see that QB64 has some progress being made on it (I use
freebasic, but I always keep track of QB64)
Anyway, there are a few issues with your code that I’m not sure they will
fix your error, but will help in the long run.

First, use SDL_WasInit() to check to see if SDL_INIT_JOYSTICK was
initialized/available.

Next, make sure you’re returning the result of the function and not the
address of the function.
void *address = &SDL_NumJoysticks;
int result = SDL_NumJoysticks();

I think the lack of braces is probably what’s throwing your code off.On Mon, Dec 6, 2010 at 4:24 PM, Unseen Machine wrote:

I have Google’d myself silly trying to figure this out! Any ideas on what
i might be doing wrong?

I am attemtping to make a dll that will provide access to functions for
QB64 that it cannot currently access. Here’s my first function. It does not
work!

Code:

SDL_LINK_API int SDL_Link_NumJoys(void)
{
if(SDL_Init(SDL_INIT_JOYSTICK)== -1)
{
return -1;
}
else
{
return SDL_NumJoysticks;
}
}

It returns error C2440: ‘return’ : cannot convert from ‘int (__cdecl
*)(void)’ to ‘int’

I am using VC++2008, any help would be great. Thanks folks.

John

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

3

Oh, I should mention that it looks like SDL_LINK_API is trying to set the
return value type to void.

Take care,
-OzOn Mon, Dec 6, 2010 at 4:30 PM, Alex Barry <@Alex_Barry> wrote:

hey there,
I’m happy to see that QB64 has some progress being made on it (I use
freebasic, but I always keep track of QB64)
Anyway, there are a few issues with your code that I’m not sure they will
fix your error, but will help in the long run.

First, use SDL_WasInit() to check to see if SDL_INIT_JOYSTICK was
initialized/available.

Next, make sure you’re returning the result of the function and not the
address of the function.
void *address = &SDL_NumJoysticks;
int result = SDL_NumJoysticks();

I think the lack of braces is probably what’s throwing your code off.

On Mon, Dec 6, 2010 at 4:24 PM, Unseen Machine wrote:

I have Google’d myself silly trying to figure this out! Any ideas on
what i might be doing wrong?

I am attemtping to make a dll that will provide access to functions for
QB64 that it cannot currently access. Here’s my first function. It does not
work!

Code:

SDL_LINK_API int SDL_Link_NumJoys(void)
{
if(SDL_Init(SDL_INIT_JOYSTICK)== -1)
{
return -1;
}
else
{
return SDL_NumJoysticks;
}
}

It returns error C2440: ‘return’ : cannot convert from ‘int (__cdecl
*)(void)’ to ‘int’

I am using VC++2008, any help would be great. Thanks folks.

John

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4

But i have just managed to create new errors! LOL!!

QB64 really has moved on, i have made a 2d game engine in it, thats why i after the joystick first!

Here is my header file and .cpp file

the new errors are the same as each other, the braces seemd to solve the other problem,

1>SDL_Link.obj : error LNK2019: unresolved external symbol _SDL_NumJoysticks referenced in function _SDL_Link_NumJoys

Code:
#ifdef SDL_LINK_EXPORTS
#define SDL_LINK_API __declspec(dllexport)
#else
#define SDL_LINK_API __declspec(dllimport)
#endif

// This class is exported from the SDL_Link.dll
class SDL_LINK_API CSDL_Link {
public:
CSDL_Link(void);
// TODO: add your methods here.
};

extern “C” SDL_LINK_API int SDL_Link_NumJoys(void);

SDL_LINK_API int fnSDL_Link(void);

Code:
// SDL_Link.cpp : Defines the exported functions for the DLL application.
//

#include “stdafx.h”
#include “SDL_Link.h”
#include “SDL.h”

SDL_LINK_API int SDL_Link_NumJoys(void)
{
if(SDL_WasInit(SDL_INIT_JOYSTICK)== -1)
{
return -1;
}
else
{
return SDL_NumJoysticks();

}

}

// This is the constructor of a class that has been exported.
// see SDL_Link.h for the class definition
CSDL_Link::CSDL_Link()
{
return;
}

5

Try compiling without the SDL_LINK_API macro. It will almost certainly get
rid of the errors, but it may not link properly. Just out of curiosity, are
you actually compiling a dynamic library, or just a module?On Mon, Dec 6, 2010 at 5:10 PM, Unseen Machine wrote:

But i have just managed to create new errors! LOL!!

QB64 really has moved on, i have made a 2d game engine in it, thats why i
after the joystick first!

Here is my header file and .cpp file

the new errors are the same as each other, the braces seemd to solve the
other problem,

1>SDL_Link.obj : error LNK2019: unresolved external symbol
_SDL_NumJoysticks referenced in function _SDL_Link_NumJoys

Code:

#ifdef SDL_LINK_EXPORTS
#define SDL_LINK_API __declspec(dllexport)
#else
#define SDL_LINK_API __declspec(dllimport)
#endif

// This class is exported from the SDL_Link.dll
class SDL_LINK_API CSDL_Link {
public:
CSDL_Link(void);
// TODO: add your methods here.
};

extern “C” SDL_LINK_API int SDL_Link_NumJoys(void);

SDL_LINK_API int fnSDL_Link(void);

Code:

// SDL_Link.cpp : Defines the exported functions for the DLL application.
//

#include “stdafx.h”
#include “SDL_Link.h”
#include “SDL.h”

SDL_LINK_API int SDL_Link_NumJoys(void)
{
if(SDL_WasInit(SDL_INIT_JOYSTICK)== -1)
{
return -1;
}
else
{
return SDL_NumJoysticks();

}
}

// This is the constructor of a class that has been exported.
// see SDL_Link.h for the class definition
CSDL_Link::CSDL_Link()
{
return;
}

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

6

What makes it dynamic?

I really just want to be able to access the functions with my own calls.

Thanks, John

7

Ummm…ya, just get rid of those SDL_LINK_API parts.On Mon, Dec 6, 2010 at 8:16 PM, Unseen Machine wrote:

What makes it dynamic?

I really just want to be able to access the functions with my own calls.

Thanks, John

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

8

I have a question - if you’re making a program in QB64, why are you
programming in C++? I thought SDL already had headers for QB64, but maybe
I’m wrong.
On another note, did that fix the problem?

-OzOn Mon, Dec 6, 2010 at 8:33 PM, Alex Barry <@Alex_Barry> wrote:

Ummm…ya, just get rid of those SDL_LINK_API parts.

On Mon, Dec 6, 2010 at 8:16 PM, Unseen Machine wrote:

What makes it dynamic?

I really just want to be able to access the functions with my own calls.

Thanks, John

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

9

No fixy the problem Mister!! And for some reason I cannot even make a dll in VC++ that will run in QB64!! Not even the default one M$ drop into the template.

Does anyone have a really simple DLL that i can both test it on and learn from?. It can only return a Long or a Float though!

Thanks

John

10

Well, my first note is this: it will be easier to make a SDL wrapper in C
than it will be in C++ (since how you are making the function doesn’t really
follow a class setup).
If you let me know exactly what you’re doing, I should be able to help you
out a bit more.

Take care,
-OzOn Tue, Dec 7, 2010 at 10:31 AM, Unseen Machine wrote:

No fixy the problem Mister!! And for some reason I cannot even make a dll
in VC++ that will run in QB64!! Not even the default one M$ drop into the
template.

Does anyone have a really simple DLL that i can both test it on and learn
from?. It can only return a Long or a Float though!

Thanks

John

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

11

I dont have C, would codeblocks do it? I have that on disc.

I am just trying to learn really and, as qb cant handle pointers (YET) we need to find a new way of getting data back to the QB user. This is probally a pipe dream but it would be nice to know exactly how to make simple dll’s so that when QB does support dll’s properly, i know what i am doing.

Any tips would be great. Many thanks,

John

12

If QB64 can’t handle pointers, then I don’t think there is really any way
that you can port SDL (which almost exclusively uses pointers for it’s data
types).
I’ll chat with Galleon to see where he’s at for implementing pointers (which
probably should have been done at QB64’s first launch!).
I’ll let you know what I find out and I’ll get back to you.
-OzOn Tue, Dec 7, 2010 at 11:05 AM, Unseen Machine wrote:

I dont have C, would codeblocks do it? I have that on disc.

I am just trying to learn really and, as qb cant handle pointers (YET) we
need to find a new way of getting data back to the QB user. This is probally
a pipe dream but it would be nice to know exactly how to make simple dll’s
so that when QB does support dll’s properly, i know what i am doing.

Any tips would be great. Many thanks,

John

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

13

If QB64 can’t handle pointers, then I don’t think there is really any way
that you can port SDL (which almost exclusively uses pointers for it’s data
types).

Uhm… There are several languages without pointers (including my own EEL)
that have SDL bindings - and this often comes with additional bonuses such as
automatic memory management and a nicer, safer API than the C version.

What you do is just wrap the “API objects” in whatever way makes most sense in
the language at hand. In EEL, I wrap them up as “objects” (memory managed
entities with an interface based on a fixed set of methods), which are then
handled by means of opaque references. That is, essentially pointers to
wrapper objects, but all wrapped up and “fool proof”. Most VM based scripting
languages, and many others, would support this model, I think.

For a language that doesn’t support “native” objects or custom types AT ALL,
there is a salution that is actually pretty common in native C APIs: integer
handles - or as OpenGL (among others) calls them: “names.” You can implement
some variant of this even if you have only a single data type, be it strings,
integers, real numbers, “bignums” or whatever.

I’ll chat with Galleon to see where he’s at for implementing pointers
(which probably should have been done at QB64’s first launch!).
I’ll let you know what I find out and I’ll get back to you.

If you have a language that is already getting by just fine without pointers,
why open up that massive, evil can of worms at all? In a high level language,
pointers don’t really solve anything that cannot be handled much better with
other constructs.

Well, either way, that’s pretty off topic for this list, anyway. :-)On Tuesday 07 December 2010, at 17.22.24, Alex Barry <alex.barry at gmail.com> wrote:

–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

14

Pointers has actually been on the dev’s todo list since 2007. I suppose a
wrapper can be made, and I’ll talk to Galleon about that, too.
@Unseen Machine: As David suggested, you could probably use arrays of
pointers in c/c++ and the interface just does basic lookups.

Take care,
-OzOn Tue, Dec 7, 2010 at 2:41 PM, David Olofson wrote:

On Tuesday 07 December 2010, at 17.22.24, Alex Barry < @Alex_Barry> wrote:

If QB64 can’t handle pointers, then I don’t think there is really any way

that you can port SDL (which almost exclusively uses pointers for it’s
data

types).

Uhm… There are several languages without pointers (including my own EEL)
that have SDL bindings - and this often comes with additional bonuses such
as automatic memory management and a nicer, safer API than the C version.

What you do is just wrap the “API objects” in whatever way makes most sense
in the language at hand. In EEL, I wrap them up as “objects” (memory managed
entities with an interface based on a fixed set of methods), which are then
handled by means of opaque references. That is, essentially pointers to
wrapper objects, but all wrapped up and “fool proof”. Most VM based
scripting languages, and many others, would support this model, I think.

For a language that doesn’t support “native” objects or custom types AT
ALL, there is a salution that is actually pretty common in native C APIs:
integer handles - or as OpenGL (among others) calls them: “names.” You can
implement some variant of this even if you have only a single data type, be
it strings, integers, real numbers, “bignums” or whatever.

I’ll chat with Galleon to see where he’s at for implementing pointers

(which probably should have been done at QB64’s first launch!).

I’ll let you know what I find out and I’ll get back to you.

If you have a language that is already getting by just fine without
pointers, why open up that massive, evil can of worms at all? In a high
level language, pointers don’t really solve anything that cannot be handled
much better with other constructs.

Well, either way, that’s pretty off topic for this list, anyway. :slight_smile:

–

//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.

| http://consulting.olofson.net http://olofsonarcade.com |

‘---------------------------------------------------------------------’

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

15

Every language uses pointers, they just don’t necessarily call them pointers.

JeffOn Tuesday 07 December 2010 11:41, David Olofson wrote:

If you have a language that is already getting by just fine without
pointers, why open up that massive, evil can of worms at all? In a high
level language, pointers don’t really solve anything that cannot be handled
much better with other constructs.

16

Right, but the physical use of pointers to implement certain constructs is
just a language implementation detail. I don’t see how that is relevant unless
the language actually allows you to mess with the pointers, C style.

Since any usable BASIC dialect has strings, arrays, functions and whatnot, and
people are still saying QB64 doesn’t have pointers, I assume their definition
of “pointer” is something like this:

http://en.wikipedia.org/wiki/Pointer_%28computing%29On Tuesday 07 December 2010, at 21.04.00, Jeff Post <j_post at pacbell.net>  wrote:

On Tuesday 07 December 2010 11:41, David Olofson wrote:

If you have a language that is already getting by just fine without
pointers, why open up that massive, evil can of worms at all? In a high
level language, pointers don’t really solve anything that cannot be
handled much better with other constructs.

Every language uses pointers, they just don’t necessarily call them
pointers.

–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

17

I sort of ran out of time, but here is a good start to an SDL wrapper for
QB64:
http://pastebin.com/PsAyVBgG

Let us know if you need more help,
-AlexOn Tue, Dec 7, 2010 at 4:07 PM, David Olofson wrote:

On Tuesday 07 December 2010, at 21.04.00, Jeff Post <j_post at pacbell.net> wrote:

On Tuesday 07 December 2010 11:41, David Olofson wrote:

If you have a language that is already getting by just fine without

pointers, why open up that massive, evil can of worms at all? In a high

level language, pointers don’t really solve anything that cannot be

handled much better with other constructs.

Every language uses pointers, they just don’t necessarily call them

pointers.

Right, but the physical use of pointers to implement certain constructs is
just a language implementation detail. I don’t see how that is relevant
unless the language actually allows you to mess with the pointers, C style.

Since any usable BASIC dialect has strings, arrays, functions and whatnot,
and people are still saying QB64 doesn’t have pointers, I assume their
definition of “pointer” is something like this:

http://en.wikipedia.org/wiki/Pointer_(computing)

–

//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.

| http://consulting.olofson.net http://olofsonarcade.com |

‘---------------------------------------------------------------------’

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

18

Like 90% went straight over my head, but i will look at it more. I posted it on QB64.net, hope you dont mind. MANY MANY MANY thanks though!!! Thats awesome!!!

19

I must be dumb as i cant make head nore tail of the help files and have googled by fingers sore, so i finally gave in and came here.

Still working with QB64 (pointer support and more has been added by Galleon) so accessing SDL is now a lot easier than when i first posted. I have this code in a lib which reports when a window resize event has occured.

Code:

int GDK_CheckResize(void)
{
SDL_Event event;
while(SDL_PollEvent(&event))
{
switch(event.type)
{
case SDL_VIDEORESIZE:
return(-1);
break;
default:
return(0);
break;
}
}
}

It Works as it should. What i need to do know is make 2 new functions that return the new width and height values of the resized window. I dont know how to do this. Is it possible??

Any ideas would be great, thanks folks.

John

20

Could you make this function do all three? ?I don’t know much about
QB, but you could have this instead:

int GDK_CheckResize(int* width, int* height);

The function would set ‘width’ and ‘height’ to the members in
SDL_ResizeEvent if they’re not NULL.

For reference:

typedef struct{
Uint8 type;
int w, h;
} SDL_ResizeEvent;

So, the width is event.resize.w

Jonny DOn Fri, Jan 14, 2011 at 11:18 AM, Unseen Machine wrote:

I must be dumb as i cant make head nore tail of the help files and have googled by fingers sore, so i finally gave in and came here.

Still working with QB64 (pointer support and more has been added by Galleon) so accessing SDL is now a lot easier than when i first posted. I have this code in a lib which reports when a window resize event has occured.

Code:

int GDK_CheckResize(void)
{
? SDL_Event event;
? while(SDL_PollEvent(&event))
? {
? ? switch(event.type)
? ? {
? ? ? case SDL_VIDEORESIZE:
? ?return(-1);
? ?break;
? ? ? default:
? ?return(0);
? ?break;
? ? }
? }
}

It Works as it should. What i need to do know is make 2 new functions that return the new width and height values of the resized window. I dont know how to do this. Is it possible??

Any ideas would be great, thanks folks.

John

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org