If this is your first visit, be sure to check out the FAQ by clicking the link above. You have to register before you can post.

If you have recently signed up, please make sure you log in so that your activity is registered. This is required for automatic promotions to work and to ensure your account is not deleted during the registration process.

AthenaOfDelphi

Moderation Process Reminder

Since this appears to be a problem, please be aware that some areas of the site are moderated. When you post to these areas, you will be told that your post is awaiting moderation.

You will not be able to see posts that you have made that are waiting to be moderated.

Do not think that because your post has not appeared that an error has occurred. If this happens an error message will be displayed (you should not this and report it in the 'Site News/Feedback' forum.

Steam wrapper, exploring options

I noticed the considerable contributions of Relfos (here) and thecocce (Lazarus forum) to the theme. Their approach requires to build a custom DLL (with Visual Studio) against the current Steamworks SDK, if I'm right. So every time the Steamworks SDK gets updated, someone has to update the custom DLL too, I guess. Perhaps you can stay with a certain SDK version over time. But if you don't have yet any SDK you have to download the current version and rely on an appropriate custom DLL.

Anyway the Steamworks API, although being a C++ construct, provides at least some simple C-functions for init and shut-down (steam_api.h). So in Pascal, after loading the steam_api.dll (win32), you can access those functions without any custom DLL:

I'm using this right now in my own game project. The Steam overlay is showing up and you even can access it. Further you can ensure that the Steam client is running. But all the other common Steam features are not available this way.

Then I stumbled upon the release notes regarding Steamworks SDK v1.32 (February 2015). One note reads as follows:

Added an auto-generated "flat" C-style API for common Steamworks features (steam_api_flat.h).

At this point the exploration begins.

I want to continue in an upcoming post. But feel free already to comment, to correct me or to give some advice regarding the possibilities of using that "flat" C-style API.

Hey, glad about your interest!
Well, this exploration is meant to be a more pragmatic approach. At least for me it's a matter of available time.
I'm not sure at all if it's possible to make use of that steam_api_flat.h. Have to see what can be done ...

Yeah, I was sparing with hints. Let me be more specific about what I have in mind with my pragmatic approach: I want to use just a few Steam features in my game (Steam achievements for example) without translating the whole API. I don't want to install a C environment (Visual Studio e.g.) for this limited purpose. And I want to avoid an additional custom DLL (which requires maintenance).

Thanks for linking the steam_api_flat.h! Nice transition

So, these are the first 10 lines (of nearly 700) of function declarations in steam_api_flat.h:

"Flat" C-style means to me that some C++ classes reveal their public methods.
The first function is SteamAPI_ISteamClient_CreateSteamPipe. I take this as: within the SteamAPI there is a Steam class ISteamClient which has a method CreateSteamPipe().
In C++ one would call it like this: ISteamClient->CreateSteamPipe(). Or in Object Pascal: ISteamClient.CreateSteamPipe().
The return value HSteamPipe seems to be a handle. That's longint to me.
That instancePtr is puzzling for now. Just pointer.

... you get Access Violation, which comes as no surprise.
Let me reveal for now, that Nil has to be replaced by a meaningful value, namely a pointer to ISteamClient, which is the Interface of the SteamClient.

But inside MyMethod implementation, you have access to automatically added variables Result and Self. Result is what received the function result while Self is the class instance from which this method was called:

Code:

var
MyInstance: TMyClass;
b: boolean;
...
b:= MyInstance.MyMethod;

..but where does Self come from?
It's not magic, it's not rocket science. Any class method is in fact a regular procedure/function with one hidden "Self" parameter in its parameter list. Both Pascal and C++, could be boiled to

Code:

function MyClass_MyMethod(Self: TMyClass): boolean;

Edit: virtual methods are the same it's the process of *calling* them that is more tricky.

In this form you can *export* it from, say, your DLL, C-style. I'm sure *lots* of windows API functions that require you first get a handle to object then pass that handle to various other functions, may very well be constructor and class methods in disguise. Because THandle is ptruint, a pointer-sized unsigned integer.
Things like TMyClass are typed pointers as well.

Thanks, Chebmaster! This adds some background knowledge and fits well what I found out in the meantime. That's reassuring.

Ok, all the following was a matter of tedious research and a bit trial-and-error. I knew almost nothing of it when I started this thread, and I wasn't confident:

1. Don't call SteamAPI_ISteamClient_CreateSteamPipe (see my last post). This is already called on the API's initialization. You get that handle from SteamAPI_GetHSteamPipe, which is declared in steam_api.h.

2. You have to connect to the Steam client's interface with SteamInternal_CreateInterface, which is declared in steam_api_internal.h. From this function you get a pointer to that interface, and you have to pass this interface pointer to every function whose name begins with "SteamAPI_ISteamClient_".
By the way, that's what the parameter instancePtr is intended for (see Chebmaster's post above).

3. From the Steam client you get pointers to all the other interfaces. In order to get the pointer to ISteamUtils for example you have to call SteamAPI_ISteamClient_GetISteamUtils.

4. Then you can use the member functions of each interface. And again you have to pass the appropriate interface pointer through that parameter instancePtr.

5. Additional requiremement: If you want to get a pointer to any of the above interfaces (see 2. and 3.), you have to specify the interface's version by passing a string.
The current version string is defined in the header file for each interface.
In isteamclient.h we find this one:

But it's not enough to make use of common Steam features. Most functions have to get data from the Steam server, or they send data to it. This is done asynchronously, and therefor you have to work with callback functions or callback results. There is a C++ template thingy that I have to puzzle out, and of course there are more internal functions involved. Would be to easy otherwise.

Ok, first of all: it is possible to make use of Steam's callback mechanism.

The tricky thing is that you have to pass a C++ class as an argument. So you have to mimic this class by the means of Pascal. This requires defining a record for example and arranging it's internals. It needs a tabel of virtual functions and some parameters. Also you have to mimic the calling convention thiscall which requires to read out the ECX register by an inline asm instruction. Fortunately that C++ class is not too big.

Moreover I found an old discussion on Steam dev forums where two guys worked out that stuff, one of them Relfos.

It appears in Relfos' unit SteamCallback.pas (Object Pascal) and although his whole project is based on Steamworks.NET (CSteamworks.DLL) that callback handling part doesn't really need that, unless I am mistaken.

As for myself I don't use classes in my implementation. By now I'm using the callback mechanism only for one thing: every time the player activates/deactivates the Steam overlay (Shift+Tab) I pause/unpause the game. Some questions remain regarding the handling of calling conventions on CPU64 and/or Linux etc.
Now I should be able to use common Steam features (achievements, leaderboard, save files to cloud etc.) We'll see about that.

If anyone wants to see plain Pascal code then I can provide another listing. Otherwise I'm pointing to Relfos' unit.